Junos OS Routing Protocols Configuration Guide - Juniper.net

Junos® OS Routing Protocols Configuration Guide

Release

11.4

Published: 2011-11-08

Copyright © 2011, Juniper Networks, Inc.

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

®

Junos OS Routing Protocols Configuration Guide Release 11.4 Copyright © 2011, Juniper Networks, Inc. All rights reserved. Revision History October 2011—R1 Junos OS 11.4 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. 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 The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at

http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions of that EULA.

ii


Abbreviated Table of Contents About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii

Part 1

Overview

Chapter 1

Routing Protocols Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2

Complete Routing and Routing Protocol Configuration Statements . . . . . . 17

Part 2

Protocol-Independent Routing Properties

Chapter 3

Protocol-Independent Routing Properties Overview . . . . . . . . . . . . . . . . . . . 49

Chapter 4

Configuring Routing Tables and Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 5

Configuring Other Protocol-Independent Routing Properties . . . . . . . . . . . 119

Chapter 6

Summary of Protocol-Independent Routing Properties Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Part 3

Routing Instances

Chapter 7

Introduction to Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Chapter 8

Routing Instances Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 239

Chapter 9

Summary of Routing Instances Configuration Statements . . . . . . . . . . . . 291

Part 4

Multitopology Routing

Chapter 10

Introduction to Multitopology Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Chapter 11

Multitopology Routing Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . 313

Chapter 12

Summary of Multitopology Routing Configuration Statements . . . . . . . . 325

Part 5

Interior Gateway Protocols

Chapter 13

Introduction to IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Chapter 14

IS-IS Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

Chapter 15

Summary of IS-IS Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . 433

Chapter 16

Introduction to OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

Chapter 17

OSPF Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Chapter 18

Summary of OSPF Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . 749

Chapter 19

Introduction to RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835

Chapter 20

RIP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839

Chapter 21

Summary of RIP Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . 867

Chapter 22

Introduction to RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893


iii

Junos OS 11.4 Routing Protocols Configuration Guide

Chapter 23

RIPng Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895

Chapter 24

Summary of RIPng Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . 905

Chapter 25

Introduction to ICMP Router Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921

Chapter 26

ICMP Router Discovery Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . 923

Chapter 27

Summary of ICMP Router Discovery Configuration Statements . . . . . . . . 927

Chapter 28

Introduction to Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939

Chapter 29

Neighbor Discovery Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 941

Chapter 30

Summary of Neighbor Discovery Router Advertisement Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949

Chapter 31

Secure Neighbor Discovery Configuration Guidelines . . . . . . . . . . . . . . . . . 961

Chapter 32

Summary of Secure Neighbor Discovery Configuration Statements . . . . 965

Part 6

BGP

Chapter 33

Introduction to BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975

Chapter 34

BGP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981

Chapter 35

Summary of BGP Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . 1293

Part 7

Indexes Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395 Index of Statements and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423

iv


Table of Contents About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii Junos OS Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii Using the Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxix Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxix Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxix Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xl Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xl Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xlii Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xlii Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xliii Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xliii

Part 1

Overview

Chapter 1

Routing Protocols Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Routing Databases Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Routing Protocol Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Junos Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Forwarding Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 How the Routing and Forwarding Tables Are Synchronized . . . . . . . . . . . . . . . 5 Route Preferences Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Alternate and Tiebreaker Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Multiple Active Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Understanding BGP Path Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Understanding Route Preference Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Equal-Cost Paths and Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 IPv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 IPv6 Packet Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Header Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Extension Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Address Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Address Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Address Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 IPv6 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15


v


Chapter 2

Complete Routing and Routing Protocol Configuration Statements . . . . . . 17 [edit logical-systems] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 [edit protocols] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 [edit routing-instances] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 [edit routing-options] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Part 2


Chapter 3

Protocol-Independent Routing Properties Overview . . . . . . . . . . . . . . . . . . . 49 [edit routing-options] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Common Routing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Complete [edit routing-options] Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Minimum Protocol-Independent Routing Properties Configuration . . . . . . . . . . . 57

Chapter 4

Configuring Routing Tables and Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Creating Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Example: Creating Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Configuring Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Configuring the Destination of Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Configuring the Next Hop for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Configuring an Independent Preference for Static Routes . . . . . . . . . . . . . . . . . . . 64 Example: Configuring Independent Preferences for an IPv4 Static Route . . . 66 Example: Configuring Independent Preferences for an IPv6 Static Route . . . 66 Example: Configuring Independent Preferences for an Unnumbered Ethernet Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Specifying an LSP as the Next Hop for Static Routes . . . . . . . . . . . . . . . . . . . . . . 68 Installing Static Routes into More than One Routing Table . . . . . . . . . . . . . . . . . . 69 Examples: Installing a Static Route into More than One Routing Table . . . . . 69 Configuring CLNS Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Example: Configuring a Static CLNS Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Configuring Static Route Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Configuring a Metric Value for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Configuring a Preference Value for Static Routes . . . . . . . . . . . . . . . . . . . . . . 74 Associating BGP Communities with Static Routes . . . . . . . . . . . . . . . . . . . . . 75 Associating AS Paths with Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Configuring an OSPF Tag String for Static Routes . . . . . . . . . . . . . . . . . . . . . . 77 Controlling Temporary Installation of Static Routes in the Forwarding Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Controlling Retention of Static Routes in the Forwarding Table . . . . . . . . . . . 78 Controlling Retention of Inactive Static Routes in the Routing and Forwarding Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Controlling Readvertisement of Static Routes . . . . . . . . . . . . . . . . . . . . . . . . 80 Controlling Resolution of Static Routes to Prefixes That Are Not Directly Connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Configuring Bidirectional Forwarding Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Tracing BFD Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Overview of BFD Authentication for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . 87 BFD Authentication Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Security Authentication Keychains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

vi


Table of Contents

Strict Versus Loose Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Configuring BFD Authentication for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . 89 Configuring the BFD Authentication Parameters . . . . . . . . . . . . . . . . . . . . . . 89 Viewing Authentication Information for BFD Sessions . . . . . . . . . . . . . . . . . . 91 Configuring Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Propagating Static Routes into Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 93 Examples: Configuring Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Configuring Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Configuring the Destination of Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Configuring Aggregate Route Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Configuring a Metric Value for Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . 98 Configuring a Preference Value for Aggregate Routes . . . . . . . . . . . . . . . . . . 98 Configuring the Next Hop for Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . 98 Associating BGP Communities with Aggregate Routes . . . . . . . . . . . . . . . . . 99 Associating AS Paths with Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . 100 Including AS Numbers in Aggregate Route Paths . . . . . . . . . . . . . . . . . . . . . . 101 Configuring an OSPF Tag String for Aggregate Routes . . . . . . . . . . . . . . . . . . 101 Controlling Retention of Inactive Aggregate Routes in the Routing and Forwarding Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Applying Policies to Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Advertising Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Configuring Generated Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Configuring the Destination of Generated Routes . . . . . . . . . . . . . . . . . . . . . . . . 105 Configuring Generated Route Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Configuring a Metric Value for Generated Routes . . . . . . . . . . . . . . . . . . . . . 106 Configuring a Preference Value for Generated Routes . . . . . . . . . . . . . . . . . 106 Configuring the Next Hop for Generated Routes . . . . . . . . . . . . . . . . . . . . . . 106 Associating BGP Communities with Generated Routes . . . . . . . . . . . . . . . . . 107 Associating AS Paths with Generated Routes . . . . . . . . . . . . . . . . . . . . . . . . 108 Configuring an OSPF Tag String for Generated Routes . . . . . . . . . . . . . . . . . 109 Including AS Numbers in Generated Route Paths . . . . . . . . . . . . . . . . . . . . . 109 Controlling Retention of Inactive Generated Routes in the Routing and Forwarding Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Applying Policies to Generated Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Configuring Martian Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Adding Martian Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Deleting Martian Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Using Class E Addresses for Interface Addresses . . . . . . . . . . . . . . . . . . . . . . 113 Configuring Flow Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Configuring Match Conditions for Flow Routes . . . . . . . . . . . . . . . . . . . . . . . . 114 Configuring the Action for Flow Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Validating Flow Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Enabling Support for BGP Flow-Specification Algorithm Version 7 and Later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Applying Filters to the Forwarding Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118


vii


Chapter 5

Configuring Other Protocol-Independent Routing Properties . . . . . . . . . . . 119 Configuring AS Numbers for BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Examples: Configuring AS Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Configuring Router Identifiers for BGP and OSPF . . . . . . . . . . . . . . . . . . . . . . . . . 122 Configuring AS Confederation Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Configuring Route Recording for Flow Aggregation . . . . . . . . . . . . . . . . . . . . . . . . 123 Creating Routing Table Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Examples: Creating Routing Table Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Configuring How Interface Routes Are Imported into Routing Tables . . . . . . . . . 125 Configuring Multicast Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Example: Configuring Multicast Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Enabling Multicast Forwarding Without PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Configuring Additional Source-Specific Multicast Groups . . . . . . . . . . . . . . . . . . 127 Configuring Multicast Forwarding Cache Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Configuring Per-Packet Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Examples: Configuring Per-Packet Load Balancing . . . . . . . . . . . . . . . . . . . . 130 Configuring Unicast Reverse-Path-Forwarding Check . . . . . . . . . . . . . . . . . . . . . . 131 Example: Configuring Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Configuring Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Configuring Route Distinguishers for VRF and Layer 2 VPN Instances . . . . . . . . . 133 Configuring Dynamic GRE Tunnels for VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Configuring System Logging for the Routing Protocol Process . . . . . . . . . . . . . . . 135 Examples: Configuring System Logging for the Routing Protocol Process . . 135 Configuring Route Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Enabling Indirect Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Enabling Nonstop Active Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Tracing Global Routing Protocol Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Examples: Tracing Global Routing Protocol Operations . . . . . . . . . . . . . . . . 139 Disabling Distributed Periodic Packet Management on the Packet Forwarding Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Enabling Source Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Creating Policies to Control Label Allocation and Substitution for MPLS Ingress and AS Border Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Chapter 6

Summary of Protocol-Independent Routing Properties Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 access-internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 aggregate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 as-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 auto-export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 autonomous-system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 bfd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 bfd-liveness-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 confederation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

viii


Table of Contents

destination-networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 discard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 dynamic-tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 export-rib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 fate-sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 forwarding-cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 forwarding-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 generate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 graceful-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 import-policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 import-rib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 independent-domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 indirect-next-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 instance-export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 instance-import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 interface (Multicast via Static Routes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 interface (Multicast Scoping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 interface-routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 lsp-next-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 martians . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 maximum-paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 maximum-prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 med-igp-update-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 metric (Aggregate, Generated, or Static Route) . . . . . . . . . . . . . . . . . . . . . . . 192 metric (Qualified Next Hop on Static Route) . . . . . . . . . . . . . . . . . . . . . . . . . 193 multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 next-hop (Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 next-hop (Access Internal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 no-install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 no-readvertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 no-retain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 nonstop-routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 p2mp-lsp-next-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 passive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 ppm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201


ix


preference (Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 qualified-next-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 qualified-next-hop (Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 qualified-next-hop (Access-Internal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 readvertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 resolution-ribs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 resolve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 restart-duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 retain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 rib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 rib (General) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 rib (Route Resolution) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 rib-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 rib-groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 route (Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 route (Access-Internal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 route-distinguisher-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 route-record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 router-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 routing-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 source-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 source-routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 ssm-groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 static . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 tag (Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 tunnel-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 unicast-reverse-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Part 3

Routing Instances

Chapter 7

Introduction to Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Routing Instances Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Chapter 8

Routing Instances Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 239 Complete Routing Instances Configuration Statements . . . . . . . . . . . . . . . . . . . 240 Routing Instances Minimum Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Minimum Routing-Instance Configuration for BGP . . . . . . . . . . . . . . . . . . . . 244 Minimum Routing-Instance Configuration for IS-IS . . . . . . . . . . . . . . . . . . . 245 Minimum Routing-Instance Configuration for Layer 2 VPNs . . . . . . . . . . . . 245 Minimum Routing-Instance Configuration for LDP . . . . . . . . . . . . . . . . . . . . 246 Minimum Routing-Instance Configuration for MSDP . . . . . . . . . . . . . . . . . . 246 Minimum Routing-Instance Configuration for Multiprotocol BGP-Based Multicast VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Minimum Routing-Instance Configuration for OSPF . . . . . . . . . . . . . . . . . . . 247

x


Table of Contents

Minimum Routing-Instance Configuration for OSPFv3 . . . . . . . . . . . . . . . . . 248 Minimum Routing-Instance Configuration for PIM . . . . . . . . . . . . . . . . . . . . 248 Minimum Routing-Instance Configuration for RIP . . . . . . . . . . . . . . . . . . . . 249 Minimum Routing-Instance Configuration for VPLS . . . . . . . . . . . . . . . . . . . 249 Configuring Multiple Instances of BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Example: Configuring Multiple Instances of BGP . . . . . . . . . . . . . . . . . . . . . 250 Configuring Multiple Instances of IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Example: Configuring Multiple Routing Instances of IS-IS . . . . . . . . . . . . . . 252 Configuring Multiple Instances of LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Configuring Multiple Instances of MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Example: Configuring Multiple Routing Instances of OSPF . . . . . . . . . . . . . . . . . 256 Configuring Multiple Instances of PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Configuring Multiple Instances of RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Configuring Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Specifying the Instance Type for Routing Instances . . . . . . . . . . . . . . . . . . . . . . 266 Configuring VRF Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Configuring Non-VPN VRF Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . 268 Configuring VPLS Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Configuring Route Distinguishers for Routing Instances . . . . . . . . . . . . . . . . . . . 269 Configuring Filter-Based Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Configuring Class-of-Service-Based Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 272 Configuring Secondary VRF Import and Export Policy . . . . . . . . . . . . . . . . . . . . . 273 Configuring Policy-Based Export for Routing Instances . . . . . . . . . . . . . . . . . . . . 274 Example: Configuring Policy-Based Export for an Overlapping VPN . . . . . . 274 Example: Configuring Policy-Based Export for a Nonforwarding Instance . . 276 Example: Exporting Specific Routes from One Routing Table Into Another Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Configuring VRF Table Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Configuring VRF Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Configuring OSPF Domain IDs for VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Examples: Configuring an OSPF Domain ID . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Configuring Route Limits for Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Configuring Independent AS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Chapter 9

Summary of Routing Instances Configuration Statements . . . . . . . . . . . . 291 access-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 instance-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 instance-role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 no-vrf-advertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 ping-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 qualified-bum-pruning-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 route-distinguisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 routing-instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 routing-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 vrf-export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 vrf-import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303


xi


vlan-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 vrf-table-label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 vrf-target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Part 4


Chapter 10

Introduction to Multitopology Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Multitopology Routing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Routing Table Naming Conventions for Multitopology Routing . . . . . . . . . . 309 Routing Protocol Support for Multitopology Routing . . . . . . . . . . . . . . . . . . . 310 Filter-Based Forwarding Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Multitopology Routing Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Chapter 11

Multitopology Routing Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . 313 Configuring Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Configuring Multitopology Routing in OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Configuring Topologies and SPF Options for MT-OSPF . . . . . . . . . . . . . . . . 314 Configuring a Prefix Export Limit for MT-OSPF . . . . . . . . . . . . . . . . . . . . . . . 316 Configuring a Topology to Appear Overloaded . . . . . . . . . . . . . . . . . . . . . . . 316 Configuring Interface Properties for MT-OSPF . . . . . . . . . . . . . . . . . . . . . . . 316 Disabling MT-OSPF on OSPF Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Disabling MT-OSPF on Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Advertising MPLS Label-Switched Paths into MT-OSPF . . . . . . . . . . . . . . . 318 Configuring Other MT-OSPF Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Configuring Multitopology Routing in Static Routes . . . . . . . . . . . . . . . . . . . . . . . 320 Configuring Multitopology Routing in BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 BGP Route Resolution in Multitopology Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Configuring Filter-Based Forwarding for Multitopology Routing . . . . . . . . . . . . . . 321

Chapter 12

Summary of Multitopology Routing Configuration Statements . . . . . . . . 325 community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 rib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 topology (Filter-Based Forwarding) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 topology (Multitopology Routing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 topology (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 topology (OSPF Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 topology-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Part 5


Chapter 13

Introduction to IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 IS-IS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 IS-IS Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 ISO Network Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 IS-IS Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Persistent Route Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 IS-IS Extensions to Support Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . 339 IS-IS IGP Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

xii


Table of Contents

IS-IS Extensions to Support Route Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 IS-IS Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Chapter 14

IS-IS Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Configuring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Minimum IS-IS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Configuring IS-IS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Hitless Authentication Key Rollover for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Overview of Hitless Authentication Key Rollover for IS-IS . . . . . . . . . . . . . . 349 Example: Configuring Hitless Authentication Key Rollover for IS-IS . . . . . . 350 Configuring of Interface-Specific IS-IS Properties . . . . . . . . . . . . . . . . . . . . . . . . 355 Configuring BFD for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Overview of Configuring BFD for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Example: Configuring BFD for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Overview of BFD Authentication for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 BFD Authentication Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Security Authentication Keychains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Strict Versus Loose Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Configuring BFD Authentication for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Configuring BFD Authentication Parameters . . . . . . . . . . . . . . . . . . . . . . . . 366 Viewing Authentication Information for BFD Sessions . . . . . . . . . . . . . . . . . 367 Enabling Packet Checksum on IS-IS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Configuring the Transmission Frequency for CSNP Packets on IS-IS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Configuring Synchronization Between LDP and IS-IS . . . . . . . . . . . . . . . . . . . . . 369 Configuring the Transmission Frequency for Link-State PDUs on IS-IS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Configuring Mesh Groups of IS-IS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Configuring IS-IS Multicast Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 IS-IS Multicast Topologies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Example: Configuring IS-IS Multicast Topology . . . . . . . . . . . . . . . . . . . . . . . 372 Configuring IS-IS IPv6 Unicast Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Configuring Point-to-Point Interfaces for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Configuring Levels on IS-IS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Disabling IS-IS at a Level on IS-IS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 389 Example: Disabling IS-IS at a Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Advertising Interface Addresses Without Running IS-IS . . . . . . . . . . . . . . . . 389 Configuring Authentication for IS-IS Hello Packets . . . . . . . . . . . . . . . . . . . 390 Configuring the Transmission Frequency for IS-IS Hello Packets . . . . . . . . 390 Configuring the Delay Before IS-IS Neighbors Mark the Routing Device as Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Configuring the Metric Value for IS-IS Routes . . . . . . . . . . . . . . . . . . . . . . . . 391 Configuring the IS-IS Metric Value Used for Traffic Engineering . . . . . . . . . . 391 Configuring the Designated Router Priority for IS-IS . . . . . . . . . . . . . . . . . . . 391 Advertising Interface Addresses Without Running IS-IS . . . . . . . . . . . . . . . . 392 Configuring the Reference Bandwidth Used in IS-IS Metric Calculations . . . . . . 392 Limiting the Number of Advertised IS-IS Areas . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Enabling Wide IS-IS Metrics for Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . 393 Configuring Preference Values for IS-IS Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 393


xiii


Limiting the Number of Prefixes Exported to IS-IS . . . . . . . . . . . . . . . . . . . . . . . . 394 Configuring Link-State PDU Lifetime for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Advertising Label-Switched Paths into IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Configuring IS-IS to Make Routing Devices Appear Overloaded . . . . . . . . . . . . . 395 Configuring SPF Options for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Configuring Graceful Restart for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 Configuring IS-IS for Multipoint Network Clouds . . . . . . . . . . . . . . . . . . . . . . . . . 398 Configuring IS-IS Traffic Engineering Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Configuring IS-IS to Use IGP Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Configuring IS-IS to Ignore the Metric of RSVP Label-Switched Paths . . . . 399 Disabling IS-IS Support for Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . 400 Installing IPv4 Routes into the Multicast Routing Table . . . . . . . . . . . . . . . . 400 Configuring IS-IS to Use Protocol Preference to Determine the Traffic Engineering Database Credibility Value . . . . . . . . . . . . . . . . . . . . . . . . . 400 Enabling Authentication for IS-IS Without Network-Wide Deployment . . . . . . . 401 Configuring Quicker Advertisement of IS-IS Adjacency State Changes . . . . . . . . 401 Enabling Padding of IS-IS Hello Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Configuring CLNS for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Example: Configuring CLNS for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Disabling IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Disabling IPv4 Routing for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Disabling IPv6 Routing for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Applying Policies to Routes Exported to IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Examples: Configuring IS-IS Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . 406 Installing a Default Route to the Nearest Routing Device That Operates at Both IS-IS Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Configuring Loop-Free Alternate Routes for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . 409 Configuring Link Protection for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Configuring Node-Link Protection for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Excluding an IS-IS Interface as a Backup for Protected Interfaces . . . . . . . . 412 Configuring RSVP Label-Switched Paths as Backup Paths for IS-IS . . . . . . 412 Using Operational Mode Commands to Monitor Protected IS-IS Routes . . . 413 Example: Configuring Node-Link Protection for IS-IS Routes . . . . . . . . . . . . 413 Disabling Adjacency Down and Neighbor Down Notification in IS-IS and OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Tracing IS-IS Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Examples: Tracing IS-IS Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 Example: Configuring IS-IS on Logical Systems Within the Same Router . . . . . . 419 Example: Configuring an IS-IS Default Route Policy on Logical Systems . . . . . . 428

Chapter 15

Summary of IS-IS Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . 433 authentication-key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 authentication-key-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 authentication-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 bfd-liveness-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 clns-routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

xiv


Table of Contents

csnp-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 disable (IS-IS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442 disable (LDP Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 external-preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 graceful-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 hello-authentication-key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 hello-authentication-key-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 hello-authentication-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 hello-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 hello-padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 hold-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 hold-time (IS-IS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 hold-time (LDP Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 ignore-attached-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 ignore-lsp-metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 ipv4-multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 ipv4-multicast-metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 ipv6-multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 ipv6-multicast-metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 ipv6-unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 ipv6-unicast-metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 isis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 label-switched-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 -synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 level (Global IS-IS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 level (IS-IS Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 link-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 loose-authentication-check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 lsp-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 lsp-lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 max-areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 mesh-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 multicast-rpf-routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 no-adjacency-down-notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 no-adjacency-holddown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 no-authentication-check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 no-csnp-authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 no-eligible-backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 no-hello-authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 no-ipv4-multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 no-ipv4-routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 no-ipv6-multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 no-ipv6-routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475


xv


no-ipv6-unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 no-psnp-authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 no-unicast-topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 node-link-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 passive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 point-to-point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 prefix-export-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 reference-bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 rib-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 spf-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 te-metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 traffic-engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 wide-metrics-only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

Chapter 16

Introduction to OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 OSPF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 OSPF Default Route Preference Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 OSPF Routing Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 OSPF Three-Way Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 OSPF Version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 OSPF Areas and Router Functionality Overview . . . . . . . . . . . . . . . . . . . . . . . . . 498 Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 Area Border Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 Backbone Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 AS Boundary Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Backbone Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Internal Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Stub Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Not-So-Stubby Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Transit Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Packets Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 OSPF Packet Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Hello Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Database Description Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Link-State Request Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Link-State Update Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 Link-State Acknowledgment Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 Link-State Advertisement Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 OSPF External Metrics Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 OSPF Routing Policy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 Default OSPF Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 Supported OSPF and OSPFv3 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

xvi


Table of Contents

Chapter 17

OSPF Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 OSPF Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 Examples: Configuring OSPF Designated Routers . . . . . . . . . . . . . . . . . . . . . . . . 509 OSPF Designated Router Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509 Example: Configuring an OSPF Router Identifier . . . . . . . . . . . . . . . . . . . . . . 510 Example: Controlling OSPF Designated Router Election . . . . . . . . . . . . . . . . 511 Examples: Configuring OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512 Understanding OSPF Areas and Backbone Areas . . . . . . . . . . . . . . . . . . . . . 513 Example: Configuring a Single-Area OSPF Network . . . . . . . . . . . . . . . . . . . 514 Example: Configuring a Multiarea OSPF Network . . . . . . . . . . . . . . . . . . . . . 516 Example: Configuring OSPF Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 Examples: Configuring OSPF Stub and Not-So-Stubby Areas . . . . . . . . . . . . . . 522 Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522 Example: Configuring OSPF Stub and Totally Stubby Areas . . . . . . . . . . . . 524 Example: Configuring OSPF Not-So-Stubby Areas . . . . . . . . . . . . . . . . . . . 528 Example: Configuring OSPF Multiarea Adjacency . . . . . . . . . . . . . . . . . . . . . . . . 533 Multiarea Adjacency for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 Example: Configuring Multiarea Adjacency for OSPF . . . . . . . . . . . . . . . . . . 534 Example: Disabling OSPFv2 Compatibility with RFC 1583 . . . . . . . . . . . . . . . . . . 538 OSPFv2 Compatibility with RFC 1583 Overview . . . . . . . . . . . . . . . . . . . . . . 538 Example: Disabling OSPFv2 Compatibility with RFC 1583 . . . . . . . . . . . . . . 538 Examples: Configuring OSPF Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 About OSPF Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 Example: Configuring an Interface on a Broadcast or Point-to-Point Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 Example: Configuring OSPF Demand Circuits . . . . . . . . . . . . . . . . . . . . . . . . 547 Example: Configuring a Passive OSPF Interface . . . . . . . . . . . . . . . . . . . . . . 550 Example: Configuring OSPFv2 Peer interfaces . . . . . . . . . . . . . . . . . . . . . . . 552 Example: Configuring Multiple Address Families for OSPFv3 . . . . . . . . . . . . . . . 554 Understanding Multiple Address Families for OSPFv3 . . . . . . . . . . . . . . . . . 554 Example: Configuring Multiple Address Families for OSPFv3 . . . . . . . . . . . . 554 Examples: Configuring OSPF Route Summarization . . . . . . . . . . . . . . . . . . . . . . 558 Understanding OSPF Route Summarization . . . . . . . . . . . . . . . . . . . . . . . . . 558 Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 Example: Limiting the Number of Prefixes Exported to OSPF . . . . . . . . . . . 563 Configuring OSPF Refresh and Flooding Reduction in Stable Topologies . . 565 Examples: Configuring OSPF Traffic Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 Understanding OSPF Traffic Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 Controlling the Cost of Individual OSPF Network Segments . . . . . . . . . 567 Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth . . 567


xvii


Controlling OSPF Route Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . 568 Example: Controlling the Cost of Individual OSPF Network Segments . . . . 568 Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572 Example: Controlling OSPF Route Preferences . . . . . . . . . . . . . . . . . . . . . . . 574 Example: Configuring OSPF Overload Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576 OSPF Overload Function Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576 Example: Configuring OSPF to Make Routing Devices Appear Overloaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 Example: Configuring the OSPF Routing Algorithm . . . . . . . . . . . . . . . . . . . . . . . 580 Understanding the SPF Algorithm Options for OSPF . . . . . . . . . . . . . . . . . . 580 Example: Configuring SPF Algorithm Options for OSPF . . . . . . . . . . . . . . . 580 Example: Configuring Synchronization Between LDP and IGPs . . . . . . . . . . . . . 583 Synchronization Between LDP and IGPs Overview . . . . . . . . . . . . . . . . . . . . 583 Example: Configuring Synchronization Between LDP and IGPs . . . . . . . . . . 583 Examples: Configuring OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 Understanding OSPFv2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 Understanding OSPFv3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587 Example: Configuring Simple Authentication for OSPFv2 Exchanges . . . . . 588 Example: Configuring MD5 Authentication for OSPFv2 Exchanges . . . . . . . 590 Example: Configuring a Transition of MD5 Keys on an OSPFv2 Interface . . 592 Example: Configuring IPsec Authentication for an OSPF Interface . . . . . . . 595 Example: Configuring OSPF Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . 601 Introduction to Routing Instances for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . 601 Minimum Routing-Instance Configuration for OSPFv2 . . . . . . . . . . . . . 601 Minimum Routing-Instance Configuration for OSPFv3 . . . . . . . . . . . . . 602 Multiple Routing Instances of OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 Configuring OSPF Routing Table Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 Example: Configuring Multiple Routing Instances of OSPF . . . . . . . . . . . . . 603 Example: Configuring OSPF Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609 OSPF Timers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609 Example: Configuring OSPF Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610 Example: Configuring BFD for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615 BFD for OSPF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615 Example: Configuring BFD for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618 Example: Configuring BFD Authentication for OSPF . . . . . . . . . . . . . . . . . . . . . . . 621 BFD Authentication for OSPF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621 BFD Authentication Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622 Security Authentication Keychains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 Strict Versus Loose Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 Configuring BFD Authentication for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 Configuring BFD Authentication Parameters . . . . . . . . . . . . . . . . . . . . . 623 Viewing Authentication Information for BFD Sessions . . . . . . . . . . . . . 625

xviii


Table of Contents

Examples: Configuring Graceful Restart for OSPF . . . . . . . . . . . . . . . . . . . . . . . . 626 Graceful Restart for OSPF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626 Helper Mode for Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627 Planned and Unplanned Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . 628 Example: Configuring Graceful Restart for OSPF . . . . . . . . . . . . . . . . . . . . . 628 Example: Configuring the Helper Capability Mode for OSPFv2 Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632 Example: Configuring the Helper Capability Mode for OSPFv3 Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635 Example: Disabling Strict LSA Checking for OSPF Graceful Restart . . . . . . 639 Examples: Configuring Loop-Free Alternate Routes for OSPF . . . . . . . . . . . . . . . 641 Loop-Free Alternate Routes for OSPF Overview . . . . . . . . . . . . . . . . . . . . . . 642 Configuring Link Protection for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 Configuring Node-Link Protection for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . 644 Excluding an OSPF Interface as a Backup for a Protected Interface . . . . . . 645 Configuring Backup SPF Options for Protected OSPF Interfaces . . . . . . . . 645 Configuring RSVP Label-Switched Paths as Backup Paths for OSPF . . . . . 647 Examples: Configuring OSPF Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 648 OSPF Support for Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648 Example: Enabling OSPF Traffic Engineering Support . . . . . . . . . . . . . . . . . 650 Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654 Example: Configuring OSPF Passive Traffic Engineering Mode . . . . . . . . . . . . . . 656 OSPF Passive Traffic Engineering Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656 Example: Configuring OSPF Passive Traffic Engineering Mode . . . . . . . . . . 656 Example: Advertising Label-Switched Paths into OSPFv2 . . . . . . . . . . . . . . . . . 659 Advertising Label-Switched Paths into OSPFv2 . . . . . . . . . . . . . . . . . . . . . . 659 Example: Advertising Label-Switched Paths into OSPFv2 . . . . . . . . . . . . . . 659 Example: Configuring OSPFv2 Sham Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670 OSPFv2 Sham Links Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670 Example: Configuring OSPFv2 Sham Links . . . . . . . . . . . . . . . . . . . . . . . . . . 671 Example: Configuring OSPF Database Protection . . . . . . . . . . . . . . . . . . . . . . . . 677 OSPF Database Protection Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677 Configuring OSPF Database Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678 Examples: Configuring OSPF Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679 Understanding OSPF Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679 Routing Policy Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680 Routing Policy Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680 Routing Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681 Example: Injecting OSPF Routes into the BGP Routing Table . . . . . . . . . . . . 681 Example: Redistributing Static Routes into OSPF . . . . . . . . . . . . . . . . . . . . 684 Example: Configuring an OSPF Import Policy . . . . . . . . . . . . . . . . . . . . . . . . 687 Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691 Examples: Configuring Routing Policy for Network Summaries . . . . . . . . . . . . . 695 Import and Export Policies for Network Summaries Overview . . . . . . . . . . 695 Example: Configuring an OSPF Export Policy for Network Summaries . . . . 695 Example: Configuring an OSPF Import Policy for Network Summaries . . . . 704


xix


Examples: Configuring OSPF and Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . 712 OSPF Support for Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712 Introduction to Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712 OSPF and Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712 Example: Configuring OSPF on Logical Systems Within the Same Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 Example: Configuring a Conditional OSPF Default Route Policy on Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719 Example: Configuring an OSPF Default Route Policy on Logical Systems . . 725 Example: Configuring an OSPF Import Policy on Logical Systems . . . . . . . . 730 Example: Configuring OSPF Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737 Tracing OSPF Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738 Example: Tracing OSPF Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739 Verifying an OSPF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744 Verifying OSPF-Enabled Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744 Verifying OSPF Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745 Verifying the Number of OSPF Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746 Verifying Reachability of All Hosts in an OSPF Network . . . . . . . . . . . . . . . . 747

Chapter 18

Summary of OSPF Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . 749 area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750 area-range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751 authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752 backup-spf-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753 bandwidth-based-metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754 bfd-liveness-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756 database-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760 dead-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762 default-lsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763 default-metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764 demand-circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765 disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766 disable (LDP Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766 disable (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767 domain-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768 domain-vpn-tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768 export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769 external-preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770 flood-reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771 graceful-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772 hello-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774 hold-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775 ignore-lsp-metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775 import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776 inter-area-prefix-export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777 inter-area-prefix-import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779 interface-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781 ipsec-sa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783

xx


Table of Contents

label-switched-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784 ldp-synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785 link-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786 lsp-metric-into-summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787 md5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789 metric-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792 network-summary-export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793 network-summary-import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794 no-domain-vpn-tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794 no-eligible-backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795 no-interface-state-traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796 no-neighbor-down-notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796 no-nssa-abr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797 no-rfc-1583 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 no-summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 node-link-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799 nssa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800 ospf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801 ospf3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802 overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803 passive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 peer-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806 poll-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808 prefix-export-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809 priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810 realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811 reference-bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812 retransmit-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813 rib-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814 route-type-community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815 secondary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815 sham-link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816 sham-link-remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816 shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817 simple-password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818 spf-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819 stub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821 summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822 te-metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823 traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824 traffic-engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827 traffic-engineering (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828 traffic-engineering (Passive TE Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830 transit-delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831 transmit-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832 type-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833


xxi


virtual-link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834

Chapter 19

Introduction to RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 RIP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 RIP Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 RIP Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836 RIP Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836

Chapter 20

RIP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 Configuring RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 Minimum RIP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841 Overview of RIP Global Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842 Overview of RIP Neighbor Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842 Configuring Authentication for RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843 Configuring BFD for RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844 Overview of BFD Authentication for RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846 BFD Authentication Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847 Security Authentication Keychains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848 Strict Versus Loose Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848 Configuring BFD Authentication for RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848 Configuring BFD Authentication Parameters . . . . . . . . . . . . . . . . . . . . . . . . 849 Viewing Authentication Information for BFD Sessions . . . . . . . . . . . . . . . . . 850 Accepting RIP Packets with Nonzero Values in Reserved Fields . . . . . . . . . . . . . . 851 Applying Policies to RIP Routes Imported from Neighbors . . . . . . . . . . . . . . . . . 852 Configuring the Number of Route Entries in RIP Update Messages . . . . . . . . . . 852 Configuring the Metric Value Added to Imported RIP Routes . . . . . . . . . . . . . . . 852 Configuring RIP Update Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 Configuring Routing Table Groups for RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 Configuring RIP Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 Configuring Group-Specific RIP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854 Applying Policies to Routes Exported by RIP . . . . . . . . . . . . . . . . . . . . . . . . . 855 Configuring the Default Preference Value for RIP . . . . . . . . . . . . . . . . . . . . . 855 Configuring the Metric for Routes Exported by RIP . . . . . . . . . . . . . . . . . . . . 856 Configuring Graceful Restart for RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856 Disabling Strict Address Checking for RIP Messages . . . . . . . . . . . . . . . . . . . . . . 857 RIP Demand Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857 RIP Demand Circuits Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857 RIP Demand Circuit Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858 Timers Used by RIP Demand Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . 859 Example: Configuring RIP Demand Circuits . . . . . . . . . . . . . . . . . . . . . . . . . 860 Tracing RIP Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863 Example: Tracing RIP Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864 Example: Configuring RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864

Chapter 21

Summary of RIP Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . 867 any-sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867 authentication-key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868 authentication-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869 bfd-liveness-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870 check-zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872

xxii


Table of Contents

demand-circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873 export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874 graceful-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875 group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876 holddown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878 import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879 max-retrans-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880 message-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881 metric-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882 metric-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883 neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884 no-check-zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885 preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885 receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886 rib-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887 rip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887 route-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888 send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889 traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890 update-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892

Chapter 22

Introduction to RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 RIPng Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 RIPng Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 RIPng Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 RIPng Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894

Chapter 23

RIPng Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 Configuring RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 Minimum RIPng Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896 Overview of RIPng Global Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897 Overview of RIPng Neighbor Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897 Applying Policies to RIPng Routes Imported from Neighbors . . . . . . . . . . . . . . . 897 Configuring the Metric Value Added to Imported RIPng Routes . . . . . . . . . . . . . 898 Configuring RIPng Update Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898 Configuring RIPng Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898 Configuring Group-Specific RIPng Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 899 Applying Policies to Routes Exported by RIPng . . . . . . . . . . . . . . . . . . . . . . 900 Configuring the Default Preference Value for RIPng . . . . . . . . . . . . . . . . . . . 900 Configuring the Metric for Routes Exported by RIPng . . . . . . . . . . . . . . . . . 900 Configuring Graceful Restart for RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901 Tracing RIPng Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901 Example: Configuring RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902

Chapter 24

Summary of RIPng Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . 905 export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 graceful-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 holddown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908 import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909


xxiii


metric-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910 metric-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912 preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913 receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914 ripng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915 route-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915 send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916 traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917 update-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919

Chapter 25

Introduction to ICMP Router Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 ICMP Router Discovery Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 Operation of a Router Discovery Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 Router Advertisement Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922 ICMP Router Discovery Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922

Chapter 26

ICMP Router Discovery Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . 923 Configuring ICMP Router Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923 Minimum ICMP Router Discovery Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 924 Configuring the Addresses Included in ICMP Router Advertisements . . . . . . . . . 924 Configuring the Frequency of ICMP Router Advertisements . . . . . . . . . . . . . . . . 925 Modifying the Lifetime in ICMP Router Advertisements . . . . . . . . . . . . . . . . . . . . 925 Tracing ICMP Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925 Example: Tracing ICMP Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926

Chapter 27

Summary of ICMP Router Discovery Configuration Statements . . . . . . . . 927 address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927 advertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928 broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928 disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929 ignore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929 ineligible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930 lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931 max-advertisement-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932 min-advertisement-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933 multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934 priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935 router-discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935 traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936

Chapter 28

Introduction to Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939 Neighbor Discovery Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939 Router Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940 Address Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940 Redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940 Neighbor Discovery Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940

xxiv


Table of Contents

Chapter 29

Neighbor Discovery Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 941 Configuring Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941 Minimum Neighbor Discovery Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942 Configuring an Interface to Send Neighbor Discovery Advertisements . . . . . . . . 942 Configuring the Hop Count in Outgoing Neighbor Discovery Packets . . . . . . . . . 943 Configuring the Lifetime for the Default Neighbor Discovery Router . . . . . . . . . . 943 Configuring the MTU Option for Neighbor Discovery Advertisements . . . . . . . . 943 Enabling Stateful Autoconfiguration with Neighbor Discovery . . . . . . . . . . . . . . 944 Configuring the Frequency of Neighbor Discovery Advertisements . . . . . . . . . . 945 Configuring the Delay Before Neighbor-Discovery Neighbors Mark the Router as Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945 Configuring the Frequency of Neighbor Solicitation Messages . . . . . . . . . . . . . . 945 Configuring the Prefix Information Included in Neighbor Discovery Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946 Setting the Prefix for Onlink Determination . . . . . . . . . . . . . . . . . . . . . . . . . 946 Setting the Prefix for Stateless Address Autoconfiguration . . . . . . . . . . . . . 946 Configuring the Preferred Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947 Configuring the Valid Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947 Tracing Neighbor Discovery Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947

Chapter 30

Summary of Neighbor Discovery Router Advertisement Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949 autonomous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949 current-hop-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950 default-lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951 link-mtu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952 managed-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952 max-advertisement-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953 min-advertisement-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953 no-autonomous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954 no-managed-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954 no-on-link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954 no-other-stateful-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954 on-link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954 other-stateful-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955 preferred-lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955 prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956 reachable-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956 retransmit-timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957 router-advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957 traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958 valid-lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959


xxv


Chapter 31

Secure Neighbor Discovery Configuration Guidelines . . . . . . . . . . . . . . . . . 961 Secure Neighbor Discovery Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . 961 Configuring Secure Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961 Enabling Secure Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962 Configuring Cryptographically Generated Addresses for Secure Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962 Specifying the Pathname for the Key File . . . . . . . . . . . . . . . . . . . . . . . . . . . 963 Specifying the RSA Key Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963 Configuring Timestamps for Secure Neighbor Discovery . . . . . . . . . . . . . . . . . . . 963 Tracing Secure Neighbor Discovery Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . 964

Chapter 32

Summary of Secure Neighbor Discovery Configuration Statements . . . . 965 cryptographic-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965 key-length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966 key-pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966 neighbor-discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967 secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968 security-level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969 timestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970 traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971

Part 6

BGP

Chapter 33

Introduction to BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975 Understanding BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976 Autonomous Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976 AS Paths and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976 External and Internal BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977 BGP Routes Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977 BGP Messages Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978 Open Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979 Update Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979 Keepalive Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980 Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980

Chapter 34

BGP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981 Examples: Configuring External BGP Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982 Understanding External BGP Peering Sessions . . . . . . . . . . . . . . . . . . . . . . 982 Example: Configuring External BGP Point-to-Point Peer Sessions . . . . . . . 983 Example: Configuring External BGP on Logical Systems with IPv6 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990 Examples: Configuring Internal BGP Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999 Understanding BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000 Autonomous Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000 AS Paths and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000 External and Internal BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001 Example: Configuring Internal BGP Peer Sessions . . . . . . . . . . . . . . . . . . . . 1001 Example: Configuring Internal BGP Peering Sessions on Logical Systems . . 1012

xxvi


Table of Contents

Example: Preventing BGP Session Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022 Understanding BGP Session Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022 Example: Preventing BGP Session Flaps When VPN Families Are Configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023 Example: Configuring BGP Interactions with IGPs . . . . . . . . . . . . . . . . . . . . . . . 1029 Understanding Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029 Example: Injecting OSPF Routes into the BGP Routing Table . . . . . . . . . . . 1029 Example: Configuring BGP Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033 Understanding BGP Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033 Example: Configuring a Route Reflector . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035 Example: Configuring BGP Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049 Understanding BGP Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049 Example: Configuring BGP Confederations . . . . . . . . . . . . . . . . . . . . . . . . . 1051 Example: Configuring BGP Route Authentication . . . . . . . . . . . . . . . . . . . . . . . . 1056 Understanding Route Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057 Example: Configuring Route Authentication for BGP . . . . . . . . . . . . . . . . . 1058 Example: Configuring IPsec Protection for BGP . . . . . . . . . . . . . . . . . . . . . . . . . 1063 Understanding IPsec for BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063 Example: Using IPsec to Protect BGP Traffic . . . . . . . . . . . . . . . . . . . . . . . . 1064 Examples: Configuring BGP MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067 Understanding the MED Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067 Example: Configuring the MED Attribute Directly . . . . . . . . . . . . . . . . . . . . 1069 Example: Configuring the MED Using Route Filters . . . . . . . . . . . . . . . . . . . 1082 Example: Configuring the MED Using Communities . . . . . . . . . . . . . . . . . . 1095 Example: Associating the MED Path Attribute with the IGP Metric and Delaying MED Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095 Example: Configuring EBGP Multihop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105 Understanding BGP Multihop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105 Example: Configuring EBGP Multihop Sessions . . . . . . . . . . . . . . . . . . . . . . 1105 Examples: Configuring BGP Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114 Understanding BGP Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115 Example: Load-Balancing BGP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115 Example: Configuring Single-Hop EBGP Peers to Accept Remote Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119 Example: Configuring BGP Local Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1130 Understanding the BGP Local Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . 1130 Example: Configuring the Local Preference Value for BGP Routes . . . . . . . . 1131 Example: Configuring BGP Route Preference (Administrative Distance) . . . . . . 1143 Understanding Route Preference Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143 Example: Configuring the Preference Value for BGP Routes . . . . . . . . . . . . 1145 Example: Configuring BGP Path Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150 Understanding BGP Path Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150 Example: Ignoring the AS Path Attribute When Selecting the Best Path . . . 1153 Examples: Configuring BGP Local AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1160 Understanding the BGP Local AS Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 1161 Example: Configuring a Local AS for EBGP Sessions . . . . . . . . . . . . . . . . . . 1164 Example: Configuring a Private Local AS for EBGP Sessions . . . . . . . . . . . . 1174


xxvii


Example: Removing Private AS Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180 Understanding Private AS Number Removal from AS Paths . . . . . . . . . . . . 1180 Example: Removing Private AS Numbers from AS Paths . . . . . . . . . . . . . . . 1181 Example: Configuring BGP Flap Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186 Understanding Damping Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186 Example: Configuring Damping Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 1187 Examples: Configuring Multiprotocol BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190 Understanding Multiprotocol BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190 Limiting the Number of Prefixes Received on a BGP Peer Session . . . . 1193 Limiting the Number of Prefixes Accepted on a BGP Peer Session . . . 1194 Configuring BGP Routing Table Groups . . . . . . . . . . . . . . . . . . . . . . . . . 1195 Resolving Routes to PE Routing Devices Located in Other ASs . . . . . . 1195 Allowing Labeled and Unlabeled Routes . . . . . . . . . . . . . . . . . . . . . . . . 1195 Example: Configuring IPv6 BGP Routes over IPv4 Transport . . . . . . . . . . . . 1196 Example: Enabling BGP to Carry Flow-Specification Routes . . . . . . . . . . . 1202 Enabling Layer 2 VPN and VPLS Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 1215 Example: Configuring BGP and CLNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216 Understanding BGP for CLNS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216 Example: Configuring BGP for CLNS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . 1217 Enabling BGP to Carry CLNS Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218 Example: Enabling CLNS Between Two Routers . . . . . . . . . . . . . . . . . . 1219 Example: Configuring CLNS Within a VPN . . . . . . . . . . . . . . . . . . . . . . . 1221 Examples: Configuring TCP and BGP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223 Understanding TCP and BGP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223 Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224 Example: Configuring a Filter to Limit TCP Access to a Port Based On a Prefix List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229 Example: Limiting TCP Segment Size for BGP . . . . . . . . . . . . . . . . . . . . . . . 1232 Example: Configuring BGP Route Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 1236 Understanding Route Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236 Applying Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236 Setting BGP to Advertise Inactive Routes . . . . . . . . . . . . . . . . . . . . . . . 1237 Configuring BGP to Advertise the Best External Route to Internal Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237 Configuring How Often BGP Exchanges Routes with the Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239 Disabling Suppression of Route Advertisements . . . . . . . . . . . . . . . . . 1239 Example: Configuring BGP Prefix-Based Outbound Route Filtering . . . . . . 1240 Example: Configuring BFD for BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243 Understanding BFD for BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243 Example: Configuring BFD on Internal BGP Peer Sessions . . . . . . . . . . . . . 1244 Example: Configuring BFD Authentication for BGP . . . . . . . . . . . . . . . . . . . . . . . 1252 Understanding BFD Authentication for BGP . . . . . . . . . . . . . . . . . . . . . . . . 1252 BFD Authentication Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1253 Security Authentication Keychains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254

xxviii


Table of Contents

Strict Versus Loose Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254 Example: Configuring BFD Authentication for BGP . . . . . . . . . . . . . . . . . . . 1254 Configuring BFD Authentication Parameters . . . . . . . . . . . . . . . . . . . . 1254 Viewing Authentication Information for BFD Sessions . . . . . . . . . . . . . 1256 Example: Advertising Multiple BGP Paths to a Destination . . . . . . . . . . . . . . . . . 1257 Understanding the Advertisement of Multiple Paths to a Single Destination in BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257 Example: Advertising Multiple Paths in BGP . . . . . . . . . . . . . . . . . . . . . . . . 1258 Example: Configuring BGP Monitoring Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 1282 Understanding the BGP Monitoring Protocol . . . . . . . . . . . . . . . . . . . . . . . . 1282 Example: Configuring the BGP Monitoring Protocol . . . . . . . . . . . . . . . . . . 1282 Example: Configuring BGP Trace Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285 Understanding Trace Operations for BGP Protocol Traffic . . . . . . . . . . . . . 1285 Example: Viewing BGP Trace Files on Logical Systems . . . . . . . . . . . . . . . . 1286

Chapter 35

Summary of BGP Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . 1293 [edit protocols bgp] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1293 Common BGP Family Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1293 Complete [edit protocols bgp] Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 1294 accept-remote-nexthop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299 accepted-prefix-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300 add-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302 advertise-external . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303 advertise-inactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304 advertise-peer-as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305 aggregate-label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306 allow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307 as-override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308 authentication-algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309 authentication-key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310 authentication-key-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311 auto-discovery-only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1312 bfd-liveness-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313 bgp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317 bgp-orf-cisco-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318 bmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1319 cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320 confederation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321 damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322 description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1323 disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1324 explicit-null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325 export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326 family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327 flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330 graceful-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1331 group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1332 hold-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335 idle-after-switch-over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336


xxix


import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1337 include-mp-next-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1338 ipsec-sa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339 iso-vpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1340 keep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1341 labeled-unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1342 local-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1344 local-as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346 local-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348 local-preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1349 log-updown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1350 logical-systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1351 loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1352 metric-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354 mtu-discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1356 multihop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358 multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359 neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360 no advertise-peer-as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1363 no-aggregator-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364 no-client-reflect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365 no-validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1366 out-delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1367 outbound-route-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368 passive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1369 path-count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1370 path-selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1371 peer-as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1373 precision-timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375 preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1376 prefix-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1377 prefix-policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1378 receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379 remove-private . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380 resolve-vpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1381 rib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382 rib-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1383 route-target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384 send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385 session-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386 tcp-mss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387 traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1388 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1391 vpn-apply-export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1392

Part 7

Indexes Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395 Index of Statements and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423

xxx


List of Figures Part 1

Overview

Chapter 1

Routing Protocols Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Figure 1: Synchronizing Routing Exchange Between the Routing and Forwarding Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Part 2


Chapter 5

Configuring Other Protocol-Independent Routing Properties . . . . . . . . . . . 119 Figure 2: Route to Forwarding Next-Hop Bindings . . . . . . . . . . . . . . . . . . . . . . . . 136 Figure 3: Route to Forwarding Indirect Next-Hop Bindings . . . . . . . . . . . . . . . . . . 137

Part 3

Routing Instances

Chapter 8

Routing Instances Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 239 Figure 4: Configuration for Multiple Routing Instances . . . . . . . . . . . . . . . . . . . . . 252 Figure 5: Configuration for Multiple Routing Instances . . . . . . . . . . . . . . . . . . . . . 258 Figure 6: Configuration of Policy-Based Export for an Overlapping VPN . . . . . . . 275

Part 5


Chapter 14

IS-IS Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Figure 7: Hitless Authentication Key Rollover for IS-IS . . . . . . . . . . . . . . . . . . . . . . 351 Figure 8: Configuring BFD on IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Figure 9: Configuring IS-IS Multicast Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 Figure 10: Install Default Route to Nearest Routing Device That Operates at Both Level 1 and Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Figure 11: Link Protection and Node-Link Protection Comparison for IS-IS Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Figure 12: IS-IS on Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 Figure 13: IS-IS with a Default Route to an ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

Chapter 16

Introduction to OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 Figure 14: OSPF Three-Way Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496

Chapter 17

OSPF Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 Figure 15: Multiarea OSPF Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 Figure 16: OSPF Topology with a Virtual Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514 Figure 17: Typical Single-Area OSPF Network Topology . . . . . . . . . . . . . . . . . . . . 515 Figure 18: Typical Multiarea OSPF Network Topology . . . . . . . . . . . . . . . . . . . . . . 517 Figure 19: OSPF Virtual Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Figure 20: OSPF AS Network with Stub Areas and NSSAs . . . . . . . . . . . . . . . . . . 523


xxxi


Figure 21: OSPF Network Topology with Stub Areas and NSSAs . . . . . . . . . . . . . 526 Figure 22: OSPF Network Topology with Stub Areas and NSSAs . . . . . . . . . . . . 530 Figure 23: IPv4 Unicast Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Figure 24: Summarizing Ranges of Routes in OSPF . . . . . . . . . . . . . . . . . . . . . . . 559 Figure 25: OSPF Metric Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569 Figure 26: Configuration for Multiple Routing Instances . . . . . . . . . . . . . . . . . . . 604 Figure 27: Advertising an LSP into OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661 Figure 28: OSPFv2 Sham Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671 Figure 29: OSPFv2 Sham Link Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673 Figure 30: Sample Topology Used for an OSPF Export Network Summary Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697 Figure 31: Sample Topology Used for an OSPF Import Network Summary Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705 Figure 32: OSPF on Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 Figure 33: OSPF with a Conditional Default Route to an ISP . . . . . . . . . . . . . . . . 720 Figure 34: OSPF with a Default Route to an ISP . . . . . . . . . . . . . . . . . . . . . . . . . . 726 Figure 35: OSPF Import Policy on Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . 731 Figure 36: Sample OSPF Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746

Part 6

BGP

Chapter 33

Introduction to BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975 Figure 37: ASs, EBGP, and IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977

Chapter 34

BGP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981 Figure 38: BGP Peering Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982 Figure 39: Typical Network with BGP Peer Sessions . . . . . . . . . . . . . . . . . . . . . . 983 Figure 40: Typical Network with BGP Peer Sessions . . . . . . . . . . . . . . . . . . . . . . 991 Figure 41: ASs, EBGP, and IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001 Figure 42: Typical Network with IBGP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 1003 Figure 43: Typical Network with IBGP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 1013 Figure 44: Topology for the EBGP Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025 Figure 45: Topology for the RR Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025 Figure 46: Simple Route Reflector Topology (One Cluster) . . . . . . . . . . . . . . . . 1033 Figure 47: Basic Route Reflection (Multiple Clusters) . . . . . . . . . . . . . . . . . . . . . 1034 Figure 48: Hierarchical Route Reflection (Clusters of Clusters) . . . . . . . . . . . . . 1034 Figure 49: IBGP Network Using a Route Reflector . . . . . . . . . . . . . . . . . . . . . . . 1036 Figure 50: BGP Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050 Figure 51: Typical Network Using BGP Confederations . . . . . . . . . . . . . . . . . . . . 1052 Figure 52: Authentication for BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059 Figure 53: IPsec for BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065 Figure 54: Default MED Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068 Figure 55: Typical Network with IBGP Sessions and Multiple Exit Points . . . . . . 1071 Figure 56: Typical Network with IBGP Sessions and Multiple Exit Points . . . . . 1083 Figure 57: Topology for Delaying the MED Update . . . . . . . . . . . . . . . . . . . . . . . 1097 Figure 58: Typical Network with EBGP Multihop Sessions . . . . . . . . . . . . . . . . . 1106 Figure 59: BGP Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116 Figure 60: Topology for Accepting a Remote Next Hop . . . . . . . . . . . . . . . . . . . . 1120 Figure 61: Typical Network with IBGP Sessions and Multiple Exit Points . . . . . . . 1132 Figure 62: BGP Preference Value Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147

xxxii


List of Figures

Figure 63: Topology for Ignoring the AS-Path Lengh . . . . . . . . . . . . . . . . . . . . . . 1155 Figure 64: Local AS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162 Figure 65: Topology for Configuring the Local AS . . . . . . . . . . . . . . . . . . . . . . . . 1165 Figure 66: Topology for Configuring a Private Local AS . . . . . . . . . . . . . . . . . . . . 1175 Figure 67: Topology for Removing a Private AS from the Advertised AS Path . . . 1181 Figure 68: Topology for Configuring IPv6 BGP Routes over IPv4 Transport . . . . 1196 Figure 69: Typical Network with BGP Peer Sessions . . . . . . . . . . . . . . . . . . . . . . 1224 Figure 70: TCP Maximum Segment Size for BGP . . . . . . . . . . . . . . . . . . . . . . . . 1233 Figure 71: BGP Prefix-Based Outbound Route Filtering . . . . . . . . . . . . . . . . . . . . 1241 Figure 72: Typical Network with IBGP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 1245 Figure 73: Advertisement of Multiple Paths in BGP . . . . . . . . . . . . . . . . . . . . . . . 1259 Figure 74: BMP Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283


xxxiii


xxxiv


List of Tables About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xli Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xli

Part 1

Overview

Chapter 1

Routing Protocols Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Table 3: Default Route Preference Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Part 2


Chapter 4

Configuring Routing Tables and Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Table 4: Flow Route Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Table 5: Flow Route Action Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Part 4


Chapter 10

Introduction to Multitopology Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Table 6: Examples of Routing Tables for Custom Topologies . . . . . . . . . . . . . . . 309

Part 5


Chapter 14

IS-IS Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Table 7: Configuring BFD for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Table 8: IPv4 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Table 9: IPv6 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Chapter 16

Introduction to OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 Table 10: Default Route Preference Values for OSPF . . . . . . . . . . . . . . . . . . . . . . 495

Chapter 20

RIP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 Table 11: RIP Demand Circuit Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858

Part 6

BGP

Chapter 34

BGP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981 Table 12: MED Options for Routing Table Path Selection . . . . . . . . . . . . . . . . . . 1069 Table 13: Default Route Preference Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144 Table 14: Damping Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187


xxxv


xxxvi


About This Guide ®

This preface provides the following guidelines for using the Junos OS Routing Protocols Configuration Guide: •

Junos OS Documentation and Release Notes on page xxxvii

•

Objectives on page xxxviii

•

Audience on page xxxviii

•

Supported Platforms on page xxxviii

•

Using the Indexes on page xxxix

•

Using the Examples in This Manual on page xxxix

•

Documentation Conventions on page xl

•

Documentation Feedback on page xlii

•

Requesting Technical Support on page xlii

Junos OS Documentation and Release Notes For a list of related Junos OS documentation, see http://www.juniper.net/techpubs/software/junos/ .

If the information in the latest release notes differs from the information in the documentation, follow the Junos OS Release Notes. ®

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


xxxvii


Objectives This guide is designed for network administrators who are configuring and monitoring a Juniper Networks J Series, M Series, MX Series, or T Series routing platform.

NOTE: For additional information about the Junos OS—either corrections to or information that might have been omitted from this guide—see the software release notes at http://www.juniper.net/ .

Audience This guide is designed for network administrators who are configuring and monitoring a Juniper Networks M Series, MX Series, T Series, EX Series, or J Series router or switch. To use this guide, you need a broad understanding of networks in general, the Internet in particular, networking principles, and network configuration. You must also be familiar with one or more of the following Internet routing protocols: •

Border Gateway Protocol (BGP)

•

Distance Vector Multicast Routing Protocol (DVMRP)

•

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

•

Internet Control Message Protocol (ICMP) router discovery

•

Internet Group Management Protocol (IGMP)

•

Multiprotocol Label Switching (MPLS)

•

Open Shortest Path First (OSPF)

•

Protocol-Independent Multicast (PIM)

•

Resource Reservation Protocol (RSVP)

•

Routing Information Protocol (RIP)

•

Simple Network Management Protocol (SNMP)

Personnel operating the equipment must be trained and competent; must not conduct themselves in a careless, willfully negligent, or hostile manner; and must abide by the instructions provided by the documentation.

Supported Platforms For the features described in this manual, the Junos OS currently supports the following platforms:

xxxviii

•

J Series

•

M Series


About This Guide

•

MX Series

•

T Series

•

EX Series

Using the Indexes This reference contains two indexes: a complete index that includes topic entries, and an index of statements and commands only. In the index of statements and commands, an entry refers to a statement summary section only. In the complete index, the entry for a configuration statement or command contains at least two parts: •

The primary entry refers to the statement summary section.

•

The secondary entry, usage guidelines, refers to the section in a configuration guidelines chapter that describes how to use the statement or command.

Using the Examples in This Manual If you want to use the examples in this manual, you can use the load merge or the load merge relative command. These commands cause the software to merge the incoming configuration into the current candidate configuration. The example does not become active until you commit the candidate configuration. If the example configuration contains the top level of the hierarchy (or multiple hierarchies), the example is a full example. In this case, use the load merge command. If the example configuration does not start at the top level of the hierarchy, the example is a snippet. In this case, use the load merge relative command. These procedures are described in the following sections.

Merging a Full Example To merge a full example, follow these steps: 1.

From the HTML or PDF version of the manual, copy a configuration example into a text file, save the file with a name, and copy the file to a directory on your routing platform. For example, copy the following configuration to a file and name the file ex-script.conf. Copy the ex-script.conf file to the /var/tmp directory on your routing platform. system { scripts { commit { file ex-script.xsl; } } } interfaces { fxp0 {


xxxix


disable; unit 0 { family inet { address 10.0.0.1/24; } } } } 2. Merge the contents of the file into your routing platform configuration by issuing the

load merge configuration mode command: [edit] user@host# load merge /var/tmp/ex-script.conf load complete

Merging a Snippet To merge a snippet, follow these steps: 1.

From the HTML or PDF version of the manual, copy a configuration snippet into a text file, save the file with a name, and copy the file to a directory on your routing platform. For example, copy the following snippet to a file and name the file ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory on your routing platform. commit { file ex-script-snippet.xsl; }

2. Move to the hierarchy level that is relevant for this snippet by issuing the following

configuration mode command: [edit] user@host# edit system scripts [edit system scripts] 3. Merge the contents of the file into your routing platform configuration by issuing the

load merge relative configuration mode command: [edit system scripts] user@host# load merge relative /var/tmp/ex-script-snippet.conf load complete

For more information about the load command, see the Junos OS CLI User Guide.

Documentation Conventions Table 1 on page xli defines notice icons used in this guide.

xl


About This Guide

Table 1: Notice Icons Icon

Meaning

Description

Informational note

Indicates important features or instructions.

Caution

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

Warning

Alerts you to the risk of personal injury or death.

Laser warning

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

Table 2 on page xli defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions Convention

Description

Examples

Bold text like this

Represents text that you type.

To enter configuration mode, type the configure command: user@host> configure

Fixed-width text like this

Italic text like this

Italic text like this

Text like this

< > (angle brackets)


Represents output that appears on the terminal screen.

user@host> show chassis alarms

•

Introduces important new terms.

•

•

Identifies book names.

•

Identifies RFC and Internet draft titles.

A policy term is a named structure that defines match conditions and actions.

•

Junos OS System Basics Configuration Guide

•

RFC 1997, BGP Communities Attribute

No alarms currently active

Represents variables (options for which you substitute a value) in commands or configuration statements.

Configure the machine’s domain name:

Represents names of configuration statements, commands, files, and directories; interface names; configuration hierarchy levels; or labels on routing platform components.

•

To configure a stub area, include the stub statement at the [edit protocols ospf area area-id] hierarchy level.

•

The console port is labeled CONSOLE.

Enclose optional keywords or variables.

stub ;

[edit] root@# set system domain-name domain-name

xli


Table 2: Text and Syntax Conventions (continued) Convention

Description

Examples

| (pipe symbol)

Indicates a choice between the mutually exclusive keywords or variables on either side of the symbol. The set of choices is often enclosed in parentheses for clarity.

broadcast | multicast

# (pound sign)

Indicates a comment specified on the same line as the configuration statement to which it applies.

rsvp { # Required for dynamic MPLS only

[ ] (square brackets)

Enclose a variable for which you can substitute one or more values.

community name members [ community-ids ]

Indention and braces ( { } )

Identify a level in the configuration hierarchy.

; (semicolon)

Identifies a leaf statement at a configuration hierarchy level.

(string1 | string2 | string3)

[edit] routing-options { static { route default { nexthop address; retain; } } }

J-Web GUI Conventions Bold text like this

Represents J-Web graphical user interface (GUI) items you click or select.

> (bold right angle bracket)

Separates levels in a hierarchy of J-Web selections.

•

In the Logical Interfaces box, select All Interfaces.

•

To cancel the configuration, click Cancel.

In the configuration editor hierarchy, select Protocols>Ospf.

Documentation Feedback We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation. You can send your comments to [email protected], or fill out the documentation feedback form at https://www.juniper.net/cgi-bin/docbugreport/ . If you are using e-mail, be sure to include the following information with your comments: •

Document or topic name

•

URL or page number

•

Software release version (if applicable)

Requesting Technical Support Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,

xlii


About This Guide

or are covered under warranty, and need postsales 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/

•

Find product documentation: http://www.juniper.net/techpubs/

•

Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/

•

Download the latest versions of software and review release notes: http://www.juniper.net/customers/csc/software/

•

Search technical bulletins for relevant hardware and software notifications: https://www.juniper.net/alerts/

•

Join and participate in the Juniper Networks Community Forum: http://www.juniper.net/company/communities/

•

Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/

To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/

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

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

•

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

For international or direct-dial options in countries without toll-free numbers, visit us at http://www.juniper.net/support/requesting-support.html


xliii


xliv


PART 1

Overview •

Routing Protocols Concepts on page 3

•

Complete Routing and Routing Protocol Configuration Statements on page 17


1


2


CHAPTER 1

Routing Protocols Concepts This chapter discusses the following topics: •

Routing Databases Overview on page 3

•

Route Preferences Overview on page 6

•

Understanding BGP Path Selection on page 7

•

Understanding Route Preference Values on page 10

•

Equal-Cost Paths and Load Sharing on page 11

•

IPv6 Overview on page 12

•

IPv6 Standards on page 15

Routing Databases Overview The Junos OS maintains two databases for routing information: •

Routing table—Contains all the routing information learned by all routing protocols.

•

Forwarding table—Contains the routes actually used to forward packets through the router.

In addition, the interior gateway protocols (IGPs), IS-IS, and OSPF maintain link-state databases. This section includes the following topics: •

Routing Protocol Databases on page 3

•

Junos Routing Tables on page 4

•

Forwarding Tables on page 5

•

How the Routing and Forwarding Tables Are Synchronized on page 5

Routing Protocol Databases Each IGP routing protocol maintains a database of the routing information it has learned from other routers running the same protocol and uses this information as defined and required by the protocol. IS-IS and OSPF use the routing information they received to maintain link-state databases, which they use to determine which adjacent neighbors are operational and to construct network topology maps.


3


IS-IS and OSPF use the Dijkstra algorithm, and RIP and RIPng use the Bellman-Ford algorithm to determine the best route or routes (if there are multiple equal-cost routes) to reach each destination and install these routes into the Junos OS routing table. When you configure a protocol on an interface, you must also configure a protocol family on that interface.

Junos Routing Tables The Junos OS routing table is used by the routing protocol process to maintain its database of routing information. In this table, the routing protocol process stores statically configured routes, directly connected interfaces (also called direct routes or interface routes), and all routing information learned from all routing protocols. The routing protocol process uses this collected routing information to select the active route to each destination, which is the route that actually is used to forward packets to that destination. By default, the Junos OS maintains three routing tables: one for unicast routes, another for multicast routes, and a third for MPLS. You can configure additional routing tables to support situations where you need to separate a particular group of routes or where you need greater flexibility in manipulating routing information. In general, most operations can be performed without resorting to the complexity of additional routing tables. However, creating additional routing tables has several specific uses, including importing interface routes into more than one routing table, applying different routing policies when exporting the same route to different peers, and providing greater flexibility with incongruent multicast topologies. Each routing table is identified by a name, which consists of the protocol family followed by a period and a small, nonnegative integer. The protocol family can be inet (Internet), iso (ISO), or mpls (MPLS). The following names are reserved for the default routing tables maintained by the Junos OS: •

inet.0—Default IP version 4 (IPv4) unicast routing table

•

inet6.0—Default IP version 6 (IPv6) unicast routing table

•

instance-name.inet.0—Unicast routing table for a particular routing instance

•

inet.1—Multicast forwarding cache

•

inet.2—Unicast routes used for multicast reverse path forwarding (RPF) lookup

•

inet.3—MPLS routing table for path information

•

mpls.0—MPLS routing table for label-switched path (LSP) next hops

NOTE: For clarity, this manual contains general discussions of routing tables as if there were only one table. However, when it is necessary to distinguish among the routing tables, their names are explicitly used.

4


Chapter 1: Routing Protocols Concepts

Forwarding Tables The Junos OS installs all active routes from the routing table into the forwarding table. The active routes are used to forward packets to their destinations. The Junos OS kernel maintains a master copy of the forwarding table. It copies the forwarding table to the Packet Forwarding Engine, which is the part of the router responsible for forwarding packets.

How the Routing and Forwarding Tables Are Synchronized The Junos OS routing protocol process is responsible for synchronizing the routing information between the routing and forwarding tables. To do this, the routing protocol process calculates the active routes from all the routes in the routing table and installs them into the forwarding table. The routing protocol process then copies the forwarding table to the router’s Packet Forwarding Engine, the part of the router that forwards packets. Figure 1 on page 5 illustrates how the routing tables are synchronized.

Figure 1: Synchronizing Routing Exchange Between the Routing and Forwarding Tables


5


Route Preferences Overview For unicast routes, the Junos OS routing protocol process uses the information in its routing table, along with the properties set in the configuration file, to choose an active route for each destination. While the Junos OS might know of many routes to a destination, the active route is the preferred route to that destination and is the one that is installed in the forwarding table and used when actually routing packets. The routing protocol process generally determines the active route by selecting the route with the lowest preference value. The preference value is an arbitrary value in the range 32 from 0 through 4,294,967,295 (2 – 1) that the software uses to rank routes received from different protocols, interfaces, or remote systems. The preference value is used to select routes to destinations in external autonomous systems (ASs) or routing domains; it has no effect on the selection of routes within an AS (that is, within an interior gateway protocol [IGP]). Routes within an AS are selected by the IGP and are based on that protocol’s metric or cost value. This section includes the following topics: •

Alternate and Tiebreaker Preferences on page 6

•

Multiple Active Routes on page 6

Alternate and Tiebreaker Preferences The Junos OS provides support for alternate and tiebreaker preferences, and some of the routing protocols, including BGP and label switching, use these additional preferences. With these protocols, you can specify a primary route preference (by including the preference statement in the configuration), and a secondary preference that is used as a tiebreaker (by including the preference2 statement). You can also mark route preferences with additional route tiebreaker information by specifying a color and a tiebreaker color (by including the color and color2 statements in the configuration). For configuration instructions, see “Configuring a Preference Value for Static Routes” on page 74, “Configuring a Preference Value for Aggregate Routes” on page 98, and “Configuring a Preference Value for Generated Routes” on page 106. The software uses a 4-byte value to represent the route preference value. When using the preference value to select an active route, the software first compares the primary route preference values, choosing the route with the lowest value. If there is a tie and a secondary preference has been configured, the software compares the secondary preference values, choosing the route with the lowest value. The secondary preference values must be included in a set for the preference values to be considered.

Multiple Active Routes The IGPs compute equal-cost multipath next hops, and IBGP picks up these next hops. When there are multiple, equal-cost next hops associated with a route, the routing protocol process installs only one of the next hops in the forwarding path with each route, randomly selecting which next hop to install. For example, if there are 3 equal-cost paths to an exit routing device and 900 routes leaving through that routing device, each path

6



ends up with about 300 routes pointing at it. This mechanism provides load distribution among the paths while maintaining packet ordering per destination. BGP multipath does not apply to paths that share the same MED-plus-IGP cost yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.

Understanding BGP Path Selection For each prefix in the routing table, the routing protocol process selects a single best path. After the best path is selected, the route is installed in the routing table. The best path becomes the active route if the same prefix is not learned by a protocol with a lower (more preferred) global preference value. The algorithm for determining the active route is as follows: 1.

Verify that the next hop can be resolved.

2. Choose the path with the lowest preference value (routing protocol process

preference). Routes that are not eligible to be used for forwarding (for example, because they were rejected by routing policy or because a next hop is inaccessible) have a preference of –1 and are never chosen. 3. For BGP, prefer the path with higher local preference.

For non-BGP paths, choose the path with the lowest preference2 value. 4. For BGP, prefer the path with the shortest autonomous system (AS) path value

(skipped if the as-path-ignore statement is configured). A confederation segment (sequence or set) has a path length of 0. An AS set has a path length of 1. 5. For BGP, prefer the route with the lower origin code.

Routes learned from an interior gateway protocol (IGP) have a lower origin code than those learned from an exterior gateway protocol (EGP), and both have lower origin codes than incomplete routes (routes whose origin is unknown). 6. For BGP, prefer the path with the lowest multiple exit discriminator (MED) metric.

Depending on whether nondeterministic routing table path selection behavior is configured, there are two possible cases: •

If nondeterministic routing table path selection behavior is not configured (that is, if the path-selection cisco-nondeterministic statement is not included in the BGP configuration), for paths with the same neighboring AS numbers at the front of the AS path, prefer the path with the lowest MED metric. To always compare MEDs whether or not the peer ASs of the compared routes are the same, include the path-selection always-compare-med statement.

•

If nondeterministic routing table path selection behavior is configured (that is, the path-selection cisco-nondeterministic statement is included in the BGP configuration), prefer the path with the lowest MED metric.


7


Confederations are not considered when determining neighboring ASs. A missing MED metric is treated as if a MED were present but zero.

NOTE: MED comparison works for single path selection within an AS (when the route does not include an AS path), though this usage Is uncommon.

7. Prefer strictly internal paths, which include IGP routes and locally generated routes

(static, direct, local, and so forth). 8. Prefer strictly external BGP (EBGP) paths over external paths learned through internal

BGP (IBGP) sessions. 9. For BGP, prefer the path whose next hop is resolved through the IGP route with the

lowest metric.

NOTE: A path is considered a BGP equal-cost path (and will be used for forwarding) if a tie-break is performed after the previous step. All paths with the same neighboring AS, learned by a multipath-enabled BGP neighbor, are considered. BGP multipath does not apply to paths that share the same MED-plus-IGP cost yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.

10. For BGP, if both paths are external, prefer the currently active path to minimize

route-flapping. This rule is not used if: •

path-selection external-router-id is configured.

•

Both peers have the same router ID.

•

Either peer is a confederation peer.

•

Neither path is the current active path.

11. For BGP, prefer the path from the peer with the lowest router ID. For any path with an

originator ID attribute, substitute the originator ID for the router ID during router ID comparison. 12. For BGP, prefer the path with the shortest cluster list length. The length is 0 for no list. 13. For BGP, prefer the path from the peer with the lowest peer IP address.

By default, only the multiple exit discriminators (MEDs) of routes that have the same peer autonomous systems (ASs) are compared. You can configure routing table path selection options to obtain different behaviors. The third step of the algorithm, by default, evaluates the length of the AS path and determines the active path. You can configure an option that enables Junos OS to skip this third step of the algorithm by including the as-path-ignore option.

8



NOTE: The as-path-ignore option is not supported for routing instances.

To configure routing table path selection behavior, include the path-selection statement: path-selection { (always-compare-med | cisco-non-deterministic | external-router-id); as-path-ignore; med-plus-igp { igp-multiplier number; med-multiplier number; } }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. Routing table path selection can be configured in one of the following ways: •

Using the same nondeterministic behavior as does the Cisco IOS software (cisco-non-deterministic). This behavior has two effects: •

The active path is always first. All nonactive but eligible paths follow the active path and are maintained in the order in which they were received, with the most recent path first. Ineligible paths remain at the end of the list.

•

When a new path is added to the routing table, path comparisons are made without removing from consideration those paths that should never be selected because those paths lose the MED tie-breaking rule.

NOTE: The result of these two effects is that the system only sometimes compares the MED values between paths that it should otherwise compare. Because of this, we recommend that you not configure nondeterministic behavior.

•

Always comparing MEDs whether or not the peer ASs of the compared routes are the same (always-compare-med).

•

Comparing the router ID between external BGP paths to determine the active path (external-router-id). By default, router ID comparison is not performed if one of the external paths is active. You can force the router ID comparison by restarting the routing process with the restart routing operational-mode command.

•

Adding the IGP cost to the next-hop destination to the MED value before comparing MED values for path selection. BGP multipath does not apply to paths that share the same MED-plus-IGP cost, yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.


9


Related Documentation

•

Example: Ignoring the AS Path Attribute When Selecting the Best Path on page 1153

•

Example: Always Comparing MEDs

Understanding Route Preference Values The Junos OS routing protocol process assigns a default preference value (also known as an administrative distance) to each route that the routing table receives. The default value depends on the source of the route. The preference value is a value from 0 32 through 4,294,967,295 (2 – 1), with a lower value indicating a more preferred route. Table 3 on page 10 lists the default preference values.

Table 3: Default Route Preference Values How Route Is Learned

Default Preference

Statement to Modify Default Preference

Directly connected network

0

–

System routes

4

–

Static and Static LSPs

5

static

RSVP-signaled LSPs

7

RSVP preference as described in the Junos OS MPLS

Applications Configuration Guide LDP-signaled LSPs

9

LDP preference, as described in the Junos OS MPLS

Applications Configuration Guide

10

OSPF internal route

10

OSPF preference

IS-IS Level 1 internal route

15

IS-IS preference


18

IS-IS preference

Redirects

30

–

Kernel

40

–

SNMP

50

–

Router discovery

55

–

RIP

100

RIP preference

RIPng

100

RIPng preference

PIM

105

Junos OS Multicast Protocols Configuration Guide

DVMRP

110




Table 3: Default Route Preference Values (continued) How Route Is Learned

Default Preference


Aggregate

130

aggregate

OSPF AS external routes

150

OSPF external-preference

IS-IS Level 1 external route

160

IS-IS external-preference


165


BGP

170

BGP preference, export, import

MSDP

175


In general, the narrower the scope of the statement, the higher precedence its preference value is given, but the smaller the set of routes it affects. To modify the default preference value for routes learned by routing protocols, you generally apply routing policy when configuring the individual routing protocols. You also can modify some preferences with other configuration statements, which are indicated in the table. Related Documentation

•

Junos OS Routing Policy Configuration Guide

Equal-Cost Paths and Load Sharing For equal-cost paths, load sharing is based on the BGP next hop. For example, if four prefixes all point to a next hop and there is more than one equal-cost path to that next hop, the routing protocol process uses a hash algorithm to choose the path among the four prefixes. Also, for each prefix, the routing protocol process installs a single forwarding entry pointing along one of the paths. The routing software does not rehash the path taken as prefixes pointing to the next hop come and go, but it does rehash if the number of paths to the next hop changes. Because a prefix is tied to a particular path, packet reordering should not happen. The degree of load sharing improves as the number of prefixes increases.


11


IPv6 Overview IP version 6 (IPv6) is the latest version of IP. IP enables numerous nodes on different networks to interoperate seamlessly. IP version 4 (IPv4) is currently used in intranets and private networks, as well as the Internet. IPv6 is the successor to IPv4, and is based for the most part on IPv4. IPv4 has been widely deployed and used to network the Internet today. With the rapid growth of the Internet, enhancements to IPv4 are needed to support the influx of new subscribers, Internet-enabled devices, and applications. IPv6 is designed to enable the global expansion of the Internet. IPv6 builds upon the functionality of IPv4, providing improvements to addressing, configuration and maintenance, and security. IPv6 offers the following benefits: •

Expanded addressing capabilities—IPv6 provides a larger address space. IPv6 addresses consist of 128 bits, while IPv4 addresses consist of 32 bits. 128-bit addressing increases the address space by approximately 1029 unique addresses, enough to last for the forseeable future.

•

Header format simplification—IPv6 packet header format is designed to be efficient. IPv6 standardizes the size of the packet header to 40 bytes, divided into 8 fields.

•

Improved support for extensions and options—Extension headers carry Internet-layer information and have a standard size and structure.

•

Flow labeling capability—Flow labels provide consistent handling of packets belonging to the same flow.

•

Improved privacy and security—IPv6 supports extensions for authentication and data integrity, which enhance privacy and security.

This section discusses the following topics: •

IPv6 Packet Headers on page 12

•

IPv6 Addressing on page 13

IPv6 Packet Headers IPv6 headers are different from IPv4 headers. This section discusses the following topics that provide background information about IPv6 headers:

12

•

Header Structure on page 13

•

Extension Headers on page 13



Header Structure IPv6 packet headers contain many of the fields found in IPv4 packet headers; some of these fields have been modified from IPv4. The 40-byte IPv6 header consists of the following 8 fields: •

Traffic class—Class-of-service (CoS) priority of the packet. Previously the type-of-service (ToS) field in IPv4. However, the semantics of this field (for example, DiffServ code points) are identical to IPv4.

•

Destination address—Final destination node address for the packet.

•

Flow label—Packet flows requiring a specific class of service. The flow label identifies all packets belonging to a specific flow, and routers can identify these packets and handle them in a similar fashion.

•

Hop limit—Maximum number of hops allowed. Previously the time-to-live (TTL) field in IPv4.

•

Next header—Next extension header to examine. Previously the protocol field in IPv4.

•

Payload length—Length of the IPv6 payload. Previously the total length field in IPv4.

•

Source address—Address of the source node sending the packet.

•

Version—Version of IP.

Extension Headers In IPv6, extension headers are used to encode optional Internet-layer information. Extension headers are placed between the IPv6 header and the upper layer header in a packet. Extension headers are chained together using the next header field in the IPv6 header. The next header field indicates to the router which extension header to expect next. If there are no more extension headers, the next header field indicates the upper layer header (TCP header, User Datagram Protocol [UDP] header, ICMPv6 header, an encapsulated IP packet, or other items).

IPv6 Addressing IPv6 uses a 128-bit addressing model. This creates a much larger address space than IPv4 addresses, which are made up of 32 bits. IPv6 addresses also contain a scope field that categorizes what types of applications are suitable for the address. IPv6 does not support broadcast addresses, but instead uses multicast addresses to serve this role. In addition, IPv6 also defines a new type of address called anycast. This section discusses the following topics that provide background information about IPv6 addressing: •

Address Representation on page 14

•

Address Types on page 14


13


•

Address Scope on page 14

•

Address Structure on page 14

Address Representation IPv6 addresses consist of 8 groups of 16-bit hexadecimal values separated by colons (:). The IPv6 address format is as follows: aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa aaaa is a 16-bit hexadecimal value, and a is a 4-bit hexadecimal value. Following is an

example of an actual IPv6 address: 3FFE:0000:0000:0001:0200:F8FF:FE75:50DF

You can omit the leading zeros, as shown: 3FFE:0:0:1:200:F8FF:FE75:50DF

You can compress 16-bit groups of zeros to the notation :: (two colons), as shown here, but only once per address: 3FFE::1:200:F8FF:FE75:50DF

Address Types There are three types of IPv6 addresses: •

Unicast—For a single interface.

•

Multicast—For a set of interfaces on the same physical medium. A packet is sent to all of the interfaces associated with the address.

•

Anycast—For a set of interfaces on different physical mediums. A packet is sent to only one of the interfaces associated with this address, not to all the interfaces.

Address Scope IPv6 addresses have scope, which identifies the application suitable for the address. Unicast and multicast addresses support scoping. Unicast addresses support two types of scope: global scope and local scope. There are two types of local scope: link-local addresses and site-local addresses. Link-local unicast addresses are used within a single network link. The first ten bits of the prefix identify the address as a link-local address. Link-local addresses cannot be used outside a network link. Site-local unicast addresses are used within a site or intranet. A site consists of multiple network links, and site-local addresses identify nodes inside the intranet. Site-local addresses cannot be used outside the site. Multicast addresses support 16 different types of scope, including node, link, site, organization, and global scope. A 4-bit field in the prefix identifies the scope.

Address Structure Unicast addresses identify a single interface. The address consists of n bits for the prefix, and 128 – n bits for the interface ID.

14



Multicast addresses identify a set of interfaces. The address is made up of the first 8 bits of all ones, a 4-bit flags field, a 4-bit scope field, and a 112-bit group ID: 11111111 | flags | scope | group ID

The first octet of ones identifies the address as a multicast address. The flags field identifies whether the multicast address is a well-known address or a transient multicast address. The scope field identifies the scope of the multicast address. The 112-bit group ID identifies the multicast group. Similar to multicast addresses, anycast addresses identify a set of interfaces. However, packets are sent to only one of the interfaces, not to all interfaces. Anycast addresses are allocated from the normal unicast address space and cannot be distinguished from a unicast address in format. Therefore, each member of an anycast group must be configured to recognize certain addresses as anycast addresses.

IPv6 Standards IPv6 is defined in the following documents: •

RFC 1981, Path MTU Discovery for IP version 6

•

RFC 2373, IP Version 6 Addressing Architecture

•

RFC 2460, Internet Protocol, Version 6 (IPv6)

•

RFC 2461, Neighbor Discovery for IP Version 6

•

RFC 2462, IPv6 Stateless Address Auto configuration

•

RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6

•

RFC 2464, Transmission of IPv6 Packets over Ethernet Networks

•

RFC 2472, IP Version 6 over PPP

•

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

•

RFC 2675, IPv6 Jumbo grams

•

RFC 2767, Dual Stack Hosts using the “Bump-In-the-Stack” Technique (BIS)

•

RFC 2878, PPP Bridging Control Protocol

•

RFC 2893, Transition Mechanisms for IPv6 Hosts and Routers

•

Internet draft draft-ietf-dhc-dhcpv6-16.txt, Dynamic Host Configuration Protocol for IPv6 (expires May 2001)

•

Internet draft draft-kato-bgp-ipv6-link-local-00.txt, BGP4+ Peering Using IPv6 Link-local Address (expires April 2002)

•

Internet draft draft-ietf-idr-flow-spec-00.txt, Dissemination of Flow Specification Rules

To access Internet Requests for Comments (RFCs) and drafts, see http://www.ietf.org.


15


16


CHAPTER 2

Complete Routing and Routing Protocol Configuration Statements For a list of the complete configuration statement hierarchy, see the Junos OS Hierarchy and RFC Reference. This chapter is organized as follows: •

[edit logical-systems] Hierarchy Level on page 17

•

[edit protocols] Hierarchy Level on page 18

•

[edit routing-instances] Hierarchy Level on page 35

•

[edit routing-options] Hierarchy Level on page 40

[edit logical-systems] Hierarchy Level The following lists the statements that can be included at the [edit logical-systems] hierarchy level and are also documented in this manual. logical-systems { logical-system-name { protocols { bgp { bgp-configuration; } isis { isis-configuration; } ospf { ospf-configuration; } ospf3 { ospf3-configuration; } rip { rip-configuration; } ripng { ripng-configuration; } router-advertisement {


17


router-advertisement-configuration; } router-discovery { router-discovery-configuration; } } routing-instances { routing-instance-name { routing-instance-configuration; } } routing-options { routing-option-configuration; } } }

[edit protocols] Hierarchy Level The following statements can also be included at the [edit logical-systems logical-system-name] hierarchy level. protocols {

BGP Global

18

bgp { accept-remote-nexthop; advertise-external ; advertise-inactive; (advertise-peer-as | noadvertise-peer-as); authentication-algorithm algorithm; authentication-key key; authentication-key-chain key-chain; bfd-liveness-detection{ authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } holddown-interval milliseconds; minimum-interval milliseconds; minimum-receive-interval milliseconds; no-adaptation; session-mode (automatic | multihop | single-hop); transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (1 | automatic); } cluster cluster-identifier; damping; description text-description;


Chapter 2: Complete Routing and Routing Protocol Configuration Statements

disable; export [ policy-names ]; family family-name{ ... family-configuration ... graceful-restart { disable; restart-time seconds; stale-routes-time seconds; } group group-name { ... group-configuration ... } hold-time seconds; idle-after-switch-over (seconds | forever); import [ policy-names ]; include-mp-next-hop; ipsec-sa ipsec-sa; keep (all | none); local-address address; local-as autonomous-system ; local-interface interface-name; local-preference local-preference; log-updown; metric-out (metric | igp (delay-med-update | ) | minimum-igp ); mtu-discovery; multihop { no-nexthop-change; ttl ttl-value; } no-aggregator-id; no-client-reflect; outbound-route-filter{ bgp-orf-cisco-mode; prefix-based { accept { (inet | inet6); } } } out-delay seconds; passive; path-selection { (cisco-non-deterministic | always-compare-med | external-router-id); med-plus-igp { igp-multiplier number; med-multiplier number; } } peer-as autonomous-system; preference preference; remove-private; tcp-mss segment-size; traceoptions { file filename ; flag flag ;


19


} vpn-apply-export; }

BGP Family

20

family { (inet | inet6 | inet-vpn | inet6-vpn | iso-vpn) { (any | flow | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown ; } add-path { send { path-count number; prefix-policy [ policy-names ]; } receive; } ; prefix-limit { maximum number; teardown ; } rib-group group-name; } flow{ no-validate policy-name; } labeled-unicast { accepted-prefix-limit { maximum number; teardown ; } aggregate-label { community community-name: } explicit-null { connected-only; } prefix-limit { maximum number; teardown ; } resolve-vpn; rib inet.3; rib-group group-name; } } route-target { accepted-prefix-limit { maximum number; teardown ; } advertise-default; external-paths number; prefix-limit {



maximum number; teardown ; } } (inet-mdt | inet-mvpn | inet6-mvpn | l2-vpn) { signaling { accepted-prefix-limit { maximum number; teardown ; } ; prefix-limit { maximum number; teardown ; } rib-group group-name } } }

BGP Group

group group-name { accept-remote-nexthop; advertise-external ; advertise-inactive; advertise-peer-as; allow ([ network/mask-length ] | all); as-override; authentication-algorithm algorithm; authentication-key key; authentication-key-chain key-chain; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } holddown-interval milliseconds; minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; session-mode (automatic | multihop | single-hop);transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } cluster cluster-identifier; damping; description text-description; export [ policy-names ]; family { (inet | inet6 | inet-vpn | inet6-vpn | iso-vpn) {


21


(any | flow | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown ; } add-path { send { path-count number; prefix-policy [ policy-names ]; } receive; } ; prefix-limit { maximum number; teardown ; } rib-group group-name; } flow { no-validate policy-name; } labeled-unicast { accepted-prefix-limit { maximum number; teardown ; } aggregate-label { community community-name: } explicit-null { connected-only; } prefix-limit { maximum number; teardown ; } resolve-vpn; rib inet.3; rib-group group-name; } } route-target { accepted-prefix-limit { maximum number; teardown ; } advertise-default; external-paths number; prefix-limit { maximum number; teardown ; } } (inet-mdt | inet-mvpn | inet6-mvpn | l2-vpn) { signaling {

22



accepted-prefix-limit { maximum number; teardown ; } ; prefix-limit { maximum number; teardown ; } rib-groupgroup-name } } } graceful-restart { disable; restart-time seconds; stale-routes-time seconds; } hold-time seconds; idle-after-switch-over (seconds | forever); import [ policy-names ]; include-mp-next-hop; ipsec-sa ipsec-sa; keep (all | none); local-address address; local-as autonomous-system ; local-interface; local-preference local-preference; log-updown; metric-out (metric | minimum-igp | igp ); mtu-discovery; multihop ; multipath { multiple-as; } no-advertise-peer-as; no-aggregator-id; no-client-reflect; outbound-route-filter { bgp-orf-cisco-mode; prefix-based { accept { (inet | inet6); } } } out-delay seconds; passive; peer-as autonomous-system; preference preference; remove-private; tcp-mss segment-size; traceoptions { file filename ; flag flag ; }


23


type type; vpn-apply-export;

BGP Neighbor

24

neighbor address { accept-remote-nexthop; advertise-external ; advertise-inactive; advertise-peer-as; as-override; authentication-algorithm algorithm; authentication-key key; authentication-key-chain key-chain; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; session-mode (automatic | multihop | single-hop); transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } cluster cluster-identifier; damping; description text-description; export [ policy-names ]; family{ (inet | inet6 | inet-vpn | inet6-vpn | iso-vpn) { (any | flow | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown ; } add-path { send { path-count number; prefix-policy [ policy-names ]; } receive; } ; prefix-limit { maximum number; teardown ; } rib-group group-name;



} flow { no-validate policy-name; } labeled-unicast { accepted-prefix-limit { maximum number; teardown ; } aggregate-label { community community-name: } explicit-null { connected-only; } prefix-limit { maximum number; teardown ; } resolve-vpn; rib inet.3; rib-group group-name; } } route-target { accepted-prefix-limit { maximum number; teardown ; } advertise-default; external-paths number; prefix-limit { maximum number; teardown ; } } (inet-mdt | inet-mvpn | inet6-mvpn | l2-vpn) { signaling { accepted-prefix-limit { maximum number; teardown ; } ; prefix-limit { maximum number; teardown ; } rib-group group-name } } } graceful-restart { disable; restart-time seconds; stale-routes-time seconds; }


25


hold-time seconds; idle-after-switch-over (seconds | forever); import [ policy-names ]; include-mp-next-hop; ipsec-sa ipsec-sa; keep (all | none); local-address address; local-as autonomous-system ; local-interface interface-name; local-preference local-preference; log-updown; metric-out (metric | minimum-igp | igp ); mtu-discovery; multihop ; multipath { multiple-as; } no-advertise-peer-as; no-aggregator-id; no-client-reflect; out-delay seconds; outbound-route-filter { bgp-orf-cisco-mode; prefix-based { accept { (inet | inet6); } } } passive; peer-as autonomous-system; preference preference; remove-private; tcp-mss segment-size; traceoptions { file filename ; flag flag ; } vpn-apply-export;

IS-IS

26

isis { clns-routing; disable; export [ policy-names ]; graceful-restart { disable; helper-disable; restart-duration seconds; } ignore-attached-bit; interface (all | interface-name) { bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check;



} detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; } checksum; csnp-interval (seconds | disable); disable; hello-padding (adaptive | loose | strict); ldp-synchronization { disable; hold-time seconds; } level level-number { disable; hello-authentication-key key; hello-authentication-key-chain key-chain-name; hello-authentication-type authentication; hello-interval seconds; hold-time seconds; ipv4-multicast-metric number; ipv6-multicast-metric number; ipv6-unicast-metric number; metric metric; passive; priority number; te-metric metric; } link-protection; lsp-interval milliseconds; mesh-group (value | blocked); no-adjacency-holddown; no-eligible-backup; no-ipv4-multicast; no-ipv6-multicast; no-ipv6-unicast; no-unicast-topology; node-link-protection; passive; point-to-point; } label-switched-path namelevel level metric metric; level level-number { authentication-key key; authentication-key-chain key-chain-name; authentication-type authentication; external-preference preference; ipv6-multicast-metric number; no-csnp-authentication;


27


no-hello-authentication; no-psnp-authentication; preference preference; prefix-export-limit number; wide-metrics-only; } loose-authentication-check; lsp-lifetime seconds; max-areas number; no-adjacency-holddown; no-authentication-check; no-ipv4-routing; no-ipv6-routing; overload { advertise-high-metrics; timeout seconds; } reference-bandwidth reference-bandwidth; rib-group { inet group--name; inet6 group--name; } spf-options { delay milliseconds; holddown milliseconds; rapid-runs number; } topologies { ipv4-multicast; ipv6-multicast; ipv6-unicast; } traceoptions { file filename ; flag flag ; } traffic-engineering { disable; family inet { shortcuts { multicast-rpf-routes; } } family inet6 { shortcuts; } } }

OSPF

28

ospf { disable; export [ policy-names ]; external-preference preference; graceful-restart { disable; helper-disable;



notify-duration seconds; restart-duration seconds; } import [ policy-names ]; no-nssa-abr; overload { timeout seconds; } preference preference; reference-bandwidth reference-bandwidth; rib-group group-name; sham-link { local address; } spf-options { delay milliseconds; holddown milliseconds; rapid-runs milliseconds; } traffic-engineering { accept-unnumbered-interfaces; multicast-rpf-routes; no-topology; shortcuts { ignore-lsp-metrics; lsp-metric-into-summary; } } traceoptions { file filename ; flag flag ; } area area-id { area-range network/mask-length ; interface interface-name { demand-circuit; disable; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); }


29


ipsec-sa name; } no-interface-state-traps; authentication { md5 key-id { key [ key-values ]; } simple-password key-id; } dead-interval seconds; hello-interval seconds; interface-type type; ldp-synchronization { disable; hold-time seconds; } metric metric; neighbor address ; network-summary-export [ policy-names ]; network-summary-import [ policy-names ]; passive; poll-interval seconds; priority number; retransmit-interval seconds; te-metric metric; transit-delay seconds; } label-switched-path name metric metric; nssa { area-range network/mask-length ; default-lsa { default-metric metric; metric-type type; type-7; } (no-summaries | summaries); } peer-interface interface-name { disable; dead-interval seconds; hello-interval seconds; retransmit-interval seconds; transit-delay seconds; } sham-link-remote address { ipsec-sa name; } demand-circuit; metric metric; } stub ; virtual-link neighbor-id router-id transit-area area-id { disable; ipsec-sa name; } authentication {

30



md5 key-id; simple-password key-id; } dead-interval seconds; hello-interval seconds; retransmit-interval seconds; transit-delay seconds;

OSPFv3

ospf3 { disable; export [ policy-names ]; external-preference preference; import [ policy-names ]; overload { timeout seconds; } preference preference; reference-bandwidth reference-bandwidth; rib-group group-name; spf-options { delay milliseconds; holddown milliseconds; rapid-runs number; } traceoptions { file filename ; flag flag ; } area area-id { area-range network/mask-length ; interface interface-name { disable; dead-interval seconds; hello-interval seconds; ipsec-sa name; metric metric; neighbor address ; passive; priority number; retransmit-interval seconds; transit-delay seconds; } inter-area-prefix-export [policy-names ]; inter-area-prefix-import [ policy-names ]; nssa { area-range network/mask-length ; default-lsa { default-metric metric; metric-type type; type-7; } (no-summaries | summaries); } stub ; virtual-link neighbor-id router-id transit-area area-id { disable;


31


dead-interval seconds; hello-interval seconds; ipsec-sa name; retransmit-interval seconds; transit-delay seconds; } } }

RIP

32

rip { any-sender; authentication-key password; authentication-type type; (check-zero | no-check-zero); graceful-restart { disable; restart-time seconds; } holddown seconds; import [ policy-names ]; message-size number; metric-in metric; receive receive-options; rib-group group-name; route-timeout seconds; send send-options; update-interval seconds; traceoptions { file filename ; flag flag ; } group group-name { bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (0 | 1 | automatic); } export [ policy-names ]; metric-out metric; preference preference; route-timeout seconds; update-interval seconds;



neighbor neighbor-name { authentication-key password; authentication-type type; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (1 | automatic); } (check-zero | no-check-zero); import [ policy-names ]; message-size number; metric-in metric; receive receive-options; route-timeout seconds; send send-options; update-interval seconds; } } }

RIPng

ripng { graceful-restart { disable; restart-time seconds; } holddown seconds; import [ policy-names ]; metric-in metric; receive ; route-timeout seconds; send ; update-interval seconds; traceoptions { file filename ; flag flag ; } group group-name { export [ policy-names ]; metric-out metric; preference number; route-timeout seconds; update-interval seconds; neighbor neighbor-name {


33


import [ policy-names ]; metric-in metric; receive ; route-timeout seconds; send ; update-interval seconds; } } }

Router Advertisement

34

router-advertisement { interface interface-name { current-hop-limit number; default-lifetime seconds; (link-mtu | no-link-mtu); (managed-configuration | no-managed-configuration); max-advertisement-interval seconds; min-advertisement-interval seconds; (other-stateful-configuration | no-other-stateful-configuration); prefix prefix { (autonomous | no-autonomous); (on-link | no-on-link); preferred-lifetime seconds; valid-lifetime seconds; } reachable-time milliseconds; retransmit-timer milliseconds; traceoptions { file filename ; flag flag ; } } }

Router Discovery

router-discovery { disable; interface interface-name { min-advertisement-interval seconds; max-advertisement-interval seconds; lifetime seconds; } address address { (advertise | ignore); (broadcast | multicast); (priority number | ineligible); } }

Secure Neighbor Discovery

neighbor-discovery { secure { security-level { (default | secure-messages-only); } cryptographic-address { key-length number;



key-pair pathname; } timestamp { clock-drift number; known-peer-window seconds; new-peer-window seconds; } traceoptions { file filename ; flag flag; no-remote-trace; } } }

[edit routing-instances] Hierarchy Level routing-instances { routing-instance-name { bridge-domains bridge-domain-name { domain-type bridge; ; ; ; interface interface-name; bridge-options { interface-mac-limit limit; mac-statistics; mac-table-size limit; no-mac-learning; static-mac mac-address; } } description text; forwarding-options; interface interface-name; instance-type (forwarding | layer2–control | l2vpn | no-forwarding | virtual-router | virtual-switch | vpls | vrf); no-vrf-advertise; no-vrf-propagate-ttl; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; vrf-propagate-ttl; vrf-table-label; vrf-target { export community-name; import community-name; } protocols { bgp { bgp-configuration; } isis {


35


isis-configuration; } l2vpn { l2vpn-configuration; } ldp { ldp-configuration; } msdp { msdp-configuration; } ospf { domain-id domain-id; domain-vpn-tag number; route-type-community (vendor | iana); ospf-configuration; } ospf 3 { domain-id domain-id; domain-vpn-tag number; route-type-community (vendor | iana); ospf3-configuration; } pim { pim-configuration; } rip { rip-configuration; } vpls { vpls-configuration; } } routing-options { aggregate { defaults { ... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... } } auto-export { (disable | enable); family { inet { flow { (disable | enable); rib-group rib-group; } multicast { (disable | enable); rib-group rib-group; } unicast {

36



(disable | enable); rib-group rib-group; } } } traceoptions { file filename ; flag flag ; } } autonomous-system autonomous-system { independent-domain ; } confederation confederation-autonomous-systems members autonomous-system; dynamic-tunnels tunnel-name { destination-prefix prefix; source-address address; tunnel-type type-of-tunnel; } fate-sharing { group group-name; cost value; from address { to address; } flow { route name { match { match-conditions; } then { actions; } } validation { traceoptions { file filename ; flag flag ; } } generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; } } instance-export [ policy-names ]; instance-import [ policy-names ]; interface-routes { family (inet | inet6) { export { lan;


37


point-to-point; } } rib-group group-name; } martians { destination-prefix match-type ; } maximum-paths path-limit ; maximum-prefixes prefix-limit ; multicast { forwarding-cache { threshold (suppress | reuse) value value; } interface interface-name { enable; } scope scope-name { interface interface-name; prefix destination-prefix; } scope-policy policy-name; ssm-groups { addresses; } } options { syslog (level level | upto level); } resolution { rib routing-table-name { import [ policy-names ]; resolution-ribs [ routing-table-names ]; } } rib routing-table-name { aggregate { defaults { ... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... } } filter { input filter-name; } generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; }

38



} martians { destination-prefix match-type ; } static { defaults { static-options; } passive group-name; route destination-prefix { lsp-next-hop { metric metric; preference preference; } next-hop; p2mp-lsp-next-hop { metric metric; preference preference; } qualified-next-hop address { interface interface-name; metric metric; preference preference; } static-options; } } } passive { group-name { import-policy [ policy-names ]; import-rib [ group-names ]; export-rib group-name; } } route-distinguisher-id address; route-record; router-id address; static { defaults { static-options; } rib-group group-name; route destination-prefix { bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } local-address ip-address; minimum-interval milliseconds; minimum-receive-interval milliseconds;


39


minimum-receive-ttl milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (1 | automatic); } lsp-next-hop { metric metric; preference preference; } next-hop; qualified-next-hop address { interface interface-name; metric metric; preference preference; } static-options; } } traceoptions { file filename ; flag flag ; } } } } }

The following statements can also be included at the [edit logical-systems logical-system-name] hierarchy level.

NOTE: The virtual-switch instance type is not supported at the [edit logical-systems logical-system-name] hierarchy level. For more detailed information about configuring a virtual switch on MX Series routers, see the Junos OS Layer 2 Configuration Guide.

[edit routing-options] Hierarchy Level The following statements can also be included at the [edit logical-systems logical-system-name] hierarchy level. routing-options { aggregate { defaults { ... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... }

40



} auto-export { (disable | enable); family { inet { flow { (disable | enable); rib-group rib-group; } multicast { (disable | enable); rib-group rib-group; } unicast { (disable | enable); rib-group rib-group; } } } traceoptions { file filename ; flag flag ; } } autonomous-system autonomous-system ; confederation confederation-autonomous-system members autonomous-system; dynamic-tunnels tunnel-name { destination-prefix prefix; source-address address; tunnel-type tunnel-type; } fate-sharing { group group-name; cost value; from address { to address; } } flow { route name { match { match-conditions; } then { actions; } } validation { traceoptions { file filename ; flag flag ; } } forwarding-table { export [ policy-names ]; (indirect-next-hop | no-indirect-next-hop);


41


unicast-reverse-path (active-paths | feasible-paths); } generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; } } graceful-restart { disable; restart-duration seconds; } instance-export [ policy-names ]; instance-import [ policy-names ]; interface-routes { family (inet | inet6) { export { lan; point-to-point; } } rib-group group-name; } martians { destination-prefix match-type ; } maximum-paths path-limit ; maximum-prefixes prefix-limit ; multicast { forwarding-cache { threshold (suppress | reuse) value value; } interface interface-name { enable; } scope scope-name { interface interface-name; prefix destination-prefix; } scope-policy policy-name; ssm-groups { address; } } options { syslog (level level | upto level); } ppm { delegate-processing; } resolution { rib routing-table-name { import [ policy-names ];

42



resolution-ribs [ routing-table-names ]; } } rib routing-table-name { aggregate { defaults { ... aggregate-options ... } rib-group group-name; route destination-prefix { policy policy-name; ... aggregate-options ... } } filter { input filter-name; } generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; } } martians { destination-prefix match-type ; } static { defaults { static-options; } rib-group group-name; route destination-prefix { lsp-next-hop { metric metric; preference preference; } next-hop; qualified-next-hop address { interface interface-name; metric metric; preference preference; } static-options; } } } rib-groups { group-name { import-policy [ policy-names ]; import-rib [ group-names ]; export-rib group-name; } }


43


route-distinguisher-id address; route-record; router-id address; static { defaults { static-options; } rib-group group-name; route destination-prefix { bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } holddown-interval milliseconds; local-address ip-address; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-receive-ttl number; multiplier number; neighbor address; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } lsp-next-hop { metric metric; preference preference; } next-hop; p2mp-lsp-next-hop { metric metric; preference preference; } qualified-next-hop (address | interface-name) { interface interface-name; metric metric; preference preference; } source-routing { (ip | ipv6); } static-options; } } topologies { (inet | inet6) { topology name; }

44



} traceoptions { file filename ; flag flag ; } } }


45


46


PART 2

Protocol-Independent Routing Properties •

Protocol-Independent Routing Properties Overview on page 49

•

Configuring Routing Tables and Routes on page 59

•

Configuring Other Protocol-Independent Routing Properties on page 119

•

Summary of Protocol-Independent Routing Properties Configuration Statements on page 143


47


48


CHAPTER 3

Protocol-Independent Routing Properties Overview This chapter discusses the following topics related to understanding and configuring protocol-independent routing properties: •

[edit routing-options] Hierarchy Level on page 49

•

Minimum Protocol-Independent Routing Properties Configuration on page 57

[edit routing-options] Hierarchy Level Several statements in the [edit routing-options hierarchy are valid at numerous locations within the hierarchy. To make the complete hierarchy easier to read, the repeated statements are listed in “Common Routing Options” on page 49 and that section is referenced at the appropriate locations in “Complete [edit routing-options] Hierarchy” on page 51. •

Common Routing Options on page 49

•

Complete [edit routing-options] Hierarchy on page 51

Common Routing Options This section lists statements that are valid at the following hierarchy levels, and is referenced at those levels in “Complete [edit routing-options] Hierarchy” on page 51 instead of the statements being repeated. •

[edit routing-options aggregate defaults]

•

[edit routing-options aggregate route ip-prefix]

•

[edit routing-options generate defaults]

•

[edit routing-options generate route ip-prefix]

•

[edit routing-options static defaults]

•

[edit routing-options static route ip-prefix]

The common routing options are as follows: (active | passive); as-path {


49


aggregator as-number address; atomic-aggregate; origin (egp | igp | incomplete); path path-identifier; } color metric ; color2 metric ; community [ community-id no-advertise no-export no-export-subconfed ]; metric metric ; metric2 metric ; metric3 metric ; metric4 metric ; passive; preference preference-value ; preference2 preference-value ; tag metric ; tag2 metric ;

50


Chapter 3: Protocol-Independent Routing Properties Overview

Complete [edit routing-options] Hierarchy The statement hierarchy in this section can also be included at the [edit logical-systems logical-system-name] hierarchy level. routing-options { access { route ip-prefix { metric metric; next-hop [ addresses ]; preference preference-value; qualified-next-hop address; tag route-tag; } } access-internal { route ip-prefix { next-hop [ addresses ]; qualified-next-hop address; tag route-tag; } } aggregate { defaults { ... statements in Common Routing Options on page 49 PLUS ... (brief | full); discard; } route ip-prefix { ... statements in Common Routing Options on page 49 PLUS ... (brief | full); discard; policy [ policy-names ]; } } auto-export { disable; family inet { disable; flow { disable; rib-group rib-group; } multicast { disable; rib-group rib-group; } unicast { disable; rib-group rib-group; } } family inet6 { disable; multicast {


51


disable; rib-group rib-group; } unicast { disable; rib-group rib-group; } } family iso { disable; unicast { disable; rib-group rib-group; } } traceoptions { file filename ; flag flag ; } } autonomous-system autonomous-system ; bgp-orf-cisco-mode; bmp { memory-limit bytes; station-address (ip-address | name); station-port-number port-number; statistics-timeout seconds; } confederation as-number members [ as-numbers ]; dynamic-tunnels tunnel-name { destination-networks prefix; source-address address; tunnel-type tunnel-type; } fate-sharing { group group-name { cost value; from { address ; } } } flow { route name { match { destination address; destination-port [ afs bgp biff bootpc bootps cmd cvspserver dhcp domain eklogin ekshell exec finger ftp ftp-data http https ident imap kerberos-sec klogin kpasswd krb-prop krbupdate kshell ldap ldp login mobileip-agent mobilip-mn msdp netbios-dgm netbios-ns netbios-ssn nfsd nntp ntalk ntp pop3 pptp printer radacct radius rip rkinit smtp snmp snmptrap snpp socks ssh sunrpc syslog tacacs tacacs-ds talk telnet tftp timed who xdmcp ]; dscp [ code-points ]; fragment [ don't-fragment first-fragment is-fragment last-fragment not-a-fragment ];

52



icmp-code [ communication-prohibited-by-filtering destination-host-prohibited destination-host-unknow fragmentation-needed host-precedence-violation host-unreachable host-unreachable-for-tos ip-header-bad network-unreachable network-unreachable-for-tos port-unreachable precedence-cutoff-in-effect protocol-unreachable redirect-for-host redirect-for-network redirect-for-tos-and-host redirect-for-tos-and-net required-option-missing source-host-isolated source-route-failed ttl-eq-zero-during-reassembly ttl-eq-zero-during-transit ]; icmp-type [ echo-reply echo-request info-reply info-request mask-reply mask-request parameter-problem redirect router-advertisement router-solicit source-quench time-exceeded timestamp timestamp-reply unreachable ]; packet-length [ values ]; port [ ... same values as for the preceding destination-port statement ... ]; protocol [ ah egp esp gre icmp igmp ipip ospf pim rsvp sctp tcp udp ]; source address; source-port [ ... same values as for the preceding destination-port statement ... ]; tcp-flags [ ack fin push rst syn urgent ]; } then { (accept | discard); community community-name; next-term; rate-limit value; routing-instance routing-instance-name; sample; } } validation { traceoptions { file filename ; flag flag ; } } } forwarding-table { export [ policy-names ]; (indirect-next-hop | no-indirect-next-hop); unicast-reverse-path (active-paths | feasible-paths); } generate { defaults { ... statements in Common Routing Options on page 49 PLUS ... (brief | full); discard; } route ip-prefix { ... statements in Common Routing Options on page 49 PLUS ... (brief | full); discard; policy [ policy-names ]; } } graceful-restart { disable; restart-duration seconds;


53


} instance-export [ policy-names ]; instance-import [ policy-names ]; interface-routes { family (inet | inet6) { export { lan; point-to-point; } import [ policy-names ]; } rib-group { inet group-name; inet6 group-name; } } l3vpn-composite-nexthop; martians { ip-prefix (exact | longer | orlonger | prefix-length-range /minimum-prefix-length–/maximum-prefix-length | through ip-prefix | upto /prefix-length) ; } maximum-paths path-limit ; maximum-prefixes prefix-limit ; med-igp-update-interval minutes; multicast { ... the multicast subhierarchy appears after the main [edit routing-options] hierarchy ... } nonstop-routing; options { mark seconds; syslog { level level; upto level; } } ppm { no-delegate-processing; } resolution { rib routing-table-name { import [ policy-names ]; resolution-ribs [ routing-table-names ]; } tracefilter [ filter-policy-names ]; traceoptions { file filename ; flag flag ; } } rib routing-table-name { access { ... same statements as at the [edit routing-options access] hierarchy level ... } access-internal {

54



... same statements as at the [edit routing-options access-internal] hierarchy level ... } aggregate { ... same statements as at the [edit routing-options aggregate] hierarchy level ... } generate { ... same statements as at the [edit routing-options generate] hierarchy level ... } martians { ip-prefix (exact | longer | orlonger | prefix-length-range /minimum-prefix-length–/maximum-prefix-length | through ip-prefix | upto /prefix-length) ; } maximum-paths path-limit ; maximum-prefixes prefix-limit ; static { ... same statements as at the [edit routing-options static] hierarchy level ... } } rib-groups { group-name { export-rib table-name; import-policy [ policy-names ]; import-rib [ table-names ]; } } route-distinguisher-id address; route-record; router-id address; source-routing { ip; ipv6; } static { ... the static subhierarchy appears after the main [edit routing-options] hierarchy ... } topologies { family (inet | inet6) { topology topology-name; } } traceoptions { file filename ; flag flag ; } } routing-options { multicast { asm-override-ssm; backup-pe-group group-name { backups [ addresses ]; local-address address; } flow-map flow-map-name {


55


bandwidth ; forwarding-cache { timeout (never | minutes); } policy [ policy-names ]; redundant-sources [ addresses ]; } forwarding-cache { threshold { reuse threshold-value; suppress threshold-value; } timeout minutes; } interface interface-name { maximum-bandwidth bps; no-qos-adjust; reverse-oif-mapping { no-qos-adjust; } subscriber-leave-timer seconds; } pim-to-igmp-proxy { upstream-interface [ interface-names ]; } pim-to-mld-proxy { upstream-interface [ interface-names ]; } rpf-check-policy [ policy-names ]; scope scope-name { interface [ interface-names ]; prefix ip-prefix; } scope-policy [ policy-names ]; ssm-groups [ ip-prefix ]; ssm-map ssm-map-name { policy [ policy-names ]; source [ addresses ]; } traceoptions { file filename ; flag flag ; } } } routing-options { static { defaults { ... statements in Common Routing Options on page 49 PLUS ... (install | no-install); (readvertise | no-readvertise); (resolve | no-resolve); (retain | no-retain); }

56



rib-group group-name; route destination-prefix { ... statements in Common Routing Options on page 49 PLUS ... backup-pe-group group-name; bfd-liveness-detection { detection-time { threshold milliseconds; } holddown-interval milliseconds; local-address ip-address; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-receive-ttl milliseconds; multiplier number; neighbor address; no-adaptation; transmit-interval { minimum-interval milliseconds; threshold milliseconds; } version (1 | automatic); } (discard | next-hop [ addresses ] | next-table address | receive | reject); (install | no-install); lsp-next-hop { metric metric; preference preference; } p2mp-lsp-next-hop lsp-name { metric metric; preference preference; } (readvertise | no-readvertise); (resolve | no-resolve); (retain | no-retain); static-lsp-next-hop lsp-name { metric metric; preference preference-value; } } } }


•

Notational Conventions Used in Junos OS Configuration Hierarchies

Minimum Protocol-Independent Routing Properties Configuration All statements that configure protocol-independent routing properties are optional and do not have to be included in the configuration for the router to operate. However, if you are configuring BGP, you must configure an AS number and a router identifier. For OSPF, the router uses the IP address configured on the loopback interface (lo0) as the router identifier. If no IP address is configured on the loopback interface, the router uses the highest IP address for the router identifier.


57


58


CHAPTER 4

Configuring Routing Tables and Routes This chapter discusses how to perform the following tasks for configuring routing tables and routes: •

Creating Routing Tables on page 60

•

Configuring Static Routes on page 61

•

Configuring the Destination of Static Routes on page 62

•

Configuring the Next Hop for Static Routes on page 63

•

Configuring an Independent Preference for Static Routes on page 64

•

Specifying an LSP as the Next Hop for Static Routes on page 68

•

Installing Static Routes into More than One Routing Table on page 69

•

Configuring CLNS Static Routes on page 70

•

Configuring Static Route Options on page 71

•

Configuring Bidirectional Forwarding Detection on page 81

•

Tracing BFD Protocol Traffic on page 86

•

Overview of BFD Authentication for Static Routes on page 87

•

Configuring BFD Authentication for Static Routes on page 89

•

Configuring Default Routes on page 92

•

Propagating Static Routes into Routing Protocols on page 93

•

Examples: Configuring Static Routes on page 93

•

Configuring Aggregate Routes on page 95

•

Configuring the Destination of Aggregate Routes on page 97

•

Configuring Aggregate Route Options on page 97

•

Applying Policies to Aggregate Routes on page 102

•

Advertising Aggregate Routes on page 103

•

Configuring Generated Routes on page 103

•

Configuring the Destination of Generated Routes on page 105

•

Configuring Generated Route Options on page 105

•

Applying Policies to Generated Routes on page 110

•

Configuring Martian Addresses on page 110


59


•

Configuring Flow Routes on page 113

•

Applying Filters to the Forwarding Table on page 118

Creating Routing Tables The Junos OS can maintain one or more routing tables, thus allowing the software to store route information learned from different protocols separately. For example, it is common for the routing software to maintain unicast routes and multicast routes in different routing tables. You also might have policy considerations that would lead you to create separate routing tables to manage the propagation of routing information. Creating routing tables is optional. If you do not create any, the Junos OS uses its default routing tables, which are inet.0 for IP version 4 (IPv4) unicast routes, inet6.0 for IP version 6 (IPv6) unicast routes, inet.1 for the IPv4 multicast forwarding cache, and inet.3 for IPv4 MPLS. If Multiprotocol BGP (MBGP) is enabled, inet.2 is used for Subsequent Address Family Indicator (SAFI) 2 routes. If you configure a routing instance, the Junos OS creates the default unicast routing table instance-name.inet.0. If you configure a flow route, the Junos OS creates the flow routing table instance-name.inetflow.0. If you want to add static, aggregate, generated, or martian routes only to the default IPv4 unicast routing table (inet.0), you do not have to create any routing tables because, by default, these routes are added to inet.0. You can add these routes just by including the static, aggregate, generate, and martians statements. For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To explicitly create a routing table, include the rib statement and child statements under the rib statement. For a list of child statements and hierarchy levels at which you can include this statement, see the statement summary section for this statement. The routing table name, routing-table-name, includes the protocol family, optionally followed by a period and a number. The protocol family can be inet for the IPv4 family, inet6 for the IPv6 family, or iso for the International Standards Organization (ISO) protocol family. The number represents the routing instance. The first instance is 0.

Example: Creating Routing Tables Create the IPv4 routing table inet.0 and add a static route to it: [edit] routing-options { rib inet.0 { static { route 140.122.0.0/16 next-hop 192.168.0.10; } } }

Configure the primary IPv6 routing table inet6.0 and add a static route to it: [edit routing-options] rib inet6.0 {

60


Chapter 4: Configuring Routing Tables and Routes

static { route 8:1::1/128 next-hop 8:3::1; } }

Configuring Static Routes The routing device uses dynamic routes to learn how to reach network destinations. Dynamic routes are determined from the information exchanged by the routing protocols and, as the name implies, the routes might change as network conditions change and these changes are discovered by the routing protocols. You can configure static (nonchanging) routes to some network destinations. The routing device uses static routes when it does not have a route to a destination that has a better (lower) preference value, when it cannot determine the route to a destination, or when it is forwarding unroutable packets. Static routes are used when the network connects to a routing device or other system outside the network and either that system cannot run a routing protocol or you do not want to run a routing protocol on it. In these situations, a static route is created from an edge routing device to the outside system and then the edge routing device redistributes the static route to IGP. A static route is installed in the routing table only when the route is active; that is, the list of next-hop routing devices configured for that route contains at least one next hop on an operational interface. You can add the same routes to more than one routing table. To configure static routes in the default IPv4 routing table (inet.0), include the static statement and associated child statements. For a list of child statements hierarchy levels at which you can include this statement, see the statement summary section for this statement. To configure static routes in one of the other routing tables, to explicitly configure static routes in the default IPv4 route table (inet.0), or to explicitly configure static routes in the primary IPv6 routing table (inet6.0), include the static statement under the rib statement.

NOTE: You cannot configure static routes for the IPv4 multicast routing table (inet.1) or the IPv6 multicast routing table (inet6.1).

The static statement consists of two parts: •

defaults—(Optional) Specify global static route options. These options only set default

attributes inherited by all newly created static routes. These are treated as global defaults and apply to all the static routes you configure in the static statement.


61


NOTE: Specifying the global static route options does not create default routes. These options only set default attributes inherited by all newly created static routes.

•

route—Configure individual static routes. In this part of the static statement, you

optionally can configure static route options. These options apply to the individual destination only and override any options you configured in the defaults part of the static statement. The following topics provide more information about configuring static routes: •

Configuring the Destination of Static Routes on page 62

•

Configuring the Next Hop for Static Routes on page 63

•


•


•

Installing Static Routes into More than One Routing Table on page 69

•

Configuring CLNS Static Routes on page 70

•

Configuring Static Route Options on page 71

•

Configuring Default Routes on page 92

•

Propagating Static Routes into Routing Protocols on page 93

•

Examples: Configuring Static Routes on page 93

Configuring the Destination of Static Routes When you configure an individual static route in the route part of the static statement, specify the destination of the route (in route destination-prefix) in one of the following ways: •

network/mask-length, where network is the network portion of the IP address and mask-length is the destination prefix length.

•

default if this is the default route to the destination. This is equivalent to specifying an

IP address of 0.0.0.0/0.

NOTE: IPv4 packets with a destination of 0.0.0.0 (the obsoleted limited broadcast address) and IPv6 packets with a destination of 0::0 are discarded by default. To forward traffic destined to these addresses, you can add a static route to 0.0.0.0/32 for IPv4 or 0::0/128 for IPv6.

62



Configuring the Next Hop for Static Routes When you configure an individual static route in the route part of the static statement, specify how to reach the destination (in next-hop) in one of the following ways: •

next-hop address—IPv4 or IPv6 address of the next hop to the destination, specified

as: •

IPv4 or IPv6 address of the next hop

•

Interface name (for point-to-point interfaces only)

•

address or interface-name to specify an IP address of a multipoint interface or an

interface name of a point-to-point interface.

NOTE: If an interface becomes unavailable, all configured static routes on that interface are withdrawn from the routing table.

NOTE: Load balancing is not supported on management and internal Ethernet (fxo) interfaces because this type of interface cannot handle the routing process. On fxp interfaces, you cannot configure multiple next hops and enable load balancing.

•

next-table routing-table-name—Name of the next routing table to the destination.

If you use the next-table action, the configuration must include a term qualifier that specifies a different table than the one specified in the next-table action. In other words, the term qualifier in the from statement must exclude the table in the next-table action. In the following example, the first term contains rib vrf-customer2.inet.0 as a matching condition. The action specifies a next-hop in a different routing table, vrf-customer1.inet.0. The second term does the opposite by using rib vrf-customer1.inet.0 in the match condition and vrf-customer2.inet.0 In the next-table action. term 1 { from { protocol bgp; rib vrf-customer2.inet.0; community customer; } then { next-hop next-table vrf-customer1.inet.0; } } term 2 { from { protocol bgp; rib vrf-customer1.inet.0; community customer; } then {


63


next-hop next-table vrf-customer2.inet.0; } }

NOTE: Within a routing instance, you cannot configure a static route with the next-table inet.0 statement if any static route in the main routing instance is already configured with the next-table statement to point to the inet.0 routing table of the routing instance. For example, if you configure on the main routing instance a static route 192.168.88.88/32 with the next-table test.inet.0 statement and the routing instance test is also configured with a static route 192.168.88.88/32 with the next-table inet.0 statement, the commit operation fails. Instead, you must configure a routing table group both on the main instance and on the routing instance, which enables you to install the static route into both routing tables. For more information, see “Installing Static Routes into More than One Routing Table” on page 69.

•

reject—Do not forward packets addressed to this destination. Instead, drop the packets,

send ICMP (or ICMPv6) unreachable messages to the packets’ originators, and install a reject route for this destination into the routing table. •

discard—Do not forward packets addressed to this destination. Instead, drop the

packets, do not send ICMP (or ICMPv6) unreachable messages to the packets’ originators, and install a reject route for this destination into the routing table. •

receive—Install a route for this next-hop destination into the routing table.

The receive option forces the packet to be sent to the Routing Engine. The receive option can be useful in the following cases: •

For receiving MPLS packets destined to a VRF instance's loopback address

•

For receiving packets on a link's subnet address, with zeros in the host portion of the address

Configuring an Independent Preference for Static Routes Configuring independent preferences allows you to configure multiple static routes with different preferences and metrics to the same destination. The static route with the best preference, metric, and reachable next hop is chosen as the active route. This feature allows you to specify preference and metric on a next-hop basis using the qualified-next-hop statement.

NOTE: The preference and metric options configured by means of this statement only apply to the qualified next hops. The qualified next hop preference and metric override the route preference and metric (for that specific qualified next hop), similar to how the route preference overrides the default preference and metric (for that specific route).

64



To specify an independent preference for a static route on a point-to-point interface or on an Ethernet interface, include the following statements: qualified-next-hop address { interface interface-name; metric metric; preference preference; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Specify a next-hop interface by including the qualified-next-hop option. Specifying a next-hop interface is useful when you are creating a route to an IPv6 link-local next-hop address (which is a link-only scope address and is specific only to an interface). The 32 preference value can be a number from 0 through 4,294,967,295 (2 – 1). A lower number indicates a more preferred route. The metric value can also be a number from 0 through 4,294,967,295. You can configure static routes on an unnumbered Ethernet interface by using the qualified-next-hop option to specify the unnumbered interface as the next-hop interface for a configured static route. To configure an unnumbered Ethernet interface as the next-hop interface for a static route and to specify independent preferences, include the following statements: qualified-next-hop interface-name { metric metric; preference preference; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Keep the following points in mind when you configure static routes for unnumbered Ethernet interfaces: •

The prefix length of the static route must be 32.

•

The routing device uses the Address Resolution Protocol (ARP) to resolve the media access control (MAC) address of the destination interface.

For information about how to configure an unnumbered Ethernet interface, see the Junos OS Network Interfaces Configuration Guide.

NOTE: The qualified-next-hop statement is mutually exclusive with all other types of next hops, except for next-hop address. Therefore, you cannot configure next-hop reject, next-hop discard, and next-hop receive with qualified-next-hop for the same destination.


65


For sample configurations, see the following sections: •

Example: Configuring Independent Preferences for an IPv4 Static Route on page 66

•

Example: Configuring Independent Preferences for an IPv6 Static Route on page 66

•

Example: Configuring Independent Preferences for an Unnumbered Ethernet Interface on page 67

Example: Configuring Independent Preferences for an IPv4 Static Route The following example configures: •

A static route to 0.0.0.0/8 with a next hop through 192.168.1.254, with a metric of 10 and preference of 10.

•

A static route to 10.0.0.0/8 with a next hop through 192.168.1.254, with a metric of 6 and preference of 5.

•

A static route to 10.0.0.0/8 with a next hop through 192.168.1.2, with a metric of 6 and preference of 7. [edit] routing-options { static { defaults { metric 10; preference 10; } route 0.0.0.0/8 { next-hop 192.168.1.254 { retain; no-readvertise; } route 10.0.0.0/8 { next-hop [192.168.1.2]; qualified-next-hop 192.168.1.254 { preference 5; } metric 6; preference 7; } } } }

Example: Configuring Independent Preferences for an IPv6 Static Route Configure the following qualified next hops:

66

•

A static route to fec0:1:1:4::/64 with a next hop through fec0:1:1:2::1, with a metric 10 and preference 10.

•

A static route to fec0:1:1:5::/64 with a next hop through fec0:1:1:2::2, with a metric 6 and preference 5.



•

A static route to fec0:1:1:5::/64 with a next hop through fec0:1:1:2::3, with a metric 6 and preference 7. [edit] routing-options { rib inet6.0 { static { defaults { metric 10; preference 10; } route fec0:1:1:4::/64 { next-hop fec0:1:1:2::1 { retain; no-readvertise; } route fec0:1:1:5::/64 { next-hop fec0:1:1:2::3; qualified-next-hop fec0:1:1:2::2 { preference 5; } metric 6; preference 7; } } } } }

Example: Configuring Independent Preferences for an Unnumbered Ethernet Interface The following example configures two things: •

An unnumbered SONET/SDH interface so-0/0/0, which borrows an IP address from donor interface lo0.

•

A static route to 7.7.7.1/32 with a next hop through unnumbered interface so-0/0/0.0 with a with a metric of 5 and preference of 6. interfaces { lo0 { unit 0 { family inet { address 5.5.5.1/32; address 6.6.6.1/32; } } } } so-0/0/0 { unit 0 { family inet { unnumbered-address lo0.0; } }


67


} routing-options { static { route 7.7.7.1/32 { qualified next-hop so-0/0/0.0 { metric 5; preference 6; } } } }

Specifying an LSP as the Next Hop for Static Routes Static routes can be configured with a next hop that is a label-switched path (LSP). This is useful when implementing filter-based forwarding. You can specify an LSP as the next hop and assign an independent preference and metric to this next hop. To specify an LSP as the next hop for a static route, include the following statements: lsp-next-hop lsp-name { metric metric; preference preference; }

NOTE: The preference and metric configured by means of the lsp-next-hop statement only apply to the LSP next hops. The LSP next-hop preference and metric override the route preference and metric (for that specific LSP next hop), similar to how the route preference overrides the default preference and metric (for that specific route).

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. 32

The preference value can be a number in the range from 0 through 4,294,967,295 (2 – 1) with a lower number indicating a more preferred route. The metric value can also be a number in the range from 0 through 4,294,967,295.

NOTE: The lsp-next-hop statement is mutually exclusive with all other types of next hops, except for next-hop address and qualified-next-hop. Therefore, you cannot configure next-hop reject, next-hop discard, next-hop receive, and next-table with lsp-next-hop for the same destination.

To specify a point-to-multipoint LSP as the next hop for a static route, include the following statements: p2mp-lsp-next-hop { interface interface-name; metric metric; preference preference;

68



}

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Enable the qualified next-hop address on the interface by specifying the interface option. 32 The preference value can be a number from 0 through 4,294,967,295 (2 – 1). A lower number indicates a more preferred route. The metric value can also be a number from 0 through 4,294,967,295.

Installing Static Routes into More than One Routing Table You can install a static route into more than one routing table. For example, you might want a simple configuration that allows you to install a static route into the default routing table inet.0, as well as a second routing table inet.2. Instead of configuring the same static route for each routing table, you can use routing table groups to insert the route into multiple tables. To create a routing table group, include the rib-group statement. For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To install the routing table into a configured routing table group, include the import-rib statement: rib-group group-name { import-rib [ routing-table-names ]; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. The first routing table you list in the import-rib statement must be the one you configured in the rib-group statement.

Examples: Installing a Static Route into More than One Routing Table Install all routes in both inet.0 and inet.2. [edit routing-options] static { rib-group foo; route 1.1.1.0/24 reject; } rib-groups { foo { import-rib [ inet.0 inet.2 ]; } } autonomous-system 65432; user@host> show route protocol static inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1.1.1.0/24


*[Static/5] 00:00:09, metric 0 Reject

69


inet.2: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1.1.1.0/24


Install only some routes in both inet.0 and inet.2, with other routes in inet.0 only. [edit routing-options] rib inet.2 { static { route 1.1.1.0/24 reject; } } static { route 1.1.1.0/24 reject; } autonomous-system 65432; user@host> show route protocol static inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1.1.1.0/24


inet.2: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1.1.1.0/24


Configuring CLNS Static Routes Connectionless Network Services (CLNS) is an ISO Layer 3 protocol that uses network service access point (NSAP) reachability information instead of IPv4 prefixes. You can configure a static route for CLNS networks.

NOTE: CLNS is supported on J Series Services Routers and MX Series routers only.

To configure a CLNS static route, include the following statements: rib (iso.0 | instance-name.iso.0) static { route nsap-prefix { next-hop (interface-name | iso-net); qualified-next-hop (interface-name | iso-net) { metric metric; preference preference; } } }

70



For a list of hierarchy levels at which you can include these statements, see the CLNS statement summary sections in the Junos OS Interfaces and Routing Configuration Guide. Specify the iso.0 routing table option to configure a primary instance CLNS static route. Specify the instance-name.iso.0 routing table option to configure CLNS static route for a particular routing instance. Specify the route nsap-prefix statement to configure the destination for the CLNS static route. Specify the next-hop (interface-name | iso-net) statement to configure the next hop, specified as an ISO network entity title (NET) or interface name. Include the qualified-next-hop (interface-name | iso-net) statement to configure the qualified next hop, specified as an ISO network entity title or interface name.

Example: Configuring a Static CLNS Route Configure a static CLNS route with an NSAP of 47.0005.80ff.f800.0000.ffff.ffff: [edit] routing-options { rib iso.0 { static { iso-route 47.0005.80ff.f800.0000.ffff.ffff next-hop 47.0005.80ff.f800.0000.0108.0001.1921.6800.4212; iso-route 47.0005.80ff.f800.0000.0108.0001.1921.6800.4212 next-hop t1-0/2/2.0; iso-route 47.0005.80ff.f800.0000.eee { qualified-next-hop 47.0005.80ff.f800.0000.0108.0001.1921.6800.4002 { preference 20; metric 10; } } } } }

For information on CLNS, see “Configuring CLNS for IS-IS” on page 402 and the Junos OS Interfaces and Routing Configuration Guide.

Configuring Static Route Options In the defaults and route parts of the static statement, you can specify options that define additional information about static routes that is included with the route when it is installed in the routing table. All static options are optional. Static options that you specify in the defaults part of the static statement are treated as global defaults and apply to all the static routes you configure in the static statement. Static options that you specify in the route part of the static statement override any global static options and apply to that destination only. To configure static route options for IPv4 static routes, include one or more options in the defaults or route part of the static statement. routing-options { static { defaults { (active | passive); as-path ;


71


community [ community-ids ]; (install | no-install); metric metric ; (preference | preference2 | color | color2) preference ; (readvertise | no-readvertise); (retain | no-retain); tag string; } rib-group group-name; route destination-prefix { (active | passive); as-path ; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } local-address ip-address; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-receive-ttl number; multiplier number; neighbor address; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds } version (1 | automatic); } community [ community-ids ]; (install | no-install); metric metric ; (preference | preference2 | color | color2) preference ; (readvertise | no-readvertise); resolve; (retain | no-retain); tag string; } } }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To configure static route options for IPv6 static routes, include one or more options in the defaults or route part of the static statement. Each of these options is explained in the sections that follow. rib inet6.0 { static {

72



defaults { (active | passive); as-path ; community [ community-ids ]; (install | metric); metric metric ; (preference | preference2 | color | color2) preference ; (readvertise | no-readvertise); resolve; (retain | no-retain); } rib-group group-name; route destination-prefix { (active | passive); as-path ; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } local-address ip-address; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-receive-ttl number; multiplier number; neighbor address; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } community [ community-ids ]; (install | no-install); metric metric ; (preference | preference2 | color | color2) preference ; (readvertise | no-readvertise); resolve; (retain | no-retain); } } }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.


73


The following sections explain how to configure static route options: •

Configuring a Metric Value for Static Routes on page 74

•

Configuring a Preference Value for Static Routes on page 74

•

Associating BGP Communities with Static Routes on page 75

•

Associating AS Paths with Static Routes on page 76

•

Configuring an OSPF Tag String for Static Routes on page 77

•

Controlling Temporary Installation of Static Routes in the Forwarding Table on page 77

•

Controlling Retention of Static Routes in the Forwarding Table on page 78

•

Controlling Retention of Inactive Static Routes in the Routing and Forwarding Tables on page 79

•

Controlling Readvertisement of Static Routes on page 80

•

Controlling Resolution of Static Routes to Prefixes That Are Not Directly Connected on page 80

Configuring a Metric Value for Static Routes To associate a metric value with an IPv4 route, include the metric statement: static (defaults | route) { metric metric ; }

To associate a metric value with an IPv6 route, include the metric statement: rib inet6.0 static (defaults | route) { metric metric ; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. In the type option, you can specify the type of route. For OSPF, when routes are exported to OSPF, type 1 routes are advertised in type 1 externals, and routes of any other type are advertised in type 2 externals. Note that if a qualified-next-hop metric value is configured, this value overrides the route metric.

Configuring a Preference Value for Static Routes By default, static routes have a preference value of 5. To modify the default preference value, specify a primary preference value (preference). You also can specify a secondary preference value (preference2) and colors, which are even finer-grained preference values (color and color2). To do this for IPv4 static routes, include one or more of the following statements: static (defaults | route) { (preference | preference2 | color | color2) preference ; }

To do this for IPv6 static routes, include one or more of the following statements: rib inet6.0 static (defaults | route) {

74



(preference | preference2 | color | color2) preference ; }


The preference value can be a number in the range from 0 through 4,294,967,295 (2 – 1) with a lower number indicating a more preferred route. For more information about preference values, see “Route Preferences Overview” on page 6. Note that if a qualified-next-hop preference value is configured, this value overrides the route preference. In the type option, you can specify the type of route.

Associating BGP Communities with Static Routes By default, no BGP community information is associated with static routes. To associate community information with IPv4 routes, include the community statement: static (defaults | route) { community [ community-ids ]; }

To associate community information with IPv6 routes, include the community statement: rib inet6.0 static (defaults | route) { community [ community-ids ]; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. community-ids is one or more community identifiers for either communities or extended

communities. The format for community identifiers is: as-number:community-value as-number is the autonomous system (AS) number and can be a value in the range from 1

through 65,534. community-value is the community identifier and can be a number in the range from 0 through 65,535. You also can specify community-ids as one of the following well-known community names, which are defined in RFC 1997: •

no-export—Routes containing this community name are not advertised outside a

BGP confederation boundary. •

no-advertise—Routes containing this community name are not advertised to other

BGP peers. •

no-export-subconfed—Routes containing this community name are not advertised to

external BGP peers, including peers in other members’ ASs inside a BGP confederation.


75


You can also explicitly exclude BGP community information with a static route using the none option. Include none when configuring an individual route in the route portion of the static statement to override a community option specified in the defaults portion of the statement.

NOTE: Extended community attributes are not supported at the [edit routing-options] hierarchy level. You must configure extended communities at the [edit policy-options] hierarchy level. For information about configuring extended communities information, see the “Defining BGP Communities and Extended Communities for Use in Routing Policy Match Conditions” section in the Junos OS Routing Policy Configuration Guide. For information about configuring 4-byte AS numbers and extended communities, see Configuring 4-Byte AS Numbers and BGP Extended Community Attributes in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview .

Associating AS Paths with Static Routes By default, no AS path information is associated with static routes. To associate AS path information with IPv4 routes, include the as-path statement: static (defaults | route) { as-path ; }

To associate AS path information with IPv6 routes, include the as-path statement: rib inet6.0 static (defaults | route) { as-path ; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. as-path is the AS path to include with the route. It can include a combination of individual

AS path numbers and AS sets. Enclose sets in brackets ( [ ] ). The first AS number in the path represents the AS immediately adjacent to the local AS. Each subsequent number represents an AS that is progressively farther from the local AS, heading toward the origin of the path.

76



NOTE: In Junos OS Release 9.1 and later, the range that you can configure for the AS number has been extended to provide BGP support for 4-byte AS numbers as defined in RFC 4893, BGP Support for Four-octet AS Number Space. You can now configure a number from 1 through 4,294,967,295. All releases of the Junos OS support 2-byte AS numbers. The 2-byte AS number range is 1 through 65,535 (this is a subset of the 4-byte range). In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. You can specify a value in the range from 0.0 through 65535.65535 in AS-dot notation format.

You also can specify the AS path using the BGP origin attribute, which indicates the origin of the AS path information: •

igp—Path information originated within the local AS.

•

egp—Path information originated in another AS.

•

incomplete—Path information learned by some other means.

To attach the BGP ATOMIC_AGGREGATE path attribute to the static route, specify the atomic-aggregate statement. This path attribute indicates that the local system selected a less specific route rather than a more specific route. To attach the BGP AGGREGATOR path attribute to the static route, specify the aggregator statement. When using this statement, you must specify the last AS number that formed the static route (encoded as two octets), followed by the IP address of the BGP system that formed the static route.

Configuring an OSPF Tag String for Static Routes By default, no OSPF tag strings are associated with static routes. You can specify an OSPF tag string by including the tag statement: static (defaults | route) { tag string; }


Controlling Temporary Installation of Static Routes in the Forwarding Table By default, the Junos OS installs all active static routes into the forwarding table. To configure the software not to install active IPv4 static routes into the forwarding table, include the no-install statement:


77


static (defaults | route) { no-install; }

To configure the software not to install active IPv6 static routes into the forwarding table, include the no-install statement: rib inet6.0 static (defaults | route) { no-install; }

Even if you configure a route so it is not installed in the forwarding table, the route is still eligible to be exported from the routing table to other protocols. To explicitly install IPv4 routes into the forwarding table, include the install statement. Include this statement when configuring an individual route in the route portion of the static statement to override a no-install option specified in the defaults portion of the statement. static (defaults | route) { install; }

To explicitly install IPv6 routes into the forwarding table, include the install statement. Include this statement when configuring an individual route in the route portion of the static statement to override a no-install statement specified in the defaults portion of the statement. rib inet6.0 static (defaults | route) { install; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

Controlling Retention of Static Routes in the Forwarding Table By default, statically configured routes are deleted from the forwarding table when the routing protocol process shuts down normally. To have an IPv4 static route remain in the forwarding table, include the retain statement. Doing this greatly reduces the time required to restart a system that has a large number of routes in its routing table. static (defaults | route) { retain; }

To have an IPv6 static route remain in the forwarding table, include the retain statement. Doing this greatly reduces the time required to restart a system that has a large number of routes in its routing table. rib inet6.0 static (defaults | route) { retain; }

To explicitly specify that IPv4 routes be deleted from the forwarding table, include the no-retain statement. Include this statement when configuring an individual route in the route portion of the static statement to override a retain option specified in the defaults portion of the statement.

78



static (defaults | route) { no-retain; }

To explicitly specify that IPv6 routes be deleted from the forwarding table, include the no-retain statement. Include this statement when configuring an individual route in the route portion of the static statement to override a retain statement specified in the defaults portion of the statement. rib inet6.0 static (defaults | route) { no-retain; }


Controlling Retention of Inactive Static Routes in the Routing and Forwarding Tables Static routes are only removed from the routing table if the next hop becomes unreachable. This can occur if the local or neighbor interface goes down. To have an IPv4 static route remain installed in the routing and forwarding tables, include the passive statement: static (defaults | route) { passive; }

To have an IPv6 static route remain installed in the routing and forwarding tables, include the passive statement: rib inet6.0 static (defaults | route) { passive; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Routes that have been configured to remain continually installed in the routing and forwarding tables are marked with reject next hops when they are inactive. To explicitly remove IPv4 static routes when they become inactive, include the active statement. Include this statement when configuring an individual route in the route portion of the static statement to override a passive option specified in the defaults portion of the statement. static (defaults | route) { active; }

To explicitly remove IPv6 static routes when they become inactive, include the active statement. Include this statement when configuring an individual route in the route portion of the static statement to override a passive statement specified in the defaults portion of the statement. rib inet6.0 static (defaults | route) { active;


79


}


Controlling Readvertisement of Static Routes By default, static routes are eligible to be readvertised (that is, exported) by dynamic routing protocols. To mark an IPv4 static route as being ineligible for readvertisement, include the no-readvertise statement: static (defaults | route) { no-readvertise; }

To mark an IPv6 static route as being ineligible for readvertisement, include the no-readvertise statement: rib inet6.0 static (defaults | route) { no-readvertise; }

To explicitly readvertise IPv4 static routes, include the readvertise statement. Include the readvertise statement when configuring an individual route in the route portion of the static statement to override a no-readvertise statement specified in the defaults portion of the statement. static (defaults | route) { readvertise; }

To explicitly readvertise IPv6 static routes, include the readvertise statement. Include the readvertise statement when configuring an individual route in the route portion of the static statement to override a no-readvertise option specified in the defaults portion of the statement. rib inet6.0 static (defaults | route) { readvertise; }


Controlling Resolution of Static Routes to Prefixes That Are Not Directly Connected By default, static routes can point only to a directly connected next hop. You can configure an IPv4 route to a prefix that is not directly connected by resolving the route through the inet.0 and inet.3 routing tables. To configure an IPv4 static route to a prefix that is not a directly connected next hop, include the resolve statement: static (defaults | route) { resolve; }

80



You can configure an IPv6 route to a prefix that is not directly connected by resolving the route through the inet6.0 routing table. To configure an IPv6 static route to a prefix that is not a directly connected next hop, include the resolve statement: rib inet6.0 static (defaults | route) { resolve; }


Configuring Bidirectional Forwarding Detection The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures in a network. Hello packets are sent at a specified, regular interval. A neighbor failure is detected when the routing device stops receiving a reply after a specified interval. BFD works with a wide variety of network environments and topologies. The failure detection timers for BFD have shorter time limits than the failure detection mechanisms of static routes, providing faster detection. These timers are also adaptive. For example, a timer can adapt to a higher value if an adjacency fails, or a neighbor can negotiate a higher value than the one configured. By default, BFD is supported on single-hop static routes. In Junos OS Release 8.2 and later, BFD also supports multihop static routes. To enable failure detection, include the bfd-liveness-detection statement: static route destination-prefix { bfd-liveness-detection { detection-time { threshold milliseconds; } holddown-interval milliseconds; local-address ip-address; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-receive-ttl number; multiplier number; neighbor address; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } }

In Junos OS Release 9.1 and later, the BFD protocol is supported for IPv6 static routes. Global unicast and link-local IPv6 addresses are supported for static routes. The BFD protocol is not supported on multicast or anycast IPv6 addresses. For IPv6, the BFD protocol supports only static routes and only in Junos OS Release 9.3 and later. IPv6 for BFD is not supported for any other protocol. To configure the BFD protocol for IPv6 static routes, include the bfd-liveness-detection statement at the [edit routing-options rib inet6.0 static route destination-prefix] hierarchy level.


81


In Junos OS Release 8.5 and later, you can configure a hold-down interval to specify how long the BFD session must remain up before state change notification is sent. To specify the hold-down interval, include the holddown-interval statement: static route destination-prefix { bfd-liveness-detection { holddown-interval milliseconds; } }

You can configure a number in the range from 0 through 255,000 milliseconds, and the default is 0. If the BFD session goes down and then comes back up during the hold-down interval, the timer is restarted.

NOTE: If a single BFD session includes multiple static routes, the hold-down interval with the highest value is used.

To specify the minimum transmit and receive intervals for failure detection, include the minimum-interval statement: static route destination-prefix { bfd-liveness-detection { minimum-interval milliseconds; } }

This value represents the minimum interval at which the local routing device transmits hello intervals as well as the minimum interval that the routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number in the range from 1 through 255,000 milliseconds. You can also specify the minimum transmit and receive intervals separately.

82



NOTE: BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD less than 100 ms for Routing Engine-based sessions and 10 ms for distributed BFD sessions can cause undesired BFD flapping. Depending on your network environment, these additional recommendations might apply: •

For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of 300 ms for Routing Engine-based sessions and 100 ms for distributed BFD sessions.

•

For very large-scale network deployments with a large number of BFD sessions, please contact Juniper Networks customer support for more information.

•

For BFD sessions to remain up during a Routing Engine switchover event when nonstop active routing (NSR) is configured, specify a minimum interval of 2500 ms for Routing Engine-based sessions. For distributed BFD sessions with NSR configured, the minimum interval recommendations are unchanged and depend only on your network deployment.

To specify only the minimum receive interval for failure detection, include the minimum-receive-interval statement: static route destination-prefix { bfd-liveness-detection { minimum-receive-interval milliseconds; } }

This value represents the minimum interval at which the local routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number in the range from 1 through 255,000 milliseconds. To specify the number of hello packets not received by the neighbor that causes the originating interface to be declared down, include the multiplier statement: static route destination-prefix { bfd-liveness-detection { multiplier number; } }

The default value is 3. You can configure a number in the range from 1 through 255. To specify a threshold for detecting the adaptation of the detection time, include the threshold statement: static route destination-prefix { bfd-liveness-detection { detection-time { threshold milliseconds;


83


} } }

When the BFD session detection time adapts to a value equal to or higher than the threshold, a single trap and a system log message are sent. The detection time is based on the multiplier of the minimum-interval or the minimum-receive-interval value. The threshold must be a higher value than the multiplier for either of these configured values. For example if the minimum-receive-interval is 300 ms and the multiplier is 3, the total detection time is 900 ms. Therefore, the detection time threshold must have a value higher than 900. To specify only the minimum transmit interval for failure detection, include the transmit-interval minimum-interval statement: static route destination-prefix { bfd-liveness-detection { transmit-interval { minimum-interval milliseconds; } } }

This value represents the minimum interval at which the local routing device transmits hello packets to the neighbor with which it has established a BFD session. You can configure a value in the range from 1 through 255,000 milliseconds. To specify the transmit threshold for detecting the adaptation of the transmit interval, include the transmit-interval threshold statement: static route destination-prefix { bfd-liveness-detection { transmit-interval { threshold milliseconds; } } }

The threshold value must be greater than the transmit interval. When the BFD session detection time adapts to a value higher than the threshold, a single trap and a system log message are sent. The detection time is based on the multiplier of the minimum-interval or the minimum-receive-interval value. The threshold must be a higher value than the multiplier for either of these configured values. To specify the BFD version, include the version statement: static route destination-prefix { bfd-liveness-detection { version (1 | automatic); } }

The default is to have the version detected automatically.

84



To include an IP address for the next hop of the BFD session, include the neighbor statement: static route destination-prefix { next-hop interface-name; bfd-liveness-detection { neighbor address; } }

NOTE: You must configure the neighbor statement if the next hop specified is an interface name. If you specify an IP address as the next hop, that address is used as the neighbor address for the BFD session.

In Junos OS Release 9.0 and later, you can configure BFD sessions not to adapt to changing network conditions. To disable BFD adaptation, include the no-adaptation statement: bfd-liveness-detection { no-adaptation; }

NOTE: We recommend that you not disable BFD adaptation unless it is preferable not to have BFD adaptation in your network.


NOTE: If BFD is configured only on one end of a static route, the route is removed from the routing table. BFD establishes a session when BFD is configured on both ends of the static route. BFD is not supported on ISO address families in static routes. BFD does support IS-IS. If you configure graceful Routing Engine switchover at the same time as BFD, graceful Routing Engine switchover does not preserve the BFD state information during a failover.

The Junos OS also supports BFD over multihop static routes. For example, you can configure BFD over a Layer 3 path to provide path integrity over that path. You can limit the number of hops by specifying the time-to-live (TTL). To configure BFD over multihop static routes, include the following statements: static route destination-prefix { bfd-liveness-detection { local-address ip-address; minimum-receive-ttl number;


85


} }

To specify the source address for the multihop static route and to enable multihop BFD support, include the local-address statement. To specify the number of hops, include the minimum-receive-ttl statement. You must configure this statement for a multihop BFD session. You can configure a value in the range from 1 through 255. It is optional for a single-hop BFD session. If you configure the minimum-receive-ttl statement for a single-hop session, the value must be 255. For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Related Documentation

•


•


•


Tracing BFD Protocol Traffic To trace BFD protocol traffic, you can specify options in the global traceoptions statement at the [edit routing-options] hierarchy level, and you can specify BFD-specific options by including the traceoptions statement at the [edit protocols bfd hierarchy level. [edit protocols] bfd { traceoptions { file filename ; flag flag ; } }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. You can specify the following BFD-specific options in the BFD traceoptions statement:

86

•

adjacency—Trace adjacency messages.

•

all—Trace all options.

•

error—Trace all error messages.

•

event—Trace all events.

•

issu—Trace in-service software upgrade (ISSU) packet activity.

•

nsr-packet—Trace active nonstop active routing (NSR) packet activity.

•

nsr-synchronization—Trace NSR synchronization events.

•

packet—Trace all packets.

•

pipe—Trace pipe messages.



•

pipe-detail—Trace pipe messages in detail.

•

ppm-packet—Trace packet activity by periodic packet management (PPM).

•

state—Trace state transitions.

•

timer—Trace timer processing.

NOTE: Use the all trace flag with caution. These flags may cause the CPU to become very busy.


•


•


•


•


Overview of BFD Authentication for Static Routes BFD enables rapid detection of communication failures between adjacent systems. By default, authentication for BFD sessions is disabled. However, when you run BFD over Network Layer protocols, the risk of service attacks can be significant. We strongly recommend using authentication if you are running BFD over multiple hops or through insecure tunnels. Beginning with Junos OS Release 9.6, the Junos OS supports authentication for BFD sessions running over IPv4 and IPv6 static routes. BFD authentication is not supported on MPLS OAM sessions. BFD authentication is only supported in the domestic image and is not available in the export image. You authenticate BFD sessions by specifying an authentication algorithm and keychain, and then associating that configuration information with a security authentication keychain using the keychain name. The following sections describe the supported authentication algorithms, security keychains, and level of authentication that can be configured: •

BFD Authentication Algorithms on page 88

•

Security Authentication Keychains on page 88

•

Strict Versus Loose Authentication on page 89


87


BFD Authentication Algorithms Junos OS supports the following algorithms for BFD authentication: •

simple-password—Plain-text password. One to 16 bytes of plain text are used to

authenticate the BFD session. One or more passwords may be configured. This method is the least secure and should be used only when BFD sessions are not subject to packet interception. •

keyed-md5—Keyed Message Digest 5 hash algorithm for sessions with transmit and

receive intervals greater than 100 ms. To authenticate the BFD session, keyed MD5 uses one or more secret keys (generated by the algorithm) and a sequence number that is updated periodically. With this method, packets are accepted at the receiving end of the session if one of the keys matches and the sequence number is greater than or equal to the last sequence number received. Although more secure than a simple password, this method is vulnerable to replay attacks. Increasing the rate at which the sequence number is updated can reduce this risk. •

meticulous-keyed-md5—Meticulous keyed Message Digest 5 hash algorithm. This

method works in the same manner as keyed MD5, but the sequence number is updated with every packet. Although more secure than keyed MD5 and simple passwords, this method may take additional time to authenticate the session. •

keyed-sha-1—Keyed Secure Hash Algorithm I for sessions with transmit and receive

intervals greater than 100 ms. To authenticate the BFD session, keyed SHA uses one or more secret keys (generated by the algorithm) and a sequence number that is updated periodically. The key is not carried within the packets. With this method, packets are accepted at the receiving end of the session if one of the keys matches and the sequence number is greater than the last sequence number received. •

meticulous-keyed-sha-1—Meticulous keyed Secure Hash Algorithm I. This method

works in the same manner as keyed SHA, but the sequence number is updated with every packet. Although more secure than keyed SHA and simple passwords, this method may take additional time to authenticate the session.

NOTE: Nonstop active routing (NSR) is not supported with meticulous-keyed-md5 and meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms may go down after a switchover.

Security Authentication Keychains The security authentication keychain defines the authentication attributes used for authentication key updates. When the security authentication keychain is configured and associated with a protocol through the keychain name, authentication key updates can occur without interrupting routing and signaling protocols. The authentication keychain contains one or more keychains. Each keychain contains one or more keys. Each key holds the secret data and the time at which the key becomes valid. The algorithm and keychain must be configured on both ends of the BFD session,

88



and they must match. Any mismatch in configuration prevents the BFD session from being created. BFD allows multiple clients per session, and each client can have its own keychain and algorithm defined. To avoid confusion, we recommend specifying only one security authentication keychain.

Strict Versus Loose Authentication By default, strict authentication is enabled and authentication is checked at both ends of each BFD session. Optionally, to smooth migration from nonauthenticated sessions to authenticated sessions, you can configure loose checking. When loose checking is configured, packets are accepted without authentication being checked at each end of the session. This feature is intended for transitional periods only. Related Documentation

•


•

bfd-liveness-detection on page 155 statement

•

authentication-key-chains statement in the Junos OS System Basics Configuration Guide

•

show bfd session command in the Junos OS Routing Protocols and Policies Command Reference

•


Configuring BFD Authentication for Static Routes Beginning with Junos OS Release 9.6, you can configure authentication for BFD sessions running over IPv4 and IPv6 static routes. Routing instances are also supported. Only three steps are needed to configure authentication on a BFD session: 1.

Specify the BFD authentication algorithm for the static route.

2. Associate the authentication keychain with the static route. 3. Configure the related security authentication keychain.

The following sections provide instructions for configuring and viewing BFD authentication on static routes: •

Configuring the BFD Authentication Parameters on page 89

•

Viewing Authentication Information for BFD Sessions on page 91

Configuring the BFD Authentication Parameters To configure BFD authentication: 1.

Specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use for BFD authentication on a static route or routing instance. [edit]


89


user@host# set routing-options static route ipv4 bfd-liveness-detection authentication algorithm keyed-sha-1


2. Specify the keychain to be used to associate BFD sessions on the specified route or

routing instance with the unique security authentication keychain attributes. This should match the keychain name configured at the [edit security authentication key-chains] hierarchy level. [edit] user@host# set routing-options static route ipv4 bfd-liveness-detection authentication keychain bfd-sr4

NOTE: The algorithm and keychain must be configured on both ends of the BFD session, and they must match. Any mismatch in configuration prevents the BFD session from being created.

3. Specify the unique security authentication information for BFD sessions: •

The matching key-chain-name as specified in step 2.

•

At least one key, a unique integer between 0 and 63. Creating multiple keys allows multiple clients to use the BFD session.

•

The secret-data used to allow access to the session.

•

The time at which the authentication key becomes active, yyyy-mm-dd.hh:mm:ss. [edit security] user@host# authentication-key-chains key-chain bfd-sr4 key 53 secret $9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm start-time 2009-06-14.10:00:00

4. (Optional) Specify loose authentication checking if you are transitioning from

nonauthenticated sessions to authenticated sessions. [edit] user@host> set routing-options static route ipv4 bfd-liveness-detection authentication loose-check 5. (Optional) View your configuration using the show bfd session detail or show bfd

session extensive command. 6. Repeat these steps to configure the other end of the BFD session.

NOTE: BFD authentication is only supported in the domestic image and is not available in the export image.

90



Viewing Authentication Information for BFD Sessions You can view the existing BFD authentication configuration using the show bfd session detail and show bfd session extensive commands. The following example shows BFD authentication configured for the static route at 192.168.208.26. It specifies the keyed SHA-1 authentication algorithm and a keychain name of bfd-static. The authentication keychain is configured with two keys. Key 1 contains the secret data “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm” and a start time of June 1, 2009, at 9:46:02 AM PST. Key 2 contains the secret data “$9$a5jiKW9l.reP38ny.TszF2/9” and a start time of June 1, 2009, at 3:29:20 PM PST. [edit routing-options] static route 192.168.208.26 { bfd-liveness-detection { authentication { algorithm keyed-sha-1; key-chain bfd-static; } } } [edit security] authentication key-chains { key-chain bfd-static { key 1 { secret “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm”; start-time “2009-6-1.09:46:02 -0700”; } key 2 { secret “$9$a5jiKW9l.reP38ny.TszF2/9”; start-time “2009-6-1.15:29:20 -0700”; } } }

If you commit these updates to your configuration, you would see output similar to the following. In the output for the show bfd sessions detail command, Authenticate is displayed to indicate that BFD authentication is configured. For more information about the configuration, use the show bfd sessions extensive command. The output for this command provides the keychain name, the authentication algorithm and mode for each client in the session, and the overall BFD authentication configuration status, keychain name, and authentication algorithm and mode. show bfd sessions detail

user@host# show bfd session detail Detect Transmit Address State Interface Time Interval 192.168.208.26 Up so-1/0/0.0 2.400 0.800 Client Static, TX interval 0.600, RX interval 0.600, Authenticate Session up time 00:18:07 Local diagnostic None, remote diagnostic NbrSignal Remote state Up, version 1 Replicated


Multiplier 10

91


1 sessions, 1 clients Cumulative transmit rate 1.2 pps, cumulative receive rate 1.2 pps

show bfd sessions extensive

user@host# show bfd session extensive Detect Transmit Address State Interface Time Interval Multiplier 192.168.208.26 Up so-1/0/0.0 2.400 0.800 10 Client Static, TX interval 0.600, RX interval 0.600, Authenticate keychain bfd-static, algo keyed-md5, mode loose Session up time 00:18:07 Local diagnostic None, remote diagnostic NbrSignal Remote state Up, version 1 Replicated Min async interval 0.600, min slow interval 1.000 Adaptive async TX interval 0.600, RX interval 0.600 Local min TX interval 0.600, minimum RX interval 0.600, multiplier 10 Remote min TX interval 0.800, min RX interval 0.800, multiplier 3 Local discriminator 2, remote discriminator 3 Echo mode disabled/inactive Authentication enabled/active, keychain bfd-static, algo keyed-md5, mode loose 1 sessions, 1 clients Cumulative transmit rate 1.2 pps, cumulative receive rate 1.2 pps


•


•


•


•


•


Configuring Default Routes To configure an IPv4 default route, include the next-hop address and retain statements: static route default { next-hop address; retain; }

To configure an IPv6 static route, include the next-hop address and retain statements: rib inet6.0 static (default | route) { next-hop address; retain; }


92



Propagating Static Routes into Routing Protocols A common way to propagate static routes into the various routing protocols is to configure the routes so that the next-hop routing device is the loopback address (commonly, 127.0.0.1). However, configuring static routes in this way with the Junos OS (by including a statement such as route address/mask-length next-hop 127.0.0.1) does not propagate the static routes, because the forwarding table ignores static routes whose next-hop routing device is the loopback address. To propagate IPv4 static routes into the routing protocols, include the discard statement: rib inet.0 static (defaults | route) { discard; }

To propagate IPv6 static routes into the routing protocols, include the discard statement: rib inet6.0 static (defaults | route) { discard; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. In this configuration, you use the discard option instead of reject because discard does not send an ICMP (or ICMPv6) unreachable message for each packet that it drops.

Examples: Configuring Static Routes Configure an IPv4 default route through the next-hop router 192.238.52.33: [edit] user@host# set routing-options static route 0.0.0.0/0 next-hop 192.238.52.33 [edit] user@host# show routing-options { static { route 0.0.0.0/0 next-hop 192.238.52.33; } }

Configure IPv4 static routes that are retained in the forwarding table when the routing software shuts down normally: [edit] user@host# set routing-options static route 0.0.0.0/0 next-hop 192.168.1.254 retain [edit] user@host# set routing-options static route 10.1.1.1/32 next-hop 127.0.0.1 retain [edit] user@host# show routing-options { static { route 0.0.0.0/0 { next-hop 192.168.1.254; retain;


93


} route 10.1.1.1/32 { next-hop 127.0.0.1; retain; } } }

Configure an IPv4 static route and have it propagate into the routing protocols. In this example, specify that the route 143.172.0.0/6 next-hop 127.0.0.1 should be discarded. [edit] user@host# set routing-options static route 143.172.0.0/6 discard [edit] user@host# show routing-options { static { route 143.172.0.0/6 discard; } }

Install an IPv4 static route into both inet.0 and inet.2: [edit] user@host# set routing-options static rib-group some-group user@host# set rib-groups some-group import-rib [inet.0 inet.2] [edit] user@host# show routing-options { static { rib-group some-group; } rib-groups { some-group { import-rib [ inet.0 inet.2 ]; } } }

Configure an IPv6 default route through the next-hop router 8:3::1: [edit] user@host# set routing-options rib inet6.0 static route 0::/0 next-hop 8:3::1 [edit] user@host# show routing-options { rib inet6.0 static { route abcd::/48 next-hop 8:3::1; } }

Resolve an IPv6 static route to non-next-hop router 1::/64 using next-hop router 2000::1: [edit] user@host# set routing-options rib inet6.0 static route 1::/64 next-hop 2000::1 resolve [edit] user@host# show route 1::/64

94



inet6.0: 26 destinations, 27 routes (25 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 1::/64 *[Static/5] 00:01:50 > to 8:1::2 via ge-0/1/0.0 user@host# show route 2000::1 inet6.0: 26 destinations, 27 routes (25 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 2000::/126 *[BGP/170] 00:05:32, MED 20, localpref 100 AS path: 2 I > to 8:1::2 via ge-0/1/0.0

Configuring Aggregate Routes Route aggregation allows you to combine groups of routes with common addresses into a single entry in the routing table. This decreases the size of the routing table as well as the number of route advertisements sent by the routing device. An aggregate route becomes active when it has one or more contributing routes. A contributing route is an active route that is a more specific match for the aggregate destination. For example, for the aggregate destination 128.100.0.0/16, routes to 128.100.192.0/19 and 128.100.67.0/24 are contributing routes, but routes to 128.0.0.0./8, 128.0.0.0/16, and 128.100.0.0/16 are not. A route can contribute only to a single aggregate route. However, an active aggregate route can recursively contribute to a less specific matching aggregate route. For example, an aggregate route to the destination 128.100.0.0/16 can contribute to an aggregate route to 128.96.0.0/13. When an aggregate route becomes active, it is installed in the routing table with the following information: •

Reject next hop—If a more-specific packet does not match a more-specific route, the packet is rejected and an ICMP unreachable message is sent to the packet’s originator.

•

Metric value as configured with the aggregate statement.

•

Preference value that results from the policy filter on the primary contributor, if a filter is specified.

•

AS path as configured in the aggregate statement, if any. Otherwise, the path is computed by aggregating the paths of all contributing routes.

•

Community as configured in the aggregate statement, if any is specified.

NOTE: You can configure only one aggregate route for each destination prefix.

To configure aggregate routes in the default routing table (inet.0), include the aggregate statement: aggregate { defaults {


95


... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... } }

To configure aggregate routes in one of the other routing tables, or to explicitly configure aggregate routes in the default routing table (inet.0), include the aggregate statement: rib routing-table-name { aggregate { defaults { ... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... } } }


NOTE: You cannot configure aggregate routes for the IPv4 multicast routing table (inet.1) nor the IPv6 multicast routing table (inet6.1).

The aggregate statement consists of two parts: •

defaults—Here you specify global aggregate route options. These are treated as global

defaults and apply to all the aggregate routes you configure in the aggregate statement. This part of the aggregate statement is optional. •

route—Here you configure individual aggregate routes. In this part of the aggregate

statement, you optionally can configure aggregate route options. These options apply to the individual destination only and override any options you configured in the defaults part of the aggregate statement. The following topics provide more information about configuring aggregate routes:

96

•

Configuring the Destination of Aggregate Routes on page 97

•

Configuring Aggregate Route Options on page 97

•

Applying Policies to Aggregate Routes on page 102

•

Advertising Aggregate Routes on page 103



Configuring the Destination of Aggregate Routes When you configure an individual aggregate route in the route part of the aggregate statement, specify the destination of the route (in route destination-prefix) in one of the following ways: •


•



Configuring Aggregate Route Options In the defaults and route parts of the aggregate statement, you can specify aggregate-options, which define additional information about aggregate routes that is included with the route when it is installed in the routing table. All aggregate options are optional. Aggregate options that you specify in the defaults part of the aggregate statement are treated as global defaults and apply to all the aggregate routes you configure in the aggregate statement. Aggregate options that you specify in the route part of the aggregate statement override any global aggregate options and apply to that destination only. To configure aggregate route options, include one or more of them in the defaults or route part of the aggregate statement: [edit] routing-options { aggregate { (defaults | route) { (active | passive); as-path ; community [ community-ids ]; discard; (brief | full); (metric | metric2 | metric3 | metric4) metric ; (preference | preference2 | color | color2) preference ; tag string; } } }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. The following sections explain how to configure aggregate route options: •

Configuring a Metric Value for Aggregate Routes on page 98

•

Configuring a Preference Value for Aggregate Routes on page 98

•

Configuring the Next Hop for Aggregate Routes on page 98


97


•

Associating BGP Communities with Aggregate Routes on page 99

•

Associating AS Paths with Aggregate Routes on page 100

•

Including AS Numbers in Aggregate Route Paths on page 101

•

Configuring an OSPF Tag String for Aggregate Routes on page 101

•

Controlling Retention of Inactive Aggregate Routes in the Routing and Forwarding Tables on page 101

Configuring a Metric Value for Aggregate Routes You can specify up to four metric values, starting with metric (for the first metric value) and continuing with metric2, metric3, and metric4 by including one or more of the following statements: aggregate (defaults | route) { (metric | metric2 | metric3 | metric4) metric ; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. In the type option, you can specify the type of route.

Configuring a Preference Value for Aggregate Routes By default, aggregate routes have a preference value of 130. If the routing table contains a dynamic route to a destination that has a better (lower) preference value than this, the dynamic route is chosen as the active route and is installed in the forwarding table. To modify the default preference value, specify a primary preference value (preference). You also can specify secondary preference value (preference2); and colors, which are even finer-grained preference values (color and color2). To do this, include one or more of the following statements: aggregate (defaults | route) { (preference | preference2 | color | color2) preference ; }


The preference value can be a number in the range from 0 through 4,294,967,295 (2 – 1) with a lower number indicating a more preferred route. For more information about preference values, see “Route Preferences Overview” on page 6. In the type option, you can specify the type of route.

Configuring the Next Hop for Aggregate Routes By default, when aggregate routes are installed in the routing table, the next hop is configured as a reject route. That is, the packet is rejected and an ICMP unreachable message is sent to the packet’s originator.

98



When you configure an individual route in the route part of the aggregate statement, or when you configure the defaults for aggregate routes, you can specify a discard next hop. This means that if a more specific packet does not match a more specific route, the packet is rejected and a reject route for this destination is installed in the routing table, but ICMP unreachable messages are not sent. Being able to discard next hops allows you to originate a summary route, which can be advertised through dynamic routing protocols, and allows you to discard received traffic that does not match a more specific route than the summary route. To discard next hops, include the discard option: discard;


Associating BGP Communities with Aggregate Routes By default, no BGP community information is associated with aggregate routes. To associate community information with the routes, include the community option: aggregate (defaults | route) { community [ community-ids ]; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. community-value is the community identifier and can be a number in the range from 0 through 65,535. community-ids is one or more community identifiers for either communities or extended

communities. The format for community identifiers is: as-number:community-value as-number is the AS number and can be a value in the range from 1 through 65,534.

You also can specify community-ids for communities as one of the following well-known community names, which are defined in RFC 1997: •

no-export—Routes containing this community name are not advertised outside a

BGP confederation boundary. •


BGP peers. •


external BGP peers, including peers in other members’ ASs inside a BGP confederation. You can explicitly exclude BGP community information with an aggregate route using the none option. Include none when configuring an individual route in the route portion of the aggregate statement to override a community option specified in the defaults portion of the statement.


99


NOTE: Extended community attributes are not supported at the [edit routing-options] hierarchy level. You must configure extended communities at the [edit policy-options] hierarchy level. For information about configuring extended communities information, see the “Configuring the Extended Communities Attribute” section in the Junos OS Routing Policy Configuration Guide. For information about configuring 4-byte AS numbers and extended communities, see Configuring 4-Byte AS Numbers and BGP Extended Community Attributes in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview.

Associating AS Paths with Aggregate Routes By default, the AS path for aggregate routes is built from the component routes. To manually specify the AS path and associate AS path information with the routes, include the as-path option: aggregate (defaults | route) { as-path ; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. as-path is the AS path to include with the route. It can include a combination of individual


NOTE: In Junos OS Release 9.1 and later, the numeric AS range is extended to provide BGP support for 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. For the AS number, you can configure a value from 1 through 4,294,967,295. All releases of the Junos OS support 2-byte AS numbers. The 2-byte AS number range is 1 through 65,535 (this is a subset of the 4-byte range). In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. You can specify a value in the range from 0.0 through 65535.65535 in AS-dot notation format.

You also can specify the AS path using the BGP origin attribute, which indicates the origin of the AS path information: •

100




•


•

incomplete—Path information was learned by some other means.

To attach the BGP ATOMIC_AGGREGATE path attribute to the aggregate route, specify the atomic-aggregate option. This path attribute indicates that the local system selected a less specific route rather than a more specific route. To attach the BGP AGGREGATOR path attribute to the aggregate route, specify the aggregator option. When using this option, you must specify the last AS number that formed the aggregate route (encoded as two octets), followed by the IP address of the BGP system that formed the aggregate route.

Including AS Numbers in Aggregate Route Paths By default, all AS numbers from all contributing paths are included in the aggregate route’s path. To include only the longest common leading sequences from the contributing AS paths, include the brief option when configuring the route. If doing this results in AS numbers being omitted from the aggregate route, the BGP ATOMIC_ATTRIBUTE path attribute is included with the aggregate route. aggregate (defaults | route) { brief; }

To explicitly have all AS numbers from all contributing paths be included in the aggregate route’s path, include the full option when configuring routes. Include this option when configuring an individual route in the route portion of the aggregate statement to override a retain option specified in the defaults portion of the statement. aggregate (defaults | route) { full; }


Configuring an OSPF Tag String for Aggregate Routes By default, no OSPF tag strings are associated with aggregate routes. You can specify an OSPF tag string by including the tag option: aggregate (defaults | route) { tag string; }


Controlling Retention of Inactive Aggregate Routes in the Routing and Forwarding Tables Static routes are only removed from the routing table if the next hop becomes unreachable, which happens if there are no contributing routes. To have an aggregate route remain continually installed in the routing and forwarding tables, include the passive option when configuring the route:


101


aggregate (defaults | route) { passive; }

Routes that have been configured to remain continually installed in the routing and forwarding tables are marked with reject next hops when they are inactive. To explicitly remove aggregate routes when they become inactive, include the active option when configuring routes. Include this option when configuring an individual route in the route portion of the aggregate statement to override a passive option specified in the defaults portion of the statement. aggregate (defaults | route) { active; }


Applying Policies to Aggregate Routes You can associate a routing policy when configuring an aggregate route’s destination prefix in the routes part of the aggregate statement. Doing so provides the equivalent of an import routing policy filter for the destination prefix. That is, each potential contributor to an aggregate route, along with any aggregate options, is passed through the policy filter. The policy then can accept or reject the route as a contributor to the aggregate route and, if the contributor is accepted, the policy can modify the default preferences. The following algorithm is used to compare two aggregate contributing routes in order to determine which one is the primary or preferred contributor: 1.

Compare the protocol’s preferences of the contributing routes. The lower the preference, the better the route. This is similar to the comparison that is done while determining the best route for the routing table.

2. Compare the protocol’s preferences2 of the contributing routes. The lower preference2

value is better. If only one route has preferences2, then this route is preferred. 3. The preference values are the same. Proceed with a numerical comparison of the

prefix values. a. The primary contributor is the numerically smallest prefix value. b. If the two prefixes are numerically equal, the primary contributor is the route that

has the smallest prefix length value. 4. At this point, the two routes are the same. The primary contributor does not change.

An additional next hop is available for the existing primary contributor. A rejected contributor still can contribute to a less specific aggregate route. If you do not specify a policy filter, all candidate routes contribute to an aggregate route. To associate a routing policy with an aggregate route, include the policy statement when configuring the route:

102



aggregate (defaults | route) { policy policy-name; }


Advertising Aggregate Routes After you have configured aggregate routes, you can have a protocol advertise the routes by configuring a policy that is then exported by a routing protocol. To configure a protocol to advertise routes, include the policy-statement statement: policy-statement advertise-aggregate-routes { term first-term { from protocol aggregate; then accept; } term second-term { then next policy; } } protocols { bgp { export advertise-aggregate-routes; ... } }


Configuring Generated Routes Generated routes are used as the route of last resort. A packet is forwarded to the route of last resort when the routing tables have no information about how to reach that packet’s destination. One use of route generation is to generate a default route to use if the routing table contains a route from a peer on a neighboring backbone. A generated route becomes active when it has one or more contributing routes. A contributing route is an active route that is a more specific match for the generated destination. For example, for the destination 128.100.0.0/16, routes to 128.100.192.0/19 and 128.100.67.0/24 are contributing routes, but routes to 128.0.0.0./8, 128.0.0.0/16, and 128.100.0.0/16 are not. A route can contribute only to a single generated route. However, an active generated route can recursively contribute to a less specific matching generated route. For example, a generated route to the destination 128.100.0.0/16 can contribute to a generated route to 128.96.0.0/13. By default, when generated routes are installed in the routing table, the next hop is chosen from the primary contributing route.


103


NOTE: Currently, you can configure only one generated route for each destination prefix.

To configure generated routes in the default routing table (inet.0), include the generate statement: generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; } }

To configure generated routes in one of the other routing tables, or to explicitly configure generated routes in the default route table (inet.0), include the generate statement: rib routing-table-name { generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; } } }

NOTE: You cannot configure generated routes for the IPv4 multicast routing table (inet.1) or the IPv6 multicast routing table (inet6.1).

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. The generate statement consists of two parts: •

defaults—Here you specify global generated route options. These are treated as global

defaults and apply to all the generated routes you configure in the generate statement. This part of the generate statement is optional. •

route—Here you configure individual generated routes. In this part of the generate

statement, you optionally can configure generated route options. These options apply to the individual destination only and override any options you configured in the defaults part of the generate statement. The following topics provide more information about configuring generated routes: •

104

Configuring the Destination of Generated Routes on page 105



•

Configuring Generated Route Options on page 105

•

Applying Policies to Generated Routes on page 110

Configuring the Destination of Generated Routes When you configure an individual generated route in the route part of the generate statement, specify the destination of the route (in route destination-prefix) in one of the following ways: •


•



Configuring Generated Route Options In the defaults and route parts of the generate statement, you can specify options that define additional information about generated routes that is included with the route when it is installed in the routing table. All generated options are optional. Generated options that you specify in the defaults part of the generate statement are treated as global defaults and apply to all the generated routes you configure in the generate statement. Generated options that you specify in the route part of the generate statement override any global generated options and apply to that destination only. To configure generated route options, include one or more of them in the defaults or route part of the generate statement (for routing instances, include the statement). [edit] routing-options generate { (defaults | route) { (active | passive); as-path ; community [ community-ids ]; discard; (brief | full); (metric | metric2 | metric3 | metric4) metric ; (preference | preference2 | color | color2) preference ; tag string; } } }



105


The following sections explain how to configure generated route options: •

Configuring a Metric Value for Generated Routes on page 106

•

Configuring a Preference Value for Generated Routes on page 106

•

Configuring the Next Hop for Generated Routes on page 106

•

Associating BGP Communities with Generated Routes on page 107

•

Associating AS Paths with Generated Routes on page 108

•

Configuring an OSPF Tag String for Generated Routes on page 109

•

Including AS Numbers in Generated Route Paths on page 109

•

Controlling Retention of Inactive Generated Routes in the Routing and Forwarding Tables on page 109

Configuring a Metric Value for Generated Routes You can specify up to four metric values, starting with metric (for the first metric value) and continuing with metric2, metric3, and metric4, by including one or more of the following statements: (metric | metric2 | metric3 | metric4) metric < type type>;

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. In the type option, you specify the type of route.

Configuring a Preference Value for Generated Routes By default, generated routes have a preference value of 130. If the Junos OS routing table contains a dynamic route to a destination that has a better (lower) preference value than this, the dynamic route is chosen as the active route and is installed in the forwarding table. To modify the default preference value, specify a primary preference value (preference). You also can specify a secondary preference value (preference2) and colors, which are even finer-grained preference values (color and color2). To do this, include one or more of the following statements: (preference | preference2 | color | color2) preference ;


The preference value can be a number in the range from 0 through 4,294,967,295 (2 – 1) with a lower number indicating a more preferred route. For more information about preference values, see “Route Preferences Overview” on page 6. In the type option, you specify the type of route.

Configuring the Next Hop for Generated Routes By default, when generated routes are installed in the routing table, the next hop is chosen from the primary contributing route.

106



When you configure an individual route in the route part of the generate statement, or when you configure the defaults for generated routes, you can specify a discard next hop. This means that if a more specific packet does not match a more specific route, the packet is rejected and a reject route for this destination is installed in the routing table, but ICMP unreachable messages are not sent. The discard next-hop feature allows you to originate a summary route, which can be advertised through dynamic routing protocols, and allows you to discard received traffic that does not match a more specific route than the summary route. For example: [edit routing-options generate route 1.0.0.0/8] user@host# set discard

Associating BGP Communities with Generated Routes By default, no BGP community information is associated with generated routes. To associate community information with the routes, include the community option: community [ community-ids ];

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. community-ids is one or more community identifiers for either communities or extended

communities. The format for community identifiers is: as-number:community-value as-number is the AS number and can be a value in the range from 1 through 65,534.

You also can specify community-ids for communities as one of the following well-known community names, which are defined in RFC 1997: •


BGP peers. •

no-export—Routes containing this community name are not advertised outside a BGP

confederation boundary. •


external BGP peers, including peers in other members’ ASs inside a BGP confederation. You can explicitly exclude BGP community information with a generated route using the none option. Include none when configuring an individual route in the route portion of the generate statement to override a community option specified in the defaults portion of the statement.


107


NOTE: Extended community attributes are not supported at the [edit routing-options] hierarchy level. You must configure extended communities at the [edit policy-options] hierarchy level. For information about configuring extended communities, see the “Configuring the Extended Communities Attribute” section in the Junos OS Routing Policy Configuration Guide. For information about configuring 4-byte AS numbers and extended communities, see Configuring 4-Byte AS Numbers and BGP Extended Community Attributes in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview.

Associating AS Paths with Generated Routes By default, no AS path information is associated with generated routes. To associate AS path information with the routes, include the as-path statement: as-path ;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. as-path is the AS path to include with the route. It can include a combination of individual


NOTE: In Junos OS Release 9.1 and later, the numeric AS range is extended to provide BGP support for 4-byte AS numbers, as defined in RFC 4983, BGP Support for Four-octet AS Number Space. For the AS number, you can configure a number from 1 through 4,294,967,295. All releases of the Junos OS support 2-byte AS numbers. The 2-byte AS number range is 1 through 65,535 (this is a subset of the 4-byte range). In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. You can specify a value in the range from 0.0 through 65535.65535 in AS-dot notation format.

You also can specify the AS path using the BGP origin attribute, which indicates the origin of the AS path information:

108

•


•


•

incomplete—Path information was learned by some other means.



To attach the BGP ATOMIC_AGGREGATE path attribute to the generated route, specify the atomic-aggregate option. This path attribute indicates that the local system selected a less specific route rather than a more specific route. To attach the BGP AGGREGATOR path attribute to the generated route, specify the aggregator option. When using this option, you must specify the last AS number that formed the generated route (encoded as two octets), followed by the IP address of the BGP system that formed the generated route.

Configuring an OSPF Tag String for Generated Routes By default, no OSPF tag strings are associated with generated routes. You can specify an OSPF tag string by including the tag statement: tag string;


Including AS Numbers in Generated Route Paths By default, all AS numbers from all contributing paths are included in the generated route’s path. To include only the longest common leading sequences from the contributing AS paths, include the brief statement when configuring the route. If doing this results in AS numbers being omitted from the generated route, the BGP ATOMIC_ATTRIBUTE path attribute is included with the generated route. brief;

To explicitly have all AS numbers from all contributing paths be included in the generated route’s path, include the full state when configuring routes. Include this option when configuring an individual route in the route portion of the generate statement to override a retain option specified in the defaults portion of the statement. full;

For a list of hierarchy levels at which you can include the brief or full statement, see the statement summary sections for these statements.

Controlling Retention of Inactive Generated Routes in the Routing and Forwarding Tables Static routes are only removed from the routing table if the next hop becomes unreachable, which happens if there are no contributing routes. To have a generated route remain continually installed in the routing and forwarding tables, include the passive option when configuring the route: generate (defaults | route) { passive; }

Routes that have been configured to remain continually installed in the routing and forwarding tables are marked with reject next hops when they are inactive. To explicitly remove generated routes when they become inactive, include the active option when configuring routes. Include this option when configuring an individual route


109


in the route portion of the generate statement to override a retain option specified in the defaults portion of the statement. generate (defaults | route) { active; }


Applying Policies to Generated Routes You optionally can associate a routing policy when configuring a generated route’s destination prefix in the routes part of the generate statement. Doing so provides the equivalent of an import routing policy filter for the destination prefix. That is, each potential contributor to a generated route, along with any generate options, is passed through the policy filter. The policy can accept or reject the route as a contributor to the generated route and, if the contributor is accepted, the policy can modify the default preferences. The following algorithm is used to compare two generated contributing routes in order to determine which one is the primary or preferred contributor: 1.

Compare the protocol’s preference of the contributing routes. The lower the preference, the better the route. This is similar to the comparison that is done while determining the best route for the routing table.

2. Compare the protocol’s preference2 of the contributing routes. The lower preference2

value is better. If only one route has preference2, then this route is preferred. 3. The preference values are the same. Proceed with a numerical comparison of the

prefixes’ values. a. The primary contributor is the numerically smallest prefix value. b. If the two prefixes are numerically equal, the primary contributor is the route that has the smallest prefix length value. At this point, the two routes are the same. The primary contributor does not change. An additional next hop is available for the existing primary contributor. A rejected contributor still can contribute to less specific generated route. If you do not specify a policy filter, all candidate routes contribute to a generated route. To associate a routing policy with an generated route, include the policy statement: policy policy-name;


Configuring Martian Addresses Martian addresses are host or network addresses about which all routing information is ignored. They commonly are sent by improperly configured systems on the network and

110



have destination addresses that are obviously invalid. To view the default and configured martian routes, run the show route martians command. In IPv4, the following are the default martian addresses: •

0.0.0.0/8

•

127.0.0.0/8

•

128.0.0.0/16

•

191.255.0.0/16

•

192.0.0.0/24

•

223.255.255.0/24

•

224.0.0.0/4

•

224.0.0.0/24

•

240.0.0.0/4

In IPv6, the loopback address and the multicast resolve and discard routes are the default martian addresses, as shown here: •

::1/128

•

ff00::/8

•

ff02::/16

Tables inet.1 and inet6.1 are multicast route tables. Table inet.1 does not include martian routes for 224/4 or 224/24. Likewise, inet6.1 does not include martian routes for ff00::/8 and ff02::/16. The default martian route for inet6.1 is ::1/128. The default martian routes for inet.1 are as follows: •

0.0.0.0/8

•

127.0.0.0/8

•

128.0.0.0/16

•

191.255.0.0/16

•

192.0.0.0/24

•

223.255.255.0/24

•

240.0.0.0/4

The following sections explain how to configure martian routes: •

Adding Martian Addresses on page 112

•

Deleting Martian Addresses on page 112

•

Using Class E Addresses for Interface Addresses on page 113


111


Adding Martian Addresses To add martian addresses to the list of default martian addresses in the default IPv4 routing table (inet.0), include the martians statement: martians { destination-prefix match-type; }

To add martian addresses to the list of default martian addresses in other routing tables, or to explicitly add martian addresses to the list of default martian addresses in the primary IPv6 routing table (inet6.0), include the martians statement: rib inet6.0 { martians { destination-prefix match-type; } }

To add martian addresses to the list of default martian addresses in any other routing tables, or to explicitly add martian addresses to the list of default martian addresses in the default routing table (inet.0), include the martians statement: rib routing-table-name { martians { destination-prefix match-type; } }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. In destination-prefix, specify the routing destination in one of the following ways: •

default—If this is the default route to the destination. This is equivalent to specifying

the IP address 0.0.0.0/0. •

network/mask-length—network is the network portion of the IP address and mask-length

is the destination prefix length. In match-type, specify the type of match to apply to the destination prefix. For more information about match types, see the Junos OS Routing Policy Configuration Guide.

Deleting Martian Addresses To delete a martian address from within a range of martian addresses, include the allow option in the martians statement. This option removes an exact prefix that is within a range of addresses that has been specified to be martian addresses. To delete a martian address from the default routing table (inet.0), include the martians statement: martians { destination-prefix match-type allow; }

112



To delete a martian address from other routing tables, or to explicitly delete a martian address from the primary IPv6 routing table (inet6.0), include the martians statement: rib inet6.0 { martians { destination-prefix match-type allow; } }


Using Class E Addresses for Interface Addresses In Junos OS Release 9.6 and later, you can configure Class E addresses on interfaces. Class E addresses are treated like any other unicast address for the purpose of forwarding. To allow Class E addresses to be configured on interfaces, you must remove the Class E prefix from the list of martian addresses. To remove the Class E prefix from the list of martian addresses include the martians 240/4 orlonger allow statement at the [edit routing-options] hierarchy level.

Configuring Flow Routes A flow route is an aggregation of match conditions for IP packets. Flow routes are propagated through the network using flow-specification network-layer reachability information (NLRI) messages and installed into the flow routing table instance-name.inetflow.0. Packets can travel through flow routes only if specific match conditions are met. Flow routes and firewall filters are similar in that they filter packets based on their components and perform an action on the packets that match. Flow routes provide traffic filtering and rate-limiting capabilities much like firewall filters. In addition, you can propagate flow routes across different autonomous systems. To configure a flow route, include the flow statement: flow { route name { match { match-conditions; } then { actions; } } term-order (legacy | standard); validation { traceoptions { file filename ; flag flag ; } } }


113


For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. Flow routes are propagated by BGP through flow-specification NLRI messages. You must enable BGP to propagate these NLRIs. For more information on configuring BGP, see Configuring BGP. The following sections describe the specified tasks: •

Configuring Match Conditions for Flow Routes on page 114

•

Configuring the Action for Flow Routes on page 116

•

Validating Flow Routes on page 116

•

Enabling Support for BGP Flow-Specification Algorithm Version 7 and Later on page 117

Configuring Match Conditions for Flow Routes You specify conditions that the packet must match before the action in the then statement is taken for a flow route. All conditions in the from statement must match for the action to be taken. The order in which you specify match conditions is not important, because a packet must match all the conditions in a term for a match to occur. To configure a match condition, include the match statement at the [edit routing-options flow] hierarchy level: [edit routing-options flow] match { match-conditions; }

Table 4 on page 114 describes the flow route match conditions.

Table 4: Flow Route Match Conditions Match Condition

Description

destination prefix

IP destination address field.

destination-port number

TCP or User Datagram Protocol (UDP) destination port field. You cannot specify both the port and destination-port match conditions in the same term. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), xdmcp (177), zephyr-clt (2103), or zephyr-hm (2104).

dscp number

Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant six bits of this byte form the DSCP. You can specify DSCP in hexadecimal or decimal form.

114



Table 4: Flow Route Match Conditions (continued) Match Condition

Description

fragment type

Fragment type field. The keywords are grouped by the fragment type with which they are associated:

icmp-code number

•

dont-fragment

•

first-fragment

•

is-fragment

•

last-fragment

•

not-a-fragment

ICMP code field. This value or keyword provides more specific information than icmp-type. Because the value’s meaning depends upon the associated icmp-type value, you must specify icmp-type along with icmp-code. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed). The keywords are grouped by the ICMP type with which they are associated:

icmp-type number

•

parameter-problem: ip-header-bad (0), required-option-missing (1)

•

redirect: redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-host (3), redirect-for-tos-and-net (2)

•

time-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)

•

unreachable: communication-prohibited-by-filtering (13), destination-host-prohibited (10), destination-host-unknown (7), destination-network-prohibited (9), destination-network-unknown (6), fragmentation-needed (4), host-precedence-violation (14), host-unreachable (1), host-unreachable-for-TOS (12), network-unreachable (0), network-unreachable-for-TOS (11), port-unreachable (3), precedence-cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8), source-route-failed (5)

ICMP packet type field. Normally, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): echo-reply (0), echo-request (8), info-reply (16), info-request (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5), router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11), timestamp (13), timestamp-reply (14), or unreachable (3).

packet-length number

Total IP packet length.

port number

TCP or UDP source or destination port field. You cannot specify both the port match and either the destination-port or source-port match condition in the same term. In place of the numeric value, you can specify one of the text synonyms listed under destination-port.

protocol number

IP protocol field. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah, egp (8), esp (50), gre (47), icmp (1), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), tcp (6), or udp (17).

source prefix

IP source address field.

source-port number

TCP or UDP source port field. You cannot specify the port and source-port match conditions in the same term. In place of the numeric field, you can specify one of the text synonyms listed under destination-port.


115


Table 4: Flow Route Match Conditions (continued) Match Condition

Description

tcp-flag type

TCP header format.

Configuring the Action for Flow Routes You can specify the action to take if the packet matches the conditions you have configured in the flow route. To configure an action, include the then statement at the [edit routing-options flow] hierarchy level: [edit routing-options flow] then { action; }

Table 5 on page 116 describes the flow route actions.

Table 5: Flow Route Action Modifiers Action or Action Modifier

Description

Actions accept

Accept a packet. This is the default.

discard

Discard a packet silently, without sending an Internet Control Message Protocol (ICMP) message.

community

Replace any communities in the route with the specified communities.

next-term

Continue to the next match condition for evaluation.

routing-instance extended-community

Specify a routing instance to which packets are forwarded.

rate-limit bytes-per-second

Limit the bandwidth on the flow route. Express the limit in bytes per second (Bps).

sample

Sample the traffic on the flow route.

Validating Flow Routes The Junos OS installs flow routes into the flow routing table only if they have been validated using the validation procedure. The Routing Engine does the validation before the installing routes into the flow routing table. Flow routes received using the BGP network layer reachability information (NLRI) messages are validated before they are installed into the flow primary instance routing table instance.inetflow.0. The validation procedure is described in the draft-ietf-idr-flow-spec-09.txt, Dissemination of Flow Specification Rules. You can bypass the validation process for flow routes using BGP NLRI messages and use your own specific import policy.

116



To trace validation operations, include the validation statement at the [edit routing-options flow] hierarchy level: [edit routing-options flow] validation { traceoptions { file filename ; flag flag ; } }

Enabling Support for BGP Flow-Specification Algorithm Version 7 and Later By default, the Junos OS uses the term-ordering algorithm defined in version 6 of the BGP flow specification draft. In Junos OS Release 10.0 and later, you can configure the router to comply with the term-ordering algorithm first defined in version 7 of the BGP flow specification and supported through RFC 5575, Dissemination of Flow Specification Routes.

BEST PRACTICE: We recommend that you configure the Junos OS to use the term-ordering algorithm first defined in version 7 of the BGP flow specification draft. We also recommend that you configure the Junos OS to use the same term-ordering algorithm on all routing instances configured on a router.

To configure BGP to use the flow-specification algorithm first defined in version 7 of the Internet draft, include the standard statement at the [edit routing-options flow term-order] hierarchy level: [edit routing-options] flow { term-order standard; }

To revert to using the term-ordering algorithm defined in version 6, include the legacy statement at the [edit routing-options flow term-order] hierarchy level: [edit routing-options] flow { term-order legacy; }

NOTE: The configured term order has only local significance. That is, the term order does not propagate with flow routes sent to the remote BGP peers, whose term order is completely determined by their own term order configuration. Therefore, you should be careful when configuring the order-dependent action next term when you are not aware of the term order configuration of the remote peers. The local next term might differ from the next term configured on the remote peer.


117



•

Example: Enabling BGP to Carry Flow-Specification Routes on page 1202

•

flow on page 169

Applying Filters to the Forwarding Table To apply a forwarding table filter to a forwarding table, include the filter and input statements at the [edit forwarding-options family family-name] hierarchy level: [edit forwarding-options family family-name] filter { input filter-name; }

NOTE: Forwarding table filtering is not supported on the interfaces you configure as tunnel sources. Input filters affect only the transit packets exiting the tunnel. Forwarding table filtering is not supported with the flow routes configuration.

For more information about forwarding table filters, see the Junos OS Routing Policy Configuration Guide.

118


CHAPTER 5

Configuring Other Protocol-Independent Routing Properties This chapter discusses how to perform the following tasks for configuring other protocol-independent routing properties: •

Configuring AS Numbers for BGP on page 120

•

Configuring Router Identifiers for BGP and OSPF on page 122

•

Configuring AS Confederation Members on page 122

•

Configuring Route Recording for Flow Aggregation on page 123

•

Creating Routing Table Groups on page 123

•

Configuring How Interface Routes Are Imported into Routing Tables on page 125

•

Configuring Multicast Scoping on page 126

•

Enabling Multicast Forwarding Without PIM on page 127

•

Configuring Additional Source-Specific Multicast Groups on page 127

•

Configuring Multicast Forwarding Cache Limits on page 128

•

Configuring Per-Packet Load Balancing on page 128

•

Configuring Unicast Reverse-Path-Forwarding Check on page 131

•

Configuring Graceful Restart on page 132

•

Configuring Route Distinguishers for VRF and Layer 2 VPN Instances on page 133

•

Configuring Dynamic GRE Tunnels for VPNs on page 134

•

Configuring System Logging for the Routing Protocol Process on page 135

•

Configuring Route Resolution on page 136

•

Enabling Indirect Next Hops on page 136

•

Enabling Nonstop Active Routing on page 137

•

Tracing Global Routing Protocol Operations on page 138

•

Disabling Distributed Periodic Packet Management on the Packet Forwarding Engine on page 140

•

Enabling Source Routing on page 141

•

Creating Policies to Control Label Allocation and Substitution for MPLS Ingress and AS Border Routers on page 141


119


Configuring AS Numbers for BGP An autonomous system (AS) is a set of routing devices that are under a single technical administration and that generally use a single interior gateway protocol (IGP) and metrics to propagate routing information within the set of routing devices. An AS appears to other ASs to have a single, coherent interior routing plan and presents a consistent picture of what destinations are reachable through it. ASs are identified by a number that is assigned by the Network Information Center (NIC) in the United States (http://www.isi.edu). In Junos OS Release 9.1 and later, you can configure a number from 1 through 4,294,967,295 in plain-number format. The range is extended to provide BGP support for 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. All releases of the Junos OS support 2-byte AS numbers. The 2-byte AS number range is 1 through 65,535 in plain-number format (this is a subset of the 4-byte range). RFC 4893 introduces two new optional transitive BGP attributes, AS4_PATH and AS4_AGGREGATOR. These new attributes are used to propagate 4-byte AS path information across BGP speakers that do not support 4-byte AS numbers. RFC 4893 also introduces a reserved, well-known, 2-byte AS number, AS 23456. This reserved AS number is called AS_TRANS in RFC 4893. In Junos OS Release 9.3 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. In AS-dot notation format, you can specify a value for AS number from 0.0 through 65535.65535. If you are using BGP on the routing device, you must configure an AS number. To configure the routing device’s AS number, include the autonomous-system statement: autonomous-system autonomous-system ;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To specify the number of times detection of the AS number in the AS_PATH attribute causes the route to be discarded or hidden, include the loops option. For example, if you configure loops 1, the route is hidden if the AS number is detected in the path one or more times. This is the default behavior. If you configure loops 2, the route is hidden if the AS number is detected in the path two or more times. You can specify a value in the range from 1 through 10. The default value is 1. The AS path attribute is modified when a route is advertised to an EBGP peer. Each time a route is advertised to an EBGP peer, the local routing device prepends its AS number to the existing path attribute, and a value of 1 is added to the AS number.

120


Chapter 5: Configuring Other Protocol-Independent Routing Properties

NOTE: When you specify the same AS number in more than one routing instance on the local routing device, you must configure the same number of loops for the AS number in each instance. For example, if you configure a value of 3 for the loops statement in a VPN routing and forwarding (VRF) routing instance that uses the same AS number as that of the master instance, you must also configure a value of 3 loops for the AS number in the master instance. Use the independent-domain option if the loops statement must be enabled only on a subset of routing instances. For more information about configuring an independent AS domain, see “Configuring Independent AS Domains” on page 289.

By default, the AS number is displayed in plain-number format even if you configured a 4-byte AS number using the AS-dot notation format. Include the asdot-notation statement to configure the router to display a 4-byte AS number in the AS-dot notation format.

Examples: Configuring AS Numbers Configure the 4-byte AS number 65,546 represented in plain-number format: [edit] routing-options { autonomous-system 65546; } }

Configure the 4-byte AS number 65,546 represented in AS-dot notation format (in this example, 1.10 is the AS-dot notation format for 65,546): [edit] routing-options { autonomous-system 1.10; } }

Configure the 2-byte AS number 60,000 represented in plain-number format: [edit] routing-options { autonomous-system 60000; } }


•

4-Byte Autonomous System Numbers Overview in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview

•

Juniper Networks Implementation of 4-Byte Autonomous System Numbers in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview

•

Configuring 4-Byte Autonomous System Numbers in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview


121


•

Understanding a 4-Byte Capable Router AS Path Through a 2-Byte Capable Domain in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview

Configuring Router Identifiers for BGP and OSPF The router identifier is used by BGP and OSPF to identify the routing device from which a packet originated. The router identifier usually is the IP address of the local routing device. If you do not configure a router identifier, the IP address of the first interface to come online is used. This is usually the loopback interface. Otherwise, the first hardware interface with an IP address is used. To configure the router identifier, include the router-id statement: router-id address;


NOTE: We strongly recommend that you configure the router identifier under the [edit routing-options] hierarchy level to avoid unpredictable behavior if the interface address on a loopback interface changes.

Configuring AS Confederation Members If you administer multiple ASs that contain a very large number of BGP systems, you can group them into one or more confederations. Each confederation is identified by its own AS number, which is called a confederation AS number. To external ASs, a confederation appears to be a single AS. Thus, the internal topology of the ASs making up the confederation is hidden. The BGP path attributes NEXT_HOP, LOCAL_PREF, and MULTI_EXIT_DISC, which normally are restricted to a single AS, are allowed to be propagated throughout the ASs that are members of the same confederation. Because each confederation is treated as if it were a single AS, you can apply the same routing policy to all the ASs that make up the confederation. Grouping ASs into confederations reduces the number of BGP connections required to interconnect ASs. If you are using BGP, you can enable the local routing device to participate as a member of an AS confederation. To do this, include the confederation statement: confederation confederation-autonomous-system members [ autonomous-systems ];


122



Specify the AS confederation identifier, along with the peer AS numbers that are members of the confederation. Note that peer adjacencies do not form if two BGP neighbors disagree about whether an adjacency falls within a particular confederation. Related Documentation

•

Example: Configuring BGP Confederations on page 1051

Configuring Route Recording for Flow Aggregation Before you can perform flow aggregation, the routing protocol process must export the AS path and routing information to the sampling process. To do this, include the route-record statement: route-record;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. Related Documentation

•

Junos OS Services Interfaces Configuration Guide

Creating Routing Table Groups You can group together one or more routing tables to form a routing table group. Within a group, a routing protocol can import routes into all the routing tables in the group and can export routes from a single routing table. To create a routing table group, include the rib-groups statement: rib-groups group-name { import-policy [ policy-names ]; import-rib [ routing-table-names ]; export-rib routing-table-name; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. The routing table group can have any name you choose (specified in group-name). If the group name you specify is not created explicitly, you can create it by naming it in the rib-groups statement. Each routing table group must contain one or more routing tables that the Junos OS uses when importing routes (specified in the import-rib statement). The first routing table you specify is the primary routing table, and any additional routing tables are the secondary routing tables. The primary routing table determines the address family of the routing table group. To configure an IP version 4 (IPv4) routing table group, specify inet.0 as the primary routing table. To configure an IP version 6 (IPv6) routing table group, specify inet6.0 as the


123


primary routing table. If you configure an IPv6 routing table group, the primary and all secondary routing tables must be IPv6 routing tables (inet6.x). In Junos OS Release 9.5 and later, you can include both IPv4 and IPv6 routing tables in an IPv4 import routing table group using the import-rib statement. In releases prior to Junos OS Release 9.5, you can only include either IPv4 or IPv6 routing tables in the same import-rib statement. The ability to configure an import routing table group with both IPv4 and IPv6 routing tables enables you, for example, to populate the inet6.3 routing table with IPv6 addresses that are compatible with IPv4. Specify inet.0 as the primary routing table, and specify inet6.3 as a secondary routing table. Each routing table group optionally can contain one routing table group that the Junos OS uses when exporting routes to the routing protocols (specified in the export-rib statement).

NOTE: If you configure an import routing table group that includes both IPv4 and IPv6 routing tables, any corresponding export routing table group must include only IPv4 routing tables.

If you have configured a routing table, configure the OSPF primary instance at the [edit protocols ospf] hierarchy level with the statements needed for your network so that routes are installed in inet.0 and in the forwarding table. Make sure to include the routing table group. For more information, see “Example: Configuring Multiple Routing Instances of OSPF” on page 256. After specifying the routing table from which to import routes, you can apply one or more policies to control which routes are installed in the routing table group. To apply a policy to routes being imported into the routing table group, include the import-policy statement: rib-groups group-name { import-policy [ policy-names ]; }


Examples: Creating Routing Table Groups Create an IPv4 routing table group so that interface routes are installed into two routing tables, inet.0 and inet.2: [edit] routing-options { interface-routes { rib-group if-rg; } rib-groups if-rg { import-rib [ inet.0 inet.2 ]; } }

124



Create an IPv6 routing table group so that interface routes are installed into two routing tables, inet6.0 and inet6.2: [edit] routing-options { interface-routes { rib-group inet6 if-rg; } rib-groups if-rg { import-rib [ inet6.0 inet6.2 ]; } }

Configuring How Interface Routes Are Imported into Routing Tables By default, IPv4 interface routes (also called direct routes) are imported into routing table inet.0, and IPv6 interface routes are imported into routing table inet6.0. If you are configuring alternate routing tables for use by some routing protocols, it might be necessary to import the interface routes into the alternate routing tables. To define the routing tables into which interface routes are imported, you create a routing table group and associate it with the routing device’s interfaces. To associate an IPv4 routing table group with the routing device’s interfaces and specify which routing table groups interface routes are imported into, include the interface-routes statement: interface-routes { rib-group group-name; }

To associate an IPv6 routing table group with an interface, include the interface-routes statement at the [edit routing-options] hierarchy level: interface-routes { rib-group inet6 group-name; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To create the routing table groups, include the passive statement at the [edit routing-options] hierarchy level. For configuration information, see “Creating Routing Table Groups” on page 123. If you have configured a routing table, configure the OSPF primary instance at the [edit protocols ospf] hierarchy level with the statements needed for your network so that routes are installed in inet.0 and in the forwarding table. Make sure to include the routing table group. For more information, see “Example: Configuring Multiple Routing Instances of OSPF” on page 256. To export local routes, include the export statement: export { lan;


125


point-to-point; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. To export LAN routes, include the lan option. To export point-to-point routes, include the point-to-point option. Only local routes on point-to-point interfaces configured with a destination address are exportable.

Configuring Multicast Scoping To configure multicast address scoping, include the following statements: multicast { scope scope-name { interface [ interface-names ]; prefix destination-prefix; } scope-policy policy-name; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Specify a name for the scope, its address range, and the routing device interfaces on which you are configuring scoping. You can apply a multicast scoping policy to the routing table. To apply a scoping policy, include the scope-policy statement at the [edit routing-options multicast] hierarchy level. For more information on configuring a scoping policy, see the Junos OS Routing Policy Configuration Guide.

Example: Configuring Multicast Scoping Configure multicast scoping by creating four scopes: local, organization, engineering, and marketing. Configure the local scope on a Fast Ethernet interface. Configure the organization scope on a Fast Ethernet and a SONET/SDH interface. Configure the engineering and marketing scopes on two SONET/SDH interfaces. [edit] routing-options { multicast { scope local { prefix 239.255.0.0/16; fe-0/1/0.0; } scope organization { prefix 239.192.0.0/14; interface [ fe-0/1/0.0 so-0/0/0.0 ]; }

126



scope engineering { prefix 239.255.255.0/24; interface [ so-0/0/1.0 so-0/0/2.0 ]; } scope marketing { prefix 239.255.254.0/24; interface [ so-0/0/1.0 so-0/0/2.0 ]; } } }

Enabling Multicast Forwarding Without PIM By default, multicast packets are forwarded by enabling Protocol Independent Multicast (PIM) on an interface. PIM adds multicast routes into the routing table. You can also configure multicast packets to be forwarded over a static route, such as a static route associated with an LSP next hop. Multicast packets are accepted on an interface and forwarded over a static route in the forwarding table. This is useful when you want to enable multicast traffic on a specific interface without configuring PIM on the interface. To enable multicast traffic on an interface, include the interface statement: interface interface-name;

To disable multicast traffic on an interface, include the disable statement: interface interface-name { disable; }

For a list of hierarchy levels at which you can include these statements, see the statement summary section for these statements.

NOTE: You cannot enable multicast traffic on an interface and configure PIM on the same interface simultaneously.

NOTE: Static routes must be configured before you can enable multicast on an interface. Configuring the interface statement alone does not install any routes into the routing table. This feature relies on the static route configuration.

Configuring Additional Source-Specific Multicast Groups IGMPv3 supports Source Specific Multicast (SSM) groups. By utilizing inclusion lists, only sources that are specified send to the SSM group. By default, the SSM group multicast address is limited to the IP address range 232.0.0.0 to 232.255.255.255. You can configure additional SSM groups. Shared tree delivery is prohibited on SSM groups.


127


To configure additional SSM groups, include the ssm-groups statement: ssm-groups { address; }


Configuring Multicast Forwarding Cache Limits To configure multicast forwarding cache limits, include the following statements: multicast { forwarding-cache { threshold suppress value ; } }

You can include these statements at the following hierarchy levels: •

[edit routing-options]

•

[edit logical-systems logical-system-name routing-options]

By default, there are no limits on the number of multicast forwarding cache entries. Specify a value for the threshold at which to suppress new multicast forwarding cache entries and an optional reuse value for the threshold at which the router begins to create new multicast forwarding cache entries. The range for both is from 1 through 200,000. If configured, the reuse value should be less than the suppression threshold value. The suppression value is mandatory. If you do not specify the optional reuse value, then the number of multicast forwarding cache entries is limited to the suppression value. A new entry is created as soon as the number of multicast forwarding cache entries falls below the suppression value. Related Documentation

•

Junos OS Logical Systems Configuration Guide

•

Junos OS Multicast over Layer 3 VPNs Feature Guide

Configuring Per-Packet Load Balancing For the active route, when there are multiple equal-cost paths to the same destination, by default, the Junos OS chooses in a random fashion one of the next-hop addresses to install into the forwarding table. Whenever the set of next hops for a destination changes in any way, the next-hop address is chosen again, also in a random fashion. You can configure the Junos OS so that, for the active route, all next-hop addresses for a destination are installed in the forwarding table. This is called per-packet load balancing. You can use load balancing to spread traffic across multiple paths between routing devices. The behavior of the per-packet load-balancing function varies according to the version of the Internet Processor ASIC in the routing device.

128



On routing devices with an Internet Processor I ASIC, when per-packet load balancing is configured, traffic between routing devices with multiple paths is spread in a random fashion across the available interfaces. The forwarding table balances the traffic headed to a destination, transmitting packets in round-robin fashion among the multiple next hops (up to a maximum of eight equal-cost load-balanced paths). The traffic is load-balanced on a per-packet basis.

NOTE: Per-packet load distribution uses a hashing algorithm that distributes packets over equal-cost links. The algorithm is designed to distribute packets to prevent any single link from being saturated. However, per-packet load balancing offers no guarantee of equal distribution of traffic over equal-cost links, nor does it guarantee that increasing the number of Internet flows creates a better hash distribution.

On routing devices with the Internet Processor II ASIC and T Series Internet Processor II ASIC, when per-packet load balancing is configured, traffic between routing devices with multiple paths is divided into individual traffic flows (up to a maximum of 16 equal-cost load-balanced paths). Packets for each individual flow are kept on a single interface. To recognize individual flows in the transit traffic, the routing device examines each of the following: •

Source IP address

•

Destination IP address

•

Protocol

•

Source port number

•

Destination port number

•

Source interface index

•

Type of service (ToS)

The routing device recognizes packets in which all of these parameters are identical, and it ensures that these packets are sent out through the same interface. This prevents problems that might otherwise occur with packets arriving at their destination out of their original sequence.

NOTE: Load balancing is not supported on management and internal Ethernet (fxo) interfaces because this type of interface cannot handle the routing process. On fxp interfaces, you cannot configure multiple next hops and enable load balancing.

The following steps shows how to configure per-packet load balancing: 1.

Define a load-balancing routing policy by including one or more policy-statement statements at the [edit policy-options] hierarchy level, defining an action of load-balance per-packet:


129


policy-statement policy-name { from { match-conditions; route-filter destination-prefix match-type ; prefix-list name; } then { load-balance per-packet; } } 2. Apply the policy to routes exported from the routing table to the forwarding table. To

do this, include the forwarding-table and export statements: forwarding-table { export policy-name; }

NOTE: You cannot apply the export policy to VRF routing instances.


NOTE: Specify all next-hops of that route, if more than one exists, when allocating a label corresponding to a route that is being advertised.

NOTE: Configure the forwarding-options hash key for MPLS to include the IP payload.

Examples: Configuring Per-Packet Load Balancing Perform per-packet load balancing for all routes: [edit] policy-options { policy-statement load-balancing-policy { then { load-balance per-packet; } } } routing-options { forwarding-table { export load-balancing-policy; } }

Perform per-packet load balancing for only a limited set of routes: [edit]

130



policy-options { policy-statement load-balancing-policy { from { route-filter 192.168.10/24 orlonger; route-filter 9.114/16 orlonger; } then { load-balance per-packet; } } } routing-options { forwarding-table { export load-balancing-policy; } }

Configuring Unicast Reverse-Path-Forwarding Check IP spoofing can occur during a denial-of-service (DoS) attack. IP spoofing allows an intruder to pass IP packets to a destination as genuine traffic, when in fact the packets are not actually meant for the destination. This type of spoofing is harmful because it consumes the destination’s resources. Unicast reverse-path-forwarding (RPF) check is a tool to reduce forwarding of IP packets that may be spoofing an address. A unicast RPF check performs a route table lookup on an IP packet’s source address, and checks the incoming interface. The router determines whether the packet is arriving from a path that the sender would use to reach the destination. If the packet is from a valid path, the router forwards the packet to the destination address. If it is not from a valid path, the router discards the packet. Unicast RPF is supported for the IPv4 and IPv6 protocol families, as well as for the virtual private network (VPN) address family. To control the operation of unicast RPF check, include the unicast-reverse-path statement: unicast-reverse-path (active-paths | feasible-paths);

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To consider only active paths during the unicast RPF check, include the active-paths option. To consider all feasible paths during the unicast RPF check, include the feasible-paths option.

NOTE: Reverse-path forwarding is not supported on the interfaces you configure as tunnel sources. This affects only the transit packets exiting the tunnel.

You must enable unicast RPF check on an interface. To do so, include the rpf-check statement: rpf-check ;


131


You can include this statement at the following hierarchy levels: •

[edit interfaces interface-name unit logical-unit-number family (inet | inet6)]

•

[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6)]

For more information about configuring unicast RPF on an interface, see the Junos OS Services Interfaces Configuration Guide.

Example: Configuring Unicast RPF Configure unicast RPF strict mode, and apply a fail filter that allows the interface to accept BOOTP packets and DHCP packets. The filter accepts all packets with a source address of 0.0.0.0 and a destination address of 255.255.255.255. [edit firewall] filter rpf-special-case-dhcp-bootp { term allow-dhcp-bootp { from { source-address { 0.0.0.0/32; } address { 255.255.255.255/32; } } then { count rpf-dhcp-bootp-traffic; accept; } } term default { then { log; reject; } } } [edit] interfaces { so-0/0/0 { unit 0 { family inet { rpf-check fail-filter rpf-special-case-dhcp-bootp; } } } }

Configuring Graceful Restart Graceful restart allows a routing device undergoing a restart to inform its adjacent neighbors and peers of its condition. The restarting routing device requests a grace period from the neighbor or peer, which can then cooperate with the restarting routing device.

132



With a graceful restart, the restarting routing device can still forward traffic during the restart period, and convergence in the network is not disrupted. The restart is not visible to the rest of the network, and the restarting routing device is not removed from the network topology. The graceful restart request occurs only if the following conditions are met: •

The network topology is stable.

•

The neighbor or peer cooperates.

•

The restarting routing device is not already cooperating with another restart already in progress.

•

The grace period does not expire.

Graceful restart is disabled by default. You must configure graceful restart at the [edit routing-options] hierarchy level to enable the feature for Layer 2 and Layer 3 VPNs. To enable graceful restart, include the graceful-restart statement: graceful-restart { disable; restart-duration seconds; }

NOTE: Configuring graceful restart for BGP resets the BGP peer routing statistics to zero.

To disable graceful restart, include the disable statement. To configure a time period for complete restart, include the restart-duration statement. You can specify a number between 120 and 900. For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. Related Documentation

•

Junos OS High Availability Configuration Guide

Configuring Route Distinguishers for VRF and Layer 2 VPN Instances If the route distinguisher ID is configured, the routing process automatically generates a type 1 route distinguisher for VPN routing and forwarding (VRF) and Layer 2 VPN instances. If a route distinguisher is explicitly configured under the routing instances stanza, then that configured route distinguisher is used. To configure a route distinguisher identifier globally, include the route-distinguisher-id statement: route-distinguisher-id address;



133



•

Junos OS VPNs Configuration Guide

Configuring Dynamic GRE Tunnels for VPNs A VPN that travels through a non-MPLS network requires a generic routing encapsulation (GRE) tunnel. This tunnel can be either a static tunnel or a dynamic tunnel. A static tunnel is configured manually between two provider edge (PE) routers. A dynamic tunnel is configured using BGP route resolution. When a router receives a VPN route that resolves over a BGP next hop that does not have an MPLS path, a GRE tunnel can be created dynamically, allowing the VPN traffic to be forwarded to that route. Formerly, GRE tunnels had to be established manually. Only GRE IPv4 tunnels are supported. To configure a dynamic tunnel between two PE routers, include the dynamic-tunnels statement: dynamic-tunnels tunnel-name { destination-networks prefix; source-address address; tunnel-type type; }


[edit routing-options]

•

[edit logical-systems logical-system-name routing-options]

Specify the IPv4 prefix range (for example, 10/8 or 11.1/16) for the destination network by including the destination-networks statement. Only tunnels within the specified IPv4 prefix range can be created. destination-networks prefix;


[edit routing-options dynamic-tunnels tunnel-name]

•

[edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]

Specify the source address for the GRE tunnels by including the source-address statement. The source address specifies the address used as the source for the local tunnel endpoint. It can be any local address on the router (typically the router ID or the loopback address). source-address address;

You can include this statement at the following hierarchy levels:

134

•


•




Specify the type of tunnel to be dynamically created by including the tunnel-type statement. The only currently valid value is gre (for GRE tunnels). tunnel-type type;



•


Configuring System Logging for the Routing Protocol Process To control how much information the routing protocol process should log, include the options statement. Include the following form of the statement to log messages for a particular severity level and all higher levels: routing-options { options syslog upto level; }

Include the following form of the statement to log messages for a particular severity level: routing-options { options syslog level level; }


NOTE: System logging frequently deals with processes logged at the info or notice severity level. Make sure that your regular system logging configurations include the info or notice levels.

Examples: Configuring System Logging for the Routing Protocol Process Configure the router to log messages of all severities: [edit] user@host# set routing-options options syslog upto emergency [edit] user@host# show routing-options { options syslog upto emergency; }

Configure the router to log only alert-level and critical-level messages: [edit] user@host# set routing-options options syslog level alert critical [edit]


135


user@host# show routing-options { options syslog alert critical; }

Configuring Route Resolution You can configure a routing table to accept routes from specific routing tables. You can also configure a routing table to use specific import policies to produce a route resolution table to resolve routes. To configure route resolution, include the resolution statement: resolution { rib routing-table-name { import [ policy-names ]; resolution-ribs [ routing-table-names ]; } }

To specify the name of the routing table to modify, include the rib routing-table-name statement. To specify one or more import policies to use for route resolution, include the import [ policy-names ] statement. To specify one or more routing tables to use for route resolution, include the resolution-ribs [ routing-table-names ] statement. For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Enabling Indirect Next Hops The Junos OS supports the concept of an indirect next hop for all routing protocols that support indirectly connected next hops, also known as third-party next hops. Because routing protocols such as IBGP can send routing information about indirectly connected routes, the Junos OS relies on routes from intra-AS routing protocols (OSPF, IS-IS, RIP, and static) to resolve the best directly connected next hop. The Routing Engine performs the task of route resolution to determine the best directly connected next hop and install the route to the Packet Forwarding Engine. By default, the Junos OS does not maintain the route for indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table. As a result, when a rerouting event occurs, potentially thousands of route to forwarding next-hop bindings must be updated, which increases the route convergence time. Figure 2 on page 136 illustrates the route to forwarding next-hop bindings with indirect next hop disabled.

Figure 2: Route to Forwarding Next-Hop Bindings

136



You can enable the Junos OS to maintain the indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table. As a result, fewer route to forwarding next-hop bindings need to be updated, which improves the route convergence time. Figure 3 on page 137 illustrates the route to forwarding next-hop bindings with indirect next hop enabled.

Figure 3: Route to Forwarding Indirect Next-Hop Bindings

To enable indirectly connected next hops, include the indirect-next-hop statement: indirect-next-hop;

NOTE: When virtual private LAN service (VPLS) is configured on the routing device, the indirect-next-hop statement is configurable at the [edit routing-options forwarding-table] hierarchy level. However, this configuration is not applicable to indirect nexthops specific to VPLS routing instances.

To disable indirectly connected next hops, include the no-indirect-next-hop statement: no-indirect-next-hop;

NOTE: By default, the Junos Trio Modular Port Concentrator (MPC) chipset on MX Series Routers is enabled with indirectly connected next hops and this cannot be disabled using the no-indirect-next-hop statement.


Enabling Nonstop Active Routing Nonstop active routing (NSR) allows a routing platform with redundant Routing Engines to switch over from a primary Routing Engine to a backup Routing Engine without alerting peer nodes that a change has occurred. NSR uses the same infrastructure as graceful Routing Engine switchover (GRES) to preserve interface and kernel information. However, NSR also saves routing protocol information by running the routing protocol (rpd) process on the backup Routing Engine. Saving this additional information makes NSR self-contained and eliminates the need for helper routers to assist the routing platform in restoring routing protocol information. As a result of this enhanced functionality, NSR is a natural replacement for graceful restart protocol extensions. If the kernel on the master Routing Engine stops operating, the master Routing Engine experiences a hardware failure, or the administrator initiates a manual switchover,


137


mastership switches to the backup Routing Engine. To configure NSR, you must first enable GRES on your routing platform. To enable NSR, include the nonstop-routing statement at the [edit routing-options] hierarchy level. [edit routing-options] nonstop-routing;

NOTE: You cannot configure NSR and graceful restart protocol extensions simultaneously. To ensure proper operation, include either the nonstop-routing statement or the graceful-restart statement at the hierarchy level, but not both statements at the same time.


•


Tracing Global Routing Protocol Operations Global routing protocol tracing operations track all general routing operations and record them in a log file. To set protocol-specific tracing operations and to modify the global tracing operations for an individual protocol, configure tracing for that protocol. For a general discussion about tracing and the precedence of multiple tracing operations, see the Junos OS System Basics Configuration Guide. To configure global routing protocol tracing, include the traceoptions statement at the [edit routing-options] hierarchy level: traceoptions { file filename ; flag flag ; }

Using the traceoptions statement, you can specify the following global routing protocol tracing flags: •

all—All tracing operations

•

condition-manager—Condition manager events

•

config-internal—Configuration internals

•

general—All normal operations and routing table changes (a combination of the normal

and route trace operations)

138

•

graceful-restart—Graceful restart operations

•

normal—All normal operations

•

nsr-synchronization—Nonstop-routing synchronization events

•

parse—Configuration parsing



•

policy—Policy operations and actions

•

regex-parse—Regular-expression parsing

•

route—Routing table changes

•

state—State transitions

•

task—Interface transactions and processing

•

timer—Timer usage

NOTE: Use the trace flag all with caution. This flag may cause the CPU to become very busy.

The flags in a traceoptions flag statement are identifiers. When you use the set command to configure a flag, any flags that might already be set are not modified. In the following example, setting the timer tracing flag has no effect on the already configured task flag. Use the delete command to delete a particular flag. [edit routing-options traceoptions] user@host# show flag task; user@host# set traceoptions flag timer user@host# show flag task; flag timer; user@host# delete traceoptions flag task user@host# show flag timer;

Examples: Tracing Global Routing Protocol Operations Log all globally traceable operations, saving the output in up to 10 files that are up to 10 MB in size: [edit] routing-options { traceoptions { file routing size 10m files 10; flag all; } }

Log all unusual or abnormal traceable operations: [edit] routing-options { traceoptions { file routing size 10m files 10; flag all; flag normal disable; } }


139


Log changes that occur in the Junos OS routing table: [edit] routing-options { traceoptions { file routing size 10m files 10; flag route; } }

Disabling Distributed Periodic Packet Management on the Packet Forwarding Engine Periodic packet management (PPM) is responsible for periodic transmission of packets on behalf of its various client processes, such as Bidirectional Forwarding Detection (BFD). PPM also receives packets on behalf of client processes. By default, PPM handles time-sensitive periodic processing and performs such processes as the gathering of statistics and the sending of process-specific packets. Distributing PPM to the Packet Forwarding Engine allows you to run such processes as BFD on the Packet Forwarding Engine. In Junos OS Release 9.4 and later, PPM automatically runs on both the Routing Engine and the host subsystem of the Packet Forwarding Engine or Dense Port Concentrator (DPC).

NOTE: Distributed PPM runs on access ports on EX3200 and EX4200 switches and on line cards on EX8200 switches. Therefore, each instance of “Packet Forwarding Engine” in this topic is a shortened version of “Packet Forwarding Engine, access ports, or line cards.”

PPM runs on the Routing Engine and Packet Forwarding Engine by default. You can only disable PPM on the Packet Forwarding Engine. To disable distributed PPM on the Packet Forwarding Engine, include the ppm statement: ppm { no-delegate-processing; }


NOTE: Distributed PPM is supported only on the M7i and M10i routers with Enhanced CFEB (CFEB-E); M120 and M320 routers; and all MX Series, T Series, TX Matrix routers, and EX Series switches.

The following types of sessions are supported by distributed PPM:

140

•

BFD single-hop session for both IPv4 and IPv6, including EBGP, ISIS, and OSPF

•

Connectivity fault management (CFM) sessions

•

Link fault management (LFM) sessions



•

Rapid Spanning Tree Protocol (RSTP) and Multiple Spanning Tree Protocol (MSTP) interface sessions

•

Link Aggregation Control Protocol (LACP) sessions (MX Series and M320 routers only)

•

BFD over an aggregated interface for IPv4

The following types of sessions are not supported by distributed PPM: •

BFD over an aggregated interface for IPv6, RSTP, MSTP, and LACP

•

BFD over an IPv6 interface that does not have the global IPv6 address (or only has a link local address)

•

Multihop BFD with IBGP, static routes, EBGP multihop, and MPLS LSP

•

BFD over an MPLS path using OAM

In addition, on the M120 router, when Forwarding Engine Board (FEB) redundancy is configured and a FEB fails over, PPM sessions do not automatically switch over to the newly active FEB. Related Documentation

•


Enabling Source Routing Starting in Junos OS Release 8.2 for IPv6 and Junos OS Release 8.5 for IPv4, source routing is disabled by default on J Series Services Routers , M Series Multiservice Edge Routers, MX Series 3D Universal Edge Routers, T Series Core Routers, and on EX Series switches. To enable source routing, include the source-routing statement:

NOTE: We recommend that you not use source routing.

source-routing { (ip | ipv6); }


Creating Policies to Control Label Allocation and Substitution for MPLS Ingress and AS Border Routers In Junos OS Release 10.0 and later, you can control label-advertisements on MPLS ingress and AS border routers (ASBRs) on a per-route basis by specifying a label allocation policy using the allocation label-allocation-policy statement at the [edit routing-instances routing-instance-name routing-options label] hierarchy level. You can configure the label allocation mode as either per-nexthop or per-table. Additionally, you can configure label substitution on a per-route basis by specifying a label substitution policy using the substitution label-substitution-policy statement at the


141


[edit routing-instances routing-instance-name routing-options label] hierarchy level. The

label substitution policy is used to determine whether or not a label should be substituted on an ASBR router. The results of the policy operation are either accept (label substitution is performed) or reject (label substitution is not performed). The default behavior is to accept. Related Documentation

142

•



CHAPTER 6

Summary of Protocol-Independent Routing Properties Configuration Statements This chapter provides a reference for each of the protocol-independent routing configuration statements. The statements are organized alphabetically.

access Syntax

Hierarchy Level

Release Information Description Options Required Privilege Level Related Documentation

access { route ip-prefix { metric route-cost; next-hop next-hop; preference (Access) route-distance; qualified-next-hop next-hop; tag tag-number } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options],

Statement introduced in Junos OS Release 10.1. Configure access routes. The remaining statements are explained separately. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



143


access-internal Syntax

Hierarchy Level


144

access-internal { route ip-prefix { next-hop next-hop; qualified-next-hop next-hop } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options],

Statement introduced in Junos OS Release 10.1. Configure parameters for internal access routes. The remaining statements are explained separately. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



Chapter 6: Summary of Protocol-Independent Routing Properties Configuration Statements

active Syntax Hierarchy Level

Release Information

Description

(active | passive); [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit routing-instances routing-instance-name routing-options (aggregate | generate | static) (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit routing-options (aggregate | generate | static) (defaults | route)], [edit routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure whether static, aggregate, or generated routes are removed from the routing and forwarding tables when they become inactive. Routes that have been configured to remain continually installed in the routing and forwarding tables are marked with reject next hops when they are inactive. •

active—Remove a route from the routing and forwarding tables when it becomes

inactive. •

passive—Have a route remain continually installed in the routing and forwarding tables

even when it becomes inactive. Default Required Privilege Level Related Documentation

active

routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


•


•



145


aggregate Syntax

Hierarchy Level

Release Information

Description Options

aggregate { defaults { ... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... } } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name], [edit logical-systems logical-system-name routing-options], [edit logical-systems logical-system-name routing-options rib routing-table-name], [edit routing-instances routing-instance-name routing-options], [edit routing-instances routing-instance-name routing-options rib routing-table-name], [edit routing-options], [edit routing-options rib routing-table-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure aggregate routes. aggregate-options—Additional information about aggregate routes that is included with

the route when it is installed in the routing table. Specify zero or more of the following options in aggregate-options. Each option is explained separately. •

(active | passive);

•

as-path ;

•

(brief | full);

•

community [ community-ids ];

•

discard;

•

(metric | metric2 | metric3 | metric4) value ;

•

(preference | preference2 | color | color2) preference ;

•

tag string;

defaults—Specify global aggregate route options. These options only set default attributes

inherited by all newly created aggregate routes. These are treated as global defaults and apply to all the aggregate routes you configure in the aggregate statement. This part of the aggregate statement is optional.

146



route destination-prefix—Configure a nondefault aggregate route: •

default—For the default route to the destination. This is equivalent to specifying an IP

address of 0.0.0.0/0. •

destination-prefix/prefix-length—destination-prefix is the network portion of the IP

address, and prefix-length is the destination prefix length. The policy statement is explained separately. Required Privilege Level Related Documentation




147


as-path Syntax

Hierarchy Level

Release Information

Description

as-path ; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit routing-instances routing-instance-name routing-options (aggregate | generate | static) (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit routing-options (aggregate | generate | static) (defaults | route)], [edit routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Associate BGP autonomous system (AS) path information with a static, aggregate, or generated route. In Junos OS Release 9.1 and later, the numeric range for the AS number is extended to provide BGP support for 4-byte AS numbers as defined in RFC 4893, BGP Support for Four-octet AS Number Space. RFC 4893 introduces two new optional transitive BGP attributes, AS4_PATH and AS4_AGGREGATOR. These new attributes are used to propagate 4-byte AS path information across BGP speakers that do not support 4-byte AS numbers. RFC 4893 also introduces a reserved, well-known, 2-byte AS number, AS 23456. This reserved AS number is called AS_TRANS in RFC 4893. For more information, see “Configuring AS Numbers for BGP” on page 120. All releases of the Junos OS support 2-byte AS numbers. In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. You can specify a value in the range from 0.0 through 65535.65535 in AS-dot notation format.

Options

aggregator—(Optional) Attach the BGP aggregator path attribute to the aggregate route.

You must specify the last AS number that formed the aggregate route (encoded as two octets) for as-number, followed by the IP address of the BGP system that formed the aggregate route for in-address. as-path—(Optional) AS path to include with the route. It can include a combination of

individual AS path numbers and AS sets. Enclose sets in brackets ( [ ] ). The first AS

148



number in the path represents the AS immediately adjacent to the local AS. Each subsequent number represents an AS that is progressively farther from the local AS, heading toward the origin of the path. You cannot specify a regular expression for as-path; you must use a full, valid AS path. atomic-aggregate—(Optional) Attach the BGP atomic-aggregate path attribute to the

aggregate route. This path attribute indicates that the local system selected a less specific route instead of a more specific route. origin egp—(Optional) BGP origin attribute that indicates that the path information

originated in another AS. origin igp—(Optional) BGP origin attribute that indicates that the path information

originated within the local AS. origin incomplete—(Optional) BGP origin attribute that indicates that the path information

was learned by some other means. Required Privilege Level Related Documentation



•


•


•

Understanding a 4-Byte Capable Router AS Path Through a 2-Byte Capable Domain in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview


149


auto-export Syntax

Hierarchy Level

Release Information Description Options

auto-export { (disable | enable); family { inet { multicast { (disable | enable); rib-group rib-group; } unicast { (disable | enable); rib-group rib-group; } } traceoptions { file filename ; flag flag ; } } } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Export routes between routing instances. (disable | enable)—Disable or enable auto-export.

Default: Enable family—Address family. inet—IP version 4 (IPv4) address family. multicast—Multicast routing information. unicast—Unicast routing information.

The remaining statements are explained separately. Required Privilege Level Related Documentation

150


Configuring Policy-Based Export for Routing Instances on page 274



autonomous-system Syntax

Hierarchy Level

Release Information

Description

autonomous-system autonomous-system { independent-domain ; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. asdot-notation introduced in Junos OS Release 9.3. asdot-notation introduced in Junos OS Release 9.3 for EX Series switches. no-attrset option introduced in Junos OS Release 10.4. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the routing device’s AS number. In Junos OS Release 9.1 and later, the numeric range is extended to provide BGP support for 4-byte AS numbers as defined in RFC 4893, BGP Support for Four-octet AS Number Space. RFC 4893 introduces two new optional transitive BGP attributes, AS4_PATH and AS4_AGGREGATOR. These new attributes are used to propagate 4-byte AS path information across BGP speakers that do not support 4-byte AS numbers. RFC 4893 also introduces a reserved, well-known, 2-byte AS number, AS 23456. This reserved AS number is called AS_TRANS in RFC 4893. All releases of the Junos OS support 2-byte AS numbers. In Junos OS Release 9.3 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format.

Options

autonomous-system—AS number. Use a number assigned to you by the Network

Information Center (NIC). 32

Range: 1 through 4,294,967,295 (2

– 1) in plain-number format for 4-byte AS numbers

Range: 1 through 65,535 in plain-number format for 2-byte AS numbers (this is a subset of the 4-byte range) Range: 0.0 through 65535.65535 in AS-dot notation format for 4-byte numbers asdot-notation—(Optional) Display the configured 4-byte autonomous system number

in the AS-dot notation format. Default: Even if a 4-byte AS number is configured in the AS-dot notation format, the default is to display the AS number in the plain-number format. loops number—(Optional) Specify the number of times detection of the AS number in

the AS_PATH attribute causes the route to be discarded or hidden. For example, if you configure loops 1, the route is hidden if the AS number is detected in the path


151


one or more times. This is the default behavior. If you configure loops 2, the route is hidden if the AS number is detected in the path two or more times. Range: 1 through 10 Default: 1

NOTE: When you specify the same AS number in more than one routing instance on the local routing device, you must configure the same number of loops for the AS number in each instance. For example, if you configure a value of 3 for the loops statement in a VRF routing instance that uses the same AS number as that of the master instance, you must also configure a value of 3 loops for the AS number in the master instance. Use the independent-domain option if the loops statement must be enabled only on a subset of routing instances.

The remaining statement is explained separately. Required Privilege Level Related Documentation

152


Configuring AS Numbers for BGP on page 120

•


•


•

Configuring 4-Byte Autonomous System Numbers in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview



bfd Syntax

Hierarchy Level

Release Information

Description Default Options

bfd { traceoptions { file filename ; flag flag ; } [edit logical-systems logical-system-name protocols], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols], [edit protocols], [edit routing-instances routing-instance-name protocols]

Statement introduced before Junos OS Release 7.4. pipe-detail statement introduced in Junos OS Release 8.3. Configure trace options for Bidirectional Forwarding Protocol (BFD) traffic. If you do not include this statement, no BFD tracing operations are performed. disable—(Optional) Disable the BFD tracing operation. You can use this option to disable

a single operation when you have defined a broad group of tracing operations, such as all. file filename—Name of the file to receive the output of the tracing operation. Enclose the

name in quotation marks. All files are placed in the /var/log directory . We recommend that you place global routing protocol tracing output in the routing-log file. files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and

so on, until the maximum number of trace files is reached. Then the oldest trace file is overwritten. If you specify a maximum number of files, you also must specify a maximum file size with the size option. Range: 2 through 1000 files Default: 2 files flag flag—Tracing operation to perform. To specify more than one tracing operation,

include multiple flag statements. These are the BFD protocol tracing options: •

adjacency—Trace adjacency messages.

•

all—Trace all options for BFD.

•

error—Trace all errors.

•

event—Trace all events.

•

issu—Trace in-service software upgrade (ISSU) packet activity.


153


•

nsr-packet—Trace non-stop-routing (NSR) packet activity.

•

nsr-synchronization—Trace NSR synchronization events.

•

packet—Trace all packets.

•

pipe—Trace pipe messages.

•

pipe-detail—Trace pipe messages in detail.

•

ppm-packet—Trace packet activity by periodic packet management (PPM).

•


•

timer—Trace timer processing.

match expression—(Optional) Regular expression for lines to be logged. no-world-readable—(Optional) Prevent any user from reading the log file. size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB),

or gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum file size, you also must specify a maximum number of trace files with the files option. Syntax: xk to specify KB, xm to specify MB, or xg to specify GB Range: 10 KB through the maximum file size supported on your system Default: 128 KB world-readable—(Optional) Allow any user to read the log file.

Required Privilege Level Related Documentation

154

routing and trace—To view this statement in the configuration. routing-control and trace–control—To add this statement to the configuration. •




bfd-liveness-detection Syntax

Hierarchy Level

bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } holddown-interval milliseconds; local-address ip-address; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-receive-ttl number; multiplier number; neighbor address; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name static route destination-prefix], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name static route destination-prefix qualified-next-hop (interface-name | address)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static route destination-prefix], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static route destination-prefix qualified-next-hop (interface-name | address)], [edit logical-systems logical-system-name routing-options rib routing-table-name static route destination-prefix], [edit logical-systems logical-system-name routing-options rib routing-table-name static route destination-prefix qualified-next-hop (interface-name | address)], [edit logical-systems logical-system-name routing-options static route destination-prefix], [edit logical-systems logical-system-name routing-options static route destination-prefix qualified-next-hop (interface-name | address)], [edit routing-instances routing-instance-name routing-options rib routing-table-name static route destination-prefix], [edit routing-instances routing-instance-name routing-options rib routing-table-name static route destination-prefix qualified-next-hop (interface-name | address)], [edit routing-instances routing-instance-name routing-options static route destination-prefix qualified-next-hop (interface-name | address)], [edit routing-instances routing-instance-name routing-options static route destination-prefix], [edit routing-options rib routing-table-name static route destination-prefix], [edit routing-options rib routing-table-name static route destination-prefix qualified-next-hop (interface-name | address)], [edit routing-options static route destination-prefix],


155


[edit routing-options static route destination-prefix qualified-next-hop (interface-name | address)]

Release Information

Description

156

Statement introduced before Junos OS Release 7.4. detection-time threshold and transmit-interval threshold options introduced in Junos OS Release 8.2. local-address statement introduced in Junos OS Release 8.2. minimum-receive-ttl statement introduced in Junos OS Release 8.2. Support for logical routers introduced in Junos OS Release 8.3. holddown-interval statement introduced in Junos OS Release 8.5. no-adaptation statement introduced in Junos OS Release 9.0. Support for IPv6 static routes introduced in Junos OS Release 9.1. authentication algorithm, authentication key-chain, and authentication loose-check statements introduced in Junos OS Release 9.6. Configure bidirectional failure detection timers and authentication criteria for static routes.



Options

authentication algorithm algorithm-name —Configure the algorithm used to authenticate

the specified BFD session: simple-password, keyed-md5, keyed-sha-1, meticulous-keyed-md5, or meticulous-keyed-sha-1. authentication key-chain key-chain-name—Associate a security key with the specified

BFD session using the name of the security keychain. The name you specify must match one of the keychains configured in the authentication-key-chains key-chain statement at the [edit security] hierarchy level. authentication loose-check—(Optional) Configure loose authentication checking on the

BFD session. Use only for transitional periods when authentication may not be configured at both ends of the BFD session. detection-time threshold milliseconds—Configure a threshold. When the Bidirectional

Forwarding Detection (BFD) protocol session detection time adapts to a value equal to or greater than the threshold, a single trap and a single system log message are sent. holddown-interval milliseconds—Configure an interval specifying how long a BFD session

must remain up before a state change notification is sent. Range: 0 through 255,000 Default: 0 local-address ip-address—Enable a multihop BFD session and configure the source address

for the BFD session. minimum-interval milliseconds—Configure the minimum intervals at which the local

routing device transmits a hello packet and then expects to receive a reply from the neighbor with which it has established a BFD session. Range: 1 through 255,000 minimum-receive-interval milliseconds—Configure the minimum interval at which the

local routing device expects to receive a reply from a neighbor with which it has established a BFD session. Range: 1 through 255,000 minimum-receive-ttl number—Configure the time-to-live (TTL) for the multihop BFD

session. Range: 1 through 255 Default: 255 multiplier number—Configure number of hello packets not received by the neighbor that

causes the originating interface to be declared down. Range: 1 through 255 Default: 3 neighbor address—Configure a next-hop address for the BFD session for a next hop

specified as an interface name.


157


no-adaptation—Specify for BFD sessions not to adapt to changing network conditions.

We recommend that you not disable BFD adaptation unless it is preferable not to have BFD adaptation enabled in your network. transmit-interval threshold milliseconds—Configure a threshold. When the BFD session

transmit interval adapts to a value greater than the threshold, a single trap and a single system log message are sent. The interval threshold must be greater than the minimum transmit interval. Range: 0 through 4,294,967,295 transmit-interval minimum-interval milliseconds—Configure the minimum interval at which

the local routing device transmits hello packets to a neighbor with which it has established a BFD session. Range: 1 through 255,000 version—Configure the BFD protocol version to detect.

Range: 1 or automatic Default: automatic (autodetect the BFD protocol version) The remaining statements are explained separately. Required Privilege Level Related Documentation

158



•




brief Syntax Hierarchy Level

Release Information

Description

(brief | full); [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options (aggregate | generate) (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate) (defaults | route)], [edit logical-systems logical-system-name routing-options (aggregate | generate) (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name (aggregate | generate) (defaults | route)], [edit routing-instances routing-instance-name routing-options (aggregate | generate) (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate) (defaults | route)], [edit routing-options (aggregate | generate) (defaults | route)], [edit routing-options rib routing-table-name (aggregate | generate) (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure all AS numbers from all contributing paths to be included in the aggregate or generated route’s path. •

brief—Include only the longest common leading sequences from the contributing AS

paths. If this results in AS numbers being omitted from the aggregate route, the BGP ATOMIC_ATTRIBUTE path attribute is included with the aggregate route. •

full—Include all AS numbers from all contributing paths in the aggregate or generated

route’s path. Default Required Privilege Level Related Documentation

full


aggregate on page 146

•

generate on page 172

•


•


color See

preference


159


community Syntax Hierarchy Level

Release Information

Description Options

community ([ community-ids ] | no-advertise | no-export | no-export-subconfed | none); [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)] [edit routing-instances routing-instance-name routing-options (aggregate | generate | static) (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit routing-options (aggregate | generate | static) (defaults | route)], [edit routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)],

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Associate BGP community information with a static, aggregate, or generated route. community-ids—One or more community identifiers. The community-ids format varies

according to the type of attribute that you use. The BGP community attribute format is as-number:community-value: •

as-number—AS number of the community member. It can be a value from 1

through 65,535. The AS number can be a decimal or hexadecimal value. •

community-value—Identifier of the community member. It can be a number from 0

through 65,535. For more information about BGP community attributes, see the “Configuring the Extended Communities Attribute” section in the Junos OS Routing Policy Configuration Guide. For specifying the BGP community attribute only, you also can specify community-ids as one of the following well-known community names defined in RFC 1997: •


BGP peers. •

no-export—Routes containing this community name are not advertised outside a BGP

confederation boundary. •


external BGP peers, including peers in other members’ ASs inside a BGP confederation.

160



•

none—Explicitly exclude BGP community information with a static route. Include this

option when configuring an individual route in the route portion to override a community option specified in the defaults portion.

NOTE: Extended community attributes are not supported at the [edit routing-options] hierarchy level. You must configure extended communities at the [edit policy-options] hierarchy level. For information about configuring extended communities, see the Junos OS Routing Policy Configuration Guide.




•


•

static on page 223

•


•


•



161


confederation Syntax Hierarchy Level

Release Information

Description Options

confederation confederation-autonomous-system members [ autonomous-systems ]; [edit logical-systems logical-system-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the routing device’s confederation AS number. autonomous-system—AS numbers of the confederation members.

Range: 1 through 65,535 confederation-autonomous-system—Confederation AS number. Use one of the numbers

assigned to you by the NIC. Range: 1 through 65,535 Required Privilege Level Related Documentation

162



•




destination-networks Syntax Hierarchy Level

Release Information Description

Options Required Privilege Level Related Documentation

destination-networks prefix; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options dynamic-tunnels tunnel-name], [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name], [edit routing-instances routing-instance-name routing-options dynamic-tunnels tunnel-name], [edit routing-options dynamic-tunnels tunnel-name]

Statement introduced before Junos OS Release 7.4. Specify the IPv4 prefix range for the destination network by including the destination-networks statement. Only tunnels within the specified IPv4 prefix range can be created. prefix—Destination prefix of network.



disable Syntax Hierarchy Level

Release Information

Description Required Privilege Level Related Documentation

disable; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options graceful-restart], [edit logical-systems logical-system-name routing-options graceful-restart], [edit routing-instances routing-instance-name routing-options graceful-restart], [edit routing-options graceful-restart]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Disable graceful restart. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



163


discard Syntax Hierarchy Level

Release Information

[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options (aggregate | generate) (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate) (defaults | route)], [edit logical-systems logical-system-name routing-options (aggregate | generate) (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name (aggregate | generate) (defaults | route)], [edit routing-instances routing-instance-name routing-options (aggregate | generate) (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate) (defaults | route)], [edit routing-options (aggregate | generate) (defaults | route)], [edit routing-options rib routing-table-name (aggregate | generate) (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series.

Description

Do not forward packets addressed to this destination. Instead, drop the packets, do not send ICMP unreachable messages to the packets’ originators, and install a reject route for this destination into the routing table.

Default

When an aggregate route becomes active, it is installed in the routing table with a reject next hop, which means that ICMP unreachable messages are sent.


164

discard;



•


•


•




dynamic-tunnels Syntax

Hierarchy Level


dynamic-tunnels tunnel-name { destination-networks prefix; source-address address; tunnel-type type-of-tunnel; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Configure a dynamic tunnel between two PE routers. tunnel-name—Name of the dynamic tunnel.

The remaining statements are explained separately in this chapter. Required Privilege Level Related Documentation




165


export Syntax Hierarchy Level

Release Information

Description


export [ policy--names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options forwarding-table], [edit logical-systems logical-system-name routing-options forwarding-table], [edit routing-instances routing-instance-name routing-options forwarding-table], [edit routing-options forwarding-table]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Apply one or more policies to routes being exported from the routing table into the forwarding table. policy-name—Name of one or more policies.



•


export-rib Syntax Hierarchy Level

Release Information

Description Options Required Privilege Level Related Documentation

166

export-rib routing-table-name; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib-group group-name], [edit logical-systems logical-system-name routing-options passive group-name], [edit routing-instances routing-instance-name routing-options rib-group group-name], [edit routing-options passive group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 11.3 for the QFX Series. Name of the routing table from which the Junos OS should export routing information. routing-table-name—Routing table group name.


import-rib on page 176

•

passive on page 198

•




fate-sharing Syntax

Hierarchy Level

Release Information

Description

fate-sharing { cost value; from address ; group group-name; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify a backup path in case the primary path becomes unusable. You specify one or more objects within a group. The objects can be a LAN interface, a router ID, or a point-to-point link. Sequence is insignificant. Changing the fate-sharing database does not affect existing established LSP until the next CSPF reoptimization. The fate-sharing database does affect fast-reroute detour path computations.

Options

group group-name—Each fate-sharing group must have a name, which can be up to

32 characters long and can contain letters, digits, periods (.) and hyphens (-). You can define up to 512 groups. cost value—Cost assigned to the group.

Range: 1 through 65,535 Default: 1 from address—Address of ingress routing device. to address—Address of egress routing device. For point-to-point link objects, you must

specify both a from and a to address. Required Privilege Level Related Documentation


Junos OS MPLS Applications Configuration Guide


167


filter Syntax

Hierarchy Level


168

filter { input filter-name; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name], [edit logical-systems logical-system-name routing-options rib routing-table-name], [edit routing-instances routing-instance-name routing-options rib routing-table-name], [edit routing-options rib routing-table-name]

Statement introduced before Junos OS Release 7.4. Name of the routing table from which the Junos OS should export routing information. input filter-name—Forwarding table filter name.





flow Syntax

Hierarchy Level Release Information


flow { route name { match { match-conditions; } term-order (legacy | standard); then { actions; } } validation { traceoptions { file filename ; flag flag ; } } } [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. term-order statement introduced in Junos OS Release 10.0 Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure a flow route. legacy actions—An action to take if conditions match. match-conditions—Match packets to these conditions. route name—Name of the flow route. standard—Specify to use version 7 or later of the flow-specification algorithm. term-order (legacy | standard)—Specify the version of the flow-specification algorithm. •

legacy—Use version 6 of the flow-specification algorithm.

•

standard—Use version 7 of the flow-specification algorithm.

then—Actions to take on matching packets.



Configuring Flow Routes on page 113

•



169


forwarding-cache Syntax

Hierarchy Level

Release Information


forwarding-cache { threshold suppress value ; timeout minutes; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast], [edit logical-systems logical-system-name routing-options multicast], [edit routing-instances routing-instance-name routing-options multicast], [edit routing-options multicast]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure multicast forwarding cache limits. The threshold statement is explained separately. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


forwarding-table Syntax

Hierarchy Level

Release Information

Description

forwarding-table { export [ policy--names ]; (indirect-next-hop | no-indirect-next-hop); unicast-reverse-path (active-paths | feasible-paths); } [edit logical-systems logical-system-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure information about the routing device’s forwarding table. The remaining statements are explained separately.


170





full See

brief


171


generate Syntax

Hierarchy Level

Release Information

Description Options

generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; } } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name], [edit routing-options], [edit routing-options rib routing-table-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure generated routes, which are used as routes of last resort. generate-options—Additional information about generated routes, which is included with

the route when it is installed in the routing table. Specify zero or more of the following options in generate-options. Each option is explained separately. •

(active | passive);

•

as-path ;

•


•

discard;

•

(brief | full);

•


•


•

tag string;

defaults—Specify global generated route options. These options only set default attributes

inherited by all newly created generated routes. These are treated as global defaults and apply to all the generated routes you configure in the generate statement. This part of the generate statement is optional. route destination-prefix—Configure a non-default generated route: •

default—For the default route to the destination. This is equivalent to specifying an IP

address of 0.0.0.0/0.

172



•

destination-prefix/prefix-length—/destination-prefix is the network portion of the IP

address, and prefix-length is the destination prefix length. The policy statement is explained separately. Required Privilege Level Related Documentation



graceful-restart Syntax

Hierarchy Level

Release Information

Description

graceful-restart { disable; restart-duration seconds; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure graceful restart. The remaining statements are explained separately.




•



173


import Syntax Hierarchy Level

Release Information


174

import [ policy-names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options resolution rib], [edit logical-systems logical-system-name routing-options resolution rib], [edit routing-instances routing-instance-name routing-options resolution rib], [edit routing-options resolution rib]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify one or more import policies to use for route resolution. policy-names—Name of one or more import policies.





import-policy Syntax Hierarchy Level

Release Information

Description


import-policy [ policy-names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib-group group-name], [edit logical-systems logical-system-name routing-options passive group-name], [edit routing-instances routing-instance-name routing-options rib-group group-name], [edit routing-options rib-groups group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Apply one or more policies to routes imported into the routing table group. The import-policy statement complements the import-rib statement and cannot be used unless you first specify the routing tables to which routes are being imported. policy-names—Name of one or more policies.


export-rib on page 166

•

passive on page 198

•



175


import-rib Syntax Hierarchy Level

Release Information

Description

import-rib [ routing-table--names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib-group group-name], [edit logical-systems logical-system-name routing-options rib-group group-name], [edit routing-instances routing-instance-name routing-options rib-group group-name], [edit routing-options rib-group group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Name of the routing table into which the Junos OS should import routing information. The first routing table name you enter is the primary routing table. Any additional names you enter identify secondary routing tables. When a protocol imports routes, it imports them into the primary and any secondary routing tables. If the primary route is deleted, the secondary route also is deleted. For IPv4 import routing tables, the primary routing table must be inet.0 or routing-instance-name.inet.0. For IPv6 import routing tables, the primary routing table must be inet6.0. In Junos OS Release 9.5 and later, you can configure an IPv4 import routing table that includes both IPv4 and IPv6 routing tables. Including both types of routing tables permits you, for example, to populate an IPv6 routing table with IPv6 addresses that are compatible with IPv4. In releases prior to Junos OS Release 9.5, you could configure an import routing table with only either IPv4 or IPv6 routing tables.


176

routing-table-names—Name of one or more routing tables.


export-rib on page 166

•

passive on page 198

•




independent-domain Syntax Hierarchy Level

Release Information

Description

independent-domain ; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options autonomous-system autonomous-system], [edit routing-instances routing-instance-name routing-options autonomous-system autonomous-system]

Statement introduced before Junos OS Release 7.4. no-attrset option introduced in Junos OS Release 10.4. Configure an independent AS domain. The independent domain uses transitive path attribute 128 (attribute set) messages to tunnel the independent domain’s BGP attributes through the internal BGP (IBGP) core.

NOTE: In Junos OS Release 10.3 and later, if BGP receives attribute 128 and you have not configured an independent domain in any routing instance, BGP treats the received attribute 128 as an unknown attribute.


no-attrset—(Optional) Disables attribute set messages on the independent AS domain.


autonomous-system on page 151

•

Configuring Independent AS Domains on page 289

•

Disabling Attribute Set Messages on Independent AS Domains for BGP Loop Detection

•

Configuring Layer 3 VPNs to Carry IBGP Traffic


177


indirect-next-hop Syntax Hierarchy Level

Release Information

Description

(indirect-next-hop | no-indirect-next-hop); [edit logical-systems logical-system-name routing-options forwarding-table], [edit routing-options forwarding-table]

Statement introduced in Junos OS Release 8.2. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable indirectly connected next hops for route convergence.

NOTE:


•

When virtual private LAN service (VPLS) is configured on the routing device, the indirect-next-hop statement is configurable at the [edit routing-options forwarding-table] hierarchy level. However, this configuration is not applicable to indirect nexthops specific to VPLS routing instances.

•

By default, the Junos Trio Modular Port Concentrator (MPC) chipset on MX Series Routers is enabled with indirectly connected next hops and this cannot be disabled using the no-indirect-next-hop statement.


Enabling Indirect Next Hops on page 136

input Syntax Hierarchy Level


178

input filter-name; [edit logical-systems logical-system-name routing-options rib routing-table-name filter], [edit routing-options rib routing-table-name filter]

Statement introduced before Junos OS Release 7.4. Name of the input filter. filter-name—Name of the input filter.





install Syntax Hierarchy Level

Release Information

Description

Options

(install | no-install); [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name static (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name static (defaults | route)], [edit logical-systems logical-system-name routing-options static (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name static (defaults | route)], [edit routing-instances routing-instance-name routing-options static (defaults | route)], [edit routing-options rib routing-table-name static (defaults | route)] [edit routing-options static (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure whether the Junos OS installs all static routes into the forwarding table. Even if you configure a route so it is not installed in the forwarding table, the route is still eligible to be exported from the routing table to other protocols. install—Explicitly install all static routes into the forwarding table. no-install—Do not install the route into the forwarding table, even if it is the route with

the lowest preference. Default: install Required Privilege Level Related Documentation


static on page 223

•



179


instance-export Syntax Hierarchy Level

Release Information


instance-export [ policy--names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Apply one or more policies to routes being exported from a routing instance. policy-names—Name of one or more export policies.



•


instance-import Syntax Hierarchy Level

Release Information


180

instance-import [ policy--names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Apply one or more policies to routes being imported into a routing instance. policy-names—Name of one or more import policies.



•




interface See the following sections: •

interface (Multicast via Static Routes) on page 181

•

interface (Multicast Scoping) on page 182

interface (Multicast via Static Routes) Syntax

Hierarchy Level

Release Information

Description

interface interface-names { maximum-bandwidth bps; no-qos-adjust; reverse-oif-mapping { no-qos-adjust; } subscriber-leave-timer seconds; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast], [edit logical-systems logical-system-name routing-options multicast], [edit routing-instances routing-instance-name routing-options multicast], [edit routing-options multicast]

Statement introduced in Junos OS Release 8.1. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable multicast traffic on an interface.

NOTE: You cannot enable multicast traffic on an interface using the enable statement and configure PIM on the same interface simultaneously.

Options

interface-name—Name of the interface on which to enable multicast traffic. Specify the interface-name to enable multicast traffic on the interface.



Enabling Multicast Forwarding Without PIM on page 127


181


interface (Multicast Scoping) Syntax Hierarchy Level


interface [ interface-names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast scope scope-name], [edit logical-systems logical-system-name routing-options multicast scope scope-name], [edit routing-instances routing-instance-name routing-options multicast scope scope-name], [edit routing-options multicast scope scope-name]

Statement introduced before Junos OS Release 7.4. Configure the set of interfaces for multicast scoping. interface-names—Names of the interfaces on which to configure scoping. Specify the full

interface name, including the physical and logical address components. To configure all interfaces, you can specify all.

NOTE: You cannot apply a scoping policy to a specific routing instance. All scoping policies are applied to all routing instances. However, you can apply the scope statement to a specific routing instance.


182


multicast on page 194

•




interface-routes Syntax

Hierarchy Level

Release Information

Description

Options

interface-routes { family (inet | inet6) { export { lan; point-to-point; } } rib-group group-name; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Associate a routing table group with the routing device’s interfaces and specify routing table groups into which interface routes are imported. inet—Specify the IPv4 address family. inet6—Specify the IPv6 address family. lan—Export LAN routes. point-to-point—Export point-to-point routes.



passive on page 198

•



183


lsp-next-hop Syntax

Hierarchy Level


Options

lsp-next-hop lsp-name { metric metric; preference preference; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static route destination-prefix], [edit logical-systems logical-system-name routing-options static route destination-prefix], [edit routing-instances routing-instance-name routing-options static route destination-prefix] [edit routing-options static route destination-prefix]

Statement introduced before Junos OS Release 7.4. Specify an LSP as the next hop for a static route, and configure an independent metric or preference on that next-hop LSP. lsp-name—Name of the next-hop LSP. metric—Metric value. 32

Range: 0 through 4,294,967,295 (2

– 1)

preference—Preference value. A lower number indicates a more preferred route. 32

Range: 0 through 4,294,967,295 (2

– 1)

Default: 5 Required Privilege Level Related Documentation

184





martians Syntax

Hierarchy Level

Release Information

Description Options

martians { destination-prefix match-type ; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name], [edit logical-systems logical-system-name routing-options], [edit logical-systems logical-system-name routing-options rib routing-table-name], [edit routing-instances routing-instance-name routing-options], [edit routing-instances routing-instance-name routing-options rib routing-table-name], [edit routing-options], [edit routing-options rib routing-table-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure martian addresses. allow—(Optional) Explicitly allow a subset of a range of addresses that has been

disallowed. The allow option is the only supported action. destination-prefix—Destination route you are configuring: •


address, and prefix-length is the destination prefix length. •

default—Default route to use when routing packets do not match a network or host in

the routing table. This is equivalent to specifying the IP address 0.0.0.0/0. match-type—Criteria that the destination must match: •

exact—Exactly match the route’s mask length.

•

longer—The route’s mask length is greater than the specified mask length.

•

orlonger—The route’s mask length is equal to or greater than the specified mask length.

•

through destination-prefix—The route matches the first prefix, the route matches the

second prefix for the number of bits in the route, and the number of bits in the route is less than or equal to the number of bits in the second prefix. •

upto prefix-length—The route’s mask length falls between the two destination prefix

lengths, inclusive. Required Privilege Level

routing—To view this statement in the configuration. routing-control—To add this statement to the configuration.


185



186

•

Configuring Martian Addresses on page 110



maximum-paths Syntax Hierarchy Level

Release Information

Description

maximum-paths path-limit ; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced in Junos OS Release 8.0. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure a limit for the number of routes installed in a routing table based upon the route path.

NOTE: The maximum-paths statement is similar to the maximum-prefixes statement. The maximum-prefixes statement limits the number of unique destinations in a routing instance. For example, suppose a routing instance has the following routes: OSPF 10.10.10.0/24 ISIS 10.10.10.0/24

These are two routes, but only one destination (prefix). The maximum-paths limit applies the total number of routes (two). The maximum-prefixes limit applies to the total number of unique prefixes (one).

Options

log-interval seconds—(Optional) Minimum time interval (in seconds) between log

messages. Range: 5 through 86,400 log-only—(Optional) Sets the route limit as an advisory limit. An advisory limit triggers

only a warning, and additional routes are not rejected. path-limit—Maximum number of routes. If this limit is reached, a warning is triggered and

additional routes are rejected. 32

Range: 1 through 4,294,967,295 (2

– 1)

Default: No default threshold value—(Optional) Percentage of the maximum number of routes that starts

triggering warning. You can configure a percentage of the path-limit value that starts triggering the warnings. Range: 1 through 100


187


NOTE: When the number or routes reaches the threshold value, routes are still installed into the routing table while warning messages are sent. When the number or routes reaches the path-limit value, then additional routes are rejected.


188


Configuring Route Limits for Routing Tables on page 288



maximum-prefixes Syntax Hierarchy Level

Release Information

Description

maximum-prefixes prefix-limit ; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced in Junos OS Release 8.0. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure a limit for the number of routes installed in a routing table based upon the route prefix.

NOTE: The maximum-paths statement is similar to the maximum-prefixes statement. The maximum-prefixes statement limits the number of unique destinations in a routing instance. For example, suppose a routing instance has the following routes: OSPF 10.10.10.0/24 ISIS 10.10.10.0/24

These are two routes, but only one destination (prefix). The maximum-paths limit applies the total number of routes (two). The maximum-prefixes limit applies to the total number of unique prefixes (one).

Options

log-interval seconds—(Optional) Minimum time interval (in seconds) between log

messages. Range: 5 through 86,400 log-only—(Optional) Sets the prefix limit as an advisory limit. An advisory limit triggers

only a warning, and additional routes are not rejected. prefix-limit—Maximum number of route prefixes. If this limit is reached, a warning is

triggered and any additional routes are rejected. Range: 1 through 4,294,967,295 Default: No default threshold value—(Optional) Percentage of the maximum number of prefixes that starts

triggering warning. You can configure a percentage of the prefix-limit value that starts triggering the warnings. Range: 1 through 100


189


NOTE: When the number or routes reaches the threshold value, routes are still installed into the routing table while warning messages are sent. When the number or routes reaches the prefix-limit value, then additional routes are rejected.




med-igp-update-interval Syntax Hierarchy Level Release Information

Description

Options

med-igp-update-interval minutes; [edit routing-options]

Statement introduced in Junos OS Release 9.0 Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure a timer for how long to delay updates for the multiple-exit discriminator (MED) path attribute for BGP groups and peers configured with the metric-out igp offset delay-med-update statement. The timer delays MED updates for the interval configured unless the MED is lower than the previously advertised attribute or another attribute associated with the route has changed or if the BGP peer is responding to a refresh route request. minutes—Interval to delay MED updates.

Default: 10 minutes Range: 10 through 600 Required Privilege Level Related Documentation

190


metric-out on page 1354

•

Example: Associating the MED Path Attribute with the IGP Metric and Delaying MED Updates on page 1095



metric See the following sections: •

metric on page 191

•

metric (Aggregate, Generated, or Static Route) on page 192

•

metric (Qualified Next Hop on Static Route) on page 193

metric Syntax Hierarchy Level Release Information Description Options Required Privilege Level Related Documentation

metric route-cost; [edit routing-options access route ip-prefix]

Statement introduced in Junos OS Release 10.1. Configure the cost for an access route. route-cost—Specific cost you want to assign to the access route.




191


metric (Aggregate, Generated, or Static Route) Syntax Hierarchy Level

Release Information

Description

Options

(metric | metric2 | metric3 | metric4) metric ; [edit logical-systems logical-system-name routing-options (aggregate | generate | static) (defaults | route)], [edit routing-options (aggregate | generate | static) (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Metric value for an aggregate, generated, or static route. You can specify up to four metric values, starting with metric (for the first metric value) and continuing with metric2, metric3, and metric4. metric—Metric value. 32

Range: 0 through 4,294,967,295 (2

– 1)

type type—(Optional) Type of route.

Range: 1 through 16 Required Privilege Level Related Documentation

192



•


•

static on page 223

•

Configuring a Metric Value for Static Routes on page 74

•

Configuring a Metric Value for Aggregate Routes on page 98

•

Configuring a Metric Value for Generated Routes on page 106



metric (Qualified Next Hop on Static Route) Syntax Hierarchy Level

Release Information

Description Options

metric metric; [edit logical-systems logical-system-name routing-options static route destination-prefix qualified-next-hop], [edit routing-options static route destination-prefix qualified-next-hop]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Metric value for a static route. metric—Metric value. 32

Range: 0 through 4,294,967,295 (2 Required Privilege Level Related Documentation

– 1)


qualified-next-hop on page 203

•

static on page 223

•



193


multicast Syntax

Hierarchy Level

Release Information

Description

multicast { forwarding-cache { threshold suppress value ; } interface interface-name { enable; } scope scope-name { interface [ interface-names ]; prefix destination-prefix; } ssm-groups { address; } } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure generic multicast properties.

NOTE: You cannot apply a scoping policy to a specific routing instance. All scoping policies are applied to all routing instances. However, you can apply the scope statement to a specific routing instance.


194


(indirect-next-hop on page 178 | no-indirect-next-hop)

•


•


•




next-hop (Access) Syntax Hierarchy Level Release Information Description


next-hop next-hop; [edit routing-options access route ip-prefix]

Statement introduced in Junos OS Release 10.1. Configure the next-hop address for an access route. Access routes are typically unnumbered interfaces. next-hop—Specific next-hop address you want to assign to the access route.



next-hop (Access Internal) Syntax Hierarchy Level Release Information Description


next-hop next-hop; [edit routing-options access-internal route ip-prefix]

Statement introduced in Junos OS Release 10.1. Configure the next-hop address for an internal access route. Access routes are typically unnumbered interfaces. next-hop—Specific next-hop address you want to assign to the internal access route.



no-install See

install

no-readvertise See

readvertise

See

retain

no-retain


195


nonstop-routing Syntax Hierarchy Level


Default Required Privilege Level Related Documentation

196

nonstop-routing; [edit logical-systems logical-system-name routing-options], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced in Junos OS Release 8.4. For routing platforms with two Routing Engines, configure a master Routing Engine to switch over gracefully to a backup Routing Engine and to preserve routing protocol information. disabled routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Enabling Nonstop Active Routing on page 137

•




options Syntax

Hierarchy Level

Release Information

options { syslog (level level | upto level level); } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]


Description

Configure the types of system logging messages sent about the routing protocols process to the system message logging file. These messages are also displayed on the system console. You can log messages at a particular level, or up to and including a particular level.

Options

level level—Severity of the message. It can be one or more of the following levels, in order

of decreasing urgency: •

alert—Conditions that should be corrected immediately, such as a corrupted system

database. •

critical—Critical conditions, such as hard drive errors.

•

debug—Software debugging messages.

•

emergency—Panic or other conditions that cause the system to become unusable.

•

error—Standard error conditions.

•

info—Informational messages.

•

notice—Conditions that are not error conditions, but might warrant special handling.

•

warning—System warning messages.

upto level level—Log all messages up to a particular level.



syslog in the Junos OS System Basics Configuration Guide

•

Configuring System Logging for the Routing Protocol Process on page 135


197


p2mp-lsp-next-hop Syntax

Hierarchy Level


Options

p2mp-lsp-next-hop { metric metric; preference preference; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static route destination-prefix], [edit logical-systems logical-system-name routing-options static route destination-prefix], [edit routing-instances routing-instance-name routing-options static route destination-prefix]. [edit routing-options static route destination-prefix]

Statement introduced before Junos OS Release 7.4. Specify a point-to-multipoint LSP as the next hop for a static route, and configure an independent metric or preference on that next-hop LSP. metric—Metric value. 32

Range: 0 through 4,294,967,295 (2

– 1)


Range: 0 through 4,294,967,295 (2

– 1)




passive See

198

active



policy Syntax Hierarchy Level

Release Information

Description


policy policy-name; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options (aggregate | generate) (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate) (defaults | route)], [edit logical-systems logical-system-name routing-options (aggregate | generate) (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name (aggregate | generate) (defaults | route)], [edit routing-instances routing-instance-name routing-options (aggregate | generate) (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate) (defaults | route)], [edit routing-options (aggregate | generate) (defaults | route)], [edit routing-options rib routing-table-name (aggregate | generate) (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Associate a routing policy when configuring an aggregate or generated route’s destination prefix in the routes part of the aggregate or generate statement. This provides the equivalent of an import routing policy filter for the destination prefix. That is, each potential contributor to an aggregate route, along with any aggregate options, is passed through the policy filter. The policy then can accept or reject the route as a contributor to the aggregate route and, if the contributor is accepted, the policy can modify the default preferences. The contributor with the numerically smallest prefix becomes the most preferred, or primary, contributor. A rejected contributor still can contribute to a less specific aggregate route. If you do not specify a policy filter, all candidate routes contribute to an aggregate route. policy-name—Name of a routing policy.



•


•


•



199


ppm Syntax

Hierarchy Level

Release Information

Description

ppm { no-delegate-processing; } [edit logical-systems logical-system-name routing-options], [edit routing-options]

Statement introduced in Junos OS Release 8.2. Statement introduced in Junos OS Release 10.2 for EX Series switches. no-delegate-processing statement introduced in Junos OS Release 9.4. no-delegate-processing statement introduced in Junos OS Release 10.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. (M120, M320, MX Series, T Series, TX Matrix routers, M7i and M10i routers with Enhanced CFEB [CFEB-E], and EX Series switches only) Disable distributed periodic packet management (PPM) to the Packet Forwarding Engine (on routers), to access ports (on EX3200 and EX4200 switches), or line cards (on EX8200 switches). After you disable PPM, PPM processing continues to run on the Routing Engine.

Default Options

enabled no-delegate-processing—Disable PPM to the Packet Forwarding Engine, access ports, or

line cards. Distributed PPM is enabled by default. Required Privilege Level Related Documentation

200


Disabling Distributed Periodic Packet Management on the Packet Forwarding Engine on page 140

•

Configuring Distributed Periodic Packet Management on an EX Series Switch (CLI Procedure)



preference Syntax Hierarchy Level

Release Information

Description

Options

(preference | preference2 | color | color2) preference ; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit routing-instances routing-instance-name routing-options (aggregate | generate | static) (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit routing-options (aggregate | generate | static) (defaults | route)], [edit routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Preference value for a static, aggregated, or generated route. You also can specify a secondary preference value (preference2), as well as colors, which are even finer-grained preference values (color and color2). preference—Preference value. A lower number indicates a more preferred route. 32

Range: 0 through 4,294,967,295 (2

– 1)

Default: 5 (for static routes), 130 (for aggregate and generated routes) type—(Optional) Type of route.




•


•

static on page 223

•


•


•



201


preference (Access) Syntax Hierarchy Level Release Information Description Options Required Privilege Level Related Documentation

preference route-distance; [edit routing-options access route ip-prefix]

Statement introduced in Junos OS Release 10.1. Configure the distance for an access route. route-distance—Specific distance you want to assign to the access route.



prefix Syntax Hierarchy Level

Release Information


202

prefix destination-prefix; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast scope scope-name], [edit logical-systems logical-system-name routing-options multicast scope scope-name], [edit routing-instances routing-instance-name routing-options multicast scope scope-name], [edit routing-options multicast scope scope-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure the prefix for multicast scopes. destination-prefix—Address range for the multicast scope.



•




qualified-next-hop Syntax

Hierarchy Level

Release Information

Description Options

qualified-next-hop (address | interface-name) { interface interface-name; metric metric; preference preference; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static route destination-prefix], [edit logical-systems logical-system-name routing-options rib inet6.0 static route destination-prefix], [edit logical-systems logical-system-name routing-options static route destination-prefix], [edit routing-instances routing-instance-name routing-options static route destination-prefix], [edit routing-options rib inet6.0 static route destination-prefix], [edit routing-options static route destination-prefix]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure an independent metric or preference on a static route. address—IPv4, IPv6, or ISO network address of the next hop. interface-name—Name of the interface on which to configure an independent metric or

preference for a static route. To configure an unnumbered Ethernet interface as the next-hop interface for a static route, specify qualified-next-hop interface-name, where interface-name is the name of the IPv4 or IPv6 unnumbered Ethernet interface. metric—Metric value. 32

Range: 0 through 4,294,967,295 (2

– 1)


Range: 0 through 4,294,967,295 (2

– 1)





203


qualified-next-hop (Access) Syntax Hierarchy Level Release Information Description Options Required Privilege Level Related Documentation

qualified-next-hop next-hop; [edit routing-options access route ip-prefix]

Statement introduced in Junos OS Release 10.1. Configure the qualified next-hop address for an access route. next-hop—The specific qualified next-hop address you want to assign to the access route.



qualified-next-hop (Access-Internal) Syntax Hierarchy Level Release Information Description Options Required Privilege Level Related Documentation

204

qualified-next-hop next-hop; [edit routing-options access-internal route ip-prefix]

Statement introduced in Junos OS Release 10.1. Configure the qualified next-hop address for an internal access route. next-hop—Specific qualified next-hop address you want to assign to the access route.





readvertise Syntax Hierarchy Level

Release Information

Description

(readvertise | no-readvertise); [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name static (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name static (defaults | route)], [edit logical-systems logical-system-name routing-options static (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name static (defaults | route)], [edit routing-instances routing-instance-name routing-options static (defaults | route)], [edit routing-options rib routing-table-name static (defaults | route)], [edit routing-options static (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure whether static routes are eligible to be readvertised by routing protocols: •

readvertise—Readvertise static routes.

•

no-readvertise—Mark a static route as being ineligible for readvertisement; include the no-readvertise option when configuring the route.


readvertise


static on page 223

•



205


resolution Syntax

Hierarchy Level

Release Information

Description

resolution { rib routing-table-name { import [ policy-names ]; resolution-ribs [ routing-table-names ]; } } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure route resolution. The remaining statements are explained separately.


206





resolution-ribs Syntax Hierarchy Level

Release Information

Description

resolution-ribs [ routing-table-names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options resolution rib], [edit logical-systems logical-system-name routing-options resolution rib], [edit routing-instances routing-instance-name routing-options resolution rib], [edit routing-options resolution rib]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify one or more routing tables to use for route resolution. The remaining statements are explained separately.


routing-table-names—Name of one or more routing tables.




207


resolve Syntax Hierarchy Level

Release Information

Description


208

resolve; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name static (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name static (defaults | route)], [edit logical-systems logical-system-name routing-options static (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name static (defaults | route)], [edit routing-instances routing-instance-name routing-options static (defaults | route)], [edit routing-options rib routing-table-name static (defaults | route)], [edit routing-options static (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure statically configured routes to be resolved to a next hop that is not directly connected. The route is resolved through the inet.0 and inet.3 routing tables. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

static on page 223

•

Controlling Resolution of Static Routes to Prefixes That Are Not Directly Connected on page 80



restart-duration Syntax Hierarchy Level

Release Information

Description Options

restart-duration seconds; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options graceful-restart], [edit logical-systems logical-system-name routing-options graceful-restart], [edit routing-instances routing-instance-name routing-options graceful-restart], [edit routing-options graceful-restart]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the restart timer for graceful restart. restart-duration seconds—Configure the time period for the restart to last.

Range: 120 through 900 seconds Default: 90 seconds Required Privilege Level Related Documentation




209


retain Syntax Hierarchy Level

Release Information

Description

(retain | no-retain); [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name static (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name static (defaults | route)], [edit logical-systems logical-system-name routing-options static (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name static (defaults | route)], [edit routing-instances routing-instance-name routing-options static (defaults | route)], [edit routing-options rib routing-table-name static (defaults | route)], [edit routing-options static (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure statically configured routes to be deleted from or retained in the forwarding table when the routing protocol process shuts down normally: •

retain—Have a static route remain in the forwarding table when the routing protocol

process shuts down normally. Doing this greatly reduces the time required to restart a system that has a large number of routes in its routing table. •

no-retain—Delete statically configured routes from the forwarding table when the

routing protocol process shuts down normally. Default Required Privilege Level Related Documentation

210

no-retain


static on page 223

•




rib See the following sections: •

rib (General) on page 212

•

rib (Route Resolution) on page 214


211


rib (General) Syntax

Hierarchy Level

Release Information

Description

rib routing-table-name { aggregate { defaults { ... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... } generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; } } martians { destination-prefix match-type ; } } static { defaults { static-options; } rib-group group-name; route destination-prefix { next-hop; static-options; } } } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Create a routing table. Explicitly creating a routing table with the routing-table-name statement is optional if you are not adding any static, martian, aggregate, or generated routes to the routing table and if you also are creating a routing table group. Simply including the passive statement to indicate that a routing table is part of a routing table group is sufficient to create it.

212



NOTE: The IPv4 multicast routing table (inet.1) and the IPv6 multicast routing table (inet6.1) are not supported for this statement.

Default

Options

If you do not specify a routing table name with the routing-table-name statement, the software uses the default routing tables, which are inet.0 for unicast routes and inet.1 for the multicast cache. routing-table-name—Name of the routing table, in the following format: protocol [.identifier].

In a routing instance, the routing table name must include the routing instance name. For example, if the routing instance name is link0, the routing table name might be link0.inet6.0. •

protocol is the protocol family. It can be inet6 for the IPv6 family, inet for the IPv4 family, iso for the ISO protocol family, or instance-name.iso.0 for an ISO routing instance.

•

identifier is a positive integer that specifies the instance of the routing table.

Default: inet.0 Required Privilege Level Related Documentation


passive on page 198

•

Example: Creating Routing Tables on page 60


213


rib (Route Resolution) Syntax

Hierarchy Level

Release Information

Description

rib routing-table-name { import [ policy-names ]; resolution-ribs [ routing-table-names ]; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options resolution], [edit logical-systems logical-system-name routing-options resolution], [edit routing-instances routing-instance-name routing-options resolution], [edit routing-options resolution]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify a routing table name for route resolution. The remaining statements are explained separately.


214





rib-group Syntax Hierarchy Level

Release Information

Description Options

rib-group group-name; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options interface-routes], [edit logical-systems logical-system-name routing-options interface-routes], [edit logical-systems logical-system-name routing-options rib routing-table-name static], [edit logical-systems logical-system-name routing-options static], [edit routing-instances routing-instance-name routing-options interface-routes], [edit routing-options interface-routes], [edit routing-options rib routing-table-name static], [edit routing-options static]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure which routing table groups interface routes are imported into. group-name—Name of the routing table group. The name must start with a letter and

can include letters, numbers, and hyphens. It generally does not make sense to specify more than a single routing table group. Required Privilege Level Related Documentation


interface-routes on page 183

•

rib-groups on page 216

•


•



215


rib-groups Syntax

Hierarchy Level

Release Information

Description

rib-groups { group-name { export-rib group-name; import-policy [ policy-names ]; import-rib [ group-names ]; } } [edit logical-systems logical-system-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Group one or more routing tables to form a routing table group. A routing protocol can import routes into all the routing tables in the group and can export routes from a single routing table. Each routing table group must contain one or more routing tables that the Junos OS uses when importing routes (specified in the import-rib statement) and optionally can contain one routing table group that the Junos OS uses when exporting routes to the routing protocols (specified in the export-rib statement).

Options

group-name—Name of the routing table group. The name must start with a letter and

can include letters, numbers, and hyphens. The remaining statements are explained separately. Required Privilege Level Related Documentation

216


rib-group on page 215

•




route (Access) Syntax

Hierarchy Level Release Information Description Options

route ip-prefix { metric route-cost; next-hop next-hop; preference route-distance; qualified-next-hop next-hop; tag tag-number; } [edit routing-options access]

Statement introduced in Junos OS Release 10.1. Configure the parameters for access routes. ip-prefix—Specific route prefix that you want to assign to the access

route. The remaining statements are explained separately. Required Privilege Level Related Documentation



route (Access-Internal) Syntax


route ip-prefix { next-hop next-hop; qualified-next-hop next-hop; } [edit routing-options access-internal]

Statement introduced in Junos OS Release 10.1. Configure the parameters for internal access routes. ip-prefix—Specific route prefix that you want to assign to the internal

access route. The remaining statements are explained separately. Required Privilege Level Related Documentation




217


route-distinguisher-id Syntax Hierarchy Level

Release Information

Description


route-distinguisher-id address; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure a route distinguisher identifier for a routing instance, specifying an IP address. If a route distinguisher is configured for a particular routing instance, that value supersedes the route distinguisher configured by this statement. address—IP address.


Configuring Route Distinguishers for VRF and Layer 2 VPN Instances on page 133

route-record Syntax Hierarchy Level

Release Information


218

route-record; [edit logical-systems logical-system-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Export the AS path and routing information to the traffic sampling process. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Configuring Route Recording for Flow Aggregation on page 123

•




router-id Syntax Hierarchy Level

Release Information

Description

router-id address; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the routing device’s IP address.

NOTE: We strongly recommend that you configure the router identifier under the [edit routing-options] hierarchy level to avoid unpredictable behavior if the interface address on a loopback interface changes.

Options

address—IP address of the routing device.

Default: Address of the first interface encountered by the Junos OS Required Privilege Level Related Documentation


Configuring Router Identifiers for BGP and OSPF on page 122

routing-options Syntax Hierarchy Level

Release Information


routing-options { ... } [edit], [edit logical-systems logical-system-name], [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure protocol-independent routing properties. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Protocol-Independent Routing Properties Configuration Statements


219


scope Syntax

Hierarchy Level

Release Information

Description Options

scope scope-name { interface [ interface-names ]; prefix destination-prefix; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast], [edit logical-systems logical-system-name routing-options multicast], [edit routing-instances routing-instance-name routing-options multicast], [edit routing-options multicast]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the set of interfaces for multicast scoping. scope-name—Name of the multicast scope.


220



•




source-address Syntax Hierarchy Level



source-address address; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options dynamic-tunnels tunnel-name, [edit logical-systems logical-system-namerouting-options dynamic-tunnels tunnel-name, [edit routing-instances routing-instance-name routing-options dynamic-tunnels tunnel-name], [edit routing-options dynamic-tunnels tunnel-name]

Statement introduced before Junos OS Release 7.4. Specify the source address for the generic routing encapsulation (GRE) tunnels. The source address specifies the address used as the source for the local tunnel endpoint. This address can be any local address on the router (typically the router ID or the loopback address). address—Name of the source address.



source-routing Syntax



source-routing { (ip | ipv6) } [edit routing-options]

Statement for IPv6 introduced in Junos OS Release 8.2. Statement for IPv4 introduced in Junos OS Release 8.5. Statement introduced in Junos OS Release 9.0 for EX Series switches. Enable source routing. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Enabling Source Routing on page 141


221


ssm-groups Syntax

Hierarchy Level

Release Information


222

ssm-groups { address; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast] [edit logical-systems logical-system-name routing-options multicast], [edit routing-instances routing-instance-name routing-options multicast], [edit routing-options multicast]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure additional (source-specific multicast) SSM groups. address—Address range of the additional SSM group.



•




static Syntax

Hierarchy Level

Release Information

static { defaults { static-options; } rib-group group-name; route destination-prefix { bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } local-address ip-address; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-receive-ttl number; multiplier number; neighbor address; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } next-hop address; next-hop options; qualified-next-hop address { metric metric; preference preference; } static-options; } } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-options], [edit logical-systems logical-system-name routing-options rib routing-table-name], [edit routing-instances routing-instance-name routing-options], [edit routing-options], [edit routing-options rib routing-table-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for BFD authentication introduced in Junos 9.6. Support for BFD authentication introduced in Junos 9.6 for EX Series switches.


223


Description

224

Configure static routes to be installed in the routing table. You can specify any number of routes within a single static statement, and you can specify any number of static options in the configuration.



Options

defaults—Specify global static route options. These options only set default attributes

inherited by all newly created static routes. These are treated as global defaults and apply to all the static routes you configure in the static statement. This part of the static statement is optional. route destination-prefix—Destination of the static route. •

defaults—For the default route to the destination. This is equivalent to specifying an

IP address of 0.0.0.0/0. •


address, and prefix-length is the destination prefix length. •

next-hop address—Reach the next-hop routing device by specifying an IP address, an

interface name, or an ISO network entity title (NET). •

nsap-prefix—nsap-prefix is the network service access point (NSAP) address for ISO.

next-hop options—Additional information for how to manage forwarding of packets to

the next hop. •

discard—Do not forward packets addressed to this destination. Instead, drop the

packets, do not send ICMP unreachable messages to the packets’ originators, and install a reject route for this destination into the routing table. •

iso-net—Reach the next-hop routing device by specifying an ISO NSAP.

•

next-table routing-table-name—Name of the next routing table to the destination.

•

receive—Install a route for this next-hop destination into the routing table.

The receive option forces the packet to be sent to the Routing Engine. The receive option can be useful in the following cases:

•

•

For receiving MPLS packets destined to a VRF instance's loopback address

•

For receiving packets on a link's subnet address, with zeros in the host portion of the address

reject—Do not forward packets addressed to this destination. Instead, drop the packets,

send ICMP unreachable messages to the packets’ originators, and install a reject route for this destination into the routing table. static-options—(Optional under route) Additional information about static routes, which

is included with the route when it is installed in the routing table. You can specify one or more of the following in static-options. Each of the options is explained separately. •

(active | passive);

•

as-path ;


225


•


•

(install | no-install);

•


•


•

(readvertise | no-readvertise);

•

(resolve | no-resolve);

•

(no-retain | retain);

•

tag string;


226





tag Syntax Hierarchy Level

Release Information


tag string; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options (aggregate | generate | static) (defaults | route)], [edit logical-systems logical-system-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit routing-instances routing-instance-name routing-options aggregate | generate | static) (defaults | route)], [edit routing-instances routing-instance-name routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)], [edit routing-options (aggregate | generate | static) (defaults | route)], [edit routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Associate an OSPF tag with a static, aggregate, or generated route. string—OSPF tag string.



•


•

static on page 223

•


•


•



227


tag (Access) Syntax Hierarchy Level Release Information Description Options Required Privilege Level Related Documentation

tag tag-number; [edit routing-options access route ip-prefix]

Statement introduced in Junos OS Release 10.1. Configure a tag for an access route. tag-number—Tag number for the access route.

interface—To view this statement in the configuration. interface-control—To add this statement to the configuration. •


threshold Syntax Hierarchy Level

Release Information

threshold suppress value ; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast forwarding-cache], [edit logical-systems logical-system-name routing-options multicast forwarding-cache], [edit routing-instances routing-instance-name routing-options multicast forwarding-cache], [edit routing-options multicast forwarding-cache]


Description

Configure the suppression and reuse thresholds for multicast forwarding cache limits.

Options

reuse value—Value at which to begin creating new multicast forwarding cache entries.

This value is optional. If configured, this number should be less than the suppress value. Range: 1 through 200,000 suppress value—Value at which to begin suppressing new multicast forwarding cache

entries. This value is mandatory. This number should be greater than the reuse value. Range: 1 through 200,000 Required Privilege Level Related Documentation

228





traceoptions Syntax

Hierarchy Level

Release Information

Description

traceoptions { file filename ; flag flag ; } [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast], [edit logical-systems logical-system-name routing-options], [edit logical-systems logical-system-name routing-options multicast], [edit routing-instances routing-instance-name routing-options], [edit routing-instances routing-instance-name routing-options multicast], [edit routing-options], [edit routing-options multicast], [edit routing-options flow]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Define tracing operations that track all routing protocol functionality in the routing device. To specify more than one tracing operation, include multiple flag statements.

Default

If you do not include this statement, no global tracing operations are performed.

Options

Values: disable—(Optional) Disable the tracing operation. You can use this option to disable a

single operation when you have defined a broad group of tracing operations, such as all. file filename—Name of the file to receive the output of the tracing operation. Enclose the

name within quotation marks. All files are placed in the directory /var/log. We recommend that you place global routing protocol tracing output in the file routing-log. files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and

so on, until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. Note that if you specify a maximum number of files, you also must specify a maximum file size with the size option. Range: 2 through 1000 files Default: 10 files flag flag—Tracing operation to perform. To specify more than one tracing operation,

include multiple flag statements. These are the global routing protocol tracing options:


229


•


•

condition-manager—Condition-manager events

•

config-internal—Configuration internals

•


and route trace operations) •


•


•

nsr-synchronization—Nonstop active routing synchronization

•

parse—Configuration parsing

•

policy—Routing policy operations and actions

•

regex-parse—Regular-expression parsing

•


•


•


•

timer—Timer usage

no-world-readable—(Optional) Prevent any user from reading the log file. size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB),

or gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. Note that if you specify a maximum file size, you also must specify a maximum number of trace files with the files option. Syntax: xk to specify KB, xm to specify MB, or xg to specify GB Range: 10 KB through the maximum file size supported on your system Default: 128 KB world-readable—(Optional) Allow any user to read the log file.


230

routing and trace—To view this statement in the configuration. routing-control and trace-control—To add this statement to the configuration. •

Tracing Global Routing Protocol Operations on page 138



tunnel-type Syntax Hierarchy Level



tunnel-type type; [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options dynamic-tunnels tunnel-name], [edit logical-systems logical-system-namerouting-options dynamic-tunnels tunnel-name, [edit routing-instances routing-instance-name routing-options dynamic-tunnels tunnel-name], [edit routing-options dynamic-tunnels tunnel-name

Statement introduced before Junos OS Release 7.4. Specify the type of tunnel to be dynamically created. The only valid value is gre (for GRE tunnels). type—Tunnel type.



unicast-reverse-path Syntax Hierarchy Level

Release Information

Description Options

unicast-reverse-path (active-paths | feasible-paths); [edit logical-systems logical-system-name routing-options forwarding-table], [edit routing-instances routing-instance-name instance-type name routing-options forwarding-table], [edit routing-options forwarding-table]

Statement introduced before Junos OS Release 7.4. Support for routing instances added in Junos OS Release 8.3. Control the operation of unicast reverse-path-forwarding check. active-paths—Consider only active paths during the unicast reverse-path check. feasible-paths—Consider all feasible paths during the unicast reverse-path check.



Configuring Unicast Reverse-Path-Forwarding Check on page 131

•

Junos OS Network Interfaces Configuration Guide


231


232


PART 3

Routing Instances •

Introduction to Routing Instances on page 235

•

Routing Instances Configuration Guidelines on page 239

•

Summary of Routing Instances Configuration Statements on page 291


233


234


CHAPTER 7

Introduction to Routing Instances This chapter discusses the following topics: •

Routing Instances Overview on page 235

Routing Instances Overview You can create multiple instances of BGP, IS-IS, LDP, Multicast Source Discovery Protocol (MSDP), OSPF version 2 (usually referred to simply as OSPF), OSPF version 3 (OSPFv3), Protocol Independent Multicast (PIM), RIP, and static routes by including statements at the following hierarchy levels: •

[edit routing-instances routing-instance-name protocols]

•

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

NOTE: You can also create multiple routing instances for separating routing tables, routing policies, and interfaces for individual DHCP wholesale subscribers (retailers) in a layer 3 wholesale network. For information about how to configure layer 3 wholesale network services, see the Junos OS Broadband Subscriber Management Solutions Guide.

A routing instance is a collection of routing tables, interfaces, and routing protocol parameters. The set of interfaces belongs to the routing tables, and the routing protocol parameters control the information in the routing tables. You can configure eight types of routing instances: forwarding, Layer 2 control (MX Series routers only), Layer 2 virtual private network (VPN), nonforwarding, VPN routing and forwarding (VRF), virtual router, virtual private LAN service (VPLS), and virtual switch (MX Series routers only). Each routing instance has a unique name and a corresponding IP unicast table. For example, if you configure a routing instance with the name my-instance, the corresponding IP unicast table is my-instance.inet.0. All routes for my-instance are installed into my-instance.inet.0.


235


NOTE: The default routing instance, master, refers to the main inet.0 routing table. The master routing instance is reserved and cannot be specified as a routing instance.

Each routing instance consists of sets of the following: •

Routing tables

•

Interfaces that belong to these routing tables

•

Routing option configurations

You can configure eight types of routing instances:

236

•

Forwarding—Use this routing instance type for filter-based forwarding applications. For this instance type, there is no one-to-one mapping between an interface and a routing instance. All interfaces belong to the default instance inet.0.

•

Layer 2 Backhaul VPN—(MX Series routers only) Use this routing instance type to provide support for Layer 2 wholesale VLAN packets with no existing corresponding logical interface. When using this instance, the router learns both the outer tag and inner tag of the incoming packets, when the instance-role statement is defined as access, or the outer VLAN tag only, when the instance-role statement is defined as nni.

•

Layer2-control—(MX Series routers only) Use this routing instance type for RSTP or MSTP in customer edge interfaces of a VPLS routing instance. This instance type cannot be used if the customer edge interface is multihomed to two provider edge interfaces. If the customer edge interface is multihomed to two provider edge interfaces, use the default BPDU tunneling.

•

Layer 2 VPN—Use this routing instance type for Layer 2 virtual private network (VPN) implementations.

•

Nonforwarding—Use this routing instance type when a separation of routing table information is required. There is no corresponding forwarding table. All routes are installed into the default forwarding table. IS-IS instances are strictly nonforwarding instance types.

•

Virtual router—Similar to a VPN routing and forwarding instance type, but used for non-VPN-related applications. There are no virtual routing and forwarding (VRF) import, VRF export, VRF target, or route distinguisher requirements for this instance type.

•

Virtual switch—(MX Series routers only) Use the virtual switch instance type to isolate a LAN segment with its Spanning Tree Protocol (STP) instance and separates its VLAN identifier space. For more detail information about configuring a virtual switch, see the Junos OS Layer 2 Configuration Guide and the Junos OS MX Series 3D Universal Edge Routers Solutions Guide.


Chapter 7: Introduction to Routing Instances

•

VPLS—Use the virtual private local-area network service (VPLS) routing instance type for point-to-multipoint LAN implementations between a set of sites in a VPN.

•

VRF—Use the VPN routing and forwarding routing (VRF) instance type for Layer 3 VPN implementations. This routing instance type has a VPN routing table as well as a corresponding VPN forwarding table. For this instance type, there is a one-to-one mapping between an interface and a routing instance. Each VRF instance corresponds with a forwarding table. Routes on an interface go into the corresponding forwarding table.

Configure global routing options and protocols for the master instance by including statements at the [edit protocols] and [edit routing-options] hierarchy levels. Routes are installed into the master routing instance inet.0 by default, unless a routing instance is specified. Multiple instances of BGP, OSPF, and RIP are used for Layer 3 VPN implementation. The multiple instances of BGP, OSPF, and RIP keep routing information for different VPNs separate. The VRF instance advertises routes from the customer edge (CE) router to the provider edge (PE) router and advertises routes from the PE router to the CE router. Each VPN receives only routing information belonging to that VPN. Forwarding instances are used to implement filter-based forwarding for Common Access Layer applications. PIM instances are used to implement multicast over VPN applications. Nonforwarding instances of IS-IS and OSPF can be used to separate a very large network into smaller administrative entities. Instead of configuring a large number of filters, nonforwarding instances can be used to filter routes, thereby instantiating policy. Nonforwarding instances can be used to reduce the amount of routing information advertised throughout all components of a network. Routing information associated with a particular instance can be announced where required, instead of being advertised to the whole network. Layer 2 VPN instances are used for Layer 2 VPN implementation. Virtual router instances are similar to a VPN routing and forwarding instance type, but used for non-VPN-related applications. There are no VRF import, VRF export, VRF target, or route distinguisher requirements for this instance type. Use the VPLS routing instance type for point-to-multipoint LAN implementations between a set of sites in a VPN. Related Documentation

•


•

Junos OS Layer 2 Configuration Guide

•

Junos OS MX Series 3D Universal Edge Routers Solutions Guide


237


238


CHAPTER 8

Routing Instances Configuration Guidelines This chapter describes the following tasks for configuring routing instances: •

Complete Routing Instances Configuration Statements on page 240

•

Routing Instances Minimum Configuration on page 244

•

Configuring Multiple Instances of BGP on page 250

•

Configuring Multiple Instances of IS-IS on page 251

•

Configuring Multiple Instances of LDP on page 255

•

Configuring Multiple Instances of MSDP on page 256

•

Example: Configuring Multiple Routing Instances of OSPF on page 256

•

Configuring Multiple Instances of PIM on page 263

•

Configuring Multiple Instances of RIP on page 263

•

Configuring Routing Instances on page 264

•

Specifying the Instance Type for Routing Instances on page 266

•

Configuring Route Distinguishers for Routing Instances on page 269

•

Configuring Filter-Based Forwarding on page 270

•

Configuring Class-of-Service-Based Forwarding on page 272

•

Configuring Secondary VRF Import and Export Policy on page 273

•


•

Example: Exporting Specific Routes from One Routing Table Into Another Routing Table on page 278

•

Configuring VRF Table Labels on page 283

•

Configuring VRF Targets on page 283

•

Configuring OSPF Domain IDs for VPNs on page 284

•


•

Configuring Independent AS Domains on page 289


239


Complete Routing Instances Configuration Statements To configure routing instances, include the following statements: access { ... address-assignment; ... } access-profile profile-name; description text; forwarding-options; instance-role; instance-type (forwarding |l2backhaul-vpn | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf); interface interface-name; bridge-domains { bridge-domains-name { domain-type bridge; vlan-id (none | all | number); vlan-tags outer number inner number; interface interface-name; routing-interface routing-interface-name; bridge-options { mac-limit limit; mac-statistics; mac-table-size limit; no-mac-learning; static-mac mac-address; } } } no-vrf-advertise; no-vrf-propagate-ttl; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy--names ]; vrf-propagate-ttl; vrf-table-label; vrf-target { export community-name; import community-name; } protocols { bgp { ... bgp-configuration ... } isis { ... isis-configuration ... } l2vpn { ... l2vpn-configuration ... } ldp { ... ldp-configuration ... }

240


Chapter 8: Routing Instances Configuration Guidelines

msdp { ... msdp-configuration ... } mstp { ... mstp-configuration ... } ospf { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ... ospf-configuration ... } ospf3 { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ... ospf3-configuration ... } pim { ... pim-configuration ... } rip { ... rip-configuration ... } ripng { ... ripng-configuration ... } rstp { ... rstp-configuration ... } vpls { ... vpls-configuration ... } } routing-options { aggregate { defaults { ... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... } } auto-export { (disable | enable); family { inet { multicast { (disable | enable); rib-group rib-group; } unicast { (disable | enable); rib-group rib-group; }


241


} } traceoptions { file filename ; flag flag ; } } autonomous-system autonomous-system { independent-domain ; } confederation confederation-autonomous-system members autonomous-system; fate-sharing { group group-name; cost value; from address [to address]; } forwarding-table { export [ policy--names ]; (indirect-next-hop | no-indirect-next-hop); } generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; } } instance-export [ policy-names ]; instance-import [ policy-names ]; interface-routes { rib-group group-name; } martians { destination-prefix match-type ; } maximum-paths path-limit ; maximum-prefixes prefix-limit ; multicast { scope scope-name { interface [ interface-names ]; prefix destination-prefix; } ssm-groups { address; } } options { syslog (level level | upto level); } rib routing-table-name { aggregate { defaults { ... aggregate-options ... }

242



route destination-prefix { policy policy-name; ... aggregate-options ... } } generate { defaults { generate-options; } route destination-prefix { policy policy-name; generate-options; } } martians { destination-prefix match-type ; } static { defaults { static-options; } rib-group group-name; route destination-prefix { lsp-next-hop{ metric metric; preference preference; } next-hop; p2mp-lsp-next-hop { metric metric; preference preference; } qualified-next-hop address { interface interface-name; metric metric; preference preference; } static-options; } } } route-record; router-id address; static { defaults { static-options; } rib-group group-name; route destination-prefix { lsp-next-hop { metric metric; preference preference; } next-hop; p2mp-lsp-next-hop { metric metric;


243


preference preference; } qualified-next-hop address { interface interface-name; metric metric; preference preference; } static-options; } } traceoptions { file filename ; flag flag ; } }

You can include the statements at the following hierarchy levels: •

[edit routing-instances routing-instance-name]

•

[edit logical-systems logical-system-name routing-instances routing-instance-name]

Routing Instances Minimum Configuration You can configure BGP, IS-IS, Layer 2 VPN, LDP, MSDP, OSPF, OSPFv3, PIM, RIP, RIPng, and VPLS routing instances. This section discusses the following routing instance minimum configurations: •

Minimum Routing-Instance Configuration for BGP on page 244

•

Minimum Routing-Instance Configuration for IS-IS on page 245

•

Minimum Routing-Instance Configuration for Layer 2 VPNs on page 245

•

Minimum Routing-Instance Configuration for LDP on page 246

•

Minimum Routing-Instance Configuration for MSDP on page 246

•

Minimum Routing-Instance Configuration for Multiprotocol BGP-Based Multicast VPNs on page 247

•

Minimum Routing-Instance Configuration for OSPF on page 247

•

Minimum Routing-Instance Configuration for OSPFv3 on page 248

•

Minimum Routing-Instance Configuration for PIM on page 248

•

Minimum Routing-Instance Configuration for RIP on page 249

•

Minimum Routing-Instance Configuration for VPLS on page 249

Minimum Routing-Instance Configuration for BGP To configure a routing instance for BGP, you must include at least the following statements: [edit] routing-instances { routing-instance-name {

244



interface interface-name; instance-type (forwarding | l2vpn | no-forwarding | virtual-router | vpls | vrf); route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { bgp { bgp configuration; } } } }

For more information about the BGP configuration statements, see Configuring BGP. For more information about configuring VPNs, see the Junos OS VPNs Configuration Guide.

Minimum Routing-Instance Configuration for IS-IS To configure a routing instance for IS-IS, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { interface interface-name; instance-type (forwarding | l2vpn | no-forwarding | virtual-router | vpls | vrf); route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { isis { ... isis configuration ... } } } }

For more information about the IS-IS configuration statements, see “Configuring IS-IS” on page 344.

Minimum Routing-Instance Configuration for Layer 2 VPNs To create a routing instance for Layer 2 VPN, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { instance-type l2vpn; interface interface-name; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { l2vpn { ... l2vpn-configuration ...


245


} } } }

For more information about configuring Layer 2 VPNs, see the Junos OS VPNs Configuration Guide.

Minimum Routing-Instance Configuration for LDP To create a routing instance for LDP, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { instance-type (forwarding | l2vpn | no-forwarding | virtual-router | vpls | vrf); interface interface-name; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { ldp { ... ldp-configuration ... } } } }

For more information about configuring LDP, see the Junos OS MPLS Applications Configuration Guide. LDP routing instances are used to support LDP over VPNs. For more information about configuring multicast over VPNs, see the Junos OS VPNs Configuration Guide.

Minimum Routing-Instance Configuration for MSDP To create a routing instance for MSDP, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { instance-type (forwarding | l2vpn | no-forwarding | virtual-router | vpls | vrf); interface interface-name; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { msdp { ... msdp-configuration ... } } } }

246



For more information about configuring MSDP, see the Junos OS Multicast Protocols Configuration Guide.

Minimum Routing-Instance Configuration for Multiprotocol BGP-Based Multicast VPNs To configure a routing instance for a multiprotocol BGP-based multicast VPN, you must include at least the following minimum configuration: [edit] routing-instances { routing-instance-name; instance-type vrf; interface interface-name; provider-tunnel { pim-asm { group-address -address; } protocols { mvpn; route-target { export-target { target; unicast; } import-target { target { receiver; sender; } unicast { receiver; sender; } } } } } route-distinguisher (as:number | ip-address:number); vrf-target community | export community-name | import community-name); } }

For more information about Multiprotocol BGP-based Multicast VPNs, see the Junos OS VPNs Configuration Guide and the Junos OS Multicast Protocols Configuration Guide.

Minimum Routing-Instance Configuration for OSPF To configure a routing instance for OSPF, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { interface interface-name; instance-type (forwarding | l2vpn | no-forwarding | virtual-router | vpls | vrf); route-distinguisher (as-number:number | ip-address:number);


247


vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { ospf { ... ospf-configuration ... } } } }

NOTE: You can configure a logical interface under only one routing instance.

For more information about the OSPF configuration statements, see Configuring OSPF.

Minimum Routing-Instance Configuration for OSPFv3 To configure a routing instance for OSPFv3, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { interface interface-name; instance-type (no-forwarding | virtual-router | vrf); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { ospf3 { ... ospf3-configuration ... } } } }


NOTE: OSPFv3 supports the no-forwarding, virtual-router, and vrf routing instance types only.

For more information about the OSPF configuration statements, see Configuring OSPF.

Minimum Routing-Instance Configuration for PIM To create a routing instance for PIM, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { instance-type (forwarding | l2vpn | no-forwarding | virtual-router | vpls | vrf);

248



interface interface-name; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { pim { ... pim-configuration ... } } } }

For more information about configuring PIM, see the Junos OS Multicast Protocols Configuration Guide. PIM routing instances are used to support multicast over VPNs. For more detailed information about configuring multicast over VPNs, see the Junos OS VPNs Configuration Guide.

Minimum Routing-Instance Configuration for RIP RIP instances are supported only for VPN routing and forwarding (VRF) instance types. This instance type provides support for Layer 3 VPNs. To configure a routing instance for RIP, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { interface interface-name; instance-type vrf; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { rip { ... rip-configuration ... } } } }

For more information about the RIP configuration statements, see “Configuring RIP” on page 839. For more information about configuring VPNs, see the Junos OS VPNs Configuration Guide.

Minimum Routing-Instance Configuration for VPLS To create a routing instance for virtual private LAN services (VPLS), you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { instance-type vpls; interface interface-name; route-distinguisher (as-number:number | ip-address:number);


249


vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { vpls { ... vpls configuration ... } } } }


•


•

Junos OS Virtual Private LAN Services Feature Guide

Configuring Multiple Instances of BGP You can configure multiple instances of BGP at the following hierarchy levels: •


•


Multiple instances of BGP are primarily used for Layer 3 VPN support. IGP peers and EBGP peers (both nonmultihop and multihop) are all supported for routing instances. BGP peering is established over one of the interfaces configured under the routing-instances hierarchy. Routes learned from the BGP peer are added to the instance-name.inet.0 table by default. You can configure import and export policies to control the flow of information into and out of the instance routing table. For Layer 3 VPN support, configure BGP on the provider edge (PE) router to receive routes from the customer edge (CE) router and to send the instances’ routes to the CE router if necessary. You can use multiple instances of BGP to maintain separate per-site forwarding tables for keeping VPN traffic separate on the PE router. For more detailed information about configuring VPNs, see the Junos OS VPNs Configuration Guide. You can configure import and export policies that allow the service provider to control and rate-limit traffic to and from the customer.

Example: Configuring Multiple Instances of BGP Configure multiple instances of BGP: [edit] routing-instances { routing-instance-name { interface so-1/1/1.0; interface so-1/1/1.1; instance-type vrf; route distinguisher (as-number:number | ip-address:number); protocols { bgp { group group-name {

250



peer-as 01; type external; import route-name; export route-name; neighbor 10.0.0.1; } } } } }

You can configure an EBGP multihop session for a VRF routing instance. Also, you can set up the EBGP peer between the PE and CE routers by using the loopback address of the CE router instead of the interface addresses.

Configuring Multiple Instances of IS-IS You can configure multiple instances of IS-IS for administrative separation. To configure multiple routing instances, perform the following tasks: 1.

Configure the IS-IS default instance at the [edit protocols isis] or [edit logical-systems logical-system-name protocols isis] hierarchy levels with the statements needed for your network so that routes are installed in inet.0 and in the forwarding table. Make sure to include the routing table group.

2. Configure an IS-IS routing instance for each additional IS-IS routing entity, configuring

the following items: •

Interfaces

•

Routing options

•

IS-IS protocol statements belonging to that entity

•

Routing table group

3. Configure a routing table group to install routes from the routing instance into the

inet.0 routing table. You can do this in two ways: •

•

Create a common routing table group so that either one of two conditions is configured: •

Routes from the routing instances are installed in inet.0 and therefore installed in the forwarding table.

•

Routes from one router in a routing instance are forwarded to another router in the same routing instance.

Create a routing table group with just the routing table from one instance and inet.0 to keep the routes from going to other instances.

4. Create an export policy to export routes with a specific tag and to use that tag to

export routes back into the instances. For more information, see the Junos OS Routing Policy Configuration Guide.


251


Example: Configuring Multiple Routing Instances of IS-IS Figure 4 on page 252 shows how you can use multiple instances of IS-IS to segregate traffic within a large network. The network consists of three administrative entities: voice-policy, other-policy, and the backbone or core. Each entity is composed of several geographically separate sites that are connected by the backbone and managed by the backbone entity.

Figure 4: Configuration for Multiple Routing Instances Site A

Site B

4

6

voice-policy

other-policy

so-5/2/2.0

so-2/2/2.0

Backbone 3

1

so-3/2/2.0

so-4/2/2.0

7

5

other-policy

voice-policy

Site C

Site D

g040730

2

Sites A and D belong to the voice-policy routing instance. Sites B and C belong to the other-policy instance. Router 1 and Router 3 at the edge of the backbone connect the routing instances. Each runs a separate IS-IS instance (one per entity). Router 1 runs three IS-IS instances: one each for Site A (voice-policy), Site C (other-policy), and the backbone, otherwise known as the default instance. Router 3 also runs three IS-IS instances: one each for Site B (other-policy), Site D (voice-policy), and the backbone (default instance). When Router 1 runs the IS-IS instances, the following occur:

252

•

Routes from the default instance routing table are placed in the voice-policy and other-policy instance routing tables.

•

Routes from the voice-policy routing instance are placed in the default instance routing table.

•

Routes from the other-policy routing instance are placed in the default instance routing table.



Configuring Router 1

•

Routes from the voice-policy routing instance do not enter the other-policy instance routing table.

•

Routes from the other-policy routing instance do not enter the voice-policy instance routing table.

The following sections describe how to configure Router 1 in the backbone entity with multiple routing instances. Configure the routing instances for voice-policy and other-policy. Use all routes learned from the routing tables in the routing table group inet-to-voice-and-other. Export routes tagged as belonging to the routing instance. [edit] routing-instances { voice-policy { interface so-2/2/2.0; protocols { isis { rib-group voice-to-inet; export filter-on-voice-policy; interface so-2/2/2.0 { level 2 metric 20; } } } } other-policy { interface so-4/2/2.0; protocols { isis { rib-group other-to-inet; export filter-on-other-policy; interface so-4/2/2.0 { level 2 metric 20; } } } } }

Configure the routing table group inet-to-voice-and-other to share routes with the inet.0 (in the backbone entity), voice-policy.inet.0, and other-policy.inet.0 routing tables: [edit] routing-options { rib-groups { inet-to-voice-and-other { import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ]; } } }

Configure the routing table group voice-to-inet to share routes with the inet.0 (in the backbone entity) and voice-policy.inet.0 routing tables:


253


[edit] routing-options { rib-groups { voice-to-inet { import-rib [ voice-policy.inet.0 inet.0]; } } }

Configure the routing table group other-to-inet to share routes with the inet.0 (in the backbone entity) and other-policy.inet.0 routing tables: [edit] routing-options { rib-groups { other-to-inet { import-rib [ other-policy.inet.0 inet.0]; } } }

Configure the default IS-IS instance so that the routes learned from the routing instances are installed in inet.0 and the tagged routes are exported from voice-policy and other-policy: [edit] protocols { isis { export apply-tag; rib-group inet-to-voice-and-other; interface so-1/0/0.0 { level 2 metric 20; } interface fxp0.0 { disable; } interface lo0.0 { passive; } } }

Configure routing policy for the routes learned from the routing instances: [edit] policy-options { policy-statement apply-tag { term voice-policy { from instance voice-policy; then { tag 10; accept; } } term other-policy { from instance other-policy; then {

254



tag 12; accept; } } } policy-statement filter-on-voice-policy { from { tag 10; protocol isis; } then { accept; } } policy-statement filter-on-other-policy { from { tag 12; protocol isis; } then { accept; } } }

Configuring Router 3

The configuration for Router 3 is the same as for Router 1 except that the interface names might differ. In this topology, the interface so-5/2/2.0 belongs to other-policy, and so-3/2/2.0 belongs to voice-policy.

Configuring Multiple Instances of LDP LDP is a protocol used to distribute labels in an MPLS-enabled network. LDP instances are used to distribute labels from a provider edge (PE) router to a customer edge (CE) router. LDP instances in a VPN are useful in carrier-of-carrier networks, where data is transmitted between two or more telecommunications carrier sites across a core provider network. Each carrier may want to restrict Internet routes strictly to the PE routers. An advantage of using LDP instances within a VPN is that full-mesh IBGP is not required between the PE and CE routers. A router ID is required to configure an instance of LDP. To configure multiple instances of LDP, include the following statements: routing-instances { routing-instance-name { interface interface-name; instance-type vrf; protocols { ldp { ... ldp-configuration ... } } }


255


}



•



•


•


Configuring Multiple Instances of MSDP MSDP instances are supported only for VRF instance types. You can configure multiple instances of MSDP to support multicast over VPNs. To configure multiple instances of MSDP, include the following statements: routing-instances { routing-instance-name { interface interface-name; instance-type vrf; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { msdp { ... msdp-configuration ... } } } }



•



•


•


Example: Configuring Multiple Routing Instances of OSPF This example shows how to configure multiple routing instances of OSPF.

256

•

Requirements on page 257

•

Overview on page 257



•

Configuration on page 258

•

Verification on page 262

Requirements Before you begin: •

Configure the device interfaces. See the Junos OS Network Interfaces Configuration Guide.

•

Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an OSPF Router Identifier” on page 510.

•

Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” on page 511

Overview When you configure multiple routing instances of OSPF, we recommend that you perform the following tasks: 1.

Configure the OSPFv2 or OSPFv3 default instance at the [edit protocols (ospf | ospf3)] and [edit logical-systems logical-system-name protocols (ospf | ospf3)] hierarchy levels with the statements needed for your network so that routes are installed in inet.0 and in the forwarding table. Make sure to include the routing table group.

2. Configure an OSPFv2 or OSPFv3 routing instance for each additional OSPFv2 or

OSPFv3 routing entity, configuring the following: •

Interfaces

•

Routing options

•

OSPF protocol statements belonging to that entity

•

Routing table group

3. Configure a routing table group to install routes from the default route table, inet.0,

into a routing instance’s route table. 4. Configure a routing table group to install routes from a routing instance into the default

route table, inet.0.

NOTE: Nonforwarding routing instances do not have forwarding tables that correspond to their routing tables.

5. Create an export policy to export routes with a specific tag, and use that tag to export

routes back into the instances. For more information, see the Junos OS Routing Policy Configuration Guide. Figure 5 on page 258 shows how you can use multiple routing instances of OSPFv2 or OSPFv3 to segregate prefixes within a large network. The network consists of three administrative entities: voice-policy, other-policy, and the default routing instance. Each


257


entity is composed of several geographically separate sites that are connected by the backbone and managed by the backbone entity.


Site B

4

6

voice-policy

other-policy

so-5/2/2.0

so-2/2/2.0

Backbone 3

1

so-3/2/2.0

so-4/2/2.0

7

5

other-policy

voice-policy

Site C

Site D

g040730

2

Sites A and D belong to the voice-policy routing instance. Sites B and C belong to the other-policy instance. Device 1 and Device 3 at the edge of the backbone connect the routing instances. Each runs a separate OSPF or OSPFv3 instance (one per entity). Device 1 runs three OSPFv2 or OSPFv3 instances: one each for Site A (voice-policy), Site C (other-policy), and the backbone, otherwise known as the default instance. Device 3 also runs three OSPFv2 or OSPFv3 instances: one each for Site B (other-policy), Site D (voice-policy), and the backbone (default instance). When Device 1 runs the OSPFv2 or OSPFv3 instances, the following occur: •


•


•


•


•


Configuration CLI Quick Configuration

258

To quickly configure multiple routing instances of OSPF, copy the following commands, remove any line breaks, and then paste the commands into the CLI.



Configuration on Device 1: [edit] set routing-instances voice-policy interface so-2/2/2 set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface so-2/2/2 set routing-instances other-policy interface so-4/2/2 set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface so-4/2/2 set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ] set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 ] set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0 inet.0 ] set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-2/2/2 set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-4/2/2


Step-by-Step Procedure

To configure multiple routing instances of OSPF: 1.

Configure the routing instances for voice-policy and other-policy.

NOTE: To specify OSPFv3, include the ospf3 statement at the [edit routing-instances protocols] hierarchy level.

[edit] user@D1# set routing-instances voice-policy interface so-2/2/2 user@D1# set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface so-2/2/2 user@D1# set routing-instances other-policy interface so-4/2/2 user@D1# set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface so-4/2/2 [edit] user@D3# set routing-instances voice-policy interface so-3/2/2 user@D3# set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface so-3/2/2 user@D3#set routing-instances other-policy interface so-5/2/2 user@D3# set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface so-5/2/2


259


2.

Configure the routing table group inet-to-voice-and-other to take routes from inet.0 (default routing table) and place them in the voice-policy.inet.0 and other-policy.inet.0 routing tables. [edit] user@D1# set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ] [edit] user@D3# set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ]

3.

Configure the routing table group voice-to-inet to take routes from voice-policy.inet.0 and place them in the inet.0 default routing table. [edit] user@D1# set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 ] [edit] user@D3# set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 ]

4.

Configure the routing table group other-to-inet to take routes from other-policy.inet.0 and place them in the inet.0 default routing table. [edit] user@D1# set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0 inet.0 ] [edit] user@D3# set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0 inet.0 ]

5.

Configure the default OSPF instance.


[edit] user@D1# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-2/2/2 user@D1# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-4/2/2 [edit] user@D3# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-3/2/2 user@D3# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-5/2/2 6.

If you are done configuring the device, commit the configuration. [edit] user@host# commit

260



Results

Confirm your configuration by entering the show routing-instances, show routing-options, and show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on Device 1: user@D1# show routing-instances voice-policy { interface so-2/2/2.0; protocols { ospf { rib-group voice-to-inet; area 0.0.0.0 { interface so-2/2/2.0; } } } } other-policy { interface so-4/2/2.0; protocols { ospf { rib-group other-to-inet; area 0.0.0.0 { interface so-4/2/2.0; } } } } user@D1# show routing-options rib-groups { inet-to-voice-and-other { import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ]; } voice-to-inet { import-rib [ voice-policy.inet.0 inet.0 ]; } other-to-inet { import-rib [ other-policy.inet.0 inet.0 ]; } } user@D1# show protocols ospf rib-group inet-to-voice-and-other; area 0.0.0.0 { interface so-2/2/2.0; interface so-4/2/2.0; }

Configuration on Device 3: user@D3# show routing-instances voice-policy { interface so-3/2/2.0; protocols { ospf {


261


rib-group voice-to-inet; area 0.0.0.0 { interface so-3/2/2.0; } } } } other-policy { interface so-5/2/2.0; protocols { ospf { rib-group other-to-inet; area 0.0.0.0 { interface so-5/2/2.0; } } } } user@D3# show routing-options rib-groups { inet-to-voice-and-other { import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ]; } voice-to-inet { import-rib [ voice-policy.inet.0 inet.0 ]; } other-to-inet { import-rib [ other-policy.inet.0 inet.0 ]; } } user@D3# show protocols ospf rib-group inet-to-voice-and-other; area 0.0.0.0 { interface so-3/2/2.0; interface so-5/2/2.0; }

To confirm your OSPFv3 configuration, enter the show routing-instances, show routing-options, and show protocols ospf3 commands.

Verification Confirm that the configuration is working properly.

Verifying the Routing Instances Purpose Action


262

Verify the configured routing instance settings. From operational mode, enter the show route instance detail command.

•

Introduction to Routing Instances for OSPF on page 601



Configuring Multiple Instances of PIM PIM instances are supported only for VRF instance types. You can configure multiple instances of PIM to support multicast over VPNs. To configure multiple instances of PIM, include the following statements: routing-instances { routing-instance-name { interface interface-name; instance-type vrf; protocols { pim { ... pim-configuration ... } } } }



•



•


•


Configuring Multiple Instances of RIP RIP instances are supported only for VRF instance types. You can configure multiple instances of RIP for VPN support only. You can use RIP in the customer edge-provider edge (CE-PE) environment to learn routes from the CE router and to propagate the PE router’s instance routes in the CE router. RIP routes learned from neighbors configured under any instance hierarchy are added to the instance’s routing table, instance-name.inet.0. RIP does not support routing table groups; therefore, it cannot import routes into multiple tables as the OSPF or OSPFv3 protocol does. To configure multiple instances of RIP, include the following statements: routing-instances { routing-instance-name { interface interface-name; instance-type vrf; protocols { rip { interface interface-name; neighbor ip-address;


263


} } } }



•


Configuring Routing Instances You can create multiple instances of BGP, IS-IS, OSPF, OSPFv3, RIP, and static routes. For information about how to configure a virtual switch, see the Junos OS Layer 2 Configuration Guide. You can include the statements at the following hierarchy levels: •


•


Each routing instance consist of the following: •

A set of routing tables

•

A set of interfaces that belong to these routing tables

•

A set of routing option configurations

Each routing instance has a unique name and a corresponding IP unicast table. For example, if you configure a routing instance with the name my-instance, its corresponding IP unicast table is my-instance.inet.0. All routes for my-instance are installed into my-instance.inet.0. Configure global routing options and protocols for the default instance by including statements. For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Routes are installed into the default routing instance inet.0 by default, unless a routing instance is specified.

NOTE: In Junos OS Release 9.0 and later, you can no longer specify a routing-instance name of default or include special characters within the name of a routing instance.

To configure a routing instance, include the following statements:

264



routing-instances { routing-instance-name { interface interface-name; instance-type (forwarding | layer2-control | l2vpn | no-forwarding | virtual-router | virtual-switch | vpls | vrf); no-vrf-advertise; no-vrf-propagate-ttl; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; vrf-propagate-ttl; vrf-table-label; protocols { bgp { ... bgp-configuration ... } isis { isis-configuration; } l2vpn { l2vpn-configuration; } ldp { ... ldp-configuration ... } msdp { msdp-configuration; } ospf { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ospf-configuration; } ospf3 { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ospf3-configuration; } pim { pim-configuration; } rip { rip-configuration; } ripng { ripng-configuration; } vpls { vpls-configuration; } } } }


265


Specifying the Instance Type for Routing Instances You can configure eight routing instance types at the [edit routing-instances routing-instance-name instance-type] and [edit logical-systems logical-system-name routing-instances routing-instance-name instance-type] hierarchy levels: •

Forwarding—Use this routing instance type for filter-based forwarding applications. For this instance type, there is no one-to-one mapping between an interface and a routing instance. All interfaces belong to the default instance inet.0.

•

Layer 2 VPN—Use this routing instance type for Layer 2 VPN implementations.

•

Layer 2-control—(MX Series routers only) Use this routing instance type for RSTP or MSTP in customer edge interfaces of a VPLS routing instance. This instance type cannot be used if the customer edge interface is multihomed to two provider edge interfaces. If the customer edge interface is multihomed to two provider edge interfaces, use the default BPDU tunneling. For more information about configuring a layer2-control instance type, see the Junos OS Layer 2 Configuration Guide.

•

No-forwarding—Use this routing instance type when a separation of routing table information is required. There is no corresponding forwarding table. All routes are installed into the default forwarding table. IS-IS instances are strictly nonforwarding instance types.

•

Virtual router—This routing instance is similar to a VPN routing and forwarding instance type, but used for non-VPN-related applications. There are no VRF import, VRF export, VRF target, or route distinguisher requirements for this instance type.

•

Virtual switch—(MX Series routers only) Use the virtual switch instance type to isolate a LAN segment with its Spanning Tree Protocol (STP) instance and separates its VLAN identifier space. For more information about configuring a virtual switch instance type, see the Junos OS Layer 2 Configuration Guide. and the Junos OS MX Series 3D Universal Edge Routers Solutions Guide.

•

VPLS—Use this routing instance type for point-to-multipoint LAN implementations between a set of sites in a VPN.

•

VRF—Use this routing instance type for Layer 3 VPN implementations. For this instance type, there is a one-to-one mapping between an interface and a routing instance. Each VRF instance corresponds with a forwarding table. Routes on an interface go into the corresponding forwarding table.

To configure a routing instance type, include the instance-type statement: routing-instances { routing-instance-name { interface interface-name; instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf); } }

You can include the statement at the following hierarchy levels:

266



•


•


For more information about configuring Layer 2 VPNs, Layer 3 VPNs, and VPLS, see the Junos OS VPNs Configuration Guide. For more information about configuring the types of routing instances, see the following sections: •

Configuring VRF Routing Instances on page 267

•

Configuring Non-VPN VRF Routing Instances on page 268

•

Configuring VPLS Routing Instances on page 269

Configuring VRF Routing Instances To configure a VPN VRF routing instance, include the following statements: interface interface-name; instance-type vrf; no-vrf-advertise; no-vrf-propagate-ttl; route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; vrf-propagate-ttl; vrf-table-label; protocols { bgp { ... bgp-configuration ... } isis { ... isis-configuration ... } l2vpn { ... l2vpn-configuration ... } ldp { ... ldp-configuration ... } msdp { ... msdp-configuration ... } ospf { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ... ospf-configuration ... } ospf3 { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ... ospf3-configuration ... }


267


pim { ... pim-configuration ... } rip { ... rip-configuration ... } vpls { ... vpls-configuration ... } }



•


Configuring Non-VPN VRF Routing Instances To configure a non-VPN VRF routing instance (for example, to allow IPsec tunnels within VRF routing instances), include the following statements: interface interface-name; instance-type virtual-router; protocols { bgp { ... bgp-configuration ... } isis { ,,, isis-configuration ... } ldp { ... ldp-configuration ... } msdp { ... msdp-configuration ... } ospf { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ... ospf-configuration ... } ospf3 { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ... ospf3-configuration ... } pim { ... pim-configuration ... } rip { ... rip-configuration ... } }

268





•


Configuring VPLS Routing Instances To configure a VPLS routing instance, include the following statements: interface interface-name; instance-type vpls; protocols { vpls { ... vpls-configuration ... } }

You can include the statements at the following hierarchy levels:


•


•


•


•

Junos OS Virtual Private LAN Services Feature Guide

Configuring Route Distinguishers for Routing Instances Each routing instance must have a unique route distinguisher associated with it. The route distinguisher is used to place bounds around a VPN so the same IP address prefixes can be used in different VPNs without having them overlap. We recommend that you use a unique route distinguisher for each routing instance that you configure. Although you could use the same route distinguisher on all PE routers for the same VPN, if you use a unique route distinguisher, you can determine the CE router from which a route originated. To configure a route distinguisher, include the route-distinguisher statement: route-distinguisher (as-number:number | ip-address:number); }

You can include the statement at the following hierarchy levels: •


•


The route distinguisher is a 6-byte value that you can specify in one of the following formats:


269


•

as-number:number, where as-number is your assigned AS number and number is any

2-byte or 4-byte value. The AS number can be in the range from 1 through 4,294,967,295. If the AS number is a 2-byte value, the administrative number is a 4-byte value. If the AS number is 4-byte value, the administrative number is a 2-byte value. A route distinguisher consisting of a 4-byte AS number and a 2-byte administrative number is defined as a type 2 route distinguisher in RFC 4364 BGP/MPLS IP Virtual Private Networks.

NOTE: In Junos OS Release 9.1 and later, the numeric range for AS numbers is extended to provide BGP support for 4-byte AS numbers, as defined in RFC 4893, BGP support for Four-octet AS Number Space. All releases of the Junos OS support 2-byte AS numbers. To configure a route distinguisher that includes a 4-byte AS number, append the letter “L” to the end of the number. For example, a route distinguisher with the 4-byte AS number 7,765,000 and an administrative number of 1,000 is represented as 77765000L:1000. In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format.

•

ip-address:number, where ip-address is an IP address in your assigned prefix range

(a 4-byte value) and number is any 2-byte value. The IP address can be in the range 32 from 0 through 4,294,967,295 (2 – 1). If the router you are configuring is a BGP peer of a router that does not support 4-byte AS numbers, you need to configure a local AS number. For more information, see Establishing a Peer Relationship Between a 4-Byte Capable Router and a 2-Byte Capable Router Using a 4-Byte AS Number in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview. Related Documentation

•

Understanding 4-Byte AS Numbers and Route Distinguishers in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview

Configuring Filter-Based Forwarding You can create a filter to classify packets to determine their forwarding path within a router. Use filter-based forwarding to redirect traffic for analysis. Filter-based forwarding is supported for IP version 4 (IPv4) and IP version 6 (IPv6). Use filter-based forwarding for service provider selection when customers have Internet connectivity provided by different ISPs yet share a common access layer. When a shared media (such as a cable modem) is used, a mechanism on the common access layer looks at Layer 2 or Layer 3 addresses and distinguishes between customers. You can use

270



filter-based forwarding when the common access layer is implemented using a combination of Layer 2 switches and a single router. With filter-based forwarding, all packets received on an interface are considered. Each packet passes through a filter that has match conditions. If the match conditions are met for a filter and you have created a routing instance, filter-based forwarding is applied to a packet. The packet is forwarded based on the next hop specified in the routing instance. For static routes, the next hop can be a specific LSP. For more information about configuring LSPs, see the Junos OS MPLS Applications Configuration Guide.

NOTE: Source-class usage filter matching and unicast reverse-path forwarding checks are not supported on an interface configured with filter-based forwarding (FBF).

To configure filter-based forwarding, perform the following tasks: •

Create a match filter on an ingress router. To specify a match filter, include the filter filter-name statement at the [edit firewall] hierarchy level. For more information about creating a match filter for packet forwarding, see the Junos OS Routing Policy Configuration Guide. A packet that passes through the filter is compared against a set of rules to classify it and to determine its membership in a set. Once classified, the packet is forwarded to a routing table specified in the accept action in the filter description language. The routing table then forwards the packet to the next hop that corresponds to the destination address entry in the table.

•

Create routing instances that specify the routing table(s) to which a packet is forwarded, and the destination to which the packet is forwarded at the [edit routing-instances] or [edit logical-systems logical-system-name routing-instances] hierarchy levels. For example: [edit] routing-instances { routing-table-name1 { instance-type forwarding; routing-options { static { route 0.0.0.0/0 nexthop 10.0.0.1; } } } routing-table-name2 { instance-type forwarding; routing-options { static { route 0.0.0.0/0 nexthop 10.0.0.2; } } } }

•

Create a routing table group that adds interface routes to the forwarding routing instances used in filter-based forwarding (FBF), as well as to the default routing


271


instance inet.0. This part of the configuration resolves the routes installed in the routing instances to directly connected next hops on that interface. Create the routing table group at the [edit routing-options] or [edit logical-systems logical-system-name routing-options] hierarchy levels. For IPv4, the following configuration installs interface routes into the default routing instance inet.0, as well as two forwarding routing instances—routing-table-name1.inet.0 and routing-table-name2.inet.0: [edit] routing-options { interface-routes { rib-group inet group-name; } rib-groups { group-name { import-rib [ inet.0 routing-table-name1.inet.0 routing-table-name2.inet.0 ]; } } }

NOTE: Specify inet.0 as one of the routing instances that the interface routes are imported into. If the default instance inet.0 is not specified, interface routes are not imported into the default routing instance.

Configuring Class-of-Service-Based Forwarding Class-of-service (CoS)-based forwarding allows you to control the next-hop selection based on a packet’s class of service or IP precedence. It allows path selection based on a multifield classifier. To configure CoS-based forwarding, perform the following tasks: 1.

Create a routing policy at the [edit policy-options] or [edit logical-systems logical-system-name policy-options] hierarchy levels to limit the configuration so that routes matching the route filter are subject to the CoS next-hop mapping specified in my-cos-map: [edit] policy-options { policy-statement my-cos-forwarding { from { route-filter ...; } then { cos-next-hop-map my-cos-map; } } }

272



2. Create a CoS next-hop map. To specify a CoS next-hop map, include the

cos-next-hop-map statement at the [edit class-of-service] hierarchy level. For more

information about creating a CoS next-hop map, see the Junos OS Class of Service Configuration Guide. 3. Specify the exporting of the routes to the forwarding table at the [edit routing-options]

or [edit logical-systems logical-system-name routing-options] hierarchy levels: [edit] routing-options { forwarding-table { export my-cos-forwarding; } } 4. Specify a static route that has multiple next hops for load balancing at the

[edit routing-options] or [edit logical-systems logical-system-name routing-options]

hierarchy levels: [edit] routing-options { static { route 12.1.1.1/32 { next-hop [ 3.1.1.2 3.1.1.4 3.1.1.6 3.1.1.8 ]; } } }

Configuring Secondary VRF Import and Export Policy You configure a VPN routing and forwarding instance (VRF) so that routes received from the provider edge-provider edge (PE-PE) session (in the default instance) can be imported into any of an instance’s VRF secondary routing tables. Importing depends on defined policies. Routes to be exported should pass through the policies listed in the export list. To configure secondary VRF import and export policies, include the following statements: [edit] routing-instances { routing-instance-name { instance-type vrf; vrf-import [ policy-names ]; vrf-export [ policy-names ]; } } policy-options { policy-statement policy-name { from community community-name; then accept; } }


•



273


Configuring Policy-Based Export for Routing Instances Configuring policy-based export simplifies the process of exchanging route information between routing instances. Exporting routing information between routing instances typically is accomplished by configuring separate routing table groups for each instance. The use of policy-based export reduces the configuration needed for exporting routes between multiple routing instances by eliminating the configuration of separate routing table groups for each instance. Policy-based export is particularly useful in the following two cases: •

Overlapping VPNs—VPN configurations in which more than one VRF has the same route target

•

Nonforwarding instances—Multilevel IGPs using multiple routing instances

NOTE: The instance-export and instance-import statements are not valid for VRF instances. The auto-export statement is valid for VRF and non-VRF instances. The instance-import statement automatically enables auto-export for non-VRF instances.

For detailed information about configuring overlapping VPNs and nonforwarding instances, see the Junos OS VPNs Configuration Guide. For sample configurations, see the following sections: •

Example: Configuring Policy-Based Export for an Overlapping VPN on page 274

•

Example: Configuring Policy-Based Export for a Nonforwarding Instance on page 276

Example: Configuring Policy-Based Export for an Overlapping VPN In Layer 3 VPNs, a CE router is often a member of more than one VPN. Figure 6 on page 275 illustrates the topology for the configuration example in this section. The configurations in this section illustrate local connectivity between CE routers connected to the same PE router using BGP. The configuration statements enable the VPN AB Router CE2 to communicate with the VPN A Router CE1 and the VPN B Router CE3, both directly connected to the Router PE1. VPN routes that originate from the remote PE routers (the PE2 Router, in this case) are placed in a global Layer 3 VPN routing table (bgp.l3vpn.inet.0) and routes with appropriate route targets are imported into the routing tables, as dictated by the VRF import policy configuration.

274



Figure 6: Configuration of Policy-Based Export for an Overlapping VPN

Configuring Router PE1

This section describes how to configure Router PE1 in the backbone entity for this overlapping VPN by means of policy-based export. Configure the routing instances for VPN-A, VPN-AB, and VPN-B: [edit] routing-instances { VPN-A { instance-type vrf; interface fe-1/0/0.0; route-distinguisher 10.255.14.175:3; vrf-export A-out; vrf-import A-in; routing-options { auto-export; static { route 1.1.1.1/32 next-hop fe-1/0/0.0; route 1.1.1.2/32 next-hop fe-1/0/0.0; } } } VPN-AB { instance-type vrf; interface fe-1/1/0.0; route-distinguisher 10.255.14.175:9; vrf-export AB-out; vrf-import AB-in; routing-options { auto-export; static {


275


route 1.1.3.1/32 next-hop fe-1/1/0.0; route 1.1.3.2/32 next-hop fe-1/1/0.0; } } VPN-B { instance-type vrf; interface fe-1/0/2.0; route-distinguisher 10.255.14.175:9; vrf-export B-out; vrf-import B-in; routing-options { auto-export; static { route 1.1.2.1/32 next-hop fe-1/0/2.0; route 1.1.2.2/32 next-hop fe-1/0/2.0; } } } } }

Configuring Router PE2

The configuration for Router PE2 is the same as that for Router PE1; however, the interface names might differ.

Example: Configuring Policy-Based Export for a Nonforwarding Instance This example shows how to use the instance-import and instance-export statements to control route export between multiple instances. This is equivalent to using the vrf-import and vrf-export statements for VPNs, except these are with nonforwarding instances, not VRF instances. There are two nonforwarding instances: data and voice. The following is the configuration for a PE router. Configure the routing instances for data and voice: [edit] routing-instances { data { instance-type no-forwarding; interface t3-0/1/3.0; routing-options { instance-import data-import; auto-export; protocols { ospf { export accept; area 0.0.0.0 { interface all; } } } } voice { instance-type no-forwarding;

276



interface t3-0/1/0.0; routing-options { instance-import voice-import; auto-export; } protocols { ospf { export accept; area 0.0.0.0 { interface all; } } } } } }

Configure a master policy: [edit] policy-options { policy-statement master-import { term a { from instance master; then { tag 11; accept; } } term b { from instance data; then { tag 10; accept; } } } }

Configure policies for each instance: [edit] policy-options { policy-statement data-import { term a { from { instance master; tag 10; then accept; } } term b { then reject; } } policy-statement voice-import { term a {


277


from { instance master; protocol ospf; tag 11; } } term b { then reject; } } }


•

Example: Exporting Specific Routes from One Routing Table Into Another Routing Table on page 278

Example: Exporting Specific Routes from One Routing Table Into Another Routing Table This example shows how to duplicate specific routes from one routing table into another routing table within the same routing instance. •


•


•


•


Requirements No special configuration beyond device initialization is required before configuring this example.

Overview This example uses the auto-export statement and the rib-group statement to accomplish the goal of exporting specific routes from one routing table to another. Consider the following points:

278

•

When auto-export is configured in a routing instance, the vrf-import and vrf-export policies are examined. Based on the route target and community information in the policies, the auto-export function performs route leaking among the local routing instance inet.0 tables.

•

You can use the rib-group statement if it is necessary to import routes into tables other than instance.inet.0. If a RIB group is used, the RIB group's export-rib and import-policy statements are not used. Only the import-rib statement is used. To use a RIB group with auto-export, the routing instance should specify explicit vrf-import and vrf-export policies. The vrf-import and vrf-export policies can be extended to contain additional terms to filter routes as needed for the RIB group.



In this example, access-internal routes are added into the vpna.inet.0 routing table. The access-internal routes are also duplicated into the vpna.inet.2 routing table.

Configuration •

CLI Quick Configuration

[xref target has no title]

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set interfaces fe-1/3/1 vlan-tagging set interfaces fe-1/3/1 unit 0 vlan-id 512 set interfaces fe-1/3/1 unit 0 family inet address 10.168.100.3/24 set interfaces lo0 unit 0 family inet address 192.168.3.3/32 set routing-options rib-groups rib-group-vpna-access-internal import-rib vpna.inet.2 set routing-options autonomous-system 63000 set policy-options policy-statement vpna-export term a from protocol bgp set policy-options policy-statement vpna-export term a then community add vpna-comm set policy-options policy-statement vpna-export term a then accept set policy-options policy-statement vpna-export term b from protocol access-internal set policy-options policy-statement vpna-export term b then accept set policy-options policy-statement vpna-export term c then reject set policy-options policy-statement vpna-import term a from protocol bgp set policy-options policy-statement vpna-import term a from community vpna-comm set policy-options policy-statement vpna-import term a then accept set policy-options policy-statement vpna-import term b from instance vpna set policy-options policy-statement vpna-import term b from protocol access-internal set policy-options policy-statement vpna-import term b then accept set policy-options policy-statement vpna-import term c then reject set policy-options community vpna-comm members target:63000:100 set routing-instances vpna instance-type vrf set routing-instances vpna interface fe-1/3/1.1 set routing-instances vpna route-distinguisher 100:1 set routing-instances vpna vrf-import vpna-import set routing-instances vpna vrf-export vpna-export set routing-instances vpna routing-options auto-export family inet unicast rib-group rib-group-vpna-access-internal set routing-instances vpna protocols bgp group bgp-vpna type external set routing-instances vpna protocols bgp group bgp-vpna family inet multicast set routing-instances vpna protocols bgp group bgp-vpna peer-as 100 set routing-instances vpna protocols bgp group bgp-vpna neighbor 10.0.0.10


The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure the device: 1.

Configure the interfaces. [edit interfaces fe-1/3/1] user@host# set vlan-tagging user@host# set unit 0 vlan-id 512 user@host# set unit 0 family inet address 10.168.100.3/24


279


[edit interfaces lo0 unit 0] user@host# set family inet address 192.168.3.3/32 2.

Configure the routing policy that specifies particular routes for import into vpna.inet.0 and export from vpna.inet.0. [edit policy-options] user@host# set policy-statement vpna-export term a from protocol bgp user@host# set policy-statement vpna-export term a then community add vpna-comm user@host# set policy-statement vpna-export term a then accept user@host# set policy-statement vpna-export term b from protocol access-internal user@host# set policy-statement vpna-export term b then accept user@host# set policy-statement vpna-export term c then reject user@host# set policy-statement vpna-import term a from protocol bgp user@host# set policy-statement vpna-import term a from community vpna-comm user@host# set policy-statement vpna-import term a then accept user@host# set policy-statement vpna-import term b from instance vpna user@host# set policy-statement vpna-import term b from protocol access-internal user@host# set policy-statement vpna-import term b then accept user@host# set policy-statement vpna-import term c then reject user@host# set community vpna-comm members target:63000:100

3.

Configure the routing instance. [edit routing-instances vpna] user@host# set instance-type vrf user@host# set interface fe-1/3/1.1 user@host# set route-distinguisher 100:1 user@host# set vrf-import vpna-import user@host# set vrf-export vpna-export

The vrf-import and vrf-export statements are used to apply the vpna-import and vpna-export routing policies configured in 2. 4.

Configure the RIB group, and import routes into the vpna.inet.2 routing table. [edit routing-options] user@host# set rib-groups rib-group-vpna-access-internal import-rib vpna.inet.2

5.

Configure the auto-export statement to enable the routes to be exported from one routing table into another. [edit routing-options] user@host# set auto-export family inet unicast rib-group rib-group-vpna-access-internal

6.

Configure BGP. [edit routing-instances vpna protocols bgp group bgp-vpna] user@host# set type external user@host# set family inet multicast user@host# set peer-as 100 user@host# set neighbor 100.0.0.10

7.

Configure the autonomous system (AS) number. [edit routing-options] user@host# set autonomous-system 63000

280



Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show routing-options, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces fe-1/3/1 { vlan-tagging; unit 0 { vlan-id 512; family inet { address 10.168.100.3/24; } } } lo0 { unit 0 { family inet { address 192.168.3.3/32; } } } user@host# show policy-options policy-statement vpna-export { term a { from { protocol bgp; } then { community add vpna-comm; accept; } } term b { from protocol access-internal; then accept; } term c { then reject; } } policy-statement vpna-import { term a { from { protocol bgp; community vpna-comm; } then accept; } term b { from { instance vpna; protocol access-internal; } then accept;


281


} term c { then reject; } } community vpna-comm members target:63000:100; user@host# show routing-options rib-groups { rib-group-vpna-access-internal { import-rib vpna.inet.2; } } autonomous-system 63000; user@host# show routing-instances vpna { instance-type vrf; interface fe-1/3/1.1; route-distinguisher 100:1; vrf-import vpna-import; vrf-export vpna-export; routing-options { auto-export { family inet { unicast { rib-group rib-group-vpna-access-internal; } } } } protocols { bgp { group bgp-vpna { type external; family inet { multicast; } peer-as 100; neighbor 100.0.0.10; } } } }

If you are done configuring the device, enter commit from configuration mode.

Verification Confirm that the configuration is working properly by running the show table route vpna.inet.0 and show route table vpna.inet.2 commands. Related Documentation

282

•




Configuring VRF Table Labels You configure a separate label for each VRF to provide double lookup and egress filtering. To configure a label for a VRF, include the following statements: [edit] routing-instances { routing-instance-name { instance-type vrf; vrf-import [ policy-names ]; vrf-export [ policy-names ]; vrf-table-label; } }


•


Configuring VRF Targets Configuring a VPN routing and forwarding (VRF) target provides a configurable community within a VRF routing instance and allows a single policy for import and a single policy for export to replace the per-VRF policies for every community. To configure a VRF target, include the vrf-target statement. Use the import and export options to specify the allowed communities to accept from neighbors and to send to neighbors: vrf-target { community; export community-name; import community-name; }

You can configure the statements at the following hierarchy levels: •


•


Within a hub-and-spoke configuration, you can configure a PE router not to advertise VPN routes from the primary (hub) instance. Instead, these routes are advertised from the secondary (downstream) instance. You can do this without configuring routing table groups, by using the no-vrf-advertise statement.

NOTE: This statement does not prevent the exportation of VPN routes to other VRF instances on the same router by configuring the [edit routing-options auto-export] statement.

To prevent advertising VPN routes from the primary instance, include the no-vrf-advertise statement:


283


no-vrf-advertise;

You can configure the statement at the following hierarchy levels:


•


•


•


Configuring OSPF Domain IDs for VPNs For most OSPF or OSPFv3 configurations involving Layer 3 VPNs, you do not need to configure an OSPF domain ID. However, for a Layer 3 VPN connecting multiple OSPF or OSPFv3 domains, configuring domain IDs can help you control LSA translation (for Type 3 and Type 5 LSAs) between the OSPF domains and back-door paths. The default domain ID is 0.0.0.0. Each VPN routing table in a PE router associated with an OSPF or OSPFv3 instance is configured with the same OSPF domain ID. Junos OS is fully compliant with Internet draft draft-ietf-l3vpn-ospf-2547-04.txt, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs. For more detailed information about configuring VPNs, see the Junos OS VPNs Configuration Guide. Without the domain IDs, there is no way to identify which domain the routes originated from after the OSPF or OSPFv3 routes are distributed into BGP routes and advertised across the BGP VPN backbone. Distinguishing which OSPF or OSPFv3 domain a route originated from allows classification of routes as Type 3 LSAs or Type 5 LSAs. To configure a domain ID, perform the following tasks: 1.

Specify a domain ID in the BGP extended community ID.

2. Set a route type. 3. Configure a VRF export policy to explicitly attach the outbound extended community

ID to outbound routes. 4. Define a community with members that possess the community ID.

For more information about configuring export policies, see the Junos OS Routing Policy Configuration Guide. This extended community ID can then be carried across the BGP VPN backbone. When the route is redistributed back as an OSPF or OSPFv3 route on the PE router and advertised to the CE near the destination, the domain ID identifies which domain the route originated from. The routing instance checks incoming routes for the domain ID. The route is then propagated as either a Type 3 LSA or Type 5 LSA. When a PE router receives a route, it redistributes and advertises the route as either a Type 3 LSA or a Type 5 LSA, depending on the following:

284



•

If the receiving PE router sees a Type 3 route with a matching domain ID, the route is redistributed and advertised as a Type 3 LSA.

•

If the receiving PE router sees a Type 3 route without a domain ID (the extended attribute field of the route’s BGP update does not include a domain ID), the route is redistributed and advertised as a Type 3 LSA.

•

If the receiving PE router sees a Type 3 route with a non-matching domain ID, the route is redistributed and advertised as a Type 5 LSA.

•

If the receiving PE router sees a Type 3 route with a domain ID, but the router does not have a domain ID configured, the route is redistributed and advertised as a Type 5 LSA.

•

If the receiving PE router sees a Type 5 route, the route is redistributed and advertised as a Type 5 LSA, regardless of the domain ID.

On the local PE router, the prefix of the directly connected PE/CE interface is an active direct route. This route is also an OSPF or OSPFv3 route. In the VRF export policy, the direct prefix is exported to advertise the route to the remote PE. This route is injected as an AS-External-LSA, much as when a direct route is exported into OSPF or OSPFv3. Domain ID ensures that an originated summary LSA arrives at the remote PE as a summary LSA. Domain ID does not translate AS-external-LSAs into summary LSAs. To configure an OSPF or OSPFv3 domain ID match condition for incoming Layer 3 VPN routes going into a routing instance, include the domain-id statement: domain-id domain-id;

For domain-id, specify either an IP address or an IP address and a local identifier using the following format: ip-address:local-identifier. If you do not specify a local identifier with the IP address, the identifier is assumed to have a value of 0. You can configure the statement at the following hierarchy levels: •

[edit routing-instances routing-instance-name protocols (ospf | ospf3)]

•

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)]

If the router ID is not configured in the routing instance, the router ID is derived from an interface address belonging to the routing instance. To prevent routing loops when a domain ID is used as an alternate route preference for the OSPF or OSPFv3 external routes generated by the PE router, the DN bit of the LSA being distributed by the PE router must be set. If the route is distributed in a Type 5 LSA and the DN bit is not supported by the PE router, the VPN tag is used instead. By default, the VPN tag is automatically calculated and needs no configuration. To configure the domain VPN tag for Type 5 LSAs, include the domain-vpn-tag number statement: domain-vpn-tag number;


285


You can configure the statement at the following hierarchy levels: •


•


The range is from 1 through 4,294,967,295. If you set VPN tags manually, you must set the same value for all PE routers in the VPN. To clear the VPN tag when it is no longer needed (when the DN bit is supported on the PE router), include the no-domain-vpn-tag statement: no-domain-vpn-tag;

You can configure the statement at the following hierarchy levels: •


•


The DN bit is not currently supported in OSPFv3. To set the route type, include the route-type-community statement: route-type-community (iana | vendor);



•


The domain-id setting in the routing instance is for a match on inbound Layer 3 VPN routes. A VRF export policy must be explicitly set for the outbound extended community domain-id attribute. You must configure an export policy to attach the domain ID to outgoing routes. To configure an export policy to attach the domain ID and route distinguisher to the extended community ID on outbound routes, include the community statement: policy-statement policy-name { term term-name { from protocol (ospf | ospf3); then { community add community-name; accept; } } term b { then reject; } } community community-name members [ target:target-id domain-id:domain-id];

286




[edit policy-options policy-statement policy-name term term-name then]

•

[edit logical-systems logical-system-name policy-options policy-statement policy-name term term-name then]

To define the members of a community, include the community statement: community name { members [ community-ids ]; }


[edit policy-options]

•

[edit logical-systems logical-system-name policy-options]

Examples: Configuring an OSPF Domain ID Configure a domain ID as a match condition for inbound Layer 3 VPN routes. Then configure an export policy to tag the extended community ID and the route distinguisher onto outgoing routes: [edit] routing-instances { CE_A { instance-type vrf; interface ge-0/1/0.0; route-distinguisher 1:100; vrf-import vrf_import_routes; vrf-export vrf_export_routes; protocols { ospf { domain-id 1.1.1.1; # match for inbound routes route-type-community vendor; export vrf_import_routes; area 0.0.0.0 { interface ge-0/1/0.0; } } } } } policy-options { policy-statement vrf_export_routes { term a { from protocol ospf; then { community add export_target; accept; } } term b { then reject;


287


} } community export_target members [ target:1:100 domain-id:1.1.1.1:0 ]; }

Leak a noninstance route into the instance routing table: [edit] routing-options { interface-routes { rib-group inet inet_to_site_A; } } [edit] rib-groups { inet_to_site_A { import-rib [ inet.0 site_A.inet.0 ]; } } [edit] protocols { ospf { rib-group inet_to_site_A; } } [edit] policy-options { policy-statement announce_to_ce { term a { from { protocol direct; interface lo0.0; } then accept; } } } [edit] routing-instances { site_A { protocols { ospf { export announce_to_ce; } } } }

Configuring Route Limits for Routing Tables A route limit sets an upper limit for the number of paths and prefixes installed in routing tables. You can, for example, use a route limit to limit the number of routes received from the CE router in a VPN. A route limit applies only to dynamic routing protocols, not to static or interface routes.

288



To configure a route limit on route paths, include the maximum-paths statement: maximum-paths path-limit ;

To configure a route limit on route prefixes, include the maximum-prefixes statement: maximum-prefixes prefix-limit ;

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Specify the log-only option to generate warning messages only (an advisory limit). Specify the threshold option to generate warnings before the limit is reached. Specify the log-interval option to configure the minimum time interval between log messages. There are two modes for route limits: advisory and mandatory. An advisory limit triggers warnings. A mandatory limit rejects additional routes after the limit is reached.

NOTE: Application of a route limit may result in unpredictable dynamic routing protocol behavior. For example, when the limit is reached and routes are rejected, BGP may not reinstall the rejected routes after the number of routes drops back below the limit. BGP sessions may need to be cleared.


•


Configuring Independent AS Domains You can configure an independent autonomous system (AS) domain that is separate from the primary routing instance domain. An AS is a set of routers that are under a single technical administration and that generally use a single IGP and metrics to propagate routing information within the set of routers. An AS appears to other ASs to have a single, coherent interior routing plan and presents a consistent picture of what destinations are reachable through it. Configuring an independent domain allows you to keep the AS paths of the independent domain from being shared with the AS path and AS path attributes of other domains, including the master routing instance domain. If you are using BGP on the router, you must configure an AS number. The independent domain uses the transitive path attribute 128 (attribute set) to tunnel the independent domain’s BGP attributes through the Internal BGP (IBGP) core. In Junos OS Release 10.3 and later, if BGP receives attribute 128 and you have not configured an independent domain in any routing instance, BGP treats the received attribute 128 as an unknown attribute. To configure an independent domain, include the independent-domain statement: independent-domain;


289


For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. There is a limit of 16 ASs for each domain.

290


CHAPTER 9

Summary of Routing Instances Configuration Statements This chapter provides a reference for each of the routing instance configuration statements. The statements are organized alphabetically.

access-profile Syntax

access-profile profile-name;

Hierarchy Level

[edit], [edit routing-instances routing-instances-name],

Release Information

Statement introduced in Junos OS Release 9.1.


Specify the access profile for use by the master routing instance. profile-name—Name of the access profile.

access—To view this statement in the configuration. access-control—To add this statement to the configuration. •

Configuring Access Components for the DHCP Layer 3 Wholesale Network Solution

•

Configuring Access Components for the PPPoE Wholesale Network Solution

•

Configuring Address Server Elements for the Broadband Subscriber Management Solution


291


description Syntax Hierarchy Level Release Information

Description


292

description text; [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 11.1 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Provide a text description for the routing instance. If the text includes one or more spaces, enclose it in quotation marks (" "). Any descriptive text you include is displayed in the output of the show route instance detail command and has no effect on the operation of the routing instance. interface—To view this statement in the configuration. interface-control—To add this statement to the configuration. •



Chapter 9: Summary of Routing Instances Configuration Statements

instance-type Syntax

Hierarchy Level

Release Information


instance-type (forwarding |l2backhaul-vpn | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf); [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4. virtual-switch and layer2-control options introduced in Junos OS Release 8.4. Define the type of routing instance. no-forwarding forwarding—Provide support for filter-based forwarding, where interfaces are not

associated with instances. All interfaces belong to the default instance. Other instances are used for populating RPD learned routes. See “Configuring Filter-Based Forwarding” on page 270. l2backhaul-vpn—Provide support for Layer 2 wholesale VLAN packets with no existing

corresponding logical interface. When using this instance, the router learns both the outer tag and inner tag of the incoming packets, when the instance-role statement is defined as access, or the outer VLAN tag only, when the instance-role statement is defined as nni. l2vpn—Provide support for Layer 2 VPNs. layer2-control—(MX Series routers only) Provide support for RSTP or MSTP in customer

edge interfaces of a VPLS routing instance. no-forwarding—This is the default routing instance. Do not create a corresponding

forwarding instance. virtual-router—Similar to a VPN routing and forwarding instance type, but used for

non-VPN-related applications. There are no VRF import, VRF export, VRF target, or route distinguisher requirements for this instance type. virtual-switch—(MX Series routers only) Provide support for Layer 2 bridging. Use this

routing instances type to isolate a LAN segment with its Spanning Tree Protocol (STP) instance and separates its VLAN identifier space. vpls—Virtual private local-area network (LAN) service. Use this routing instance type for

point-to-multipoint LAN implementations between a set of sites in a VPN. vrf—VPN routing and forwarding instance. Provides support for Layer 3 VPNs, where

interface routes for each instance go into the corresponding forwarding table only. Required Privilege Level



293



•


•


•

Junos OS Layer 2 Configuration Guide

•

Junos OS MX Series 3D Universal Edge Routers Solutions Guide

instance-role Syntax Hierarchy Level


instance-role (access | nni); [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced in Junos OS Release 11.2. Define the role of the routing instance in a Layer 2 Wholesale network. access—Defines the connectivity role of the routing instance in a Layer 2 Wholesale

network as an access routing instance. When defined for this role, the same process occurs as in a Layer 3 Wholesale network—when the first packet is received from a given client,, authentication for the client initiates with an external entity (for example, RADIUS). If authentication is successful, a logical interface is created with the appropriate outer and inner VLAN tags for that client. nni—Defines the connectivity role of the routing instance in a Layer 2 Wholesale network

as a network to network interface (NNI) routing instance. When defined for this role, only outer VLAN tags are learned. In addition, when the NNI routing instance receives a response from the ISP, the packets are forwarded to the appropriate client, provided the packet has the same two tags that were verified during authentication.

NOTE: If you connect an access node or MSAN device to a router participating in the Layer 2 Wholesale network in an NNI role, you must create a new routing instance of type l2backhaul-vpn with an instance role of type access for that connection.


294



•

Configuring Separate Access Routing Instances for Layer 2 Wholesale Service Retailers

•

Configuring Separate NNI Routing Instances for Layer 2 Wholesale Service Retailers

•

Junos OS Broadband Subscriber Management Solutions Guide



interface Syntax Hierarchy Level

Release Information

Description


interface interface-name; [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.2 for EX Series switches. Identify the logical, private interface between the provider edge (PE) router and the customer edge (CE) router on the PE side. interface-name—Name of the interface.


Configuring Routing Instances on page 264

•

Example: Configuring MPLS-Based Layer 3 VPNs on EX Series Switches

no-vrf-advertise Syntax Hierarchy Level

Release Information Description Required Privilege Level Related Documentation

no-vrf-advertise; [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4. Prevent advertising VPN routes from a VRF instance to remote PEs. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



295


ping-interval Syntax Hierarchy Level


Options

ping-interval; [edit logical-systems logical-system-name protocols l2circuit neighbor address interface interface-name oam], [edit logical-systems logical-system-name routing-instances instance-name protocols l2vpn oam], [edit logical-systems logical-system-name routing-instances instance-name protocols vpls neighbor address oam], [edit logical-systems logical-system-name routing-instances instance-name protocols vpls mesh-group mesh-group-name neighbor address oam], [edit logical-systems logical-system-name routing-instances instance-name protocols vpls oam], [edit protocols l2circuit neighbor address interface interface-name oam], [edit routing-instances instance-name protocols l2vpn oam], [edit routing-instances instance-name protocols vpls neighbor address oam], [edit routing-instances instance-name protocols vpls mesh-group mesh-group-name neighbor address oam], [edit routing-instances instance-name protocols vpls oam]

Statement introduced in Junos OS Release 10.0. Configure the time interval between ping messages for bidirectional forwarding detection (BFD) sessions enabled over pseudowires inside a VPN. seconds—Time interval between ping messages. Range: 30 through 3600


296


Configuring BFD for VCCV for Layer 2 VPNs, Layer 2 Circuits, and VPLS in the Junos OS VPNs Configuration Guide



protocols Syntax

Hierarchy Level

Release Information

protocols { bgp { ... bgp-configuration ... } isis { ... isis-configuration ... } ldp { ... ldp-configuration ... } msdp { ... msdp-configuration ... } mstp { ... mstp-configuration ... } ospf { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ... ospf-configuration ... } ospf3 { domain-id domain-id; domain-vpn-tag number; route-type-community (iana | vendor); ... ospf3-configuration ... } pim { ... pim-configuration ... } rip { ... rip-configuration ... } ripng { ... ripng-configuration ... } rstp { rstp-configuration; } vstp { vstp configuration; } vpls { vpls configuration; } } [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4.


297


Support for RIPng introduced in Junos OS Release 9.0. Statement introduced in Junos OS Release 11.1 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Description

Options

Specify the protocol for a routing instance. You can configure multiple instances of the following supported protocols: BGP, IS-IS, LDP, MSDP, OSPF, OSPFv3, PIM, RIP, and RIPng. Not all protocols are supported on the switches. See the switch CLI. bgp—Specify BGP as the protocol for a routing instance. isis—Specify IS-IS as the protocol for a routing instance. ldp—Specify LDP as the protocol for a routing instance. l2vpn—Specify Layer 2 VPN as the protocol for a routing instance. msdp—Specify the Multicast Source Discovery Protocol (MSDP) for a routing instance. mstp—Specify the Multiple Spanning Tree Protocol (MSTP) for a virtual switch routing

instance. ospf—Specify OSPF as the protocol for a routing instance. ospf3—Specify OSPF version 3 (OSPFv3) as the protocol for a routing instance.

NOTE: OSPFv3 supports the no-forwarding, virtual-router, and vrf routing instance types only.

pim—Specify the Protocol Independent Multicast (PIM) protocol for a routing instance. rip—Specify RIP as the protocol for a routing instance. ripng—Specify RIP next generation (RIPng) as the protocol for a routing instance. rstp—Specify the Rapid Spanning Tree Protocol (RSTP) for a virtual switch routing

instance. vstp—Specify the VLAN Spanning Tree Protocol (VSTP) for a virtual switch routing

instance. vpls—Specify VPLS as the protocol for a routing instance.

Required Privilege Level

298





•

Configuring Multiple Instances of BGP on page 250

•

Configuring Multiple Instances of IS-IS on page 251

•

Configuring Multiple Instances of LDP on page 255

•

Configuring Multiple Instances of MSDP on page 256

•


•

Configuring Multiple Instances of PIM on page 263

•

Configuring Multiple Instances of RIP on page 263

qualified-bum-pruning-mode Syntax Hierarchy Level



qualified-bum-pruning-mode; [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced in Junos OS Release 10.4. For Junos OS Layer 2 Wholesale configurations, prune (constrain) distribution of broadcast, unicast, and multicast (BUM) packets of unknown origin to only those interfaces that match the traffic from a specific VLAN pair. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


•



299


route-distinguisher Syntax Hierarchy Level

Release Information

Description

Options

route-distinguisher (as-number:number | ip-address:number); [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name], [edit routing-instances routing-instance-name], [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 11.1 for EX Series switches. Specify an identifier attached to a route, enabling you to distinguish to which VPN the route belongs. Each routing instance must have a unique route distinguisher associated with it. The route distinguisher is used to place bounds around a VPN so that the same IP address prefixes can be used in different VPNs without having them overlap. If the instance type is vrf, the route-distinguisher statement is required. as-number:number—as-number is an assigned AS number and number is any 2-byte for

4-byte value. The AS number can be from 1 through 4,294,967,295. If the AS number is a 2-byte value, the administrative number is a 4-byte value. If the AS number is 4-byte value, the administrative number is a 2-byte value. A route distinguisher consisting of a 4-byte AS number and a 2-byte administrative number is defined as a type 2 route distinguisher in RFC 4364 BGP/MPLS IP Virtual Private Networks.

NOTE: In Junos OS Release 9.1 and later, the numeric range for AS numbers is extended to provide BGP support for 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. All releases of the Junos OS support 2-byte AS numbers. To configure a route distinguisher that includes a 4-byte AS number, append the letter “L” to the end of the number. For example, a route distinguisher with the 4-byte AS number 7,765,000 and an administrative number of 1,000 is represented as 77765000L:1000. In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format.

ip-address:number—ip-address is an IP address in your assigned prefix range (a 4-byte

value) and number is any 2-byte value. Required Privilege Level

300





•

Configuring Routing Instances on PE Routers in VPNs

•

Configuring Route Distinguishers for Routing Instances on page 269

•

Configuring an MPLS-Based Layer 2 VPN (CLI Procedure)

•

Configuring an MPLS-Based Layer 3 VPN (CLI Procedure)

•

Understanding 4-Byte AS Numbers and Route Distinguishers in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview


301


routing-instances Syntax Hierarchy Level


Default Options

routing-instances routing-instance-name { ... } [edit], [edit logical-systems logical-system-name]

Statement introduced before Junos OS Release 7.4. Configure an additional routing entity for a router. You can create multiple instances of BGP, IS-IS, OSPF, OSPFv3, and RIP for a router. You can also create multiple routing instances for separating routing tables, routing policies, and interfaces for individual wholesale subscribers (retailers) in a Layer 3 wholesale network. Routing instances are disabled for the router. routing-instance-name—Name of the routing instance, a maximum of 128 characters. A

routing instance name can contain letters, numbers, and hyphens.

NOTE: In Junos OS Release 9.6 and later, you can include a slash (/) in a routing-instance name only if a logical system is not configured. That is, you cannot include the slash character in a routing-instance name if a logical system other than the default is explicitly configured.

The remaining statements are explained separately.

NOTE: In Junos OS Release 9.0 and later, you cannot specify a routing-instance name of default or include special characters within the name of a routing instance.




•

Example: Configuring E-LINE and E-LAN Services for a PBB Network on MX Series Routers

•


routing-options See

302

routing-options



vrf-export Syntax Hierarchy Level


Default


vrf-export [ policy-names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4. Define which routes are exported from a local instance table—instance-name.inet.0—to a remote PE router. Specify one or more policy names. If the instance-type is vrf, vrf-export is a required statement. The default action is to reject. policy-names—Specify one or more policy names.



vrf-import Syntax Hierarchy Level


Default


vrf-import [ policy-names ]; [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4. How routes are imported into the local PE router’s VPN routing table—instance-name.inet.0—from the remote PE router. If the instance-type is vrf, vrf-import is a required statement. The default action is to accept. policy-names—Specify one or more policy names.




303


vlan-model Syntax Hierarchy Level


vlan-model one-to-one; [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced in Junos OS Release 11.2. Define the network VLAN model. one-to-one—Specify that any received, dual-tagged VLAN packet triggers the provisioning

process in a Layer 2 Wholesale network. Using this option, the router learns VLAN tags for each individual client. The router learns both the outer tag and inner tag of the incoming packets, when the instance-role statement is defined as access, or the outer VLAN tag only, when the instance-role statement is defined as nni. Required Privilege Level Related Documentation



•

Configuring Separate Access Routing Instances for Layer 2 Wholesale Service Retailers

•


•

Junos OS Broadband Subscriber Management Solutions Guide

vrf-table-label Syntax Hierarchy Level



304

vrf-table-label; [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4. Enable mapping of the inner label of a packet to a specific VRF, thereby allowing the examination of the encapsulated IP header. All routes in the VRF configured with this option are advertised with the label allocated per VRF. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Configuring VRF Table Labels on page 283



vrf-target Syntax

Hierarchy Level


Options

vrf-target { community; import community; export community; } [edit logical-systems logical-system-name routing-instances routing-instance-name], [edit routing-instances routing-instance-name]

Statement introduced before Junos OS Release 7.4. Configure a single policy for import and a single policy for export to replace the per-VRF policies for every community. community—Community name. import—Specifies the allowed communities to accept from neighbors. export—Specifies the allowed communities to send to neighbors.





305


306


PART 4

Multitopology Routing •

Introduction to Multitopology Routing on page 309

•

Multitopology Routing Configuration Guidelines on page 313

•

Summary of Multitopology Routing Configuration Statements on page 325


307


308


CHAPTER 10

Introduction to Multitopology Routing Multitopology Routing Overview Multitopology Routing enables you to configure class-based forwarding for different types of traffic, such as voice, video, and data. Each type of traffic is defined by a topology that is used to create a new routing table for that topology. Multitopology Routing provides the ability to generate forwarding tables based on the resolved entries in the routing tables for the custom topologies you create. In this way, packets of different classes can be routed independently from one another. This chapter discusses the following topics that provide background information about Multitopology Routing: •

Routing Table Naming Conventions for Multitopology Routing on page 309

•

Routing Protocol Support for Multitopology Routing on page 310

•

Filter-Based Forwarding Support on page 310

Routing Table Naming Conventions for Multitopology Routing Each routing protocol creates a routing table based on the topology name, the instance name, and the purpose of the table. A routing table for each topology uses the following format: logical-system-name/routing-instance-name:topology-name.protocol.identifier

The routing instance string is included only if the instance is not the master. The logical system string is included only if the logical system identifier has a value other than 0 (zero). Each routing table for a topology includes a colon (:) before the topology name that also separates the routing-instance name from the topology name. protocol is the protocol family, which can be inet or inet6. identifier is a positive integer that specifies the instance of the routing table. Table 6 on page 309 shows specific examples of routing tables for various topologies.

Table 6: Examples of Routing Tables for Custom Topologies Name of Routing Table

Description

:voice.inet.0

Master instance, voice topology, unicast IPv4 routes


309


Table 6: Examples of Routing Tables for Custom Topologies (continued) Name of Routing Table

Description

:voice.inet6.0

Master instance, voice topology, unicast IPv6 routes

:voice.inet.3

Master instance, voice topology, ingress label-switched paths (LSPs)

private_1/:voice.inet.0

Logical system private, voice topology, unicast IPv4 routes

customer-A:voice.inet.0

Virtual-router customer-A, voice topology, unicast IPV4 routes

customer-B:voice.inet.3

Virtual-router customer-B, voice topology, ingress LSPs

customer-A:voice.mpls.0

Virtual-router customer-A, voice topology, unicast carrier-of-carriers IPV4 routes

Routing Protocol Support for Multitopology Routing To run Multitopology Routing, you must configure IP routing. Multitopology Routing supports OSPF version 2 (OSPFv2), static routes, and BGP. You must configure an interior gateway protocol (IGP), such as OSPFv2 or static routing. Configure BGP to add routes learned through BGP to the appropriate custom topologies. OSPF in Multitopology Routing uses a single instance of OSPF to carry connectivity and IP reachability information for different topologies. That information is used to calculate shortest-path-first (SPF) trees and routing tables. OSPF in Multitopology Routing supports protocol extensions that include metrics that correspond to different topologies for link and prefix reachability information. The type-of-service (TOS) metric field is used to advertise the topology-specific metric for links and prefixes belonging to that topology. The TOS field is redefined as MT-ID in the payload of router, summary, and Type 5 and Type 7 autonomous-system-external link-state advertisements (LSAs). BGP in Multitopology Routing provides the ability to resolve BGP routes against configured topologies. An inbound policy is used to select routes for inclusion in the appropriate routing tables for the topologies.

NOTE: Multitopology Routing is also supported on logical systems and the virtual router routing instance. No other routing instance type is supported on Multitopology Routing. For more information about configuring routing instances see, “Complete Routing Instances Configuration Statements” on page 240. For more information about configure a virtual router instance, see the Junos OS VPNs Configuration Guide.

Filter-Based Forwarding Support By default, the ingress interface forwards traffic to the default topology for each configured routing instance. Multitopology Routing supports filter-based forwarding,

310


Chapter 10: Introduction to Multitopology Routing

which enables you to match traffic on the ingress interface with a specific type of forwarding class and then forward that traffic to the specified topology. You can further define how traffic is handled for each forwarding class by configuring additional firewall filters that match traffic for such values as the IP precedence field or the Differentiated Services code point (DSCP).

Multitopology Routing Standards Multitopology Routing is defined in the following document: •

RFC 4915, Multi-Topology (MT) Routing in OSPF


311


312


CHAPTER 11

Multitopology Routing Configuration Guidelines This chapter discusses the following tasks for configuring Multitopology Routing (MTR). •

Configuring Topologies on page 313

•

Configuring Multitopology Routing in OSPF on page 314

•

Configuring Multitopology Routing in Static Routes on page 320

•

Configuring Multitopology Routing in BGP on page 321

•

BGP Route Resolution in Multitopology Routing on page 321

•

Configuring Filter-Based Forwarding for Multitopology Routing on page 321

Configuring Topologies For Multitopology Routing to run on the router, you need to configure one or more topologies. For each topology, you specify a string value, such as voice, that defines the type of traffic, as well as an interface family, such as IPv4. In addition, a default topology is automatically created. You can also enable a topology for IPv4 multicast traffic. Each topology that you configure creates a new routing table and populates it with direct routes from the topology. For more information about the naming conventions for routing tables for topologies, see “Routing Table Naming Conventions for Multitopology Routing” on page 309. To configure a custom topology, include the following statements at the [edit routing options] hierarchy level: [edit routing-options] topologies { family (inet | inet6) { topology topology-name; } }

Include the family inet statement to specify IPv4 traffic. Include the family inet6 statement to specify IPv6 traffic. Include the topology topology-name statement to create a topology. For topology-name, specify a name for the topology in the form of a string. Typically, you would specify a name that describes the type of traffic, such as video. You can also specify ipv4-multicast


313


to create a topology for IPv4 multicast traffic. A default topology is also automatically created.

Configuring Multitopology Routing in OSPF Multitopology Routing OSPF (MT-OSPF) enables you to define multiple topologies and to configure topology-specific metrics for individual links as well as to exclude individual links from specific topologies. As a result, you can use a single instance of OSPF to carry connectivity and IP reachability information for different topologies. Information for different topologies is used to calculate independent shortest-path-first (SPF) trees and routing tables. For information about configuration tasks for MT-OSPF, see the following sections: •

Configuring Topologies and SPF Options for MT-OSPF on page 314

•

Configuring a Prefix Export Limit for MT-OSPF on page 316

•

Configuring a Topology to Appear Overloaded on page 316

•

Configuring Interface Properties for MT-OSPF on page 316

•

Disabling MT-OSPF on OSPF Interfaces on page 317

•

Disabling MT-OSPF on Virtual Links on page 317

•

Advertising MPLS Label-Switched Paths into MT-OSPF on page 318

•

Configuring Other MT-OSPF Properties on page 319

Configuring Topologies and SPF Options for MT-OSPF Include the following statements to enable topologies for OSPF and to configure topology identifiers. Any topologies you enable for OSPF must first be created under the [edit routing-options] hierarchy level. The routes for each topology are added to the routing table for the topology. For more information about the naming conventions for routing tables for topologies, see “Routing Table Naming Conventions for Multitopology Routing” on page 309. The default topology is automatically created and has a topology identifier of 0 (zero), which cannot be modified. The routes that correspond to the default topology are added to the inet.0 routing table. You can, however, modify other parameters, such as shortest-path first (SPF) options. In addition, you can specify a topology for IPv4 multicast traffic. The topology for IPv4 multicast has a topology identifier of 1, which you cannot modify. The routes corresponding to this topology are added to the inet.2 routing table. You can also configure SPF options for each topology that override the default or globally configured SPF values. Include the following statements to configure a topology for OSPF and SPF options for the topology at the [edit protocols ospf] hierarchy level: [edit protocols ospf] topology (default | ipv4-multicast | name) { topology-id number; spf-options { delay milliseconds; holddown milliseconds; rapid-runs number; }

314


Chapter 11: Multitopology Routing Configuration Guidelines

}

For name, include the name of a topology that you configured under the [edit routing-options] hierarchy level to create the topology. Use ipv4-multicast for IPv4 multicast traffic. You must first enable this topology under the [edit routing-options] hierarchy level. topology-id number is the topology identifier. The range for topology-id number is from 32

through 127 for any topology you create, except for the default and IPv4 multicast topologies. The identifier for those topologies is predefined and cannot be modified.

NOTE: Multitopology Routing is not currently supported for OSPF version 3 (OSPFv3).

You can configure SPF options for each topology. The values you configure for each of the following options override the default or globally configured values. •

The delay in the time between the detection of a topology change and when the SPF algorithm actually runs

•

The maximum number of times that the SPF algorithm can run in succession before the hold-down timer begins

•

The time to hold down, or wait, before running another SPF calculation after the SPF algorithm has run in succession the configured maximum number of times

To configure the SPF delay, include the delay statement when specifying the spf-options statement: delay milliseconds;

By default, the SPF algorithm runs 200 milliseconds after the detection of a topology change. The range that you can configure is from 50 through 8000 milliseconds. To configure the maximum number of times that the SPF algorithm can run in succession, include the rapid-runs statement when specifying the spf-options statement: rapid-runs number;

The default number of SPF calculations that can occur in succession is 3. The range that you can configure is from 1 through 5. Each SPF algorithm is run after the configured SPF delay. When the maximum number of SPF calculations occurs, the hold-down timer begins. Any subsequent SPF calculation is not run until the hold-down timer expires. To configure the SPF hold-down timer, include the holddown statement when specifying the spf-options statement: holddown milliseconds;

The default is 5000 milliseconds, and the range that you can configure is from 2000 through 20,000 milliseconds. Use the hold-down timer to hold down, or wait, before running any subsequent SPF calculations after the SPF algorithm runs for the configured


315


maximum number of times. If the network stabilizes during the hold-down period and the SPF algorithm does not need to run again, the system reverts to the configured values for the delay and rapid-runs statements.

Configuring a Prefix Export Limit for MT-OSPF By default, each topology uses the globally configured value to determine the maximum number of prefixes that can be exported into OSPF. You can override the globally configured value for any configured topology. Include the prefix-export-limit number statement at the [edit protocols ospf topology name] hierarchy level: [edit protocols ospf] topology (default | ipv4-multicast | name) { prefix-export-limit number; }

The number that you can configure for each topology is from 0 through 4,294,967,295.

Configuring a Topology to Appear Overloaded You can configure a specific topology so that it appears to be overloaded. You might do this when you want the topology to participate in OSPF routing but do not want it to be used for transit traffic. To mark a topology as overloaded, include the overload statement: [edit protocols ospf] topology (default | ipv4-multicast | name) { overload; }

Configuring Interface Properties for MT-OSPF The default value of the topology metric is the same as the default metric value calculated by OSPF or the value configured for the OSPF metric. You can configure a topology-specific metric for an OSPF interface. To configure interfaces for MT-OSPF, include the following statements at the [edit protocols ospf area area-id] hierarchy level: interface interface-name { metric metric; topology (ipv4-multicast | name); metric metric; } }

All OSPF interfaces have a cost, which is a routing metric that is used in the link-state calculation. Routes with lower total path metrics are preferred over those with higher path metrics. The default value for the OSPF metric for an interface is 1. You can modify the default value for an OSPF interface and configure a topology-specific metric for that interface. The topology-specific metric applies to routes advertised from the interface that belong only to that topology. The range that you can configure is from 1 through 65,535. You can also configure any interface that belongs to one or more topologies to advertise the direct interface addresses without actually running OSPF on that interface. By default,

316



OSPF must be configured on an interface in order for direct interface addresses to be advertised as interior routes. Include the passive statement at the [edit protocols ospf area area-id interface interface-name] hierarchy level: [edit protocols ospf] area area-id { interface interface-name { passive; topology name; } }

NOTE: If you configure an interface with the passive statement, it applies to all the topologies to which the interface belongs. You cannot configure an interface as passive for only one specific topology and have it remain active for any other topologies to which it belongs.

Disabling MT-OSPF on OSPF Interfaces By default, all topologies configured for OSPF are enabled on all OSPF interfaces. You can disable one or more configured topologies on an OSPF interface. To disable a configured topology on an OSPF interface, include the disable statement at the [edit protocols ospf area area-id interface interface-name topology name] hierarchy level: [edit protocols ospf] area area-id { interface interface-name { topology (ipv4-multicast | name) { disable; } } }

You cannot disable an interface in the default topology and have it remain active in any other configured topologies.

NOTE: If you disable OSPF on an interface by including the disable statement at the [edit protocols ospf area area-id interface interface-name] hierarchy level, the interface is disabled for all topologies, including the default topology.

Disabling MT-OSPF on Virtual Links By default, control packets sent to the remote end of a virtual link must be forwarded using the default topology. In addition, the transit area path consists only of links that are in the default topology. You can disable a virtual link for a configured topology, but not for a default topology. Include the disable statement at the [edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-id topology name] hierarchy level: [edit protocols ospf] area area-id {


317


virtual-link neighbor-id router-id transit-area area-id { topology (ipv4-multicast | name) { disable; } } }

NOTE: If you disable the virtual link by including the disable statement at the [edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-id] hierarchy level, you disable the virtual link for all topologies, including

the default topology. You cannot disable the virtual link only in the default topology.

Advertising MPLS Label-Switched Paths into MT-OSPF You can advertise label-switched paths (LSPs) into OSPFv2 as point-to-point links so that all participating routers can take the LSP into account when performing SPF calculations. By default, all topologies configured for OSPF are enabled on all MPLS LSPs advertised into OSPF. You can override this behavior by disabling one or more configured topologies on an MPLS LSP. The LSP advertisement contains a local address (the from address of the LSP), a remote address (the to address of the LSP), and a metric with the following precedence: 1.

Use the LSP metric defined under OSPFv2.

2. Use the LSP metric configured under MPLS. 3. If you do not configure any of the above, use the default OSPFv2 metric of 1.

In addition, the default value of the topology-specific metric is the same as the default metric calculated by OSPF or configured for the MPLS LSPs. You can also override this value by configuring a specific metric for the topology. For more information about configuring a topology-specific metric, see “Configuring Topologies” on page 313. To disable a topology on LSPs and configure a label-switched path metric for OSPFv2, include the following statements at the [edit protocols ospf] hierarchy level: [edit protocols ospf] area area-id { label-switched-path name; metric metric; topology (ipv4-multicast | name) { disable; } } }

NOTE: You cannot disable an MPLS LSP in the default topology only and have it remain enabled in other topologies.

318



For more information about advertising LSPs, see the Junos OS MPLS Applications Configuration Guide.

Configuring Other MT-OSPF Properties You can also configure the following properties for all topologies in an instance. You cannot configure the following properties for an individual topology: •

Disable not-so-stubby area (NSSA) support on an autonomous-system border router (ASBR)

•

Modify the preference value for OSPF internal routes

•

Modify the default preference value for OSPF external routes

•

Modify the reference-bandwidth value

•

Enable graceful restart

To disable exporting Type 7 LSAs into LSAs, include the no-nssa-abr statement. For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. [edit protocols ospf] no-nssa-abr;

By default, internal OSPF routes have a preference value of 10, and external OSPF routes have a preference value of 150. To modify the preference values for all topologies, include the preference statement (for internal routes) or the external-preference statement (for external routes): [edit protocols ospf] external-preference preference; preference preference;

For a complete list of hierarchy levels at which you can configure these statements, see the statement summary sections for these statements. You can configure a preference value of from 0 through 255 for each statement. The reference bandwidth is used to calculate the default cost of a route using the following formula: cost = reference-bandwidth / bandwidth

The default value for the reference bandwidth is 100 Mbps (which you specify as 100,000,000), which gives a metric of 1 for any bandwidth that is 100 Mbps or greater. To modify the default value, include the reference-bandwidth statement: [edit protocols ospf] reference-bandwidth;

The range that you can specify is from 9,600 through 1,000,000,000,000. For a complete list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement.


319


NOTE: You can specify topology-specific metrics for routes advertised from an interface. For more information, see “Configuring Topologies” on page 313.

Graceful restart enables a restarting router and its neighbors to continue forwarding packets without disrupting network performance. Because neighboring routers assist in the restart (these neighbors are called helper routers), the restarting router can quickly resume full operation without recalculating algorithms. Graceful restart is disabled by default. You can globally configure graceful restart for all routing protocols at the [edit routing-options] hierarchy level. To configure graceful restart parameters specifically for OSPF, include the graceful-restart statement at the [edit protocols ospf] hierarchy level. Related Documentation

•


Configuring Multitopology Routing in Static Routes You can configure static routes to become installed in the routing table for any configured topology. Include the rib routing-table-name statement at the [edit routing-options] hierarchy level: [edit routing-options] rib routing-table-name { static { route destination-prefix { next-hop; } static-options; } } }

For routing-table-name, use the following format: logical-system-name/routing-instance-name:topology-name.protocol.identifier. The routing

instance string is included only if the instance is not the master. The logical system string is included only if the logical system identifier has a value other than 0 (zero). Each routing table for a topology includes a colon (:) before the topology name that also separates the routing instance name from the topology name. protocol is the protocol family, which can be inet or inet6. identifier is a positive integer that specifies the instance of the routing table. When you create a topology for an instance (master or virtual-router), a new routing table is created within the instance for that topology. For more detailed information about routing table naming conventions for Multitopology Routing, see “Routing Table Naming Conventions for Multitopology Routing” on page 309. For route destination-prefix, specify the destination of the route in the following way: network/mask-length, where network is the network portion of the IP address and mask-length is the destination prefix length. You can specify an IPv4 or IPv6 address.

320



You can optionally specify how to reach the destination by including the next-hop statement. In addition, you can specify static-options, which defines additional information about static routes that is included with the route when it is installed in the routing table. For more information about specific static options you can optionally configure, see “Configuring Static Route Options” on page 71.

Configuring Multitopology Routing in BGP Multitopology Routing in BGP enables you to configure a community target identifier for each type of traffic, or topology. The target community identifies the destination to which the route is going. BGP uses these community target identifiers to have routes imported into the routing tables for the specific topologies. The forwarding class then determines which table to use to forward traffic. To configure Multitopology Routing in BGP, include the community target identifier statement at the [edit protocols bgp family (inet | inet6) unicast topology name] hierarchy level: [edit protocols bgp] family (inet | inet6) { unicast { topology name { community target identifier; } } }

Multitopology Routing in BGP is also supported for BGP groups and BGP peers. To configure for a BGP group, include the family (inet | inet6) unicast topology name community target identifier statement at the [edit protocols bgp group group-name] hierarchy level. To configure for a BGP peer, include the family (inet | inet6) unicast topology name community target identifier statement at the [edit protocols bgp group group-name neighbor address] hierarchy level.

BGP Route Resolution in Multitopology Routing The default behavior is for the Junos OS to resolve BGP routes against the inet.0 and inet.3 routing tables. By default, the secondary route points to the next hop of the primary BGP route. This means that under the default behavior, BGP cannot perform secondary route resolution. Multitopology Routing in BGP provides support for secondary routes to resolve to an independent set of next hops. When Multitopology Routing in BGP resolves a route against the inet.0 routing table, a forwarding state is generated to match the topologies for which you configured a BGP import policy.

Configuring Filter-Based Forwarding for Multitopology Routing Each routing instance (master or virtual-router) supports one default topology to which all forwarding classes are forwarded. For Multitopology Routing, you can configure a


321


firewall filter on the ingress interface to match a specific forwarding class, such as expedited forwarding, with a specific topology. The traffic that matches the specified forwarding class is then added to the routing table for that topology. To configure filter-based forwarding for Multitopology Routing, include the following statements at the [edit firewall] hierarchy level: [edit firewall] family (inet | inet6) { filter filter-name { term term-name { from { forwarding-class (assured-forwarding | best-effort | expedited-forwarding | network-control) } then { (topology topology-name | routing-instance routing-instance-name topology topology-name | logical-system logical-system-name topology topology-name | logical-system logical-system-name routing-instance routing-instance-name topology topology-name); } } } }

To configure the family address type, specify family inet to filter IPv4 packets or family inet6 to filter IPv6 packets. To configure the filter name, include the filter filter-name statement. The filter name can contain letters, numbers, and hyphens (-) and can be up to 64 characters long. To include spaces in the name, enclose the entire name in quotation marks (“ ”). Each filter consists of one or more terms. To configure a term, include the term term-name statement. The term name can contain letters, numbers, and hyphens (-) and can be up to 255 characters long. To include spaces in the name, enclose the entire name in quotation marks (“ ”). Each term name must be unique within a filter. Include the forwarding-class class statement to define the forwarding class against which to match the incoming packets. You can configure the following types of forwarding classes: assured-forwarding, expedited-forwarding, best-effort, and network-control. You can specify multiple terms in a filter, effectively chaining together a series of match-action operations to apply to the packets on an interface. Firewall filter terms are evaluated in the order in which you specify them in the configuration. To reorder terms, use the configuration mode insert command. For example, the command insert term up before term start places the term up before the term start. Use the topology statement to specify that packets that match the specified forwarding class be directed to the specified topology. For a topology in the master instance, include the topology name statement, where name is the name of the topology.

322



For a topology in a nonmaster instance, include the routing-instance routing-instance-name topology topology-name statement, where routing-instance-name is the name of the routing instance and topology-name is the name of the topology. For a topology in a nonmaster logical system, include the logical-system logical-system-name topology topology-name statement, where logical-system-name is the name of the logical system and topology-name is the name of the topology. For a topology in a nonmaster instance within a nonmaster logical system, include the logical-system logical-system-name routing-instance routing-instance-name topology topology-name statement, where logical-system-name is the name of the logical system, routing-instance-name is the name of the routing instance configured within the logical

system, and topology-name is the name of the topology. You must apply the filter to an ingress interface. Include the following statements to apply the filter to an interface: [edit interfaces interface-name] unit number { family (inet | inet6) { filter { input filter-name { } } }


•



323


324


CHAPTER 12

Summary of Multitopology Routing Configuration Statements The following sections explain each of the Multitopology Routing configuration statements. They are organized alphabetically.


325


community Syntax

Hierarchy Level



326

community { target identifier; } [edit logical-systems logical-system-name protocols bgp family (inet | inet6) unicast topology name], [edit logical-systems logical-system-name protocols bgp group group-name family (inet | inet6) unicast topology name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family (inet | inet6) unicast topology name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family (inet | inet6) unicast topology name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family (inet | inet6) unicast topology name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet6) unicast topology name], [edit protocols bgp family (inet | inet6) unicast topology name], [edit protocols bgp group group-name family (inet | inet6) unicast topology name], [edit protocols bgp group group-name neighbor address family (inet | inet6) unicast topology name], [edit routing-instances routing-instance-name protocols bgp family (inet | inet6) unicast topology name], [edit routing-instances routing-instance-name protocols bgp group group-name family (inet | inet6) unicast topology name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet6) topology name]

Statement introduced in Junos OS Release 9.0. Configure the community to identify the multitopology routes. BGP uses the target community identifier to install the routes it learns in the appropriate Multitopology Routing tables. target identifier—Configure the destination to which the route is going.


Configuring Multitopology Routing in BGP on page 321


Chapter 12: Summary of Multitopology Routing Configuration Statements

rib Syntax

Hierarchy Level

rib routing-table-name { static { route destination-prefix { next-hop; } static-options; } } [edit logical-systems logical-system-name routing-options], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Release Information

Statement support for Multitopology Routing introduced in Junos OS Release 9.0. Statement introduced in Junos OS Release 9.0 for EX Series switches.

Description

Configure a static route to install routes in the routing table for a specific topology.

Options

routing-table-name—Name of the routing table for a topology. Use the following format: logical-system-name/routing-instance-name:topology-name.protocol.identifier. Include

the routing instance string only if the instance is not the master. The logical system string is included only if the logical system identifier has a value other than 0 (zero). Each routing table for a topology includes a colon (:) before the topology name. protocol is the protocol family, which can be inet or inet6. identifier is the positive integer that specifies the instance of the routing table. For example, to install IPv6 routes to the routing table for a topology named voice in the master instance, include :voice.inet6.0. The remaining statements are explained separately. Required Privilege Level Related Documentation


static on page 223

•

Configuring Multitopology Routing in Static Routes on page 320


327


topologies Syntax

Hierarchy Level


Options

topologies { family (inet | inet6) { topology topology-name; } } [edit logical-systems logical-system-name routing-options], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], [edit routing-instances routing-instance-name routing-options], [edit routing-options]

Statement introduced in Junos OS Release 9.0. Configure a topology for Multitopology Routing. Each topology creates a new routing table that is populated with direct routes from the topology. family—Configure the type of family address type. inet—IPv4 inet6—IPv6


328


topology on page 331

•




topology •

topology (Filter-Based Forwarding) on page 330

•

topology (Multitopology Routing) on page 331

•

topology (OSPF) on page 332

•

topology (OSPF Interface) on page 333


329


topology (Filter-Based Forwarding) Syntax Hierarchy Level


topology topology-name; [edit firewall family (inet | inet6) filter filter-name term term-name then], [edit firewall family (inet | inet6) filter filter-name term term-name then logical-system logical-system-name], [edit firewall family (inet | inet6) filter filter-name term term-name then logical-system logical-system-name routing-instance routing-instance-name], [edit firewall family (inet | inet6) filter filter-name term term-name then routing-instance routing-instance-name]

Statement introduced in Junos OS Release 9.0. Configure a topology for filter-based forwarding for Multitopology Routing. The firewall filter you apply to the ingress interface is used to look up traffic against the configured topology, and, if a route matches the conditions you configure for the term, the route is accepted and added to the to the routing table for the specific topology. There are multiple ways to configure a topology for filter-based forwarding, depending on the type of instance or logical system you want to specify for the forwarding class. See Options for more information.

NOTE: The options for logical system and routing instance precede the topology statement with the then statement.

Options

topology-name—Name of a topology against which you want to match traffic. logical-system logical-system-name topology topology-name—For a nonmaster logical

system, specify the name of the logical system and a topology name configured for a nonmaster logical system. routing-instance routing-instance-name topology topology-name—For a nonmaster routing

instance, specify the name of the routing instance and a topology name configured for a nonmaster routing instance. logical-system logical-system-name routing-instance routing-instance-name topology topology-name—For a nonmaster routing instance configured within a nonmaster

logical system, specify the name of the logical system, the name of the routing instance, and a topology name configured for a nonmaster routing instance within a nonmaster logical system. Required Privilege Level Related Documentation

330


Configuring Filter-Based Forwarding for Multitopology Routing on page 321

•




topology (Multitopology Routing) Syntax Hierarchy Level


topology topology-name; [edit logical-systems logical-system-name routing-options topologies family (inet | inet6)], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options topologies family (inet | inet6)], [edit routing-instances routing-instance-name routing-options topologies family (inet | inet6)], [edit routing-options topologies family (inet | inet6)]

Statement introduced in Junos OS Release 9.0. Configure the name of a topology configured to run Multitopology Routing. topology-name—Name of the topology. Include a string value that describes the type of

traffic, such as voice or video. For IPv4 multicast traffic, include ipv4-multicast as the name. Required Privilege Level Related Documentation


topologies on page 328

•



331


topology (OSPF) Syntax

Hierarchy Level

Release Information

Description

Options

topology (default | ipv4-multicast | name) { topology-id number; spf-options { delay milliseconds; holddown milliseconds; rapid-runs number; } } [edit logical-systems logical-system-name protocols ospf], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf], [edit protocols ospf], [edit routing-instances routing-instance-name protocols ospf]

Statement introduced in Junos OS Release 9.0. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable a topology for OSPF Multitopology Routing. You must first configure one or more topologies under the [edit routing-options] hierarchy level. default—Name of the default topology. This topology is automatically created and all

routes that correspond to it are automatically added to the inet.0 routing table. You can modify certain default parameters, such as for the shortest-path-first (SPF) algorithm. ipv4-multicast—Name of the topology for IPv4 multicast traffic. name—Name of a topology you configured at the [edit routing-options] hierarchy level

to create a topology for a specific type of traffic, such as voice or video. Required Privilege Level Related Documentation

332





topology (OSPF Interface) Syntax

Hierarchy Level

Release Information

topology (ipv4-multicast | name) { metric metric; } [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name]


Description

Configure interface-specific properties for MT-OSPF, including topology-specific metric values for an interface.

Default

The default value of the topology metric is the same as the default metric value calculated by OSPF or the value configured for the OSPF metric.

Options

ipv4-multicast—Name of the topology for IPv4 multicast traffic. name—Name of a topology created under the [edit routing-options] hierarchy level. metric metric—Cost of a route from an OSPF interface. You can specify a metric value

for a topology that is different from the value specified for the interface. Range: 1 through 65,535 Default: 1 Required Privilege Level Related Documentation




333


topology-id Syntax Hierarchy Level

Release Information Description Default

Options

topology-id number; [edit logical-systems logical-system-name protocols ospf topology name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf topology name], [edit protocols ospf topology name], [edit routing-instances routing-instance-name protocols ospf topology name]

Statement introduced in Junos OS Release 9.0. Configure a topology identifier for a topology enabled for OSPF. The default identifier for the default topology is 0, and the default identifier for the topology for IPv4 multicast traffic is 1. These identifiers are predefined and cannot be modified. number—the integer value used to identify the topology.


334


topology on page 332

•



PART 5

Interior Gateway Protocols •

Introduction to IS-IS on page 337

•

IS-IS Configuration Guidelines on page 343

•

Summary of IS-IS Configuration Statements on page 433

•

Introduction to OSPF on page 493

•

OSPF Configuration Guidelines on page 507

•

Summary of OSPF Configuration Statements on page 749

•

Introduction to RIP on page 835

•

RIP Configuration Guidelines on page 839

•

Summary of RIP Configuration Statements on page 867

•

Introduction to RIPng on page 893

•

RIPng Configuration Guidelines on page 895

•

Summary of RIPng Configuration Statements on page 905

•

Introduction to ICMP Router Discovery on page 921

•

ICMP Router Discovery Configuration Guidelines on page 923

•

Summary of ICMP Router Discovery Configuration Statements on page 927

•

Introduction to Neighbor Discovery on page 939

•

Neighbor Discovery Configuration Guidelines on page 941

•

Summary of Neighbor Discovery Router Advertisement Configuration Statements on page 949

•

Secure Neighbor Discovery Configuration Guidelines on page 961

•

Summary of Secure Neighbor Discovery Configuration Statements on page 965


335


336


CHAPTER 13

Introduction to IS-IS This chapter discusses the following topics that provide background information about IS-IS: •

IS-IS Overview on page 337

•

IS-IS Extensions to Support Traffic Engineering on page 339

•

IS-IS Extensions to Support Route Tagging on page 340

•

IS-IS Standards on page 340

IS-IS Overview IS-IS protocol is an interior gateway protocol (IGP) that uses link-state information to make routing decisions. IS-IS is a link-state IGP that uses the shortest path first (SPF) algorithm to determine routes. IS-IS evaluates the topology changes and determines whether to perform a full SPF recalculation or a partial route calculation (PRC). This protocol originally was developed for routing International Organization for Standardization (ISO) Connectionless Network Protocol (CLNP) packets.

NOTE: Because IS-IS uses ISO addresses, the configuration of IP version 6 (IPv6) and IP version 4 (IPv4) implementations of IS-IS is identical.


IS-IS Terminology on page 337

•

ISO Network Addresses on page 338

•

IS-IS Packets on page 339

•

Persistent Route Reachability on page 339

IS-IS Terminology An IS-IS network is a single autonomous system (AS), also called a routing domain, that consists of end systems and intermediate systems. End systems are network entities that send and receive packets. Intermediate systems send and receive packets and relay


337


(forward) packets. (Intermediate system is the Open System Interconnection [OSI] term for a router.) ISO packets are called network protocol data units (PDUs). In IS-IS, a single AS can be divided into smaller groups called areas. Routing between areas is organized hierarchically, allowing a domain to be administratively divided into smaller areas. This organization is accomplished by configuring Level 1 and Level 2 intermediate systems. Level 1 systems route within an area; when the destination is outside an area, they route toward a Level 2 system. Level 2 intermediate systems route between areas and toward other ASs.

ISO Network Addresses IS-IS uses ISO network addresses. Each address identifies a point of connection to the network, such as a router interface, and is called a network service access point (NSAP). IS-IS supports multiple NSAP addresses on the loopback (lo0) interface. An end system can have multiple NSAP addresses, in which case the addresses differ only by the last byte (called the n-selector). Each NSAP represents a service that is available at that node. In addition to having multiple services, a single node can belong to multiple areas. Each network entity also has a special network address called a network entity title (NET). Structurally, an NET is identical to an NSAP address but has an n-selector of 00. Most end systems and intermediate systems have one NET. Intermediate systems that participate in multiple areas can have multiple NETs. The following ISO addresses illustrate the IS-IS address format: 49.0001.00a0.c96b.c490.00 49.0001.2081.9716.9018.00

The first portion of the address is the area number, which is a variable number from 1 through 13 bytes. The first byte of the area number (49) is the authority and format indicator (AFI). The next bytes are the assigned domain (area) identifier, which can be from 0 through 12 bytes. In the examples above, the area identifier is 0001. The next six bytes form the system identifier. The system identifier can be any six bytes that are unique throughout the entire domain. The system identifier commonly is the media access control (MAC) address (as in the first example, 00a0.c96b.c490) or the IP address expressed in binary-coded decimal (BCD) (as in the second example, 2081.9716.9018, which corresponds to IP address 208.197.169.18). The last byte (00) is the n-selector.

NOTE: The system identifier cannot be 0000.0000.0000. All 0s is an illegal setting and the adjacency is not formed with this setting.

To provide help with IS-IS debugging, the Junos OS supports dynamic mapping of ISO system identifiers to the hostname. Each system can be configured with a hostname, which allows the system identifier-to-hostname mapping to be carried in a dynamic hostname type length value (TLV) in IS-IS link-state protocol data units (LSPs). This

338


Chapter 13: Introduction to IS-IS

permits ISs in the routing domain to learn about the ISO system identifier of a particular IS.

IS-IS Packets IS-IS uses the following protocol data units (PDUs) to exchange protocol information: •

IS-IS hello (IIH) PDUs—Broadcast to discover the identity of neighboring IS-IS systems and to determine whether the neighbors are Level 1 or Level 2 intermediate systems.

•

Link-state PDUs —Contain information about the state of adjacencies to neighboring IS-IS systems. Link-state PDUs are flooded periodically throughout an area.

•

Complete sequence number PDUs (CSNPs)—Contain a complete list of all link-state PDUs in the IS-IS database. CSNPs are sent periodically on all links, and the receiving systems use the information in the CSNP to update and synchronize their link-state PDU databases. The designated router multicasts CSNPs on broadcast links in place of sending explicit acknowledgments for each link-state PDU .

•

Partial sequence number PDUs (PSNPs)—Multicast by a receiver when it detects that it is missing an link-state PDU; that is, when its link-state PDU database is out of date. The receiver sends a PSNP to the system that transmitted the CSNP, effectively requesting that the missing link-state PDU be transmitted. That router, in turn, forwards the missing link-state PDU to the requesting router.

Persistent Route Reachability IPv4 and IPv6 route reachability information in IS-IS link-state PDUs is preserved when you commit a configuration. IP prefixes are preserved to their original packet fragment upon LSP regeneration.

IS-IS Extensions to Support Traffic Engineering To help provide traffic engineering and MPLS with information about network topology and loading, extensions have been added to the Junos OS implementation of IS-IS. Specifically, IS-IS supports new TLVs that specify link attributes. These TLVs are included in the IS-IS link-state PDUs. The link-attribute information is used to populate the traffic engineering database, which is used by the Constrained Shortest Path First (CSPF) algorithm to compute the paths that MPLS LSPs take. This path information is used by RSVP to set up LSPs and reserve bandwidth for them.

NOTE: Whenever possible, use IS-IS IGP shortcuts instead of traffic engineering shortcuts.

The traffic engineering extensions are defined in Internet draft draft-isis-traffic-traffic-02, IS-IS Extensions for Traffic Engineering.

IS-IS IGP Shortcuts In IS-IS, you can configure shortcuts, which allow IS-IS to use an LSP as the next hop as if it were a subinterface from the ingress routing device to the egress routing device. The


339


address specified on the to statement at the [edit protocols mpls label-switched-path lsp-path-name] hierarchy level must match the router ID of the egress routing device for the LSP to function as a direct link to the egress routing device and to be used as input to IS-IS SPF calculations. When used in this way, LSPs are no different than Asynchronous Transfer Mode (ATM) and Frame Relay virtual circuits (VCs), except that LSPs carry only IPv4 traffic.

IS-IS Extensions to Support Route Tagging To control the transmission of routes into IS-IS, or to control transmission of IS-IS routes between different IS-IS levels, you can tag routes with certain attributes. IS-IS routes can carry these attributes, which the routing policies can use to export and import routes between different IS-IS levels. A sub-TLV to the IP prefix TLV is used to carry the tag or attribute on the routes.

NOTE: Route tagging does not work when IS-IS traffic engineering is disabled.

IS-IS Standards IS-IS is defined in the following documents:

340

•

ISO 8473, Protocol for providing the connectionless-mode network services

•

ISO 9542, End System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for the Provision of the Connectionless-mode Network Service

•

ISO 10589, Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for the Provision of the Connectionless-mode Network Service

•

RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual Environments

•

RFC 2973, IS-IS Mesh Groups

•

RFC 3787, Recommendations for Interoperable IP Networks Using Intermediate System to Intermediate System (IS-IS)

•

RFC 5120, M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)

•

RFC 5130, A Policy Control Mechanism in IS-IS Using Administrative Tags

•

RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates

•

RFC 5301, Dynamic Hostname Exchange Mechanism for IS-IS

•

RFC 5302, Domain-wide Prefix Distribution with Two-Level IS-IS

•

RFC 5303, Three-Way Handshake for IS-IS Point-to-Point Adjacencies

•

RFC 5304, IS-IS Cryptographic Authentication

•

RFC 5305, IS-IS Extensions for Traffic Engineering


Chapter 13: Introduction to IS-IS

•

RFC 5306, Restart Signaling for IS-IS

•

RFC 5307, IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)

•

RFC 5308, Routing IPv6 with IS-IS

•

RFC 5309, Point-to-Point Operation over LAN in Link State Routing Protocols

•

Internet draft draft-ietf-bfd-base-09.txt, Bidirectional Forwarding Detection (except for the transmission of echo packets)

•

Internet draft draft-ietf-isis-wg-255adj-02.txt, Maintaining more than 255 circuits in IS-IS

To access Internet RFCs and drafts, go to the Internet Engineering Task Force (IETF) Web site at http://www.ietf.org.


341


342


CHAPTER 14

IS-IS Configuration Guidelines This chapter discusses the following topics that provide information about configuring IS-IS: •

Configuring IS-IS on page 344

•

Minimum IS-IS Configuration on page 347

•

Configuring IS-IS Authentication on page 347

•

Hitless Authentication Key Rollover for IS-IS on page 349

•

Configuring of Interface-Specific IS-IS Properties on page 355

•

Configuring BFD for IS-IS on page 356

•

Overview of BFD Authentication for IS-IS on page 364

•

Configuring BFD Authentication for IS-IS on page 366

•

Enabling Packet Checksum on IS-IS Interfaces on page 369

•

Configuring the Transmission Frequency for CSNP Packets on IS-IS Interfaces on page 369

•

Configuring Synchronization Between LDP and IS-IS on page 369

•

Configuring the Transmission Frequency for Link-State PDUs on IS-IS Interfaces on page 370

•

Configuring Mesh Groups of IS-IS Interfaces on page 370

•

Configuring IS-IS Multicast Topology on page 371

•

Configuring IS-IS IPv6 Unicast Topologies on page 387

•

Configuring Point-to-Point Interfaces for IS-IS on page 387

•

Configuring Levels on IS-IS Interfaces on page 388

•

Configuring the Reference Bandwidth Used in IS-IS Metric Calculations on page 392

•

Limiting the Number of Advertised IS-IS Areas on page 393

•

Enabling Wide IS-IS Metrics for Traffic Engineering on page 393

•

Configuring Preference Values for IS-IS Routes on page 393

•

Limiting the Number of Prefixes Exported to IS-IS on page 394

•

Configuring Link-State PDU Lifetime for IS-IS on page 394

•

Advertising Label-Switched Paths into IS-IS on page 394


343


•

Configuring IS-IS to Make Routing Devices Appear Overloaded on page 395

•

Configuring SPF Options for IS-IS on page 396

•

Configuring Graceful Restart for IS-IS on page 397

•

Configuring IS-IS for Multipoint Network Clouds on page 398

•

Configuring IS-IS Traffic Engineering Attributes on page 398

•

Enabling Authentication for IS-IS Without Network-Wide Deployment on page 401

•

Configuring Quicker Advertisement of IS-IS Adjacency State Changes on page 401

•

Enabling Padding of IS-IS Hello Packets on page 401

•

Configuring CLNS for IS-IS on page 402

•

Disabling IS-IS on page 405

•

Disabling IPv4 Routing for IS-IS on page 405

•


•

Applying Policies to Routes Exported to IS-IS on page 406

•

Installing a Default Route to the Nearest Routing Device That Operates at Both IS-IS Levels on page 408

•

Configuring Loop-Free Alternate Routes for IS-IS on page 409

•

Disabling Adjacency Down and Neighbor Down Notification in IS-IS and OSPF on page 415

•

Tracing IS-IS Protocol Traffic on page 416

•

Example: Configuring IS-IS on Logical Systems Within the Same Router on page 419

•

Example: Configuring an IS-IS Default Route Policy on Logical Systems on page 428

Configuring IS-IS To configure IS-IS, you include the following statements in the configuration: protocols { isis { clns-routing; disable; ignore-attached-bit; graceful-restart { disable; helper-disable; restart-duration seconds; } label-switched-path name level level metric metric; level level-number { authentication-key key; authentication-key-chain key-chain-name; authentication-type authentication; external-preference preference; no-csnp-authentication; no-hello-authentication; no-psnp-authentication; preference preference;

344


Chapter 14: IS-IS Configuration Guidelines

prefix-export-limit number; wide-metrics-only; } loose-authentication-check; lsp-lifetime seconds; max-areas seconds; no-adjacency-holddown; no-authentication-check; no-ipv4-routing; no-ipv6-routing; overload { advertise-high-metrics; timeout seconds; } reference-bandwidth reference-bandwidth; rib-group { inet group-name; inet6 group-name; } spf-options { delay milliseconds; holddown milliseconds; rapid-runs number; } topologies { ipv4-multicast; ipv6-multicast; ipv6-unicast; } traffic-engineering { disable; ignore-lsp-metrics; family inet; shortcuts { multicast-rpf-routes; } } family inet6; shortcuts; } } traceoptions { file filename ; flag flag ; } interface (all | interface-name) { disable; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; }


345


minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } checksum; csnp-interval (seconds | disable); hello-padding (adaptive | loose | strict); ldp-synchronization { disable; hold-time seconds; } link-protection; lsp-interval milliseconds; mesh-group (value | blocked); no-adjacency-holddown; no-eligible-backup; no-ipv4-multicast; no-ipv6-multicast; no-ipv6-unicast; no-unicast-topology; node-link-protection; passive; point-to-point; level level-number { disable; hello-authentication-key key; hello-authentication-key-chain key-chain-name; hello-authentication-type authentication; hello-interval seconds; hold-time seconds; ipv4-multicast-metric number; ipv6-multicast-metric number; ipv6-unicast-metric number; metric metric; passive; priority number; te-metric metric; } } } }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. By default, IS-IS is enabled for Level 1 and Level 2 routers on all interfaces on which an International Organization for Standardization (ISO) address is configured.

346



Minimum IS-IS Configuration For IS-IS to run on the routing device, you must enable IS-IS on the routing device, configure a network entity title (NET) on one of the routing device’s interfaces (preferably the loopback interface, lo0), and configure the ISO family on all interfaces on which you want IS-IS to run. When you enable IS-IS, Level 1 and Level 2 are enabled by default. The following is the minimum IS-IS configuration. In the address statement, address is the NET: interfaces { lo0 { unit logical-unit-number { family iso { address address; } } } interface-type-fpc/pic/port { unit logical-unit-number { family iso; } } } protocols { isis { interface all; } }

NOTE: To create the IS-IS interface, you must also configure IS-IS at the [edit protocols isis interface interface-name] hierarchy level. If you want the Junos OS to create IS-IS interfaces automatically, include the interface all option at the [edit protocols isis] hierarchy level.

Configuring IS-IS Authentication All IS-IS protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in the autonomous system (AS) routing. By default, IS-IS authentication is disabled on the routing device. To configure IS-IS authentication, you must define an authentication password and specify the authentication type. You can configure one of the following authentication methods: •

Simple authentication—Uses a text password that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet. Simple authentication is included for compatibility with existing IS-IS implementations. However, we recommend that you do not use this authentication method because it is insecure (the text can be “sniffed”).


347


CAUTION: A simple password that exceeds 254 characters is truncated.

•

HMAC-MD5 authentication—Uses an iterated cryptographic hash function. The receiving routing device uses an authentication key (password) to verify the packet.

You can also configure more fine-grained authentication for hello packets. To do this, see “Configuring Authentication for IS-IS Hello Packets” on page 390. To enable authentication and specify an authentication method, include the authentication-type statement, specifying the simple or md5 authentication type: authentication-type authentication;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To configure a password, include the authentication-key statement. The authentication password for all routing devices in a domain must be the same. authentication-key key;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To configure hitless authentication key rollover, include the authentication-key-chain statement. The password can contain up to 255 characters. If you include spaces, enclose all characters in quotation marks (“ ”). If you are using the Junos OS IS-IS software with another implementation of IS-IS, the other implementation must be configured to use the same password for the domain, the area, and all interfaces that are shared with a Junos implementation. Authentication of hello packets, partial sequence number PDU (PSNP), and complete sequence number PDU (CSNP) may be suppressed to enable interoperability with the routing software of different vendors. Different vendors handle authentication in various ways, and suppressing authentication for different PDU types may be the simplest way to allow compatibility within the same network. To configure IS-IS to generate authenticated packets, but not to check the authentication on received packets, include the no-authentication-check statement: no-authentication-check;

To suppress authentication of IS-IS hello packets, include the no-hello-authentication statement: no-hello-authentication;

To suppress authentication of PSNP packets, include the no-psnp-authentication statement:

348



no-psnp-authentication;

To suppress authentication of CSNP packets, include the no-csnp-authentication statement: no-csnp-authentication;


NOTE: The authentication and the no-authentication statements must be configured at the same hierarchy level. Configuring authentication at the interface hierarchy level and configuring no-authentication at the isis hierarchy level has no effect.

Hitless Authentication Key Rollover for IS-IS •

Overview of Hitless Authentication Key Rollover for IS-IS on page 349

•

Example: Configuring Hitless Authentication Key Rollover for IS-IS on page 350

Overview of Hitless Authentication Key Rollover for IS-IS IS-IS protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in routing. By default, authentication is disabled. The authentication algorithm creates an encoded checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet’s checksum. If you configure authentication for all peers, each peer in that group inherits the group’s authentication. You can update authentication keys without resetting any IS-IS neighbor sessions. This is referred to as hitless authentication key rollover. Hitless authentication key rollover uses authentication keychains, which consist of the authentication keys that are being updated. The keychain includes multiple keys. Each key in the keychain has a unique start time. At the next key’s start time, a rollover occurs from the current key to the next key, and the next key becomes the current key. You can choose the algorithm through which authentication is established. You can configure MD5 or SHA-1 authentication. You associate a keychain and the authentication algorithm with an IS-IS neighboring session. Each key contains an identifier and a secret password. The sending peer chooses the active key based on the system time and the start times of the keys in the keychain. The receiving peer determines the key with which it authenticates based on the incoming key identifier. You can configure either RFC 5304-based encoding or RFC 5310-based encoding for the IS-IS protocol transmission encoding format.


349



•


Example: Configuring Hitless Authentication Key Rollover for IS-IS This example shows how to configure hitless authentication key rollover for IS-IS. •


•


•


•


Requirements No special configuration beyond device initialization is required before configuring hitless authentication key rollover for IS-IS.

Overview Authentication guarantees that only trusted routers participate in routing updates. This keychain authentication method is referred to as hitless because the keys roll over from one to the next without resetting any peering sessions or interrupting the routing protocol. Junos OS supports both RFC 5304, IS-IS Cryptographic Authentication and RFC 5310, IS-IS Generic Cryptographic Authentication. This example includes the following statements for configuring the keychain: •

algorithm—For each key in the keychain, you can specify an encryption algorithm. The

algorithm can be SHA-1 or MD-5. •

key—A keychain can have multiple keys. Each key within a keychain must be identified

by a unique integer value. The range of valid identifier values is from 0 through 63. •

key-chain—For each keychain, you must specify a name. This example defines two

keychains: base-key-global and base-key-inter. •

options—For each key in the keychain, you can specify the encoding for the message

authentication code:isis-enhanced or basic. The basic (RFC 5304) operation is enabled by default. When you configure the isis-enhanced option, Junos OS sends RFC 5310-encoded routing protocol packets and accepts both RFC 5304-encoded and RFC 5310-encoded routing protocol packets that are received from other devices. When you configure basic (or do not include the options statement in the key configuration) Junos OS sends and receives RFC 5304-encoded routing protocols packets, and drops 5310-encoded routing protocol packets that are received from other devices. Because this setting is for IS-IS only, the TCP and the BFD protocol ignore the encoding option configured in the key.

350



•

secret—For each key in the keychain, you must set a secret password. This password

can be entered in either encrypted or plain text format in the secret statement. It is always displayed in encrypted format. •

start-time—Each key must specify a start time in UTC format. Control gets passed

from one key to the next. When a configured start time arrives (based on the routing device’s clock), the key with that start time becomes active. Start times are specified in the local time zone for a routing device and must be unique within the key chain. You can apply a keychain globally to all interfaces or more granularly to specific interfaces. This example includes the following statements for applying the keychain to all interfaces or to particular interfaces: •

authentication-key-chain—Enables you to apply a keychain at the global IS-IS level for

all Level 1 or all Level 2 interfaces. •

hello-authentication-key-chain—Enables you to apply a keychain at the individual IS-IS

interface level. The interface configuration overrides the global configuration. Figure 7 on page 351 shows the topology used in the example.

Figure 7: Hitless Authentication Key Rollover for IS-IS {

}

ISIS Level 1

{

}

ISIS Level 2 B

FE/GE/XE

R1 A

FE/GE/XE

R0 A

R2 A

C

B SONET

FE/GE/XE

R3 A

g040568

B

This example shows the configuration for Router R0.


To quickly configure the hitless authentication key rollover for IS-IS, copy the following commands and paste the commands into the CLI. [edit] set interfaces ge-0/0/0 unit 0 description "interface A" set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/30 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family inet6 address fe80::200:f8ff:fe21:67cf/128 set interfaces ge-0/0/1 unit 0 description "interface B" set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.5/30 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family inet6 address 10FB::C:ABC:1F0C:44DA/128 set interfaces ge-0/0/2 unit 0 description "interface C" set interfaces ge-0/0/2 unit 0 family inet address 10.0.0.9/30 set interfaces ge-0/0/2 unit 0 family iso set interfaces ge-0/0/2 unit 0 family inet6 address ff06::c3/128


351


set security authentication-key-chains key-chain base-key-global key 63 secret "$9$jfkqfTQnCpBDiCt" set security authentication-key-chains key-chain base-key-global key 63 start-time "2011-8-6.06:54:00-0700" set security authentication-key-chains key-chain base-key-global key 63 algorithm hmac-sha-1 set security authentication-key-chains key-chain base-key-global key 63 options isis-enhanced set security authentication-key-chains key-chain base-key-inter key 0 secret "$9$8sgx7Vws4ZDkWLGD" set security authentication-key-chains key-chain base-key-inter key 0 start-time "2011-8-6.06:54:00-0700" set security authentication-key-chains key-chain base-key-inter key 0 algorithm md5 set security authentication-key-chains key-chain base-key-inter key 0 options basic set protocols isis level 1 authentication-key-chain base-key-global set protocols isis interface ge-0/0/0.0 level 1 hello-authentication-key-chain base-key-inter


To configure hitless authentication key rollover for IS-IS: 1.

Configure Router R0’s interfaces. [edit] user@host# edit interfaces ge-0/0/0 unit 0 [edit interfaces ge-0/0/0 unit 0] user@host# set description "interface A" user@host# set family inet address 10.0.0.1/30 user@host# set family iso user@host# set family inet6 address fe80::200:f8ff:fe21:67cf/128 user@host# exit [edit] user@host# edit interfaces ge-0/0/1 unit 0 [edit interfaces ge-0/0/1 unit 0] user@host# set interfaces ge-0/0/1 unit 0 description "interface B" user@host# set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.5/30 user@host# set interfaces ge-0/0/1 unit 0 family iso user@host# set interfaces ge-0/0/1 unit 0 family inet6 address 10FB::C:ABC:1F0C:44DA/128 user@host# exit [edit] user@host# edit interfaces ge-0/0/2 unit 0 [edit interfaces ge-0/0/2 unit 0] user@host# set description "interface C" user@host# set family inet address 10.0.0.9/30 user@host# set interfaces ge-0/0/2 unit 0 family iso user@host# set interfaces ge-0/0/2 unit 0 family inet6 address ff06::c3/128 user@host# exit

2.

Configure one or more authentication keys. [edit] user@host# edit security authentication-key-chains key-chain base-key-global [edit security authentication-key-chains key-chain base-key-global] user@host# set key 63 secret "$9$jfkqfTQnCpBDiCt" user@host# set key 63 start-time "2011-8-6.06:54:00-0700" user@host# set key 63 algorithm hmac-sha-1

352



user@host# set key 63 options isis-enhanced user@host# exit [edit] user@host# edit security authentication-key-chains key-chain base-key-inter [edit security authentication-key-chains key-chain base-key-inter] user@host# set key 0 secret "$9$8sgx7Vws4ZDkWLGD" user@host# set key 0 start-time "2011-8-6.06:54:00-0700" user@host# set key 0 algorithm md5 user@host# set key 0 options basic user@host# exit 3.

Apply the base-key-global keychain to all Level 1 IS-IS interfaces on Router R0. [edit] user@host# edit protocols isis level 1 [edit protocols isis level 1] set authentication-key-chain base-key-global user@host# exit

4.

Apply the base-key-inter keychain to the ge-0/0/0.0 interface on Router R0. [edit] user@host# edit protocols isis interface ge-0/0/0.0 level 1 [edit protocols isis interface ge-0/0/0.0 level 1] set hello-authentication-key-chain base-key-inter user@host# exit

5.


Results

Confirm your configuration by entering the show interfaces, show protocols, and show security commands. user@host# show interfaces ge-0/0/0 { unit 0 { description "interface A"; family inet { address 10.0.0.1/30; } family iso; family inet6 { address fe80::200:f8ff:fe21:67cf/128; } } } ge-0/0/1 { unit 0 { description "interface B"; family inet { address 10.0.0.5/30; } family iso; family inet6 { address 10FB::C:ABC:1F0C:44DA/128;


353


} } } ge-0/0/2 { unit 0 { description "interface C"; family inet { address 10.0.0.9/30; } family iso; family inet6 { address ff06::c3/128; } } } user@host# show protocols isis { level 1 authentication-key-chain base-key-global; interface ge-0/0/0.0 { level 1 hello-authentication-key-chain base-key-inter; } } user@host# show security authentication-key-chains { key-chain base-key-global { key 63 { secret "$9$jfkqfTQnCpBDiCt"; ## SECRET-DATA start-time "2011-8-6.06:54:00-0700"; algorithm hmac-sha-1; options isis-enhanced; } } key-chain base-key-inter { key 0 { secret "$9$8sgx7Vws4ZDkWLGD"; ## SECRET-DATA start-time "2011-8-6.06:54:00-0700"; algorithm md5; options basic; } } }

Verification To verify the configuration, run the following commands:


354

•

show isis authentication

•

show security keychain

•




Configuring of Interface-Specific IS-IS Properties You can configure interface-specific IS-IS properties by including the interface statement. interface (all | interface-name) { disable; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (1 | automatic); } checksum; csnp-interval (seconds | disable); ldp-synchronization { disable; hold-time seconds; } lsp-interval milliseconds; mesh-group (value | blocked); no-ipv4-multicast; no-ipv6-multicast; no-ipv6-unicast; no-unicast-topology; passive; point-to-point; level level-number { disable; hello-authentication-type authentication; hello-authentication-key key; hello-authentication-key-chain key-chain-name; hello-interval seconds; hold-time seconds; ipv4-multicast-metric number; ipv6-multicast-metric number; ipv6-unicast-metric number; metric metric; passive; priority number; te-metric metric; } }


355


For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. For interface-name, specify the full interface name, including the physical and logical address components. To configure all interfaces, specify the interface name as all. For more information about configuring IS-IS interface properties, see the following topics: •


•


•


•


•


•


•


•


•


•


•


•


Configuring BFD for IS-IS •

Overview of Configuring BFD for IS-IS on page 356

•

Example: Configuring BFD for IS-IS on page 358

Overview of Configuring BFD for IS-IS The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures in a network. Hello packets are sent at a specified, regular interval. A neighbor failure is detected when the routing device stops receiving a reply after a specified interval. BFD works with a wide variety of network environments and topologies. The failure detection timers for BFD have shorter time limits than the failure detection mechanisms of IS-IS, providing faster detection. The BFD failure detection timers are adaptive and can be adjusted to be faster or slower. For example, the timers can adapt to a higher value if the adjacency fails, or a neighbor can negotiate a higher value for a timer than the configured value. The timers adapt to a higher value when a BFD session flap occurs more than three times in a span of 15 seconds. A back-off algorithm increases the receive (RX) interval by two if the local BFD instance is the reason for the session flap. The transmission (TX) interval is increased by two if the remote BFD instance is the reason for the session flap.

356



You can use the clear bfd adaptation command to return BFD interval timers to their configured values. The clear bfd adaptation command is hitless, meaning that the command does not affect traffic flow on the IS-IS routing device.

NOTE: BFD for IS-IS on an IPv6-only interface is not supported. However, if the interface is dual-stacked (both IPv4 and IPv6 are configured), then you can configure BFD as a client on the IPv4 IS-IS session.

To detect failures in the network, the following set of statements are used in the configuration.

Table 7: Configuring BFD for IS-IS Statement

Description

bfd-liveness-detection

Enable failure detection.

minimum-interval milliseconds

Specify the minimum transmit and receive intervals for failure detection. This value represents the minimum interval at which the local router transmits hellos packets as well as the minimum interval at which the router expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number from 1 through 255,000 milliseconds. You can also specify the minimum transmit and receive intervals separately. NOTE: BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD less than 100 ms for Routing Engine-based sessions and 10 ms for distributed BFD sessions can cause undesired BFD flapping. Depending on your network environment, these additional recommendations might apply:

minimum-receive-interval milliseconds

•


•


•


Specify only the minimum receive interval for failure detection. This value represents the minimum interval at which the local router expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number from 1 through 255,000 milliseconds.

multiplier number

Specify the number of hello packets not received by the neighbor that causes the originating interface to be declared down. The default is 3, and you can configure a value from 1 through 225.


357


Table 7: Configuring BFD for IS-IS (continued) Statement

Description

no-adaptation

Disable BFD adaptation. In Junos OS Release 9.0 and later, you can specify that the BFD sessions not adapt to changing network conditions. NOTE: We recommend that you not disable BFD adaptation unless it is preferable not to have BFD adaptation enabled in your network.

threshold

•

Specify the threshold for the adaptation of the detection time. When the BFD session detection time adapts to a value equal to or greater than the threshold, a single trap and a system log message are sent.

•

Specify the threshold for the transmit interval.

NOTE: The threshold value must be greater than the minimum transmit interval multiplied by the multiplier number. transmit-interval minimum-interval

Specify the minimum transmit interval for failure detection. This value represents the minimum interval at which the local routing device transmits hello packets to the neighbor with which it has established a BFD session. You can configure a value from 1 through 255,000 milliseconds.

version

Specify the BFD version used for detection. The default is to have the version detected automatically.

NOTE: You can trace BFD operations by including the traceoptions statement at the [edit protocols bfd] hierarchy level.


Example: Configuring BFD for IS-IS This example describes how to configure the Bidirectional Forwarding Detection (BFD) protocol to detect failures in an IS-IS network. •


•


•


•


Requirements Before you begin, configure IS-IS on both routers. See “Minimum IS-IS Configuration” on page 347 for information about the required IS-IS configuration. This example uses the following hardware and software components:

358



•

Junos OS Release 7.3 or later

•

M Series, MX Series, and T Series routers

Overview This example shows two routers connected to each other. A loopback interface is configured on each router. IS-IS and BFD protocols are configured on both routers. Figure 8 on page 359 shows the sample network.

Figure 8: Configuring BFD on IS-IS


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. Router R1 set protocols isis interface so-0/0/0 bfd-liveness-detection detection-time threshold 5 set protocols isis interface so-0/0/0 bfd-liveness-detection minimum-interval 2 set protocols isis interface so-0/0/0 bfd-liveness-detection minimum-receive-interval 1 set protocols isis interface so-0/0/0 bfd-liveness-detection no-adaptation set protocols isis interface so-0/0/0 bfd-liveness-detection transmit-interval threshold 3 set protocols isis interface so-0/0/0 bfd-liveness-detection transmit-interval minimum-interval 1 set protocols isis interface so-0/0/0 bfd-liveness-detection multiplier 2 set protocols isis interface so-0/0/0 bfd-liveness-detection version automatic

Router R2 set protocols isis interface so-0/0/0 bfd-liveness-detection detection-time threshold 6 set protocols isis interface so-0/0/0 bfd-liveness-detection minimum-interval 3 set protocols isis interface so-0/0/0 bfd-liveness-detection minimum-receive-interval 1 set protocols isis interface so-0/0/0 bfd-liveness-detection no-adaptation set protocols isis interface so-0/0/0 bfd-liveness-detection transmit-interval threshold 4 set protocols isis interface so-0/0/0 bfd-liveness-detection transmit-interval minimum-interval 1 set protocols isis interface so-0/0/0 bfd-liveness-detection multiplier 2 set protocols isis interface so-0/0/0 bfd-liveness-detection version automatic


359



The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

NOTE: To simply configure BFD for IS-IS, only the minimum-interval statement is required. The BFD protocol selects default parameters for all the other configuration statements when you use the bfd-liveness-detection statement without specifying any parameters.

NOTE: You can change parameters at any time without stopping or restarting the existing session. BFD automatically adjusts to the new parameter value. However, no changes to BFD parameters take place until the values resynchronize with each BFD peer.

To configure BFD for IS-IS on Routers R1 and R2: 1.

Enable BFD failure detection for IS-IS. [edit protocols isis] user@R1# set interface so-0/0/0 bfd-liveness-detection [edit protocols isis] user@R2# set interface so-0/0/0 bfd-liveness-detection

2.

Configure the threshold for the adaptation of the detection time, which must be greater than the multiplier number multiplied by the minimum interval. [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R1# set detection-time threshold 5 [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R2# set detection-time threshold 6

3.

Configure the minimum transmit and receive intervals for failure detection. [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R1# set minimum-interval 2 [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R2# set minimum-interval 3

4.

Configure only the minimum receive interval for failure detection. [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R1# set minimum-receive-interval 1 [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R2# set minimum-receive-interval 1

5.

Disable BFD adaptation. [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R1# set no-adaptation [edit protocols isis interface so-0/0/0 bfd-liveness-detection]

360



user@R2# set no-adaptation 6.

Configure the threshold for the transmit interval, which must be greater than the minimum transmit interval. [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R1# set transmit-interval threshold 3 [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R2# set transmit-interval threshold 4

7.

Configure the minimum transmit interval for failure detection. [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R1# set transmit-interval minimum-interval 1 [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R2# set transmit-interval minimum-interval 1

8.

Configure the multiplier number, which is the number of hello packets not received by the neighbor that causes the originating interface to be declared down. [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R1# set multiplier 2 [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R2# set multiplier 2

9.

Configure the BFD version used for detection. The default is to have the version detected automatically. [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R1# set version automatic [edit protocols isis interface so-0/0/0 bfd-liveness-detection] user@R2# set version automatic

Results

Confirm your configuration by issuing the show protocols isis interface command. user@R1# show protocols isis interface so-0/0/0 bfd-liveness-detection { version automatic; minimum-interval 2; minimum-receive-interval 1; multiplier 2; no-adaptation; transmit-interval { minimum-interval 1; threshold 3; } detection-time { threshold 5; } } ... user@R2# show protocols isis interface so-0/0/0 bfd-liveness-detection { version automatic;


361


minimum-interval 3; minimum-receive-interval 1; multiplier 2; no-adaptation; transmit-interval { minimum-interval 1; threshold 4; } detection-time { threshold 6; } } ...

Verification Confirm that the configuration is working properly. •

Verifying the Connection Between Routers R1 and R2 on page 362

•

Verifying That IS-IS Is Configured on page 362

•

Verifying That BFD Is configured on page 363

Verifying the Connection Between Routers R1 and R2 Purpose Action

Make sure that the Routers R1 and R2 are connected to each other. Ping the other router to check the connectivity between the two routers as per the network topology. user@R1> ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=64 time=1.367 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=1.662 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=1.291 ms ^C --- 10.0.0.2 ping statistics --3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.291/1.440/1.662/0.160 ms user@R2> ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=1.287 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=1.310 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=1.289 ms ^C --- 10.0.0.1 ping statistics --3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.287/1.295/1.310/0.010 ms

Meaning

Routers R1 and R2 are connected to each other. Verifying That IS-IS Is Configured

Purpose

362

Make sure that the IS-IS instance is running on both routers.



Action

Use the show isis database statement to check if IS-IS instance is running on both routers, R1 and R2. user@R1> show isis database IS-IS level 1 link-state database: LSP ID Sequence Checksum Lifetime Attributes R1.00-00 0x4a571 0x30c5 1195 L1 L2 R2.00-00 0x4a586 0x4b7e 1195 L1 L2 R2.02-00 0x330ca1 0x3492 1196 L1 L2 3 LSPs IS-IS level 2 link-state database: LSP ID Sequence Checksum Lifetime Attributes R1.00-00 0x4a856 0x5db0 1194 L1 L2 R2.00-00 0x4a89d 0x149b 1194 L1 L2 R2.02-00 0x1fb2ff 0xd302 1194 L1 L2 3 LSPs user@R2> show isis database IS-IS level 1 link-state database: LSP ID Sequence Checksum Lifetime Attributes R1.00-00 0x4b707 0xcc80 1195 L1 L2 R2.00-00 0x4b71b 0xeb37 1198 L1 L2 R2.02-00 0x33c2ce 0xb52d 1198 L1 L2 3 LSPs IS-IS level 2 link-state database: LSP ID Sequence Checksum Lifetime Attributes R1.00-00 0x4b9f2 0xee70 1192 L1 L2 R2.00-00 0x4ba41 0x9862 1197 L1 L2 R2.02-00 0x3 0x6242 1198 L1 L2 3 LSPs

Meaning

IS-IS is configured on both routers, R1 and R2. Verifying That BFD Is configured

Purpose Action

Make sure that the BFD instance is running on both routers, R1 and R2. Use the show bfd session detail statement to check if BFD instance is running on the routers. user@R1> show bfd session detail Detect Address State Interface Time 10.0.0.2 Up so-0/0/0 2.000 Client ISIS R2, TX interval 0.001, RX interval 0.001 Client ISIS R1, TX interval 0.001, RX interval 0.001 Session down time 00:00:00, previous up time 00:00:15 Local diagnostic NbrSignal, remote diagnostic NbrSignal Remote state AdminDown, version 1 Router 3, routing table index 17

Transmit Interval 1.000

Multiplier 2

1 sessions, 2 clients Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps user@R2> show bfd session detail


363


Detect Address State Interface Time 10.0.0.1 Up so-0/0/0 2.000 Client ISIS R2, TX interval 0.001, RX interval 0.001 Session down time 00:00:00, previous up time 00:00:05 Local diagnostic NbrSignal, remote diagnostic NbrSignal Remote state AdminDown, version 1 Router 2, routing table index 15

Transmit Interval 1.000

Multiplier 2


Meaning

BFD is configured on Routers R1 and R2 for detecting failures in the IS-IS network.

Overview of BFD Authentication for IS-IS BFD enables rapid detection of communication failures between adjacent systems. By default, authentication for BFD sessions is disabled. However, when running BFD over Network Layer protocols, the risk of service attacks can be significant. We strongly recommend using authentication if you are running BFD over multiple hops or through insecure tunnels. Beginning with Junos OS Release 9.6, the Junos OS supports authentication for BFD sessions running over IS-IS. BFD authentication is only supported in the domestic image and is not available in the export image. You authenticate BFD sessions by specifying an authentication algorithm and keychain, and then associating that configuration information with a security authentication keychain using the keychain name. The following sections describe the supported authentication algorithms, security keychains, and level of authentication that can be configured: •


•


•






receive intervals greater than 100 ms. To authenticate the BFD session, keyed MD5 uses one or more secret keys (generated by the algorithm) and a sequence number that is updated periodically. With this method, packets are accepted at the receiving end of the session if one of the keys matches and the sequence number is greater than or equal to the last sequence number received. Although more secure than a simple password, this method is vulnerable to replay attacks. Increasing the rate at which the sequence number is updated can reduce this risk.

364



•








Security Authentication Keychains The security authentication keychain defines the authentication attributes used for authentication key updates. When the security authentication keychain is configured and associated with a protocol through the keychain name, authentication key updates can occur without interrupting routing and signaling protocols. The authentication keychain contains one or more keychains. Each keychain contains one or more keys. Each key holds the secret data and the time at which the key becomes valid. The algorithm and keychain must be configured on both ends of the BFD session, and they must match. Any mismatch in configuration prevents the BFD session from being created. BFD allows multiple clients per session, and each client can have its own keychain and algorithm defined. To avoid confusion, we recommend specifying only one security authentication keychain.


•


•



365


•


•


•


Configuring BFD Authentication for IS-IS Beginning with Junos OS Release 9.6, you can configure authentication for BFD sessions running over IS-IS. Routing instances are also supported. Only three steps are needed to configure authentication on a BFD session: 1.

Specify the BFD authentication algorithm for the IS-IS protocol.

2. Associate the authentication keychain with the IS-IS protocol. 3. Configure the related security authentication keychain.

The following sections provide instructions for configuring and viewing BFD authentication on IS-IS: •

Configuring BFD Authentication Parameters on page 366

•


Configuring BFD Authentication Parameters To configure BFD authentication: 1.

Specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use for BFD authentication on an IS-IS route or routing instance. [edit] user@host# set protocols isis interface if1-isis bfd-liveness-detection authentication algorithm keyed-sha-1


2. Specify the keychain to be used to associate BFD sessions on the specified IS-IS route

or routing instance with the unique security authentication keychain attributes. This should match the keychain name configured at the [edit security authentication key-chains] hierarchy level. [edit] user@host# set protocols isis interface if1-isis bfd-liveness-detection authentication keychain bfd-isis

366





The matching key-chain-name as specified in step 2.

•


•


•

The time at which the authentication key becomes active, yyyy-mm-dd.hh:mm:ss. [edit security] user@host# authentication-key-chains key-chain bfd-sr4 key 53 secret $9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm start-time 2009-06-14.10:00:00


nonauthenticated sessions to authenticated sessions. [edit] user@host> set protocols isis interface if1-isis bfd-liveness-detection authentication loose-check 5. (Optional) View your configuration using the show bfd session detail or show bfd



Viewing Authentication Information for BFD Sessions You can view the existing BFD authentication configuration using the show bfd session detail and show bfd session extensive commands. The following example shows BFD authentication configured for the if1-isis interface. It specifies the keyed SHA-1 authentication algorithm and a keychain name of bfd-isis. The authentication keychain is configured with two keys. Key 1 contains the secret data “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm” and a start time of June 1, 2009, at 9:46:02 AM PST. Key 2 contains the secret data “$9$a5jiKW9l.reP38ny.TszF2/9” and a start time of June 1, 2009, at 3:29:20 PM PST. [edit protocols isis] interface if1-isis { bfd-liveness-detection { authentication { algorithm keyed-sha-1;


367


key-chain bfd-isis; } } } [edit security] authentication key-chains { key-chain bfd-isis { key 1 { secret “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm”; start-time “2009-6-1.09:46:02 -0700”; } key 2 { secret “$9$a5jiKW9l.reP38ny.TszF2/9”; start-time “2009-6-1.15:29:20 -0700”; } } }


user@host# show bfd session detail Detect Transmit Address State Interface Time Interval Multiplier 10.9.1.29 Up ge-4/0/0.0 0.600 0.200 3 Client ISIS L2, TX interval 0.200, RX interval 0.200, multiplier 3, Authenticate Session up time 3d 00:34, previous down time 00:00:01 Local diagnostic NbrSignal, remote diagnostic AdminDown Remote state Up, version 1 1 sessions, 1 clients Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps


user@host# show bfd session extensive Detect Transmit Address State Interface Time Interval Multiplier 10.9.1.29 Up ge-4/0/0.0 0.600 0.200 3 Client ISIS L2, TX interval 0.200, RX interval 0.200, multiplier 3, Authenticate keychain bfd-isis, algo keyed-sha-1, mode strict Session up time 00:04:42 Local diagnostic None, remote diagnostic NbrSignal Remote state Up, version 1 Replicated Min async interval 0.300, min slow interval 1.000 Adaptive async TX interval 0.300, RX interval 0.300 Local min TX interval 0.300, minimum RX interval 0.300, multiplier 3 Remote min TX interval 0.300, min RX interval 0.300, multiplier 3 Local discriminator 2, remote discriminator 2 Echo mode disabled/inactive Authentication enabled/active, keychain bfd-isis, algo keyed-sha-1, mode strict

368





•


•

bfd-liveness-detection on page 437

•


•


•


Enabling Packet Checksum on IS-IS Interfaces You can enable checksum for packets on a per-interface basis. To enable checksum, include the checksum statement: checksum;


Configuring the Transmission Frequency for CSNP Packets on IS-IS Interfaces By default, IS-IS sends complete sequence number (CSN) packets periodically. If the routing device is the designated router on a LAN, IS-IS sends CSN packets every 10 seconds. If the routing device is on a point-to-point interface, it sends CSN packets every 5 seconds. You might want to modify the default interval to protect against link-state PDU (LSP) flooding. To modify the CSNP interval, include the csnp-interval statement: csnp-interval seconds;

The time can range from 1 through 65,535 seconds. To configure the interface not to send any CSN packets, specify the disable option: csnp-interval disable;


Configuring Synchronization Between LDP and IS-IS LDP distributes labels in non-traffic-engineered applications. Labels are distributed along the best path determined by IS-IS. If the synchronization between LDP and IS-IS is lost, the label-switched path (LSP) goes down. Therefore, LDP and IS-IS synchronization is beneficial. When LDP is not fully operational on a given link (a session is not established


369


and labels are not exchanged), IS-IS advertises the link with the maximum cost metric. The link is not preferred but remains in the network topology. LDP synchronization is supported only on point-to-point interfaces and LAN interfaces configured as point-to-point interfaces under IS-IS. LDP synchronization is not supported during graceful restart. To advertise the maximum cost metric until LDP is operational for LDP synchronization, include the ldp-synchronization statement: ldp-synchronization { disable; hold-time seconds; }

To disable synchronization, include the disable statement. To configure the time period to advertise the maximum cost metric for a link that is not fully operational, include the hold-time statement.

NOTE: When an interface has been in the holddown state for more than three minutes, a system log message with a warning level is sent. This message appears in both the messages file and the trace file.


Configuring the Transmission Frequency for Link-State PDUs on IS-IS Interfaces By default, the routing device sends one link-state PDU packet out an interface every 100 milliseconds. To modify this interval, include the lsp-interval statement: lsp-interval milliseconds;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To disable the transmission of all link-state PDU packets, set the interval to 0.

Configuring Mesh Groups of IS-IS Interfaces A mesh group is a set of routing devices that are fully connected; that is, they have a fully meshed topology. When link-state PDU packets are being flooded throughout an area, each router within a mesh group receives only a single copy of an link-state PDU packet instead of receiving one copy from each neighbor, thus minimizing the overhead associated with the flooding of link-state PDU packets. To create a mesh group and designate that an interface is part of the group, assign a mesh-group number to all the routing device interfaces in the group: mesh-group value;

370



To prevent an interface in the mesh group from flooding link-state PDUs, configure blocking on that interface: mesh-group blocked;


Configuring IS-IS Multicast Topology •

IS-IS Multicast Topologies Overview on page 371

•

Example: Configuring IS-IS Multicast Topology on page 372

IS-IS Multicast Topologies Overview Most multicast routing protocols perform a reverse-path forwarding (RPF) check on the source of multicast data packets. If a packet comes in on the interface that is used to send data to the source, the packet is accepted and forwarded to one or more downstream interfaces. Otherwise, the packet is discarded and a notification is sent to the multicast routing protocol running on the interface. In certain instances, the unicast routing table used for the RPF check is also the table used for forwarding unicast data packets. Thus, unicast and multicast routing are congruent. In other cases, where it is preferred that multicast routing be independent of unicast routing, the multicast routing protocols are configured to perform the RPF check using an alternate unicast routing table inet.2. You can configure IS-IS to calculate an alternate IPv4 multicast topology, in addition to the normal IPv4 unicast topology, and add the corresponding routes to inet.2. The IS-IS interface metrics for the multicast topology can be configured independently of the unicast metrics. You can also selectively disable interfaces from participating in the multicast topology while continuing to participate in the regular unicast topology. This lets you exercise control over the paths that multicast data takes through a network so that it is independent of unicast data paths. You can also configure IS-IS to calculate an alternate IPv6 multicast topology, in addition to the normal IPv6 unicast topology.

NOTE: IS-IS only starts advertising the routes when the interface routes are in inet.2.

Table 8 on page 371 lists the various IPv4 statements you can use to configure IS-IS multicast topologies.

Table 8: IPv4 Statements Statement

Description

ipv4-multicast

Enables an alternate IPv4 multicast topology.

ipv4-multicast-metric number

Configures the multicast metric for an alternate IPv4 multicast topology.


371


Table 8: IPv4 Statements (continued) Statement

Description

no-ipv4-multicast

Excludes an interface from the IPv4 multicast topology.

no-unicast-topology

Excludes an interface from the IPv4 unicast topologies.

Table 9 on page 372 lists the various IPv6 statements you can use to configure IS-IS multicast topologies.

Table 9: IPv6 Statements Statement

Description

ipv6-multicast

Enables an alternate IPv6 multicast topology.

ipv6-multicast-metric number

Configures the multicast metric for an alternate IPv6 multicast topology.

ipv6-unicast-metric number

Configures the unicast metric for an alternate IPv6 multicast topology.

no-ipv6-multicast

Excludes an interface from the IPv6 multicast topology.

no-ipv6-unicast

Excludes an interface from the IPv6 unicast topologies.


Example: Configuring IS-IS Multicast Topology This example shows how to configure multicast topology for an IS-IS network. •


•


•


•


Requirements Before you begin, configure IS-IS on all routers. See “Minimum IS-IS Configuration” on page 347 for information about the required IS-IS configuration. This example uses the following hardware and software components:

372

•

Junos OS Release 7.3 or later

•

M Series, MX Series, and T Series routers



Overview This example shows an IS-IS multicast topology configuration. Three routers are connected to each other. A loopback interface is configured on each router. Figure 9 on page 373 shows the sample network.

Figure 9: Configuring IS-IS Multicast Topology


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. Router R1 set protocols isis traceoptions file isis size 5m world-readable set protocols isis traceoptions flag error set protocols isis topologies ipv4-multicast set protocols isis interface so-0/0/0 level 1 metric 15 set protocols isis interface so-0/0/0 level 1 ipv4-multicast-metric 18 set protocols isis interface so-0/0/0 level 2 metric 20 set protocols isis interface so-0/0/0 level 2 ipv4-multicast-metric 14 set protocols isis interface so-1/0/0 level 1 metric 13 set protocols isis interface so-1/0/0 level 1 ipv4-multicast-metric 12 set protocols isis interface so-1/0/0 level 2 metric 29 set protocols isis interface so-1/0/0 level 2 ipv4-multicast-metric 23 set protocols isis interface so-0/0/1 no-ipv4-multicast set protocols isis interface so-0/0/1 level 1 metric 14


373


set protocols isis interface so-0/0/1 level 2 metric 23 set protocols isis interface fxp0.0 disable

Router R2 set protocols isis traceoptions file isis size 5m world-readable set protocols isis traceoptions flag error set protocols isis topologies ipv4-multicast set protocols isis interface so-0/0/0 level 1 metric 13 set protocols isis interface so-0/0/0 level 1 ipv4-multicast-metric 12 set protocols isis interface so-0/0/0 level 2 metric 29 set protocols isis interface so-0/0/0 level 2 ipv4-multicast-metric 23 set protocols isis interface so-1/0/0 level 1 metric 14 set protocols isis interface so-1/0/0 level 1 ipv4-multicast-metric 18 set protocols isis interface so-1/0/0 level 2 metric 32 set protocols isis interface so-1/0/0 level 2 ipv4-multicast-metric 26 set protocols isis interface so-0/0/1 no-ipv4-multicast set protocols isis interface so-0/0/1 no-ipv6-unicast set protocols isis interface so-0/0/1 level 1 metric 17 set protocols isis interface so-0/0/1 level 2 metric 26 set protocols isis interface fxp0.0 disable

Router R3 set protocols isis traceoptions file isis size 5m world-readable set protocols isis traceoptions flag error set protocols isis topologies ipv4-multicast set protocols isis interface so-0/0/0 level 1 metric 19 set protocols isis interface so-0/0/0 level 1 ipv4-multicast-metric 11 set protocols isis interface so-0/0/0 level 2 metric 27 set protocols isis interface so-0/0/0 level 2 ipv4-multicast-metric 21 set protocols isis interface so-1/0/0 level 1 metric 16 set protocols isis interface so-1/0/0 level 1 ipv4-multicast-metric 26 set protocols isis interface so-1/0/0 level 2 metric 30 set protocols isis interface so-1/0/0 level 2 ipv4-multicast-metric 20 set protocols isis interface so-0/0/1 no-ipv4-multicast set protocols isis interface so-0/0/1 level 1 metric 20 set protocols isis interface so-0/0/1 level 2 metric 29 set protocols isis interface fxp0.0 disable

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide. To configure IS-IS multicast topologies: 1.

Enable the multicast topology for IS-IS by using the ipv4-multicast statement. Routers R1, R2, and R3 [edit protocols isis] user@host# set traceoptions file isis size 5m world-readable user@host# set traceoptions flag error user@host# set topologies ipv4-multicast

2. Enable multicast metrics on the first sonet Interface by using the ipv4-multicast-metric

statement. Router R1

374



[edit protocols isis interface so-0/0/0 ] user@R1# set level 1 metric 15 user@R1# set level 1 ipv4-multicast-metric 18 user@R1# set level 2 metric 20 user@R1# set level 2 ipv4-multicast-metric 14

Router R2 [edit protocols isis interface so-0/0/0] user@R2# set level 1 metric 13 user@R2# set level 1 ipv4-multicast-metric 12 user@R2# set level 2 metric 29 user@R2# set level 2 ipv4-multicast-metric 23

Router R3 [edit protocols isis interface so-0/0/0] user@R3# set level 1 metric 19 user@R3# set level 1 ipv4-multicast-metric 11 user@R3# set level 2 metric 27 user@R3# set level 2 ipv4-multicast-metric 21 3. Enable multicast metrics on a second sonet Interface by using the ipv4-multicast-metric

statement. Router R1 [edit protocols isis interface so-1/0/0] user@R1# set level 1 metric 13 user@R1# set level 1 ipv4-multicast-metric 12 user@R1# set level 2 metric 29 user@R1# set level 2 ipv4-multicast-metric 23

Router R2 [edit protocols isis interface so-1/0/0] user@R2# set level 1 metric 14 user@R2# set level 1 ipv4-multicast-metric 18 user@R2# set level 2 metric 32 user@R2# set level 2 ipv4-multicast-metric 26

Router R3 [edit protocols isis interface so-1/0/0] user@R3# set level 1 metric 16 user@R3# set level 1 ipv4-multicast-metric 26 user@R3# set level 2 metric 30 user@R3# set level 2 ipv4-multicast-metric 20 4. Disable IPv4 multicast topology on a third sonet interface by using the

no-ipv4-multicast statement.

Router R1 [edit protocols isis interface so-0/0/1] user@R1# set no-ipv4-multicast user@R1# set level 1 metric 14 user@R1# set level 2 metric 23

Router R2


375


[edit protocols isis interface so-0/0/1] user@R2# set no-ipv4-multicast user@R2# set level 1 metric 17 user@R2# set level 2 metric 26

Router R3 [edit protocols isis interface so-0/0/1] user@R3# set no-ipv4-multicast user@R3# set level 1 metric 20 user@R3# set level 2 metric 29 5. Disable the out-of-band management port, fxp0.

Routers R1, R2, and R3 [edit protocols isis] user@host# set interface fxp0.0 disable 6. If you are done configuring the routers, commit the configuration.

Routers R1, R2, and R3 [edit] user@host# commit

Results

Confirm your configuration by using the show protocols isis statement. Router R1 user@R1# show protocols isis traceoptions { file isis size 5m world-readable; flag error; } topologies ipv4-multicast; interface so-0/0/0 { level 1 { metric 15; ipv4-multicast-metric 18; } level 2 { metric 20; ipv4-multicast-metric 14; } } interface so-1/0/0 { level 1 { metric 15; ipv4-multicast-metric 17; } level 2 { metric 31; ipv4-multicast-metric 22; } } interface fxp0.0 { disable; }

Router R2

376



user@R2# show protocols isis traceoptions { file isis size 5m world-readable; flag error; } topologies ipv4-multicast; interface so-0/0/0 { level 1 { metric 13; ipv4-multicast-metric 12; } level 2 { metric 29; ipv4-multicast-metric 23; } } interface so-1/0/0 { level 1 { metric 14; ipv4-multicast-metric 18; } level 2 { metric 32; ipv4-multicast-metric 26; } } interface fxp0.0 { disable; }

Router R3 user@R3# show protocols isis traceoptions { file isis size 5m world-readable; flag error; } topologies ipv4-multicast; interface so-0/0/0 { level 1 { metric 19; ipv4-multicast-metric 11; } level 2 { metric 27; ipv4-multicast-metric 21; } } interface so-1/0/0 { level 1 { metric 16; ipv4-multicast-metric 26; } level 2 { metric 30; ipv4-multicast-metric 20; } } interface fxp0.0 {


377


disable; }


Verifying the Connection Between Routers R1, R2, and R3 on page 378

•

Verifying That IS-IS Is Configured on page 379

•

Verifying the Configured Multicast Metric Values on page 381

•

Verifying the Configuration of Multicast Topology on page 382

Verifying the Connection Between Routers R1, R2, and R3 Purpose Action

Make sure that Routers R1, R2, and R3 are connected to each other. Ping the other two routers from any router, to check the connectivity between the three routers as per the network topology. user@R1> ping 10.0.3.9 PING 10.0.3.9 (10.0.3.9): 56 data bytes 64 bytes from 10.0.3.9: icmp_seq=0 ttl=64 time=1.299 ms 64 bytes from 10.0.3.9: icmp_seq=1 ttl=64 time=52.304 ms 64 bytes from 10.0.3.9: icmp_seq=2 ttl=64 time=1.271 ms 64 bytes from 10.0.3.9: icmp_seq=3 ttl=64 time=1.343 ms 64 bytes from 10.0.3.9: icmp_seq=4 ttl=64 time=1.434 ms 64 bytes from 10.0.3.9: icmp_seq=5 ttl=64 time=1.306 ms ^C --- 10.0.3.9 ping statistics --6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.271/9.826/52.304/18.997 ms user@R1> ping 10.0.3.10 PING 10.0.3.10 (10.0.3.10): 56 data bytes 64 bytes from 10.0.3.10: icmp_seq=0 ttl=64 time=1.431 ms 64 bytes from 10.0.3.10: icmp_seq=1 ttl=64 time=1.296 ms 64 bytes from 10.0.3.10: icmp_seq=2 ttl=64 time=1.887 ms ^C --- 10.0.3.10 ping statistics --3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.296/1.538/1.887/0.253 ms user@R2> ping 10.0.2.9 PING 10.0.2.9 (10.0.2.9): 56 data bytes 64 bytes from 10.0.2.9: icmp_seq=0 ttl=64 time=1.365 ms 64 bytes from 10.0.2.9: icmp_seq=1 ttl=64 time=1.813 ms 64 bytes from 10.0.2.9: icmp_seq=2 ttl=64 time=1.290 ms ^C --- 10.0.2.9 ping statistics --3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.290/1.489/1.813/0.231 ms user@R2> ping 10.0.2.10

378



PING 10.0.2.10 (10.0.2.10): 56 data bytes 64 bytes from 10.0.2.10: icmp_seq=0 ttl=63 time=1.318 ms 64 bytes from 10.0.2.10: icmp_seq=1 ttl=63 time=1.394 ms 64 bytes from 10.0.2.10: icmp_seq=2 ttl=63 time=1.366 ms 64 bytes from 10.0.2.10: icmp_seq=3 ttl=63 time=1.305 ms ^C --- 10.0.2.10 ping statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.305/1.346/1.394/0.036 ms user@R3> ping 10.0.1.10 PING 10.0.1.10 (10.0.1.10): 56 data bytes 64 bytes from 10.0.1.10: icmp_seq=0 ttl=63 time=1.316 ms 64 bytes from 10.0.1.10: icmp_seq=1 ttl=63 time=1.418 ms 64 bytes from 10.0.1.10: icmp_seq=2 ttl=63 time=1.277 ms ^C --- 10.0.1.10 ping statistics --3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.277/1.337/1.418/0.059 ms user@R3> ping 10.0.1.9 PING 10.0.1.9 (10.0.1.9): 56 data bytes 64 bytes from 10.0.1.9: icmp_seq=0 ttl=64 time=1.381 ms 64 bytes from 10.0.1.9: icmp_seq=1 ttl=64 time=1.499 ms 64 bytes from 10.0.1.9: icmp_seq=2 ttl=64 time=1.300 ms 64 bytes from 10.0.1.9: icmp_seq=3 ttl=64 time=1.397 ms ^C --- 10.0.1.9 ping statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.300/1.394/1.499/0.071 ms

Meaning

Routers R1, R2, and R3 have a peer relationship with each other. Verifying That IS-IS Is Configured

Purpose

Make sure that the IS-IS instance is running on Routers R1, R2, and R3, and that they are adjacent to each other.

Action

Use the show isis adjacency detail statement to check the adjacency between the routers. Router R1 user@R1> show isis adjacency detail R2 Interface: so-0/0/0, Level: 1, State: Up, Expires in 8 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:23:59 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bd Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R2.02, IP addresses: 10.0.1.10 R2 Interface: so-0/0/0, Level: 2, State: Up, Expires in 8 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:23:58 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bd


379


Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R2.02, IP addresses: 10.0.1.10 R3 Interface: so-1/0/0, Level: 1, State: Up, Expires in 7 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:24:20 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bd Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R3.02, IP addresses: 10.0.2.10 R3 Interface: so-1/0/0, Level: 2, State: Up, Expires in 6 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:24:20 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bd Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R3.02, IP addresses: 10.0.2.10

Router R2 user@R2> show isis adjacency detail R1 Interface: so-0/0/0, Level: 1, State: Up, Expires in 20 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:27:50 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bc Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R2.02, IP addresses: 10.0.1.9 R1 Interface: so-0/0/0, Level: 2, State: Up, Expires in 26 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:27:50 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bc Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R2.02, IP addresses: 10.0.1.9 R3 Interface: so-1/0/0, Level: 1, State: Up, Expires in 8 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:27:22 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bd Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R3.03, IP addresses: 10.0.3.10 R3 Interface: so-1/0/0, Level: 2, State: Up, Expires in 8 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:27:22 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bd Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R3.03, IP addresses: 10.0.3.10

Router R3 user@R3> show isis adjacency detail R2 Interface: so-0/0/0, Level: 1, State: Up, Expires in 18 secs

380



Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:33:09 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bc Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R3.03, IP addresses: 10.0.3.9 R2 Interface: so-0/0/0, Level: 2, State: Up, Expires in 22 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:33:09 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bc Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R3.03, IP addresses: 10.0.3.9 R1 Interface: so-1/0/0, Level: 1, State: Up, Expires in 21 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:33:59 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bc Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R3.02, IP addresses: 10.0.2.9 R1 Interface: so-1/0/0, Level: 2, State: Up, Expires in 19 secs Priority: 64, Up/Down transitions: 1, Last transition: 2d 19:33:59 ago Circuit type: 3, Speaks: IP, MAC address: 0:1b:c0:86:54:bc Topologies: IPV4-Multicast Restart capable: Yes, Adjacency advertisement: Advertise LAN id: R3.02, IP addresses: 10.0.2.9

Meaning

IS-IS is configured on Routers R1, R2, and R3 and they are adjacent to each other. Verifying the Configured Multicast Metric Values

Purpose

Action

Make sure that the SPF calculations are accurate as per the configured multicast metric values on Routers R1, R2, and R3. Use the show isis spf results statement to check the SPF calculations for the network. Router R1 user@R1> show isis spf results ... IPV4 Multicast IS-IS level 1 SPF results: Node Metric Interface NH Via R3.03 28 so-1/0/0 IPV4 R3 R2.00 18 so-0/0/0 IPV4 R2 R3.00 17 so-1/0/0 IPV4 R3 R1.00 0 4 nodes IPV4 Multicast IS-IS level 2 SPF results: Node Metric Interface NH Via R3.03 40 so-0/0/0 IPV4 R2 R3.00 22 so-1/0/0 IPV4 R3 R2.00 14 so-0/0/0 IPV4 R2 R1.00 0 4 nodes


SNPA 0:1b:c0:86:54:bd 0:1b:c0:86:54:bd 0:1b:c0:86:54:bd

SNPA 0:1b:c0:86:54:bd 0:1b:c0:86:54:bd 0:1b:c0:86:54:bd

381


Router R2 user@R2> show isis spf results ... IPV4 Multicast IS-IS level 1 SPF results: Node Metric Interface NH Via R3.02 29 so-0/0/0 IPV4 R1 R3.00 18 so-1/0/0 IPV4 R3 R1.00 12 so-0/0/0 IPV4 R1 R2.02 12 R2.00 0 5 nodes IPV4 Multicast IS-IS level 2 SPF results: Node Metric Interface NH Via R3.02 45 so-0/0/0 IPV4 R1 R3.00 26 so-1/0/0 IPV4 R3 R1.00 23 so-0/0/0 IPV4 R1 R2.02 23 R2.00 0 5 nodes

SNPA 0:1b:c0:86:54:bc 0:1b:c0:86:54:bd 0:1b:c0:86:54:bc

SNPA 0:1b:c0:86:54:bc 0:1b:c0:86:54:bd 0:1b:c0:86:54:bc

Router R3 user@R3> show isis spf results ... IPV4 Multicast IS-IS level 1 SPF results: Node Metric Interface NH Via R3.02 26 R1.00 23 so-0/0/0 IPV4 R2 R2.02 23 so-0/0/0 IPV4 R2 R2.00 11 so-0/0/0 IPV4 R2 R3.03 11 R3.00 0 6 nodes IPV4 Multicast IS-IS level 2 SPF results: Node Metric Interface NH Via R2.02 34 so-1/0/0 IPV4 R1 R2.00 21 so-0/0/0 IPV4 R2 R3.03 21 R1.00 20 so-1/0/0 IPV4 R1 R3.02 20 R3.00 0 6 nodes

Meaning

SNPA 0:1b:c0:86:54:bc 0:1b:c0:86:54:bc 0:1b:c0:86:54:bc

SNPA 0:1b:c0:86:54:bc 0:1b:c0:86:54:bc 0:1b:c0:86:54:bc

The configured multicast metric values are used in SPF calculations for the IS-IS network. Verifying the Configuration of Multicast Topology

Purpose Action

Make sure that multicast topology is configured on Routers R1, R2, and R3. Use the show isis database detail statement to verify the multicast topology configuration on the routers. Router R1 user@R1> show isis database detail IS-IS level 1 link-state database:

382



R1.00-00 Sequence: 0x142, Checksum: 0xd07, Lifetime: 663 secs IPV4 Unicast IS neighbor: R2.02 Metric: 15 IPV4 Unicast IS neighbor: R3.02 Metric: 15 IPV4 Multicast IS neighbor: R2.02 Metric: 18 IPV4 Multicast IS neighbor: R3.02 Metric: 17 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 15 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 15 Internal Up R2.00-00 Sequence: 0x13f, Checksum: 0xf02b, Lifetime: 883 secs IPV4 Unicast IS neighbor: R2.02 Metric: 13 IPV4 Unicast IS neighbor: R3.03 Metric: 14 IPV4 Multicast IS neighbor: R2.02 Metric: 12 IPV4 Multicast IS neighbor: R3.03 Metric: 18 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 13 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 14 Internal Up R2.02-00 Sequence: 0x13c, Checksum: 0x57e2, Lifetime: 913 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R2.00 Metric: 0 R3.00-00 Sequence: 0x13c, Checksum: 0xc8de, Lifetime: 488 secs IPV4 Unicast IS neighbor: R3.02 Metric: 16 IPV4 Unicast IS neighbor: R3.03 Metric: 19 IPV4 Multicast IS neighbor: R3.02 Metric: 26 IPV4 Multicast IS neighbor: R3.03 Metric: 11 IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 16 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 19 Internal Up R3.02-00 Sequence: 0x139, Checksum: 0xfb0e, Lifetime: 625 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0 R3.03-00 Sequence: 0x138, Checksum: 0xad56, Lifetime: 714 secs IPV4 Unicast IS neighbor: R2.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0 IS-IS level 2 link-state database: R1.00-00 Sequence: 0x142, Checksum: 0x2c7c, Lifetime: 816 secs IPV4 Unicast IS neighbor: R2.02 Metric: 20 IPV4 Unicast IS neighbor: R3.02 Metric: 31 IPV4 Multicast IS neighbor: R2.02 Metric: 14 IPV4 Multicast IS neighbor: R3.02 Metric: 22 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 20 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 31 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 29 Internal Up R2.00-00 Sequence: 0x13f, Checksum: 0x4826, Lifetime: 966 secs IPV4 Unicast IS neighbor: R2.02 Metric: 29 IPV4 Unicast IS neighbor: R3.03 Metric: 32 IPV4 Multicast IS neighbor: R2.02 Metric: 23 IPV4 Multicast IS neighbor: R3.03 Metric: 26 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 29 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 28 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 32 Internal Up R2.02-00 Sequence: 0x13c, Checksum: 0x57e2, Lifetime: 966 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R2.00 Metric: 0


383


R3.00-00 Sequence: 0x13d, Checksum: 0x1b19, Lifetime: 805 secs IPV4 Unicast IS neighbor: R3.02 Metric: 30 IPV4 Unicast IS neighbor: R3.03 Metric: 27 IPV4 Multicast IS neighbor: R3.02 Metric: 20 IPV4 Multicast IS neighbor: R3.03 Metric: 21 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 31 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 30 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 27 Internal Up R3.02-00 Sequence: 0x139, Checksum: 0xfb0e, Lifetime: 844 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0 R3.03-00 Sequence: 0x139, Checksum: 0xab57, Lifetime: 844 secs IPV4 Unicast IS neighbor: R2.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0

Router R2 user@R2> show isis database detail IS-IS level 1 link-state database: R1.00-00 Sequence: 0x142, Checksum: 0xd07, Lifetime: 524 secs IPV4 Unicast IS neighbor: R2.02 Metric: 15 IPV4 Unicast IS neighbor: R3.02 Metric: 15 IPV4 Multicast IS neighbor: R2.02 Metric: 18 IPV4 Multicast IS neighbor: R3.02 Metric: 17 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 15 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 15 Internal Up R2.00-00 Sequence: 0x13f, Checksum: 0xf02b, Lifetime: 748 secs IPV4 Unicast IS neighbor: R2.02 Metric: 13 IPV4 Unicast IS neighbor: R3.03 Metric: 14 IPV4 Multicast IS neighbor: R2.02 Metric: 12 IPV4 Multicast IS neighbor: R3.03 Metric: 18 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 13 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 14 Internal Up R2.02-00 Sequence: 0x13c, Checksum: 0x57e2, Lifetime: 777 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R2.00 Metric: 0 R3.00-00 Sequence: 0x13d, Checksum: 0xc6df, Lifetime: 1102 secs IPV4 Unicast IS neighbor: R3.02 Metric: 16 IPV4 Unicast IS neighbor: R3.03 Metric: 19 IPV4 Multicast IS neighbor: R3.02 Metric: 26 IPV4 Multicast IS neighbor: R3.03 Metric: 11 IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 16 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 19 Internal Up R3.02-00 Sequence: 0x139, Checksum: 0xfb0e, Lifetime: 488 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0 R3.03-00 Sequence: 0x138, Checksum: 0xad56, Lifetime: 577 secs IPV4 Unicast IS neighbor: R2.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0 IS-IS level 2 link-state database: R1.00-00 Sequence: 0x142, Checksum: 0x2c7c, Lifetime: 676 secs

384



IPV4 Unicast IS neighbor: R2.02 Metric: IPV4 Unicast IS neighbor: R3.02 Metric: IPV4 Multicast IS neighbor: R2.02 Metric: IPV4 Multicast IS neighbor: R3.02 Metric: IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: IP IPV4 Unicast prefix: 10.0.3.8/30 Metric:

20 31 14 22 20 Internal Up 31 Internal Up 29 Internal Up

R2.00-00 Sequence: 0x13f, Checksum: 0x4826, Lifetime: 831 secs IPV4 Unicast IS neighbor: R2.02 Metric: 29 IPV4 Unicast IS neighbor: R3.03 Metric: 32 IPV4 Multicast IS neighbor: R2.02 Metric: 23 IPV4 Multicast IS neighbor: R3.03 Metric: 26 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 29 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 28 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 32 Internal Up R2.02-00 Sequence: 0x13c, Checksum: 0x57e2, Lifetime: 831 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R2.00 Metric: 0 R3.00-00 Sequence: 0x13d, Checksum: 0x1b19, Lifetime: 667 secs IPV4 Unicast IS neighbor: R3.02 Metric: 30 IPV4 Unicast IS neighbor: R3.03 Metric: 27 IPV4 Multicast IS neighbor: R3.02 Metric: 20 IPV4 Multicast IS neighbor: R3.03 Metric: 21 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 31 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 30 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 27 Internal Up R3.02-00 Sequence: 0x139, Checksum: 0xfb0e, Lifetime: 707 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0 R3.03-00 Sequence: 0x139, Checksum: 0xab57, Lifetime: 707 secs IPV4 Unicast IS neighbor: R2.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0

Router R3 user@R3> show isis database detail IS-IS level 1 link-state database: R1.00-00 Sequence: 0x143, Checksum: 0xb08, Lifetime: 1155 secs IPV4 Unicast IS neighbor: R2.02 Metric: 15 IPV4 Unicast IS neighbor: R3.02 Metric: 15 IPV4 Multicast IS neighbor: R2.02 Metric: 18 IPV4 Multicast IS neighbor: R3.02 Metric: 17 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 15 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 15 Internal Up R2.00-00 Sequence: 0x13f, Checksum: 0xf02b, Lifetime: 687 secs IPV4 Unicast IS neighbor: R2.02 Metric: 13 IPV4 Unicast IS neighbor: R3.03 Metric: 14 IPV4 Multicast IS neighbor: R2.02 Metric: 12 IPV4 Multicast IS neighbor: R3.03 Metric: 18 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 13 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 14 Internal Up R2.02-00 Sequence: 0x13c, Checksum: 0x57e2, Lifetime: 716 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0


385


IPV4 Unicast IS neighbor: R2.00

Metric:

0

R3.00-00 Sequence: 0x13d, Checksum: 0xc6df, Lifetime: 1044 secs IPV4 Unicast IS neighbor: R3.02 Metric: 16 IPV4 Unicast IS neighbor: R3.03 Metric: 19 IPV4 Multicast IS neighbor: R3.02 Metric: 26 IPV4 Multicast IS neighbor: R3.03 Metric: 11 IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 16 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 19 Internal Up R3.02-00 Sequence: 0x139, Checksum: 0xfb0e, Lifetime: 430 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0 R3.03-00 Sequence: 0x138, Checksum: 0xad56, Lifetime: 519 secs IPV4 Unicast IS neighbor: R2.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0 IS-IS level 2 link-state database: R1.00-00 Sequence: 0x142, Checksum: 0x2c7c, Lifetime: 617 secs IPV4 Unicast IS neighbor: R2.02 Metric: 20 IPV4 Unicast IS neighbor: R3.02 Metric: 31 IPV4 Multicast IS neighbor: R2.02 Metric: 14 IPV4 Multicast IS neighbor: R3.02 Metric: 22 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 20 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 31 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 29 Internal Up R2.00-00 Sequence: 0x13f, Checksum: 0x4826, Lifetime: 769 secs IPV4 Unicast IS neighbor: R2.02 Metric: 29 IPV4 Unicast IS neighbor: R3.03 Metric: 32 IPV4 Multicast IS neighbor: R2.02 Metric: 23 IPV4 Multicast IS neighbor: R3.03 Metric: 26 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 29 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 28 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 32 Internal Up R2.02-00 Sequence: 0x13c, Checksum: 0x57e2, Lifetime: 769 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R2.00 Metric: 0 R3.00-00 Sequence: 0x13d, Checksum: 0x1b19, Lifetime: 610 secs IPV4 Unicast IS neighbor: R3.02 Metric: 30 IPV4 Unicast IS neighbor: R3.03 Metric: 27 IPV4 Multicast IS neighbor: R3.02 Metric: 20 IPV4 Multicast IS neighbor: R3.03 Metric: 21 IP IPV4 Unicast prefix: 10.0.1.8/30 Metric: 31 Internal Up IP IPV4 Unicast prefix: 10.0.2.8/30 Metric: 30 Internal Up IP IPV4 Unicast prefix: 10.0.3.8/30 Metric: 27 Internal Up R3.02-00 Sequence: 0x139, Checksum: 0xfb0e, Lifetime: 649 secs IPV4 Unicast IS neighbor: R1.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0 R3.03-00 Sequence: 0x139, Checksum: 0xab57, Lifetime: 649 secs IPV4 Unicast IS neighbor: R2.00 Metric: 0 IPV4 Unicast IS neighbor: R3.00 Metric: 0

Meaning

386

Multicast topology is configured on routers R1, R2, and R3.



Configuring IS-IS IPv6 Unicast Topologies You can configure IS-IS to calculate an alternate IPv6 unicast topology, in addition to the normal IPv4 unicast topology, and add the corresponding routes to inet6.0. The IS-IS interface metrics for the IPv4 topology can be configured independently of the IPv6 metrics. You can also selectively disable interfaces from participating in the IPv6 topology while continuing to participate in the IPv4 topology. This lets you exercise control over the paths that unicast data takes through a network. To enable an alternate IPv6 unicast topology for IS-IS, include the ipv6-unicast statement: isis { topologies { ipv6-unicast; } }

To configure a metric for an alternate IPv6 unicast topology, include the ipv6-unicast-metric statement: isis { interface interface-name { level level-number { ipv6-unicast-metric number; } } }

To exclude an interface from the IPv6 unicast topologies for IS-IS, include the no-ipv6-unicast statement: isis { interface interface-name { no-ipv6-unicast; } }


Configuring Point-to-Point Interfaces for IS-IS You can use the point-to-point statement to configure a LAN interface to act like a point-to-point interface for IS-IS. You do not need an unnumbered LAN interface, and it has no effect if configured on an interface that is already point-to-point. The point-to-point statement affects only IS-IS protocol procedures on that interface; all other protocols continue to treat the interface as a LAN interface. Only two IS-IS routing devices can be connected to the LAN interface and both must be configured as point-to-point. To configure a point-to-point IS-IS interface, include the point-to-point statement: point-to-point;


387



Configuring Levels on IS-IS Interfaces You can administratively divide a single AS into smaller groups called areas. You configure each routing device interface to be in an area. Any interface can be in any area. The area address applies to the entire routing device; you cannot specify one interface to be in one area and another interface in a different area. In order to route between areas you must have two adjacent Level 2 routers that communicate with each other. Level 1 routers can only route within their IS-IS area. To send traffic outside their area, Level 1 routers must send packets to the nearest intra-area Level 2 router. A routing device can be a Level 1 router, a Level 2 router, or both. You specify the router level on a per-interface basis, and a routing device becomes adjacent with other routing devices on the same level on that link only. You can configure one Level 1 routing process and one Level 2 routing process on each interface, and you can configure the two levels differently. To configure an area, include the level statement: level level-number { disable; hello-authentication-key key; hello-authentication-key-chain key-chain-name; hello-authentication-type authentication; hello-interval seconds; hold-time seconds; ipv4-multicast-metric number; ipv6-multicast-metric number; ipv6-unicast-metric number; metric metric; passive; priority number; te-metric metric; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. The statements within the level statement allow you to perform the following tasks when configuring the following optional level-specific properties:

388

•

Disabling IS-IS at a Level on IS-IS Interfaces on page 389

•

Advertising Interface Addresses Without Running IS-IS on page 389

•

Configuring Authentication for IS-IS Hello Packets on page 390

•

Configuring the Transmission Frequency for IS-IS Hello Packets on page 390

•

Configuring the Delay Before IS-IS Neighbors Mark the Routing Device as Down on page 391

•

Configuring the Metric Value for IS-IS Routes on page 391



•

Configuring the IS-IS Metric Value Used for Traffic Engineering on page 391

•

Configuring the Designated Router Priority for IS-IS on page 391

•


Disabling IS-IS at a Level on IS-IS Interfaces By default, IS-IS is enabled for IS-IS areas on all enabled interfaces on which the ISO protocol family is enabled (at the [edit interfaces interface unit logical-unit-number] hierarchy level). To disable IS-IS at any particular level on an interface, include the disable statement: disable;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. Enabling IS-IS on an interface (by including the interface statement at the [edit protocols isis] hierarchy level), disabling it (by including the disable statement), and not actually having IS-IS run on an interface (by including the passive statement) are mutually exclusive states.

Example: Disabling IS-IS at a Level On SONET/SDH interface so-0/0/0, enable IS-IS for Level 1 only. With this configuration, tracing messages periodically indicate that IS-IS is creating Level 2 link-state PDUs. However, because IS-IS for Level 2 is disabled, these link-state PDUs are never distributed to neighboring routers. protocols { isis { traceoptions { file isis size 1m files 10; flag spf; flag lsp; flag error; } interface so-0/0/0 { level 2 { disable; } } } }

Advertising Interface Addresses Without Running IS-IS By default, IS-IS must be configured on an interface or a level for direct interface addresses to be advertised into that level. To advertise the direct interface addresses without actually running IS-IS on that interface or level, include the passive statement: passive;



389


Enabling IS-IS on an interface (by including the interface statement at the [edit protocols isis] hierarchy level), disabling it (by including the interface disable statement), and not actually having IS-IS run on an interface (by including the passive statement) are mutually exclusive states.

NOTE: If neither passive mode nor family ISO are configured on the IS-IS interface, then the routing device treats the interface as not being operational and no direct IPv4/IPv6 routes are exported into IS-IS.

Configuring Authentication for IS-IS Hello Packets You can configure authentication for a given IS-IS level on an interface. On a point-to-point link, if you enable hello authentication for both IS-IS levels, the password configured for Level 1 is used for both levels.

CAUTION: If no authentication is configured for Level 1 on a point-to-point link with both levels enabled, the hello packets are sent without any password, regardless of the Level 2 authentication configurations.

By default, hello authentication is not configured on an interface. However, if IS-IS authentication is configured, the hello packets are authenticated using the IS-IS authentication type and password. To enable hello authentication for an IS-IS level on an interface and define the password, include the hello-authentication-type and hello-authentication-key statements. To configure hitless authentication key rollover, include the hello-authentication-key-chain statement: hello-authentication-type (md5 | simple); hello-authentication-key password; hello-authentication-key-chain key-chain-name;


Configuring the Transmission Frequency for IS-IS Hello Packets Routing devices send hello packets at a fixed interval on all interfaces to establish and maintain neighbor relationships. This interval is advertised in the hello interval field in the hello packet. By default, a designated intersystem (DIS) router sends hello packets every 3 seconds, and a non-DIS router sends hello packets every 9 seconds. To modify how often the routing device sends hello packets out of an interface, include the hello-interval statement: hello-interval seconds;

The hello interval range is from 1 through 20,000 seconds.

390



You can send out hello packets in sub-second intervals. To send out hello packets every 333 milliseconds, set the hello-interval value to 1. For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Configuring the Delay Before IS-IS Neighbors Mark the Routing Device as Down The hold time specifies how long a neighbor should consider this routing device to be operative without receiving another hello packet. If the neighbor does not receive a hello packet from this routing device within the hold time, it marks the routing device as being unavailable. The default hold-time value is three times the default hello interval: 9 seconds for a DIS router and 27 seconds for a non-DIS router. To modify the hold-time value on the local routing device, include the hold-time statement: hold-time seconds;


Configuring the Metric Value for IS-IS Routes All IS-IS routes have a cost, which is a routing metric that is used in the IS-IS link-state calculation. The cost is an arbitrary, dimensionless integer that can be from 1 through 63, 24 or from 1 through 16,777,215 (2 – 1) if you are using wide metrics. The default metric value is 10 (with the exception of the lo0 interface, which has a default metric of 0). To modify the default value, include the metric statement: metric metric;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. For more information about IS-IS interface metrics, see “Configuring the Reference Bandwidth Used in IS-IS Metric Calculations” on page 392.

Configuring the IS-IS Metric Value Used for Traffic Engineering When traffic engineering is enabled on the routing device, you can configure an IS-IS metric that is used exclusively for traffic engineering. The traffic engineering metric is used for information injected into the traffic engineering database. Its value does not affect normal IS-IS forwarding. To modify the default value, include the te-metric statement: te-metric metric;


Configuring the Designated Router Priority for IS-IS A routing device advertises its priority to become a designated router in its hello packets. On all multiaccess networks, IS-IS uses the advertised priorities to elect a designated


391


router for the network. This routing device is responsible for sending network link-state advertisements, which describe all the routing devices attached to the network. These advertisements are flooded throughout a single area. The priority value is meaningful only on a multiaccess network. It has no meaning on a point-to-point interface. A routing device’s priority for becoming the designated router is indicated by an arbitrary number from 0 through 127; routing devices with a higher value are more likely to become the designated router. By default, routing devices have a priority value of 64. To modify the interface’s priority value, include the priority statement: priority number;


Advertising Interface Addresses Without Running IS-IS The routing device can advertise the direct interface addresses on an interface or on a sub-level of the interface without actually running IS-IS on that interface or at that level. This occurs in passive mode. To enable an interface as passive, include the passive statement: passive;


Configuring the Reference Bandwidth Used in IS-IS Metric Calculations All IS-IS interfaces have a cost, which is a routing metric that is used in the IS-IS link-state calculation. Routes with lower total path metrics are preferred over those with higher path metrics. When there are several equal-cost routes to a destination, traffic is distributed equally among them. The cost of a route is described by a single dimensionless metric that is determined using the following formula: cost = reference-bandwidth/bandwidth

To modify the reference bandwidth, include the reference-bandwidth statement: reference-bandwidth reference-bandwidth;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. reference-bandwidth is the reference bandwidth. If the reference bandwidth is not

configured, all interfaces have a default metric of 10 (with the exception of the lo0 interface, which has a default metric of 0).

392



For example, if you set the reference bandwidth to 1 Gbps (that is, reference-bandwidth is set to 1,000,000,000), a 100-Mbps interface has a default metric of 10. For more information about IS-IS route metrics, see “Configuring the Metric Value for IS-IS Routes” on page 391.

Limiting the Number of Advertised IS-IS Areas By default, IS-IS advertises a maximum of three areas in the IS-IS hello (IIH) PDUs and link-state PDUs. To advertise more than three ISO network addresses for a router, include the max-areas statement: max-areas number;

The range that you can configure is from 3 through 36, and the default is 3. This value is included in the Maximum Address Area field of the IS-IS common PDU header included in all outgoing PDUs.

NOTE: The maximum number areas you can advertise is restricted to 36 to ensure that the IIH PDUs have enough space to include other type, length, and value (TLV) fields, such as the Authentication and IPv4 and IPv6 Interface Address TLVs.

For a list of hierarchy levels at which you an configure this statement, see the statement summary section for this statement.

Enabling Wide IS-IS Metrics for Traffic Engineering Normally, IS-IS metrics can have values up to 63, and IS-IS generates two type length values (TLVs), one for an IS-IS adjacency and the second for an IP prefix. To allow IS-IS to support traffic engineering, a second pair of TLVs has been added to IS-IS, one for IP prefixes and the second for IS-IS adjacency and traffic engineering information. With 24 these TLVs, IS-IS metrics can have values up to 16,777,215 (2 – 1). By default, the Junos OS supports the sending and receiving of wide metrics. The Junos OS allows a maximum metric value of 63 and generates both pairs of TLVs. To configure IS-IS to generate only the new pair of TLVs and thus to allow the wider range of metric values, include the wide-metrics-only statement: wide-metrics-only;


Configuring Preference Values for IS-IS Routes Route preferences are used to select which route is installed in the forwarding table when several protocols calculate routes to the same destination. The route with the lowest preference value is selected. For more information about route preferences, see “Route Preferences Overview” on page 6.


393


By default, Level 1 IS-IS internal routes have a preference value of 15, Level 2 IS-IS internal routes have a preference of 18, Level 1 IS-IS external routes have a preference of 160, and Level 2 external routes have a preference of 165. To change the preference values, include the preference statement (for internal routes) or the external-preference statement: external-preference preference; preference preference;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. 32

The preference value can range from 0 through 4,294,967,295 (2

– 1).

Limiting the Number of Prefixes Exported to IS-IS By default, there is no limit to the number of prefixes that can be exported into IS-IS. To configure a limit to the number of prefixes that can be exported into IS-IS, include the prefix-export-limit statement: prefix-export-limit number;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. You can specify a number range from 0 through 4,294,967,295.

Configuring Link-State PDU Lifetime for IS-IS By default, link-state PDUs are maintained in network databases for 1200 seconds (20 minutes) before being considered invalid. This length of time, called the LSP lifetime, normally is sufficient to guarantee that link-state PDUs never expire. To modify the link-state PDU lifetime, include the lsp-lifetime statement: lsp-lifetime seconds;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. The time can range from 350 through 65,535 seconds. The link-state PDU refresh interval is derived from the link-state PDU lifetime and is equal to the lifetime minus 317 seconds.

Advertising Label-Switched Paths into IS-IS You can advertise label-switched paths into IS-IS as point-to-point links, and the label-switched paths can be used in SPF calculations. The advertisement contains a local address (the from address of the label-switched path), a remote address (the to address of the label-switched path), and a metric with the following precedence:

394

•

Use the label-switched path metric defined under IS-IS.

•

Use the label-switched path metric configured for the label-switched path under MPLS.



•

If you do not configure any of the above, use the default IS-IS metric of 10.

To advertise label-switched paths, include the label-switched-path statement, with a specified level and metric: label-switched-path name level level metric metric;


NOTE: Before a single-hop label-switched path between a multiaccess link can be announced as up and used in SPF calculations, you must configure a label-switched path in both directions between two label-switched routers.


•


Configuring IS-IS to Make Routing Devices Appear Overloaded If the time elapsed after the IS-IS instance is enabled is less than the specified timeout, overload mode is set. You configure or disable overload mode in IS-IS with or without a timeout. Without a timeout, overload mode is set until it is explicitly deleted from the configuration. With a timeout, overload mode is set if the time elapsed since the IS-IS instance started is less than the specified timeout. A timer is started for the difference between the timeout and the time elapsed since the instance started. When the timer expires, overload mode is cleared. In overload mode, the routing device IS-IS advertisements are originated with the overload bit set. This causes the transit traffic to avoid the overloaded routing device and take paths around the routing device. However, the overloaded routing device’s own links are still accessible. In overload mode, the routing device advertisement is originated with all the transit routing device links (except stub) set to a metric of 0xFFFF. The stub routing device links are advertised with the actual cost of the interfaces corresponding to the stub. This causes the transit traffic to avoid the overloaded routing device and take paths around the routing device. However, the overloaded routing device’s own links are still accessible. You can configure the local routing device so that it appears to be overloaded. You might want to do this when you want the routing device to participate in IS-IS routing, but do not want it to be used for transit traffic. (Note that traffic to immediately attached interfaces continues to transit the routing device.) To mark the routing device as overloaded, include the overload statement: overload { advertise-high-metrics; allow-route-leaking; timeout seconds; }


395


To advertise maximum link metrics in network layer reachability information (NLRI) instead of setting the overload bit, include the advertise-high-metrics option when specifying the overload statement: advertise-high-metrics;

When you configure the advertise-high-metrics option, the routing device in overload mode stops passing (leaking) route information into the network. So, an L1-L2 router in overload mode stops passing route information between L1 and L2 levels and clears its attached bit when the advertise-high-metrics option is configured. To allow route information to pass (leak) into the network when the routing device is in overload mode, include the allow-route-leaking option when specifying the overload statement: allow-route-leaking;

NOTE: The allow-route-leaking option will not work if the routing device is in dynamic overload mode. Dynamic overload can occur if the device has exceeded its resource limits, such as the prefix limit.

To specify the number of seconds at which overload is reset, include the timeout option when specifying the overload statement: overload timeout seconds;

The time can range from 60 through 1800 seconds. For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

Configuring SPF Options for IS-IS You can configure the following shortest-path-first (SPF) options: •

The delay in the time between the detection of a topology change and when the SPF algorithm actually runs.

•

The maximum number of times that the SPF algorithm can run in succession before the hold-down timer begins.

•

The time to hold down, or wait, before running another SPF calculation after the SPF algorithm has run in succession the configured maximum number of times.

To configure SPF options, include the spf-options statement: spf-options { delay milliseconds; holddown milliseconds; rapid-runs number; }

396



To configure the SPF delay, include the delay statement when specifying the spf-options statement: delay milliseconds;

By default, the SPF algorithm runs 200 milliseconds after the detection of a topology change. The range that you can configure is from 50 through 1000 milliseconds. To configure the maximum number of times that the SPF algorithm can run in succession, include the rapid-runs statement when specifying the spf-options statement: rapid-runs number;

The default number of SPF calculations that can occur in succession is 3. The range that you can configure is from 1 through 5. Each SPF algorithm is run after the configured SPF delay. When the maximum number of SPF calculations occurs, the hold-down timer begins. Any subsequent SPF calculation is not run until the hold-down timer expires. To configure the SPF hold-down timer, include the holddown statement when specifying the spf-options statement: holddown milliseconds;

The default is 5000 milliseconds, and the range that you can configure is from 2000 through 10,000 milliseconds. Use the hold-down timer to hold down, or wait, before running any subsequent SPF calculations after the SPF algorithm runs for the configured maximum number of times. If the network stabilizes during the hold-down period and the SPF algorithm does not need to run again, the system reverts to the configured values for the delay and rapid-runs statements.

Configuring Graceful Restart for IS-IS Graceful restart allows a routing device to restart with minimal effects to the network, and is enabled globally for all routing protocols at the [edit routing-options] hierarchy level. When graceful restart for IS-IS is enabled, the restarting routing device is not removed from the network topology during the restart period. The adjacencies are reestablished after restart is complete. You can configure graceful restart parameters specifically for IS-IS. To do this, include the graceful-restart statement: graceful-restart { helper-disable; restart-duration seconds; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To disable graceful restart for IS-IS, specify the disable statement. Helper mode is enabled by default. To disable the graceful restart helper capability, specify the helper-disable statement. To configure a time period for complete restart, specify the restart-duration statement. You can specify a number between 1 and 3600. The default value is 90 seconds.


397


Configuring IS-IS for Multipoint Network Clouds IS-IS does not support multipoint configurations. Therefore, when configuring Frame Relay or Asynchronous Transfer Mode (ATM) networks, you must configure them as collections of point-to-point links, not as multipoint clouds.

Configuring IS-IS Traffic Engineering Attributes You can configure the following IS-IS traffic engineering attributes: •

Configuring IS-IS to Use IGP Shortcuts on page 398

•

Configuring IS-IS to Ignore the Metric of RSVP Label-Switched Paths on page 399

•

Disabling IS-IS Support for Traffic Engineering on page 400

•

Installing IPv4 Routes into the Multicast Routing Table on page 400

•

Configuring IS-IS to Use Protocol Preference to Determine the Traffic Engineering Database Credibility Value on page 400

When configuring traffic engineering support, you can also configure IS-IS to use metric values greater than 63, as described in “Enabling Wide IS-IS Metrics for Traffic Engineering” on page 393.

Configuring IS-IS to Use IGP Shortcuts IS-IS always performs SPF calculations to determine next hops. For prefixes reachable through a particular next hop, IS-IS places that next hop for that prefix in the inet.0 routing table. In addition, for routers running MPLS, IS-IS installs the prefix for IPv4 routes in the inet.3 routing table as well. The inet.3 table, which is present on the ingress router, contains the host address of each MPLS label-switched path (LSP) egress router. BGP uses this routing table to resolve next-hop addresses. If you enable IS-IS traffic engineering shortcuts and if there is a label-switched path to a point along the path to that prefix, IS-IS installs the prefix in the inet.3 routing table and uses the LSP as a next hop. The net result is that for BGP egress routers for which there is no LSP, BGP automatically uses an LSP along the path to reach the egress router. In Junos OS Release 9.3 and later, IS-IS traffic engineering shortcuts support IPv6 routes. LSPs to be used for shortcuts continue to be signaled using IPv4. However, by default, shortcut routes calculated through IPv6 routes are added to the inet6.3 routing table. The default behavior is for only BGP to use LSPs in its calculations. If you configure MPLS so that both BGP and interior gateway protocols use LSPs for forwarding traffic, shortcut routes calculated through IPv6 are added to the inet6.0 routing table. IS-IS ensures that the IPv6 routes running over the IPv4 MPLS LSP are correctly de-encapsulated at the tunnel egress by pushing an extra IPv6 explicit null label between the IPv6 payload and the IPv4 transport label. RSVP LSPs with a higher preference than IS-IS routes are not considered during the computation of traffic engineering shortcuts.

398



To configure IS-IS so that it uses label-switched paths as shortcuts when installing information in the inet.3 or inet6.3 routing table, include the following statements: traffic-engineering { family inet { shortcuts; } } family inet6 { shortcuts; } }

For IPv4 traffic, include the inet statement. For IPv6 traffic, include the inet6 statement. To ignore the metric of RSVP LSPs in shortcut decisions, include the ignore-lsp-metrics statement: traffic-engineering { ignore-lsp-metrics; }

This option avoids mutual dependency between IS-IS and RSVP, eliminating the time period when the RSVP metric used for shortcuts is not up to date. For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Because the inet.3 routing table is present only on ingress routers, you can configure LSP shortcuts only on these routers. For more information about configuring LSPs and MPLS, see the Junos OS MPLS Applications Configuration Guide.

Configuring IS-IS to Ignore the Metric of RSVP Label-Switched Paths You can configure IS-IS to ignore the metric of RSVP label-switched paths (LSPs) when LDP tunneling is enabled. If you are using the RSVP for traffic engineering, you can run LDP simultaneously to eliminate the distribution of external routes in the core. The LSPs established by LDP are tunneled through the LSPs established by RSVP. LDP effectively treats the traffic-engineered LSPs as single hops. Ignoring the metric of RSVP LSPs avoids mutual dependency between IS-IS and RSVP, eliminating the time period when the RSVP metric used for tunneling traffic is not up to date. To configure IS-IS to ignore the metric of RSVP LSPs, include the ignore-lsp-metrics statement: traffic-engineering { ignore-lsp-metrics; }



399


For more information about configuring LSPs and MPLS, see the Junos OS MPLS Applications Configuration Guide.

Disabling IS-IS Support for Traffic Engineering By default, IS-IS supports traffic engineering by exchanging basic information with the traffic engineering database. To disable this support, and to disable IS-IS shortcuts if they are configured, include the disable statement: traffic-engineering { disable; }


Installing IPv4 Routes into the Multicast Routing Table You can install unicast IPv4 routes into the multicast routing table (inet.2) for multicast reverse-path forwarding (RPF) checks. To install routes into the multicast routing table for RPF checks, include the multicast-rpf-routes statement: traffic-engineering { family inet { shortcuts { multicast-rpf-routes; } } }


NOTE: Traffic engineering shortcuts must be enabled.

NOTE: IPv4 multicast topology must not be enabled.

NOTE: LSPs must not be advertised into IS-IS.

Configuring IS-IS to Use Protocol Preference to Determine the Traffic Engineering Database Credibility Value By default, the Junos OS prefers IS-IS routes in the traffic engineering database over other IGP routes even if the routes of another IGP are configured with a lower, that is, more preferred, preference value. The traffic engineering database assigns a credibility value to each IGP and prefers the routes of the IGP with the highest credibility value. In Junos OS Release 9.4 and later, you can configure IS-IS to take protocol preference into

400



account to determine the traffic engineering database credibility value. When protocol preference is used to determine the credibility value, IS-IS routes are not automatically preferred by the traffic engineering database, depending on your configuration. For example, OSPF routes have a default preference value of 10, while IS-IS Level 1 routes have a default preference value of 15. When protocol preference is enabled, the credibility value is determined by deducting the protocol preference value from a base value of 512. Using default protocol preference values, OSPF has a credibility value of 502, while IS-IS has a credibility value of 497. Because the traffic engineering database prefers IGP routes with the highest credibility value, OSPF routes are now preferred.

NOTE: This feature is also supported for OSPFv2. For more information, see “Example: Enabling OSPF Traffic Engineering Support” on page 650.

To configure IS-IS to use the configured protocol preference for IGP routes to determine the traffic engineering database credibility value, include the credibility-protocol-preference statement at the [edit protocols isis traffic-engineering] hierarchy level: [edit protocols isis] traffic-engineering { credibility-protocol-preference; }

Enabling Authentication for IS-IS Without Network-Wide Deployment To allow the use of authentication without requiring network-wide deployment, include the loose-authentication-check statement: loose-authentication-check;


Configuring Quicker Advertisement of IS-IS Adjacency State Changes A hold-down timer delays the advertising of adjacencies by waiting until a time period has elapsed before labeling adjacencies in the up state. You can disable this hold-down timer, which labels adjacencies up faster. However, disabling the hold-down timer creates more frequent link-state PDU updates and SPF computation. To disable the adjacency hold-down timer, include the no-adjacency-holddown statement: no-adjacency-holddown;


Enabling Padding of IS-IS Hello Packets You can configure padding on hello packets to accommodate asymmetrical maximum transfer units (MTUs) from different routing devices. This help prevents a premature


401


adjacency UP state when one routing device’s MTU does not meet the requirements to establish the adjacency. As an OSI Layer 2 protocol, IS-IS does not support data fragmentation. Therefore, maximum packet sizes must be established and supported between two routers. During adjacency establishment, the IS-IS protocol makes sure that the link supports a packet size of 1,492 bytes by padding outgoing hello packets up to the maximum packet size of 1,492 bytes. To configure padding for hello packets, include the hello-padding statement: hello-padding (adaptive | loose | strict);

There are three types of hello padding: •

Adaptive padding. On point-to-point connections, the hello packets are padded from the initial detection of a new neighbor until the neighbor verifies the adjacency as Up in the adjacency state TLV. If the neighbor does not support the adjacency state TLV, then padding continues. On LAN connections, padding starts from the initial detection of a new neighbor until there is at least one active adjacency on the interface. Adaptive padding has more overhead than loose padding and is able to detect MTU asymmetry from one side of the connection. This one-sided detection may result in generation of extra LSPs that are flooded throughout the network. Specify the adaptive option to configure enough padding to establish an adjacency to neighbors.

•

Loose padding (the default). The hello packet is padded from the initial detection of a new neighbor until the adjacency transitions to the Up state. Loose padding may not be able to detect certain situations such as asymmetrical MTUs between the routing devices. Specify the loose option to configure enough padding to initialize an adjacency to neighbors.

•

Strict padding. Padding is done on all interface types and for all adjacency states, and is continuous. Strict padding has the most overhead. The advantage is that strict padding detects MTU issues on both sides of a link. Specify the strict option to configure padding to allow all adjacency states with neighbors.

For a list of hierarchy levels at which you can include this statement, see the statement summary sections for this statement.

Configuring CLNS for IS-IS Connectionless Network Services (CLNS) is a Layer 3 protocol, similar to IP version 4 (IPv4). CLNS uses network service access points (NSAPs) to address end systems and intermediate systems. You can use IS-IS as the IGP to carry ISO CLNS routes through a network.


To enable IS-IS to exchange CLNS routes, include the clns-routing statement:

402



clns-routing;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. You can configure a pure CLNS network by disabling IPv4 and IPv6 for IS-IS. To disable IPv4, include the no-ipv4-routing statement: no-ipv4-routing;

To disable IPv6, include the no-ipv6-routing statement: no-ipv6-routing;

For a list of hierarchy levels at which you can include these statements, see the statement summary section for these statements. You can export BGP routes into Layer 2 IS-IS by configuring an export policy and applying the policy to IS-IS. You can export BGP routes from a specific VRF instance into IS-IS by configuring and applying an export policy at the [edit routing-instance instance-name protocols isis] hierarchy level. ES-IS routes from one routing instance cannot be exported into a Layer 1 IS-IS area of another routing instance. To configure an export policy to export BGP routes into IS-IS, include the policy-statement statement: policy-statement policy-name { from { protocol bgp; family iso; } then { accept; } }

To apply an export policy, include the export statement at the [edit protocols isis] hierarchy level: export policy-name;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for these statements. For more information on policy configuration, see the Junos OS Routing Policy Configuration Guide. You can also export routes from protocols other than BGP into IS-IS. ES-IS routes are exported to IS-IS by default. You can export ES-IS routes into IS-IS by configuring a routing policy.

Example: Configuring CLNS for IS-IS Configure a routing policy to accept CLNS routes: policy-options {


403


policy-statement dist-bgp { from { protocol bgp; family iso; } then accept; } policy-statement dist-static { from { protocol static; family iso; } then accept; } }

Configure CLNS for IS-IS: protocols { isis { traceoptions { file isis size 5m world-readable; flag error; } export dist-static; no-ipv6-routing; no-ipv4-routing; clns-routing; interface fe-0/0/1.0; interface t1-0/2/1.0; interface fxp0.0 { disable; } interface lo0.0; } }

Configure a routing instance that supports CLNS routes: routing-instances { aaaa { instance-type vrf; interface lo0.1; interface t1-3/0/0.0; interface fe-5/0/1.0; route-distinguisher 10.245.245.1:1; vrf-target target:11111:1; protocols { isis { export dist-bgp; no-ipv4-routing; no-ipv6-routing; clns-routing; interface all; } } }

404



}

Disabling IS-IS To disable IS-IS on the routing device without removing the IS-IS configuration statements from the configuration, include the disable statement: isis { disable; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To reenable IS-IS, remove the disable statement from the configuration: [edit protocols] user@host# delete isis disable [edit protocols] user@host# show isis;

Disabling IPv4 Routing for IS-IS You can disable IP version 4 (IPv4) routing for IS-IS. Disabling IPv4 routing results in the following: •

Routing device does not advertise the NLPID for IPv4 in Junos OS 0th link-state PDU fragment.

•

Routing device does not advertise any IPv4 prefixes in Junos OS link-state PDUs.

•

Routing device does not advertise the NLPID for IPv4 in Junos OS hello packets.

•

Routing device does not advertise any IPv4 addresses in Junos OS hello packets.

•

Routing device does not calculate any IPv4 routes.

To disable IPv4 routing on the routing device, include the no-ipv4-routing statement: isis { no-ipv4-routing; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To reenable IS-IS, remove the no-ipv4-routing statement from the configuration: [edit protocols] user@host# delete isis no-ipv4-routing

Disabling IPv6 Routing for IS-IS You can disable IP version 6 (IPv6) routing for IS-IS. Disabling IPv6 routing results in the following:


405


•

Routing device does not advertise the NLPID for IPv6 in Junos OS 0th link-state PDU fragment.

•

Routing device does not advertise any IPv6 prefixes in Junos OS link-state PDUs.

•

Routing device does not advertise the NLPID for IPv6 in Junos OS hello packets.

•

Routing device does not advertise any IPv6 addresses in Junos OS hello packets.

•

Routing device does not calculate any IPv6 routes.

To disable IPv6 routing on the routing device, include the no-ipv6-routing statement: isis { no-ipv6-routing; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To re-enable IS-IS, remove the disable statement from the configuration: [edit protocols] user@host# delete isis no-ipv6-routing

Applying Policies to Routes Exported to IS-IS All routing protocols store the routes that they learn in the routing table. The routing table uses this collected route information to determine the active routes to destinations. The routing table then installs the active routes into its forwarding table and exports them into the routing protocols. It is these exported routes that the protocols advertise. For each protocol, you control which routes the protocol stores in the routing table and which routes the routing table exports into the protocol from the routing table by defining a routing policy for that protocol. For information about defining routing policy, see the Junos OS Routing Policy Configuration Guide. To apply routing policies that affect how the routing protocol process (rpd) exports routes into IS-IS, include the export statement: export [ policy-names ];


NOTE: For IS-IS, you cannot apply routing policies that affect how routes are imported into the routing table; doing so with a link-state protocol can easily lead to an inconsistent topology database.

Examples: Configuring IS-IS Routing Policy Define a policy that allows only host routes from USC (128.125.0.0/16), and apply the policy to routes exported from the routing table into IS-IS:

406



policy-options { policy-statement usc-hosts-only { term first { from { route-filter 128.125.0.0/16 upto /31; } then reject; } then accept; } } protocols { isis { export usc-hosts-only; } }

Define a policy that takes BGP routes from the Edu community and places them into IS-IS with a metric of 14. Apply the policy to routes exported from the routing table into IS-IS: protocols { isis { export edu-to-isis; } } policy-options { community Edu members 666:5; policy-statement edu-to-isis { from { protocol bgp; community Edu; } to protocol isis; then metric 14; } }

Define a policy that rejects all IS-IS Level 1 routes so that none are exported into IS-IS: policy-options { policy-statement level1 { term first { from level 1; then reject; } then accept; } } protocols { isis { export level1; interface fxp0; } }

Define a routing policy to export IS-IS Level 1 internal-only routes into Level 2:


407


[edit] protocols { isis { export L1-L2; } } policy-statement L1-L2 { term one { from { level 1; external; } then reject; } term two { from level 1; to level 2; then accept; } }

Define a routing policy to export IS-IS Level 2 routes into Level 1: [edit] protocols { isis { export L2-L1; } } policy-statement L2-L1 { term one { from level 2; to level 1; then accept; } }

Installing a Default Route to the Nearest Routing Device That Operates at Both IS-IS Levels When a routing device that operates as both a Level 1 and Level 2 router (Router B) determines that it can reach at least one area other than its own (for example, in Area Y), it sets the ATTACHED bit in its Level LSP. Thereafter, the Level 1 router (Router A) introduces a default route pointing to the nearest attached routing device that operates as both a Level 1 and Level 2 router (Router B). See Figure 10 on page 409.

408



Figure 10: Install Default Route to Nearest Routing Device That Operates at Both Level 1 and Level 2

Configuring Loop-Free Alternate Routes for IS-IS In Junos OS Release 9.5 and later, support for IS-IS loop-free alternate routes enables IP fast-reroute capability for IS-IS. The Junos OS precomputes loop-free backup routes for all IS-IS routes. These backup routes are preinstalled in the Packet Forwarding Engine, which performs a local repair and implements the backup path when the link for a primary next hop for a particular route is no longer available. With local repair, the Packet Forwarding Engine can correct a path failure before it receives recomputed paths from the Routing Engine. Local repair reduces the amount of time needed to reroute traffic to less than 50 milliseconds. In contrast, global repair can take up to 800 milliseconds to compute a new route. Local repair and global repair are thus complementary. Local repair enables traffic to continue to be routed using a backup path until global repair is able to calculate a new route. A loop-free path is one that does not forward traffic back through the routing device to reach a given destination. That is, a neighbor whose shortest path to the destination traverses the routing device is not used as a backup route to that destination. To determine loop-free alternate paths for IS-IS routes, the Junos OS runs shortest-path-first (SPF) calculations on each one-hop neighbor. You can enable support for alternate loop-free routes on any IS-IS interface. Because it is common practice to enable LDP on an interface for which IS-IS is already enabled, this feature also provides support for LDP label-switched paths (LSPs).

NOTE: If you enable support for alternate loop-free routes on an interface configured for both LDP and IS-IS, you can use the traceroute command to trace the active path to the primary next hop.


409


The level of backup coverage available through IS-IS routes depends on the actual network topology and is typically less than 100 percent for all destinations on any given routing device. You can extend backup coverage to include RSVP LSP paths. The Junos OS provides two mechanisms for route redundancy for IS-IS through alternate loop-free routes: link protection and node-link protection. When you enable link protection or node-link protection on an IS-IS interface, the Junos OS creates an alternate path to the primary next hop for all destination routes that traverse a protected interface. Link protection offers per-link traffic protection. Use link protection when you assume that only a single link might become unavailable but that the neighboring node on the primary path would still be available through another interface. Node-link protection establishes an alternate path through a different routing device altogether. Use node-link protection when you assume that access to a node is lost when a link is no longer available. As a result, the Junos OS calculates a backup path that avoids the primary next-hop routing device. In Junos OS Release 9.4 and earlier, only the RSVP protocol supports Packet Forwarding Engine local repair and fast reroute as well as link protection and node protection. In Figure 11 on page 410, Case 1 shows how link protection allows source Router A to switch to Link B when the primary next hop Link A to destination Router C fails. However, if Router B fails, Link B also fails, and the protected Link A is lost. If node-link protection is enabled, Router A is able to switch to Link D on Router D and bypass the failed Router B altogether. As shown in Case 2, with node-link protection enabled, Router A has a node-link protection alternate path available through Router D to destination Router C. That means that if Router B fails, Router A can still reach Router C because the path from Router A to Link D remains available as an alternate backup path.

Figure 11: Link Protection and Node-Link Protection Comparison for IS-IS Routes Case 1

Node-link protection alternate path

Link D

A

D

Link A X

Link E

B

C Link C

Link B Link protection alternate path X

Case 2

Node-link protection alternate path

Link D

A

Link A X

D

Link E

C

B

Link B

410

g017299

Link C



The Junos OS implementation of support for loop-free alternate paths for IS-IS routes is based on the following standards: •

Internet draft draft-ietf-rtgwg-ipfrr-spec-base-12.txt, Basic Specification for IP Fast-Reroute: Loop-free Alternates

•

Internet draft draft-ietf-rtgwg-ipfrr-framework-06.txt, IP Fast Reroute Framework


Configuring Link Protection for IS-IS on page 411

•

Configuring Node-Link Protection for IS-IS on page 411

•

Excluding an IS-IS Interface as a Backup for Protected Interfaces on page 412

•

Configuring RSVP Label-Switched Paths as Backup Paths for IS-IS on page 412

•

Using Operational Mode Commands to Monitor Protected IS-IS Routes on page 413

•

Example: Configuring Node-Link Protection for IS-IS Routes on page 413

Configuring Link Protection for IS-IS You can configure link protection on any interface for which IS-IS is enabled. When you enable link protection, the Junos OS creates an alternate path to the primary next hop for all destination routes that traverse a protected interface. Link protection assumes that only a single link becomes unavailable but that the neighboring node would still be available through another interface.

NOTE: You must also configure a per-packet load-balancing routing policy to ensure that the routing protocol process installs all the next hops for a given route in the routing table. For more information, see “Configuring Per-Packet Load Balancing” on page 128.

To enable link protection, include the link-protection statement at the [edit protocols isis interface interface-name] hierarchy level: [edit] protocols { isis { interface interface-name: link-protection; } } }

Configuring Node-Link Protection for IS-IS You can configure node-link protection on any interface for which IS-IS is enabled. Node-link protection establishes an alternate path through a different routing device altogether for all destination routes that traverse a protected interface. Node-link protection assumes that the entire routing device, or node, has failed. The Junos OS therefore calculates a backup path that avoids the primary next-hop routing device.


411


NOTE: You must also configure a per-packet load-balancing routing policy to ensure that the routing protocol process installs all the next hops for a given route in the routing table. For more information, see “Configuring Per-Packet Load Balancing” on page 128.

To enable node-link protection, include the node-link-protection statement at the [edit protocols isis interface interface-name] hierarchy level: [edit] protocols { isis { interface interface-name: node-link-protection; } } }

Excluding an IS-IS Interface as a Backup for Protected Interfaces By default, all IS-IS interfaces that belong to the master instance or a specific routing instance are eligible as backup interfaces for protected interfaces. You can specify that any IS-IS interface be excluded from functioning as a backup interface to protected interfaces. To exclude an IS-IS interface as a backup interface, include the no-eligible-backup statement at the [edit protocols isis interface interface-name] hierarchy level: [edit] protocols { isis { interface interface-name { no-eligible-backup; } } }

Configuring RSVP Label-Switched Paths as Backup Paths for IS-IS Relying on the shortest-path first (SPF) calculation of backup paths for one-hop neighbors might result in less than 100 percent backup coverage for a specific network topology. You can enhance coverage of IS-IS and LDP label-switched paths (LSPs) by configuring RSVP LSPs as backup paths. To configure a specific RSVP LSP as a backup path, include the backup statement at the [edit protocols mpls label-switched-path lsp-name] hierarchy level: [edit] protocols { mpls { label-switched-path lsp-name { backup; to ip-address; } }

412



}

When configuring an LSP, you must specify the IP address of the egress routing device with the to statement. For detailed information about configuring LSPs and RSVP, see the Junos OS MPLS Applications Configuration Guide.

Using Operational Mode Commands to Monitor Protected IS-IS Routes You can issue operational mode commands that provide more details about your link-protected and node-link-protected IS-IS routes. The following guidelines explain the type of information available from the output of each command: •

show isis backup label-switched-path—Displays which MPLS LSPs have been designated

as backup paths and the current status of those LSPs. •

show isis backup spf results—Displays SPF calculations for each neighbor for a given

destination. Indicates whether a specific interface or node has been designated as a backup path and why. Use the no-coverage option to display only those nodes that do not have backup coverage. •

show isis backup coverage—Displays the percentage of nodes and prefixes for each

type of address family that are protected. •

show isis interface detail—Displays the type of protection (link or node-link) applied

to each protected interface. For more detailed information about these commands, see the Junos OS Routing Protocols and Policies Command Reference.

Example: Configuring Node-Link Protection for IS-IS Routes In this example, all the logical interfaces on the router are enabled for IS-IS level 2, LDP, and RSVP. Node-link protection is enabled on all the interfaces, which means that if the primary next hop for any destination that traverses the interfaces becomes unavailable, the Junos OS uses a backup link that avoids the next-hop router altogether if necessary. You also need to configure a routing policy that requires all traffic to use per-packet load balancing in order to enable Packet Forwarding Engine local repair. With local repair, the Packet Forwarding Engine can correct a path failure and implement a backup loop-free alternate route before it receives recomputed paths from the Routing Engine. Configure the interfaces. Enable IS-IS and MPLS. In this example, the interfaces are also enabled for both IPv4 and IPv6 traffic. [edit interfaces] ge-2/0/0 { unit 0 { family inet { address 11.14.0.1/30; } family iso; family inet6; family mpls; } }


413


ge-2/0/1 { unit 0 { family inet { address 11.14.1.1/30; } family iso; family inet6; family mpls; } } so-3/0/1 { unit 0 { family inet { address 11.16.1.1/30; } family iso; family inet6; family mpls; } } so-3/0/2 { unit 0 { family inet { address 11.16.0.1/30; } family iso; family inet6; family mpls; } } so-6/0/0 { unit 0 { family inet { address 11.12.0.1/30; } family iso; family inet6; family mpls; } }

Configure the IS-IS interfaces for Level 2 only, and configure MPLS to use both RSVP and LDP label-switched paths (LSPs). Enable IS-IS node-link protection, which also automatically extends backup coverage to all LDP LSPs. [edit protocols] rsvp { interface all; interface fxp0.0 { disable; } } mpls { interface all;

414



interface fxp0.0 { disable; } } isis { interface all { node-link-protection; # Enable node-link protection on all IS-IS interfaces. # Protection is automatically extended to all LDP LSPs. level 2 metric 10; level 1 disable; } interface fxp0.0 { disable; } interface lo0.0 { level 2 metric 0; } } ldp { deaggregate; # Enable forwarding equivalence class deaggregation, which results in faster global convergence. interface all; interface fxp0.0 { disable; } }

To enable Packet Forwarding Engine local repair, establish a policy that forces the routing protocol process to install all the next hops for a given route. This policy ensures that the backup route is installed in the forwarding table used by the Packet Forwarding Engine to forward traffic to a given destination. After this policy is configured, export it to the forwarding table of the local routerwith the export statement at the [edit routing-options forwarding-table] hierarchy level. [edit policy-options] policy-statement ecmp { term 1 { then { load-balance per-packet; } } } [edit routing-options] forwarding-table { export ecmp; }

Disabling Adjacency Down and Neighbor Down Notification in IS-IS and OSPF Whenever IS-IS is deactivated, the IS-IS adjacencies are brought down. IS-IS signals to RSVP to bring down any RSVP neighbors associated with the IS-IS adjacencies, and this further causes the associated LSPs signaled by RSVP to go down as well.


415


A similar process occurs whenever OSPF is deactivated. The OSPF neighbors are brought down. OSPF signals to RSVP to bring down any of the RSVP neighbors associated with the OSPF neighbors, and this further causes the associated LSPs signaled by RSVP to go down as well. If you need to migrate from IS-IS to OSPF or from OSPF to IS-IS, the IGP notification to RSVP for an adjacency or neighbor down event needs to be ignored. Using the no-adjacency-down-notification or no-neighbor-down-notification statements, you can disable IS-IS adjacency down notification or OSPF neighbor down notification, respectively, until the migration is complete. The network administrator is responsible for configuring the statements before the migration, and then removing them from the configuration afterward, so that IGP notification can function normally. To disable adjacency down notification in IS-IS, include the no-adjacency-down-notification statement: no-adjacency-down-notification;


[edit protocols isis interface interface-name]

•

[edit logical-systems logical-system-name protocols isis interface interface-name]

To disable neighbor down notification in OSPF, include the no-neighbor-down-notification statement: no-neighbor-down-notification;


[edit protocols ospf area area-id interface interface-name]

•

[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name]

Tracing IS-IS Protocol Traffic You can trace various types of IS-IS protocol traffic to help debug IS-IS protocol issues. To trace IS-IS protocol traffic include the traceoptions statement at the [edit protocols isis] hierarchy level: traceoptions { file filename ; flag flag ; }

You can specify the following IS-IS protocol-specific trace options using the flag statement:

416

•

csn—Complete sequence number PDU (CSNP) packets

•

error—Errored packets

•




•

hello—Hello packets

•

ldp-synchronization—Synchronization between IS-IS and LDP

•

lsp—Link-state PDU packets

•

lsp-generation—Link-state PDU generation packets

•

nsr-synchronization—NSR synchronization events

•

packets—All IS-IS protocol packets

•

psn—Partial sequence number PDU (PSNP) packets

•

spf—Shortest-path-first (SPF) calculations

You can optionally specify one or more of the following flag modifiers: •

detail—Detailed trace information

•

receive—Packets being received

•

send—Packets being transmitted

NOTE: Use the flag modifier detail with caution as this may cause the CPU to become very busy.

Global tracing options are inherited from the configuration set by the traceoptions statement at the [edit routing-options] hierarchy level. You can override the following global trace options for the IS-IS protocol using the traceoptions flag statement included at the [edit protocols isis] hierarchy level: •


•



normal—Normal events

•

policy—Policy processing

•

route—Routing information

•


•

task—Routing protocol task processing

•

timer—Routing protocol timer processing

NOTE: Use the trace flag all with caution as this may cause the CPU to become very busy.


417


Examples: Tracing IS-IS Protocol Traffic A common configuration traces SPF calculations, LSP calculations, normal protocol operations, and errors in protocol operation: [edit] protocols { isis { traceoptions { file isis-log size 1m files 10; flag spf; flag lsp; flag error; flag normal; } } }

Trace only unusual or abnormal operations to the file routing-log, and trace detailed information about all IS-IS packets to the file isis-log: [edit] routing-options { traceoptions { file routing-log; } } protocols { isis { traceoptions { file isis-log size 10k files 5; flag csn detail; flag hello detail; flag lsp detail; flag psn detail; } } }

Perform detailed tracing of mesh-group flooding: [edit] protocols { isis { traceoptions { file isis-log; flag lsp detail; } } }

IS-IS LSP packets that contain errors are discarded by default. To log these errors, specify the error tracing operation: [edit] protocols {

418



isis { traceoptions { file isis-log; flag error; } } }


•

traceoptions on page 489 statement

•

For more information about tracing and global tracing options, see Tracing Global Routing Protocol Operations on page 138.

Example: Configuring IS-IS on Logical Systems Within the Same Router This example shows how to configure an IS-IS network by using multiple logical systems that are running on a single physical router. The logical systems are connected by logical tunnel interfaces. •


•


•


•


Requirements You must connect the logical systems by using logical tunnel (lt) interfaces. See Example: Connecting Logical Systems Within the Same Router Using Logical Tunnel Interfaces.

Overview This example shows an IS-IS configuration with three logical systems running on one physical router. Each logical system has its own routing table. The configuration enables the protocol on all logical tunnel interfaces that participate in the IS-IS domain. Figure 12 on page 420 shows the sample network.


419


Figure 12: IS-IS on Logical Systems


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems LS1 interfaces lt-0/1/0 unit 2 description LS1->LS2 set logical-systems LS1 interfaces lt-0/1/0 unit 2 encapsulation ethernet set logical-systems LS1 interfaces lt-0/1/0 unit 2 peer-unit 1 set logical-systems LS1 interfaces lt-0/1/0 unit 2 family inet address 10.0.0.1/30 set logical-systems LS1 interfaces lt-0/1/0 unit 2 family iso set logical-systems LS1 interfaces lt-0/1/0 unit 0 description LS1->LS3 set logical-systems LS1 interfaces lt-0/1/0 unit 0 encapsulation ethernet set logical-systems LS1 interfaces lt-0/1/0 unit 0 peer-unit 5 set logical-systems LS1 interfaces lt-0/1/0 unit 0 family inet address 10.0.1.2/30 set logical-systems LS1 interfaces lt-0/1/0 unit 0 family iso set logical-systems LS1 interfaces lo0 unit 1 family iso address 49.0001.1720.1600.1001.00 set logical-systems LS1 protocols isis interface lt-0/1/0.0 set logical-systems LS1 protocols isis interface lt-0/1/0.2 set logical-systems LS1 protocols isis interface lo0.1 passive set logical-systems LS2 interfaces lt-0/1/0 unit 1 description LS2->LS1 set logical-systems LS2 interfaces lt-0/1/0 unit 1 encapsulation ethernet set logical-systems LS2 interfaces lt-0/1/0 unit 1 peer-unit 2 set logical-systems LS2 interfaces lt-0/1/0 unit 1 family inet address 10.0.0.2/30 set logical-systems LS2 interfaces lt-0/1/0 unit 1 family iso set logical-systems LS2 interfaces lt-0/1/0 unit 4 description LS2->LS3 set logical-systems LS2 interfaces lt-0/1/0 unit 4 encapsulation ethernet set logical-systems LS2 interfaces lt-0/1/0 unit 4 peer-unit 3 set logical-systems LS2 interfaces lt-0/1/0 unit 4 family inet address 10.0.2.2/30 set logical-systems LS2 interfaces lt-0/1/0 unit 4 family iso

420



set logical-systems LS2 interfaces lo0 unit 2 family iso address 49.0001.1720.1600.2002.00 set logical-systems LS2 protocols isis interface lt-0/1/0.1 set logical-systems LS2 protocols isis interface lt-0/1/0.4 set logical-systems LS2 protocols isis interface lo0.2 passive set logical-systems LS3 interfaces lt-0/1/0 unit 3 description LS3->LS2 set logical-systems LS3 interfaces lt-0/1/0 unit 3 encapsulation ethernet set logical-systems LS3 interfaces lt-0/1/0 unit 3 peer-unit 4 set logical-systems LS3 interfaces lt-0/1/0 unit 3 family inet address 10.0.2.1/30 set logical-systems LS3 interfaces lt-0/1/0 unit 3 family iso set logical-systems LS3 interfaces lt-0/1/0 unit 5 description LS3->LS1 set logical-systems LS3 interfaces lt-0/1/0 unit 5 encapsulation ethernet set logical-systems LS3 interfaces lt-0/1/0 unit 5 peer-unit 0 set logical-systems LS3 interfaces lt-0/1/0 unit 5 family inet address 10.0.1.1/30 set logical-systems LS3 interfaces lt-0/1/0 unit 5 family iso set logical-systems LS3 interfaces lo0 unit 3 family iso address 49.0001.1234.1600.2231.00 set logical-systems LS3 protocols isis interface lt-0/1/0.5 set logical-systems LS3 protocols isis interface lt-0/1/0.3 set logical-systems LS3 protocols isis interface lo0.3 passive


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure IS-IS on logical systems: 1.

Configure the logical tunnel interface on Logical System LS1 connecting to Logical System LS2. [edit logical-systems LS1] user@host# set interfaces lt-0/1/0 unit 2 description LS1->LS2 user@host# set interfaces lt-0/1/0 unit 2 encapsulation ethernet user@host# set interfaces lt-0/1/0 unit 2 peer-unit 1 user@host# set interfaces lt-0/1/0 unit 2 family inet address 10.0.0.1/30 user@host# set interfaces lt-0/1/0 unit 2 family iso

2.


3.



421


4.


5.


6.


7.

Configure the ISO address on the loopback interface for the three logical systems. [edit logical-systems LS1] user@host# set interfaces lo0 unit 1 family iso address 49.0001.1720.1600.1001.00 user@host# set protocols isis interface lo0.1 passive [edit logical-systems LS2] user@host# set interfaces lo0 unit 2 family iso address 49.0001.1720.1600.2002.00 user@host# set protocols isis interface lo0.2 passive [edit logical-systems LS3] user@host# set interfaces lo0 unit 3 family iso address 49.0001.1234.1600.2231.00 user@host# set protocols isis interface lo0.3 passive

8.

Configure IS-IS on all the interfaces. [edit logical-systems LS1 protocols isis] user@host# set interface lt-0/1/0.0 user@host# set interface lt-0/1/0.2 [edit logical-systems LS2 protocols isis] user@host# set interface lt-0/1/0.1 user@host# set interface lt-0/1/0.4 [edit logical-systems LS3 protocols isis] user@host# set interface lt-0/1/0.5 user@host# set interface lt-0/1/0.3

9.

If you are done configuring the device, commit the configuration. [edit]

422



user@host# commit

Results

Confirm your configuration by issuing the show logical-systems command. user@host# show logical-systems LS1 { interfaces { lt-0/1/0 { unit 0 { description LS1->LS3; encapsulation ethernet; peer-unit 5; family inet { address 10.0.1.2/30; } family iso; } unit 2 { description LS1->LS2; encapsulation ethernet; peer-unit 1; family inet { address 10.0.0.1/30; } family iso; } } lo0 { unit 1 { family iso { address 49.0001.1720.1600.1001.00; } } } } protocols { isis { interface lt-0/1/0.0; interface lt-0/1/0.2; interface lo0.1 { passive; } } } } LS2 { interfaces { lt-0/1/0 { unit 1 { description LS2->LS1; encapsulation ethernet; peer-unit 2; family inet { address 10.0.0.2/30; } family iso; } unit 4 { description LS2->LS3; encapsulation ethernet; peer-unit 3;


423


family inet { address 10.0.2.2/30; } family iso; } } lo0 { unit 2 { family iso { address 49.0001.1720.1600.2002.00; } } } } protocols { isis { interface lt-0/1/0.1; interface lt-0/1/0.4; interface lo0.2 { passive; } } } } LS3 { interfaces { lt-0/1/0 { unit 3 { description LS3->LS2; encapsulation ethernet; peer-unit 4; family inet { address 10.0.2.1/30; } family iso; } unit 5 { description LS3->LS1; encapsulation ethernet; peer-unit 0; family inet { address 10.0.1.1/30; } family iso; } } lo0 { unit 3 { family iso { address 49.0001.1234.1600.2231.00; } } } } protocols { isis { interface lt-0/1/0.3; interface lt-0/1/0.5; interface lo0.3 { passive;

424



} } } }


Verifying That the Logical Systems Are Up on page 425

•

Verifying Connectivity Between the Logical Systems on page 425

Verifying That the Logical Systems Are Up Purpose Action

Make sure that the interfaces are properly configured. user@host> show interfaces terse Interface Admin Link Proto ... lt-0/1/0 up up lt-0/1/0.0 up up inet iso lt-0/1/0.1 up up inet iso lt-0/1/0.2 up up inet iso lt-0/1/0.3 up up inet iso lt-0/1/0.4 up up inet iso lt-0/1/0.5 up up inet iso ...

Local

Remote

10.0.1.2/30 10.0.0.2/30 10.0.0.1/30 10.0.2.1/30 10.0.2.2/30 10.0.1.1/30

Verifying Connectivity Between the Logical Systems Purpose

Action

Make sure that the IS-IS adjacencies are established by checking the logical system routing entries and by pinging the logical systems. user@host> show route logical-system LS1 inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30 10.0.0.1/32 10.0.1.0/30 10.0.1.2/32 10.0.2.0/30

*[Direct/0] 3w0d 01:37:52 > via lt-0/1/0.2 *[Local/0] 3w0d 01:37:52 Local via lt-0/1/0.2 *[Direct/0] 3w0d 01:37:52 > via lt-0/1/0.0 *[Local/0] 3w0d 01:37:52 Local via lt-0/1/0.0 *[IS-IS/15] 3w0d 01:37:13, metric 20 > to 10.0.1.1 via lt-0/1/0.0 to 10.0.0.2 via lt-0/1/0.2

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both


425


49.0001.1720.1600.1001/72 *[Direct/0] 3w0d 01:37:52 > via lo0.1

user@host> show route logical-system LS2 inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30 10.0.0.2/32 10.0.1.0/30

10.0.2.0/30 10.0.2.2/32

*[Direct/0] 3w0d 01:38:01 > via lt-0/1/0.1 *[Local/0] 3w0d 01:38:01 Local via lt-0/1/0.1 *[IS-IS/15] 3w0d 01:37:01, metric 20 to 10.0.0.1 via lt-0/1/0.1 > to 10.0.2.1 via lt-0/1/0.4 *[Direct/0] 3w0d 01:38:01 > via lt-0/1/0.4 *[Local/0] 3w0d 01:38:01 Local via lt-0/1/0.4

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 49.0001.1720.1600.2002/72 *[Direct/0] 3w0d 01:38:01 > via lo0.2 user@host> show route logical-system LS3 inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30

10.0.1.0/30 10.0.1.1/32 10.0.2.0/30 10.0.2.1/32

*[IS-IS/15] 3w0d 01:37:10, metric 20 to 10.0.2.2 via lt-0/1/0.3 > to 10.0.1.2 via lt-0/1/0.5 *[Direct/0] 3w0d 01:38:10 > via lt-0/1/0.5 *[Local/0] 3w0d 01:38:11 Local via lt-0/1/0.5 *[Direct/0] 3w0d 01:38:11 > via lt-0/1/0.3 *[Local/0] 3w0d 01:38:11 Local via lt-0/1/0.3

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 49.0001.1234.1600.2231/72 *[Direct/0] 3w0d 01:38:11 > via lo0.3

From LS1, Ping LS3

user@host> set cli logical-system LS1 user@host:LS1> ping 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes 64 bytes from 10.0.2.1: icmp_seq=0 ttl=63 time=1.264 ms 64 bytes from 10.0.2.1: icmp_seq=1 ttl=63 time=1.189 ms 64 bytes from 10.0.2.1: icmp_seq=2 ttl=63 time=1.165 ms ^C --- 10.0.2.1 ping statistics ---

426



3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.165/1.206/1.264/0.042 ms

From LS3, Ping LS1

user@host> set cli logical-system LS3 user@host:LS3> ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=63 time=1.254 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=63 time=1.210 ms ^C --- 10.0.0.1 ping statistics --2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.210/1.232/1.254/0.022 ms

From LS1, Ping LS2

user@host> set cli logical-system LS1 user@host:LS1> ping 10.0.2.2 PING 10.0.2.2 (10.0.2.2): 56 data bytes 64 bytes from 10.0.2.2: icmp_seq=0 ttl=64 time=1.240 ms 64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=1.204 ms 64 bytes from 10.0.2.2: icmp_seq=2 ttl=64 time=1.217 ms ^C --- 10.0.2.2 ping statistics --3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.204/1.220/1.240/0.015 ms

From LS2, Ping LS1


From LS2, Ping LS3

user@host> set cli logical-system LS2 user@host:LS2> ping 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 56 data bytes 64 bytes from 10.0.1.1: icmp_seq=0 ttl=64 time=1.253 ms 64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=1.194 ms 64 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=1.212 ms 64 bytes from 10.0.1.1: icmp_seq=3 ttl=64 time=1.221 ms 64 bytes from 10.0.1.1: icmp_seq=4 ttl=64 time=1.195 ms ^C --- 10.0.1.1 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.194/1.215/1.253/0.022 ms

From LS3, Ping LS2



427



•

Example: Creating an Interface on a Logical System

•

Example: Connecting Logical Systems Within the Same Router Using Logical Tunnel Interfaces

Example: Configuring an IS-IS Default Route Policy on Logical Systems This example shows logical systems configured on a single physical router and explains how to configure a default route on one logical system. •


•


•


•



Connect the logical systems by using logical tunnel (lt) interfaces. See Example: Connecting Logical Systems Within the Same Router Using Logical Tunnel Interfaces.

•

Enable IS-IS on the interfaces. See “Example: Configuring IS-IS on Logical Systems Within the Same Router” on page 419.

Overview This example shows a logical system redistributing a default route to other logical systems. All logical systems are running IS-IS. A common reason for a default route is to provide a path for sending traffic destined outside the IS-IS domain. In this example, the default route is not used for forwarding traffic. The no-install statement prevents the route from being installed in the forwarding table of Logical System LS3. If you configure a route so it is not installed in the forwarding table, the route is still eligible to be exported from the routing table to other protocols. The discard statement silently drops packets without notice. Figure 13 on page 429 shows the sample network.

428



Figure 13: IS-IS with a Default Route to an ISP


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems LS3 routing-options static route 0.0.0.0/0 discard set logical-systems LS3 routing-options static route 0.0.0.0/0 no-install set logical-systems LS3 policy-options policy-statement isis-default from protocol static set logical-systems LS3 policy-options policy-statement isis-default from route-filter 0.0.0.0/0 exact set logical-systems LS3 policy-options policy-statement isis-default then accept set logical-systems LS3 protocols isis export isis-default


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure an IS-IS default route policy on logical systems: 1.

Configure the default route on Logical System LS3. [edit logical-systems LS3 routing-options] user@host# set static route 0.0.0.0/0 discard user@host# set static route 0.0.0.0/0 no-install

2.

Configure the default route policy on Logical System LS3. [edit logical-systems LS3 policy-options] user@host# set policy-statement isis-default from protocol static user@host# set policy-statement isis-default from route-filter 0.0.0.0/0 exact user@host# set policy-statement isis-default then accept


429


3.

Apply the export policy to IS-IS on Logical System LS3. [edit logical-systems LS3 protocols isis] user@host# set export isis-default

4.


Results

Confirm your configuration by issuing the show logical-systems LS3 command. user@host# show logical-systems LS3 LS3 { interfaces { lt-1/2/0 { unit 3 { description LS3->LS2; encapsulation ethernet; peer-unit 4; family inet { address 10.0.2.1/30; } family iso; } unit 5 { description LS3->LS1; encapsulation ethernet; peer-unit 0; family inet { address 10.0.1.1/30; } family iso; } } lo0 { unit 3 { family iso { address 49.0001.1234.1600.2231.00; } } } } protocols { isis { export isis-default; interface lt-1/2/0.3; interface lt-1/2/0.5; interface lo0.3 { passive; } } } policy-options { policy-statement isis-default { from { protocol static; route-filter 0.0.0.0/0 exact; } then accept; }

430



} routing-options { static { route 0.0.0.0/0 { discard; no-install; } } } }


Verifying That the Static Route Is Redistributed Purpose Action

Make sure that the IS-IS policy is working by checking the routing tables. user@host> show route logical-system LS3 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.0.0.0/30

10.0.1.0/30 10.0.1.1/32 10.0.2.0/30 10.0.2.1/32

*[Static/5] 00:00:45 Discard *[IS-IS/15] 1w0d 10:14:14, metric 20 to 10.0.2.2 via lt-1/2/0.3 > to 10.0.1.2 via lt-1/2/0.5 *[Direct/0] 1w0d 10:15:18 > via lt-1/2/0.5 *[Local/0] 1w0d 10:15:18 Local via lt-1/2/0.5 *[Direct/0] 1w0d 10:15:18 > via lt-1/2/0.3 *[Local/0] 1w0d 10:15:18 Local via lt-1/2/0.3

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 49.0001.1234.1600.2231/72 *[Direct/0] 1w0d 10:17:19 > via lo0.3 user@host> show route logical-system LS2 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.0.0.0/30 10.0.0.2/32 10.0.1.0/30

10.0.2.0/30 10.0.2.2/32


*[IS-IS/160] 00:01:38, metric 10 > to 10.0.2.1 via lt-1/2/0.4 *[Direct/0] 1w0d 10:16:11 > via lt-1/2/0.1 *[Local/0] 1w0d 10:16:11 Local via lt-1/2/0.1 *[IS-IS/15] 1w0d 10:15:07, metric 20 > to 10.0.0.1 via lt-1/2/0.1 to 10.0.2.1 via lt-1/2/0.4 *[Direct/0] 1w0d 10:16:11 > via lt-1/2/0.4 *[Local/0] 1w0d 10:16:11

431


Local via lt-1/2/0.4 iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 49.0001.1720.1600.2002/72 *[Direct/0] 1w0d 10:18:12 > via lo0.2 user@host> show route logical-system LS1 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.0.0.0/30 10.0.0.1/32 10.0.1.0/30 10.0.1.2/32 10.0.2.0/30

*[IS-IS/160] 00:02:01, metric 10 > to 10.0.1.1 via lt-1/2/0.0 *[Direct/0] 1w0d 10:16:34 > via lt-1/2/0.2 *[Local/0] 1w0d 10:16:34 Local via lt-1/2/0.2 *[Direct/0] 1w0d 10:16:34 > via lt-1/2/0.0 *[Local/0] 1w0d 10:16:34 Local via lt-1/2/0.0 *[IS-IS/15] 1w0d 10:15:55, metric 20 to 10.0.1.1 via lt-1/2/0.0 > to 10.0.0.2 via lt-1/2/0.2

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 49.0001.1720.1600.1001/72 *[Direct/0] 1w0d 10:18:35 > via lo0.1

Meaning


432

The routing table on Logical System LS3 contains the default 0.0.0.0/0 route from protocol Static. The routing tables on Logical System LS1 and Logical System LS2 contain the default 0.0.0.0/0 route from protocol IS-IS. If Logical System LS1 and Logical System LS2 receive packets destined for networks not specified in their routing tables, those packets will be sent to Logical System LS3 for further processing. This configuration assumes that Logical System LS3 has a connection to an ISP or another external network.

•

Example: Creating an Interface on a Logical System


CHAPTER 15

Summary of IS-IS Configuration Statements The following sections explain each of the IS-IS configuration statements. The statements are organized alphabetically.


433


authentication-key Syntax Hierarchy Level

Release Information

Description

authentication-key key; [edit logical-systems logical-system-name protocols isislevel level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances routing-instance-name protocols isis level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Authentication key (password). Neighboring routing devices use the password to verify the authenticity of packets sent from this interface. For the key to work, you also must include the authentication-type statement. All routing devices must use the same password. If you are using the Junos OS IS-IS software with another implementation of IS-IS, the other implementation must be configured to use the same password for the domain, the area, and all interfaces adjacent to the Juniper Networks routing device.

Default

If you do not include this statement and the authentication-type statement, IS-IS authentication is disabled.

Options

key—Authentication password. The password can be up to 1024 characters long.

Characters can include any ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”).

CAUTION: A simple password for authentication is truncated if it exceeds 254 characters.


434




Chapter 15: Summary of IS-IS Configuration Statements

authentication-key-chain Syntax Hierarchy Level


authentication-key-chain key-chain-name; [edit logical-systems name protocols isis level level-number], [edit logical-systems name routing-instances instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances instance-name protocols isis level level-number]

Statement introduced in Junos OS Release 11.2. Apply and enable an authentication keychain to the routing device. key-chain—Authentication keychain name. It can be up to 126 characters. Characters can

include any ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”). Required Privilege Level Related Documentation



•



435


authentication-type Syntax Hierarchy Level

Release Information

Description

Default

Options

authentication-type authentication; [edit logical-systems logical-system-name protocols isis level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances routing-instance-name protocols isis level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Enable authentication and specify the authentication scheme for IS-IS. If you enable authentication, you must specify a password by including the authentication-key statement. If you do not include this statement and the authentication-key statement, IS-IS authentication is disabled. authentication—Authentication scheme: •

md5—Use HMAC authentication in combination with MD5. HMAC-MD5 authentication

is defined in RFC 2104, HMAC: Keyed-Hashing for Message Authentication. •

simple—Use a simple password for authentication. The password is included in the

transmitted packet, making this method of authentication relatively insecure. We recommend that you not use this authentication method. Required Privilege Level Related Documentation

436


authentication-key on page 434

•

no-authentication-check on page 472

•





Hierarchy Level

Release Information

Description Options

bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (1 | automatic); } [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. detection-time threshold and transmit-interval threshold options added in Junos OS Release 8.2. Support for logical systems introduced in Junos OS Release 8.3. no-adaptation statement introduced in Junos OS Release 9.0. authentication algorithm, authentication key-chain, and authentication loose-check statements introduced in Junos OS Release 9.6. Configure bidirectional failure detection timers and authentication. authentication algorithm algorithm-name —Configure the algorithm used to authenticate

the specified BFD session: simple-password, keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1. authentication key-chain key-chain-name—Associate a security key with the specified


BFD session. Use only for transitional periods when authentication may not be configured at both ends of the BFD session.


437


detection-time threshold milliseconds—Configure a threshold. When the BFD session

detection time adapts to a value equal to or greater than the threshold, a single trap and a single system log message are sent. minimum-interval milliseconds—Configure the minimum intervals at which the local

routing device transmits a hello packet and then expects to receive a reply from the neighbor with which it has established a BFD session. Range: 1 through 255,000 minimum-receive-interval milliseconds—Configure only the minimum interval at which

the local routing device expects to receive a reply from a neighbor with which it has established a BFD session. Range: 1 through 255,000 multiplier number—Configure the number of hello packets not received by a neighbor

that causes the originating interface to be declared down. Range: 1 through 255 Default: 3 no-adaptation—Specify that BFD sessions not adapt to changing network conditions.


transmit interval adapts to a value greater than the threshold, a single trap and a single system log message are sent. The interval threshold must be greater than the minimum transmit interval. 32

Range: 0 through 4,294,967,295 (2

– 1)

transmit-interval minimum-interval milliseconds—Configure only the minimum interval

at which the routing device sends hello packets to a neighbor with which it has established a BFD session. Range: 1 through 255,000 version—Specify the BFD version to detect.

Range: 1 (BFD version 1), or automatic (autodetection) Default: automatic The remaining statements are explained separately. Required Privilege Level Related Documentation

438



•




checksum Syntax Hierarchy Level

Release Information

Description


checksum; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Enable checksum for packets on this interface. The checksum cannot be enabled with MD5 hello authentication on the same interface. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


clns-routing Syntax Hierarchy Level


clns-routing; [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Enable IS-IS to exchange CLNS routes.




Configuring CLNS for IS-IS on page 402


439


csnp-interval Syntax Hierarchy Level

Release Information

Description

Options

csnp-interval (seconds | disable); [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the interval between complete sequence number (CSN) packets on a LAN interface. disable—Do not send CSN packets on this interface. seconds—Number of seconds between the sending of CSN packets.

Range: 1 through 65,535 seconds Default: 10 seconds Required Privilege Level Related Documentation

440





disable See the following sections: •

disable (IS-IS) on page 442

•

disable (LDP Synchronization) on page 443


441


disable (IS-IS) Syntax Hierarchy Level

Release Information

Description

disable; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name protocols isis interface interface-namelevel level-number], [edit logical-systems logical-system-name protocols isis traffic-engineering], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis traffic-engineering], [edit protocols isis], [edit protocols isis interface interface-name], [edit protocols isis interface interface-name level level-number], [edit protocols isis traffic-engineering], [edit routing-instances routing-instance-name protocols isis], [edit routing-instances routing-instance-name protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis traffic-engineering]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Disable IS-IS on the routing device, on an interface, or on a level. At the [edit protocols isis traffic-engineering] hierarchy level, disable IS-IS support for traffic engineering. Enabling IS-IS on an interface (by including the interface statement at the [edit protocols isis] or the [edit routing-instances routing-instance-name protocols isis] hierarchy level), disabling it (by including the disable statement), and not actually having IS-IS run on an interface (by including the passive statement) are mutually exclusive states.

Default

IS-IS is enabled for Level 1 and Level 2 routers on all interfaces on which an International Organization for Standardization (ISO) protocol family is enabled. IS-IS support for traffic engineering is enabled.


442


IS-IS Overview on page 337

•

Disabling IS-IS Support for Traffic Engineering on page 400

•

Disabling IS-IS on page 405



disable (LDP Synchronization) Syntax Hierarchy Level


disable; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced in Junos OS Release 7.5. Disable LDP for IS-IS. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



Release Information


export [ policy-names ]; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Apply one or more policies to routes being exported from the routing table into IS-IS. policy-names—Name of one or more policies.


Applying Policies to Routes Exported to IS-IS on page 406

•



443


external-preference Syntax Hierarchy Level

Release Information

Description Options

external-preference preference; [edit logical-systems logical-system-name protocols isis level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances routing-instance-name protocols isis level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the preference of external routes. preference—Preference value. 32

Range: 0 through 4,294,967,295 (2

– 1)

Default: 15 (for Level 1 internal routes), 18 (for Level 2 internal routes), 160 (for Level 1 external routes), 165 (for Level 2 external routes) Required Privilege Level Related Documentation

444


preference on page 480

•




family Syntax

Hierarchy Level


Options

family inet { shortcuts { multicast-rpf-routes; } } family inet6 { shortcuts; } [edit logical-systems logical-system-name protocols isis level], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level] [edit protocols isis level], [edit routing-instances routing-instance-name protocols isis level],

Statement introduced in Junos OS Release 9.3. Configure the address family for traffic engineering IS-IS interior gateway protocol (IGP) shortcuts. Support for IPv6 for IGP shortcuts introduced in Junos OS Release 9.3. inet—IPv4 address family inet6—IPv6 address family





445



Hierarchy Level

Release Information

Description Options

graceful-restart { disable; helper-disable; restart-duration seconds; } [edit logical-systems logical-system-name protocols isis], [edit protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure graceful restart for IS-IS. disable—Disable graceful restart. helper-disable—Disable graceful restart helper capability. Helper mode is enabled by

default. restart-duration seconds—Configure the time period for the restart to last, in seconds.


446



•

Configuring Graceful Restart for IS-IS on page 397



hello-authentication-key Syntax Hierarchy Level

Release Information

Description

Default

Options

hello-authentication-key password; [edit logical-systems logical-system-name protocols isis interface interface-namelevel number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level number], [edit protocols isis interface interface-name level number], [edit routing-instances routing-instance-name protocols isis interface interface-name level number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure an authentication key (password) for hello packets. Neighboring routing devices use the password to verify the authenticity of packets sent from an interface. For the key to work, you also must include the hello-authentication-type statement. By default, hello authentication is not configured on an interface. However, if IS-IS authentication is configured, the hello packets are authenticated using the IS-IS authentication type and password. password—Authentication password. The password can be up to 255 characters.

Characters can include any ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”). Required Privilege Level Related Documentation



•

authentication-type on page 436

•

hello-authentication-type on page 449

•



447


hello-authentication-key-chain Syntax Hierarchy Level


hello-authentication-key-chain key-chain-name; [edit logical-systems name protocols isis interface interface-name level level-number], [edit logical-systems name routing-instances instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name level level-number], [edit routing-instances instance-name protocols isis interface interface-name level level-number]

Statement introduced in Junos OS Release 11.2. Apply and enable an authentication keychain to the IS-IS interface. key-chain-name—Authentication keychain name. It can be up to 126 characters. Characters

can include any ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”). Required Privilege Level Related Documentation

448



•




hello-authentication-type Syntax Hierarchy Level

Release Information

Description

Default

Options

hello-authentication-type (md5 | simple); [edit logical-systems logical-system-name protocols isis interface interface-name level number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level number], [edit protocols isis interface interface-name level number], [edit routing-instances routing-instance-name protocols isis interface interface-name level number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Enable authentication on an interface for hello packets. If you enable authentication on hello packets, you must specify a password by including the hello-authentication-key statement. By default, hello authentication is not configured on an interface. However, if IS-IS authentication is configured, the hello packets are authenticated using the IS-IS authentication type and password. md5—Specifies Message Digest 5 as the packet verification type. simple—Specifies simple authentication as the packet verification type.




•

authentication-type on page 436

•

hello-authentication-key on page 447

•



449


hello-interval Syntax Hierarchy Level

Release Information

Description

Options

hello-interval seconds; [edit logical-systems logical-system-name protocols isis interface interface-name level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Frequency with which the routing device sends hello packets out of an interface, in seconds. seconds—Frequency of transmission for hello packets.

Range: 1 through 20,000 seconds Default: 3 seconds (for designated intersystem [DIS] routers), 9 seconds (for non-DIS routers) Required Privilege Level Related Documentation

450


hold-time on page 453

•

Configuring the Transmission Frequency for IS-IS Hello Packets on page 390



hello-padding Syntax Hierarchy Level

Release Information

Description

Options

hello-padding (adaptive | loose | strict); [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced in Junos OS Release 8.0. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure padding on hello packets to accommodate asymmetrical maximum transfer units (MTUs) from different hosts. adaptive—Configure padding until state of neighbor adjacency is up. loose—Configure padding until state of adjacency is initialized. strict—Configure padding for all adjacency states.



Enabling Padding of IS-IS Hello Packets on page 401


451


hold-time See the following sections: •

hold-time (IS-IS) on page 452

•

hold-time (LDP Synchronization) on page 453

hold-time (IS-IS) Syntax Hierarchy Level

Release Information

Description

Options

hold-time seconds; [edit logical-systems logical-system-name protocols isis interface interface-namelevel level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Set the length of time a neighbor considers this router to be operative (up) after receiving a hello packet. If the neighbor does not receiver another hello packet within the specified time, it marks this routing device as inoperative (down). The hold time itself is advertised in the hello packets. seconds—Hold-time value, in seconds.

Range: 3 through 65,535 seconds, or 1 to send out hello packets every 333 milliseconds Default: 9 seconds (for DIS routers), 27 seconds (for non-DIS routers; three times the default hello interval) Required Privilege Level Related Documentation

452


hello-interval on page 450

•

Configuring the Delay Before IS-IS Neighbors Mark the Routing Device as Down on page 391



hold-time (LDP Synchronization) Syntax Hierarchy Level


Options

hold-time seconds; [edit logical-systems logical-system-name protocols isis interface interface-name ldp-synchronization], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name ldp-synchronization], [edit protocols isis interface interface-name ldp-synchronization], [edit routing-instances routing-instance-name protocols isis interface interface-name ldp-synchronization]

Statement introduced in Junos OS Release 7.5. Configure the time period to advertise the maximum cost metric for a link that is not fully operational. seconds—Hold-time value, in seconds.

Range: 1 through 65,535 seconds Default: Infinity Required Privilege Level Related Documentation




453


ignore-attached-bit Syntax Hierarchy Level

Release Information

Description


ignore-attached-bit; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Ignore the attached bit on IS-IS Level 1 routers. Configuring this statement allows the routing device to ignore the attached bit on incoming Level 1 LSPs. If the attached bit is ignored, no default route, which points to the routing device which has set the attached bit, is installed. The ignore-attached-bit statement is disabled by default. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Configuring IS-IS on page 344

ignore-lsp-metrics Syntax Hierarchy Level



454

ignore-lsp-metrics; [edit logical-systems logical-system-name protocols isis traffic-engineering], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis traffic-engineering], [edit protocols isis traffic-engineering], [edit routing-instances routing-instance-name protocols isis traffic-engineering]

Statement introduced in Junos OS Release 8.0. Ignore the metrics for RSVP label-switched paths in IS-IS traffic engineering shortcut calculations or when you configure LDP over RSVP label-switched paths. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

shortcuts on page 485

•

Configuring IS-IS to Use IGP Shortcuts on page 398

•




interface Syntax

interface (all | interface-name) { disable; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; } checksum; csnp-interval (seconds | disable); hello-padding (adaptive | loose | strict); ldp-synchronization { disable; hold-time seconds; } lsp-interval milliseconds; mesh-group (value | blocked); no-adjacency-holddown; no-ipv4-multicast; no-ipv6-multicast; no-ipv6-unicast; no-unicast-topology; passive; point-to-point; level level-number { disable; hello-authentication-key key; hello-authentication-key-chain key-chain-name; hello-authentication-type authentication; hello-interval seconds; hold-time seconds; ipv4-multicast-metric number; ipv6-multicast-metric number; ipv6-unicast-metric number; metric metric; passive; priority number; te-metric metric; } }


455


Hierarchy Level

Release Information

Description

[edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure interface-specific IS-IS properties. To configure more than one interface, include the interface statement multiple times. Enabling IS-IS on an interface (by including the interface statement at the [edit protocols isis] or the [edit routing-instances routing-instance-name protocols isis] hierarchy level), disabling it (by including the disable statement), and not actually having IS-IS run on an interface (by including the passive statement) are mutually exclusive states.

Options

all—Have the Junos OS create IS-IS interfaces automatically. interface-name—Name of an interface. Specify the full interface name, including the

physical and logical address components. The remaining statements are explained separately. Required Privilege Level Related Documentation


Configuring of Interface-Specific IS-IS Properties on page 355

ipv4-multicast Syntax Hierarchy Level

Release Information

Description Default Required Privilege Level Related Documentation

456

ipv4-multicast; [edit logical-systems logical-system-name protocols isis topologies], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis topologies], [edit protocols isis topologies], [edit routing-instances routing-instance-name protocols isis topologies]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure alternate IPv4 multicast topologies. Multicast topologies are disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




ipv4-multicast-metric Syntax Hierarchy Level

Release Information

Description Options

ipv4-multicast-metric metric; [edit logical-systems logical-system-name protocols isis interface interface-namelevel level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify the multicast topology metric value for the level. metric—Metric value.

Range: 0 through 16,777,215 Required Privilege Level Related Documentation



ipv6-multicast Syntax Hierarchy Level

Release Information


ipv6-multicast; [edit logical-systems logical-system-name protocols isis topologies], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis topologies], [edit protocols isis topologies], [edit routing-instances routing-instance-name protocols isis topologies]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure alternate IPv6 multicast topologies. Multicast topologies are disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



457


ipv6-multicast-metric Syntax Hierarchy Level

Release Information

Description Options

ipv6-multicast-metric metric; [edit logical-systems logical-system-name protocols isis interface interface-name level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify the IPv6 alternate multicast topology metric value for the level. metric—Metric value.




ipv6-unicast Syntax Hierarchy Level

Release Information


458

ipv6-unicast; [edit logical-systems logical-system-name protocols isis topologies], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis topologies], [edit protocols isis topologies], [edit routing-instances routing-instance-name protocols isis topologies]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure alternate IPv6 unicast topologies. IPv6 unicast topologies are disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




ipv6-unicast-metric Syntax Hierarchy Level

Release Information

Description Options

ipv6-unicast-metric metric; [edit logical-systems logical-system-name protocols isis interface interface-name level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify the IPv6 unicast topology metric value for the level. metric—Metric value.





459


isis Syntax Hierarchy Level

Release Information

Description

isis { ... } [edit logical-systems logical-system-name protocols], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols], [edit protocols], [edit routing-instances routing-instance-name protocols]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Enable IS-IS routing on the routing device or for a routing instance. The isis statement is the one statement you must include in the configuration to run IS-IS on the routing device or in a routing instance.


460

IS-IS is disabled on the routing device. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Minimum IS-IS Configuration on page 347



label-switched-path Syntax Hierarchy Level


Options

label-switched-path name level level-number metric metric; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Advertise LSPs into IS-IS as point-to-point links. The LSP is advertised in the appropriate IS-IS levels as a point-to-point link and contains a local address and a remote address. name—Identifies the LSP. level-number—IS-IS level number.

Values: 1 or 2 metric—Metric value.

Range: 1 through 63, or 1 through 16,777,215 (if you have configured wide metrics) Default: 0 (for lo0), 10 (for all other interfaces) Required Privilege Level Related Documentation


Advertising Label-Switched Paths into IS-IS on page 394


461


-synchronization Syntax

Hierarchy Level


ldp-synchronization { disable; hold-time seconds; } [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced in Junos OS Release 7.5. Enable synchronization by advertising the maximum cost metric until LDP is operational on the link. The remaining statements are explained separately.


462


Example: Configuring Synchronization Between LDP and IGPs on page 583



level See the following sections: •

level (Global IS-IS) on page 463

•

level (IS-IS Interfaces) on page 464

level (Global IS-IS) Syntax

Hierarchy Level

Release Information

Description Options

level level-number { authentication-key key; authentication-key-chain key-chain-name; authentication-type type; external-preference preference; no-csnp-authentication; no-hello-authentication; no-psnp-authentication; preference preference; wide-metrics-only; } [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the global-level properties. level-number—IS-IS level number.

Values: 1 or 2 The remaining statements are explained separately. Required Privilege Level Related Documentation




463


level (IS-IS Interfaces) Syntax

Hierarchy Level

Release Information

Description

Options

level level-number { level (IS-IS Interfaces); hello-authentication-key key; hello-authentication-key-chain key-chain-name; hello-authentication-type authentication; hello-interval seconds; hold-time seconds; ipv4-multicast-metric number; ipv6-unicast-metric number; metric metric; passive; priority number; te-metric metric; } [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the IS-IS level. You can configure one instance of Level 1 routing and one instance of Level 2 routing on each interface, and you can configure the two levels differently. level-number—IS-IS level number.

Values: 1 or 2 Default: The routing device operates as both a Level 1 and Level 2 router. The remaining statements are explained separately. Required Privilege Level Related Documentation

464





link-protection Syntax Hierarchy Level

Release Information

Description


link-protection; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced in Junos OS Release 9.5. Statement introduced in Junos OS Release 9.0 for EX Series switches. Enable link protection on the specified IS-IS interface. The Junos OS creates a backup loop-free alternate path to the primary next hop for all destination routes that traverse the protected interface. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

node-link-protection on page 477

•

Configuring Link Protection for IS-IS on page 411

loose-authentication-check Syntax Hierarchy Level

Release Information


loose-authentication-check; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Allow the use of MD5 authentication without requiring network-wide deployment. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Enabling Authentication for IS-IS Without Network-Wide Deployment on page 401


465


lsp-interval Syntax Hierarchy Level

Release Information

Description Options

lsp-interval milliseconds; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the link-state PDU interval time. milliseconds—Number of milliseconds between the sending of link-state PDUs. Specifying

a value of 0 blocks all link-state PDU transmission. Range: 0 through 1000 milliseconds Default: 100 milliseconds Required Privilege Level Related Documentation

466





lsp-lifetime Syntax Hierarchy Level

Release Information

Description

Options

lsp-lifetime seconds; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify how long a link-state PDU originating from the routing device should persist in the network. The routing device sends link-state PDUs often enough so that the link-state PDU lifetime never expires. seconds—link-state PDU lifetime, in seconds.



Configuring Link-State PDU Lifetime for IS-IS on page 394


467


max-areas Syntax Hierarchy Level

Release Information

Description Options

max-areas number; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis] [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced in Junos OS Release 8.1. Statement introduced in Junos OS Release 9.0 for EX Series switches. Modify the maximum number of IS-IS areas advertised. number—Maximum number of areas to include in the IS-IS hello (IIH) PDUs and link-state

PDUs. Range: 3 through 36 Default: 3 Required Privilege Level Related Documentation

468


Limiting the Number of Advertised IS-IS Areas on page 393



mesh-group Syntax Hierarchy Level

Release Information

Description Options

mesh-group (blocked | value); [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure an interface to be part of a mesh group, which is a set of fully connected nodes. blocked—Configure the interface so that it does not flood link-state PDU packets. value—Number that identifies the mesh group. 32


– 1; 32 bits are allocated to identify a mesh group)




469


metric Syntax Hierarchy Level

Release Information

Description Options

metric metric; [edit logical-systems logical-system-name protocols isis interface interface-name level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify the metric value for the level. metric—Metric value.

Range: 1 through 63, or 1 through 16,777,215 (if you have configured wide metrics) Default: 10 (for all interfaces except lo0), 0 (for the lo0 interface) Required Privilege Level Related Documentation


te-metric on page 487

•

wide-metrics-only on page 492

•


multicast-rpf-routes Syntax Hierarchy Level


470

multicast-rpf-routes; [edit logical-systems logical-system-name protocols isis traffic-engineering family inet shortcuts], [edit logical-systems logical-system-name routing-instances traffic-engineering family inet shortcuts], [edit protocols isis traffic-engineering family inet shortcuts], [edit routing-instances routing-instance-name protocols isis traffic-engineering family inet shortcuts]

Statement introduced in Junos OS Release 9.3. Install IPv4 routes into the multicast routing table for RPF checks. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Installing IPv4 Routes into the Multicast Routing Table on page 400



no-adjacency-down-notification Syntax Hierarchy Level



no-adjacency-down-notification; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit protocols isis interface interface-name]

Statement introduced in Junos OS Release 8.0. Disable adjacency down notification for IS-IS to allow for migration from IS-IS to OSPF without disruption of the RSVP neighbors and associated RSVP-signaled LSPs. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


no-adjacency-holddown Syntax Hierarchy Level

Release Information


no-adjacency-holddown; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced in Junos OS Release 8.0. Statement introduced in Junos OS Release 9.0 for EX Series switches. Disable the hold-down timer for IS-IS adjacencies. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Configuring Quicker Advertisement of IS-IS Adjacency State Changes on page 401


471


no-authentication-check Syntax Hierarchy Level

Release Information

Description


no-authentication-check; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Generate authenticated packets and check the authentication on received packets, but do not reject packets that cannot be authenticated. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

csnp-interval on page 440

•


•


no-csnp-authentication Syntax Hierarchy Level

Release Information


472

no-csnp-authentication; [edit logical-systems logical-system-name protocols isis level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances routing-instance-name protocols isis level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Suppress authentication check on complete sequence number PDU (CSNP) packets. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

csnp-interval on page 440

•




no-eligible-backup Syntax Hierarchy Level

Release Information

Description


no-eligible-backup; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced in Junos OS Release 9.5. Statement introduced in Junos OS Release 9.5 for EX Series switches. Exclude the specified interface as a backup interface for IS-IS interfaces on which link protection or node-link protection is enabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

link-protection on page 465

•


•

Excluding an IS-IS Interface as a Backup for Protected Interfaces on page 412

no-hello-authentication Syntax Hierarchy Level

Release Information


no-hello-authentication; [edit logical-systems logical-system-name protocols isis level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances routing-instance-name protocols isis level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Suppress authentication check on complete sequence number hello packets. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


•



473


no-ipv4-multicast Syntax Hierarchy Level

Release Information


no-ipv4-multicast; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Exclude an interface from the IPv4 multicast topologies. Multicast topologies are disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


no-ipv4-routing Syntax Hierarchy Level

Release Information


474

no-ipv4-routing; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Disable IP version 4 (IPv4) routing. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




no-ipv6-multicast Syntax Hierarchy Level

Release Information


no-ipv6-multicast; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Exclude an interface from the IPv6 multicast topologies. Multicast topologies are disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


no-ipv6-routing Syntax Hierarchy Level

Release Information


no-ipv6-routing; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Disable IP version 6 (IPv6) routing. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



475


no-ipv6-unicast Syntax Hierarchy Level

Release Information


no-ipv6-unicast; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Exclude an interface from the IPv6 unicast topologies. IPv6 unicast topologies are disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


no-psnp-authentication Syntax Hierarchy Level

Release Information


476

no-psnp-authentication; [edit logical-systems logical-system-name protocols isis level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances routing-instance-name protocols isis level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Suppress authentication check on partial sequence number PDU (PSNP) packets. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




no-unicast-topology Syntax Hierarchy Level

Release Information


no-unicast-topology; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Exclude an interface from the IPv4 unicast topologies. IPv4 unicast topologies are disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


node-link-protection Syntax Hierarchy Level

Release Information

Description


node-ink-protection; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-routers logical-router-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced in Junos OS Release 9.5. Statement introduced in Junos OS Release 9.5 for EX Series switches. Enable node-link protection on the specified IS-IS interface. The Junos OS creates an alternate loop-free path to the primary next hop for all destination routes that traverse a protected interface. This alternate path avoids the primary next-hop routing device altogether and establishes a path through a different routing device. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


•

Configuring Node-Link Protection for IS-IS on page 411


477


overload Syntax

Hierarchy Level

Release Information

Description

overload { advertise-high-metrics; allow-route-leaking; timeout seconds; } [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the local routing device so that it appears to be overloaded. You might want to do this when you want the routing device to participate in IS-IS routing, but do not want it to be used for transit traffic. Note that traffic to immediately attached interfaces continues to transit the routing device. You can also advertise maximum link metrics in network layer reachability information (NLRI) instead of setting the overload bit.

NOTE: If the time elapsed after the IS-IS instance is enabled is less than the specified timeout, overload mode is set.

Options

advertise-high-metrics—Advertise maximum link metrics in NLRIs instead of setting the

overload bit. Default: With advertise-high-metrics configured, the routing device in overload mode stops leaking route information into the network. allow-route-leaking—Enable leaking of route information into the network even if the

overload bit is set.

NOTE: The allow-route-leaking option will not work if the routing device is in dynamic overload mode. Dynamic overload can occur if the device has exceeded its resource limits, such as the prefix limit.

timeout seconds—Number of seconds at which the overloading is reset.

Default: 0 seconds Range: 60 through 1800 seconds Required Privilege Level

478





•

Configuring IS-IS to Make Routing Devices Appear Overloaded on page 395

passive Syntax Hierarchy Level

Release Information

Description

passive; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name protocols isis interface interface-name level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name], [edit protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Advertise the direct interface addresses on an interface or into a level on the interface without actually running IS-IS on that interface or level. This statement effectively prevents IS-IS from running on the interface. To enable IS-IS on an interface, include the interface statement at the [edit protocols isis] or the [edit routing-instances routing-instance-name protocols isis] hierarchy level. To disable it, include the disable statement at those hierarchy levels. The three states are mutually exclusive.



disable on page 443

•



479


point-to-point Syntax Hierarchy Level

Release Information


point-to-point; [edit logical-systems logical-system-name protocols isis interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name], [edit protocols isis interface interface-name], [edit routing-instances routing-instance-name protocols isis interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure an IS-IS interface to behave like a point-to-point connection. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



Release Information

Description Options

preference preference; [edit logical-systems logical-system-name protocols isis level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances routing-instance-name protocols isis level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the preference of internal routes. preference—Preference value. 32

Range: 0 through 4,294,967,295 (2

– 1)

Default: 15 (for Level 1 internal routes), 18 (for Level 2 internal routes), 160 (for Level 1 external routes), 165 (for Level 2 external routes) Required Privilege Level Related Documentation

480


external-preference on page 444

•




prefix-export-limit Syntax Hierarchy Level

Release Information

Description Options

prefix-export-limit number; [edit logical-systems logical-system-name protocols isis level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances routing-instance-name protocols isis level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure a limit to the number of prefixes exported into IS-IS. number—Prefix limit. 32


– 1)


Limiting the Number of Prefixes Exported to IS-IS on page 394


481


priority Syntax Hierarchy Level

Release Information

Description

priority number; [edit logical-systems logical-system-name protocols isis interface interface-name level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. The interface’s priority for becoming the designated router. The interface with the highest priority value becomes that level’s designated router. The priority value is meaningful only on a multiaccess network. It has no meaning on a point-to-point interface.

Options

number—Priority value.

Range: 0 through 127 Default: 64 Required Privilege Level Related Documentation

482


Configuring the Designated Router Priority for IS-IS on page 391



reference-bandwidth Syntax Hierarchy Level

Release Information

Description

reference-bandwidth reference-bandwidth; [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Set the reference bandwidth used in calculating the default interface cost. The cost is calculated using the following formula: cost = reference-bandwidth/bandwidth

Options

reference-bandwidth—Reference bandwidth, in megabits per second.

Default: 10 Mbps Range: 9600 through 1,000,000,000,000 Mbps Required Privilege Level Related Documentation


Configuring the Reference Bandwidth Used in IS-IS Metric Calculations on page 392


483


rib-group Syntax

Hierarchy Level

Release Information

Description

rib-group { inet group-name; inet6 group-name; } [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Install routes learned from IS-IS routing instances into routing tables in the IS-IS routing table group. You can install IPv4 routes or IPv6 routes. Support for IPv6 routing table groups in IS-IS enables IPv6 routes that are learned from IS-IS routing instances to be installed into other routing tables defined in an IS-IS routing table group.

Options

group-name—Name of the routing table group. inet—Install IPv4 IS-IS routes. inet6—Install IPv6 IS-IS routes.


484



•


•

Understanding Multiprotocol BGP on page 1190



shortcuts Syntax

Hierarchy Level

Release Information

Description

shortcuts { multicast-rpf-routes; } [edit logical-systems logical-system-name protocols isis traffic-engineering family (inet | inet6)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis traffic-engineering family (inet | inet6)], [edit protocols isis traffic-engineering family (inet | inet6)], [edit routing-instances routing-instance-name protocols isis traffic-engineering family (inet | inet6)]

Statement introduced before Junos OS Release 7.4. The family statement and support for IPv6 routes for IS-IS traffic engineering shortcuts introduced in Junos OS Release 9.3. Configure IS-IS to use MPLS label-switched paths (LSPs) as next hops if possible when installing routing information into the inet.3 or inet6.3 routing table. The remaining statement is explained separately.





485


spf-options Syntax

Hierarchy Level

Release Information

spf-options { delay milliseconds; holddown milliseconds; rapid-runs number; } [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced in Junos OS Release 8.5. Statement introduced in Junos OS Release 9.0 for EX Series switches.

Description

Configure options for running the shortest-path-first (SPF) algorithm. You can configure a delay for when to run the SPF algorithm after a network topology change is detected, the maximum number of times the SPF algorithm can run in succession, and a holddown interval after SPF algorithm runs the maximum number of times.

Options

delay milliseconds—Time interval between the detection of a topology change and when

the SPF algorithm runs. Range: 50 through 1000 milliseconds Default: 200 milliseconds holddown milliseconds—Time interval to hold down, or wait before a subsequent SPF

algorithm runs after the SPF algorithm has run the configured maximum number of times in succession. Range: 2000 through 10,000 milliseconds Default: 5000 milliseconds rapid-runs number—Maximum number of times the SPF algorithm can run in succession.

After the maximum is reached, the holddown interval begins. Range: 1 through 5 Default: 3 Required Privilege Level Related Documentation

486


Configuring SPF Options for IS-IS on page 396



te-metric Syntax Hierarchy Level


Options

te-metric metric; [edit logical-systems logical-system-name protocols isis interface interface-name level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis interface interface-name level level-number], [edit protocols isis interface interface-name level level-number], [edit routing-instances routing-instance-name protocols isis interface interface-name level level-number]

Statement introduced before Junos OS Release 7.4. Metric value used by traffic engineering for information injected into the traffic engineering database. The value of the traffic engineering metric does not affect normal IS-IS forwarding. metric—Metric value.

Range: 1 through 16,777,215 Default: Value of the IGP metric Required Privilege Level Related Documentation


metric on page 470

•

wide-metrics-only on page 492

•



487


topologies Syntax

Hierarchy Level

Release Information

Description

topologies { ipv4-multicast; ipv6-multicast; ipv6-unicast; } [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure alternate IS-IS topologies. The remaining statements are explained separately.


488





traceoptions Syntax

Hierarchy Level

Release Information

Description

traceoptions { file name ; flag flag ; } [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure IS-IS protocol-level tracing options. To specify more than one tracing operation, include multiple flag statements.

Default

The default IS-IS protocol-level tracing options are those inherited from the routing protocols traceoptions statement included at the [edit routing-options] hierarchy level.

Options

disable—(Optional) Disable the tracing operation. You can use this option to disable a

single operation when you have defined a broad group of tracing operations, such as all. file name—Name of the file to receive the output of the tracing operation. Enclose the

name within quotation marks (“ ”). All files are placed in the directory /var/log. We recommend that you place IS-IS tracing output in the file isis-log. files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and

so on, until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum number of files, you also must specify a maximum file size with the size option. Range: 2 through 1000 files Default: 10 files flag flag—Tracing operation to perform. To specify more than one flag, include multiple flag statements. IS-IS Protocol-Specific Tracing Flags •

csn—Complete sequence number PDU (CSNP) packets

•

error—Errored IS-IS packets

•

graceful-restart—Graceful restart operation

•

hello—Hello packets


489


•

ldp-synchronization—Synchronization between IS-IS and LDP

•

lsp—Link-state PDU packets

•

lsp-generation—Link-state PDU generation packets

•

packets—All IS-IS protocol packets

•

psn—Partial sequence number PDU (PSNP) packets

•

spf—Shortest-path-first calculations

Global Tracing Flags •


•

general—A combination of the normal and route trace operations

•

normal—All normal operations, including adjacency changes

Default: If you do not specify this option, only unusual or abnormal operations are traced. •


•


•


•


•


flag-modifier—(Optional) Modifier for the tracing flag. You can specify one or more of

these modifiers: •


•


•



or gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. Note that if you specify a maximum file size, you also must specify a maximum number of trace files with the files option. Syntax: xk to specify KB, xm to specify MB, or xg to specify GB Range: 10 KB through the maximum file size supported on your system Default: 128 KB world-readable—(Optional) Allow any user to read the log file.

490





Tracing IS-IS Protocol Traffic on page 416

traffic-engineering Syntax

Hierarchy Level

Release Information


traffic-engineering { credibility-protocol-preference; disable; family inet; shortcuts { multicast-rpf-routes; } } family inet6 { shortcuts; } } [edit logical-systems logical-system-name protocols isis], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis], [edit protocols isis], [edit routing-instances routing-instance-name protocols isis]

Statement introduced before Junos OS Release 7.4. Support for the family statement introduced in Junos OS Release 9.3. credibility-protocol-preference statement introduced in Junos OS Release 9.4. Configure traffic engineering properties for IS-IS. IS-IS traffic engineering support is enabled. credibility-protocol-preference—Specify for IS-IS to use the configured protocol preference

for IGP routes to determine the traffic engineering database credibility value. By default, the traffic engineering database prefers IS-IS routes even when the routes of another IGP are configured with a lower, that is, more preferred, preference value. Use this statement to override this default behavior. The remaining statements are explained separately. Required Privilege Level Related Documentation


traffic-engineering on page 828

•



491


wide-metrics-only Syntax Hierarchy Level

Release Information


492

wide-metrics-only; [edit logical-systems logical-system-name protocols isis level level-number], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols isis level level-number], [edit protocols isis level level-number], [edit routing-instances routing-instance-name protocols isis level level-number]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure IS-IS to generate metric values greater than 63 on a per IS-IS level basis. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

te-metric on page 487

•

Enabling Wide IS-IS Metrics for Traffic Engineering on page 393


CHAPTER 16

Introduction to OSPF This chapter discusses the following topics that provide background information about OSPF: •

OSPF Overview on page 494

•

OSPF Areas and Router Functionality Overview on page 498

•

Packets Overview on page 500

•

OSPF External Metrics Overview on page 503

•

OSPF Routing Policy Overview on page 503

•

Supported OSPF and OSPFv3 Standards on page 504


493


OSPF Overview OSPF is an interior gateway protocol (IGP) that routes packets within a single autonomous system (AS). OSPF uses link-state information to make routing decisions, making route calculations using the shortest-path-first (SPF) algorithm (also referred to as the Dijkstra algorithm). Each router running OSPF floods link-state advertisements throughout the AS or area that contain information about that router’s attached interfaces and routing metrics. Each router uses the information in these link-state advertisements to calculate the least cost path to each network and create a routing table for the protocol. Junos OS supports OSPF version 2 (OSPFv2) and OSPF version 3 (OSPFv3), including virtual links, stub areas, and for OSPFv2, authentication. Junos OS does not support type-of-service (ToS) routing. OSPF was designed for the Transmission Control Protocol/Internet Protocol (TCP/IP) environment and as a result explicitly supports IP subnetting and the tagging of externally derived routing information. OSPF also provides for the authentication of routing updates. OSPF routes IP packets based solely on the destination IP address contained in the IP packet header. OSPF quickly detects topological changes, such as when router interfaces become unavailable, and calculates new loop-free routes quickly and with a minimum of routing overhead traffic. An OSPF AS can consist of a single area, or it can be subdivided into multiple areas. In a single-area OSPF network topology, each router maintains a database that describes the topology of the AS. Link-state information for each router is flooded throughout the AS. In a multiarea OSPF topology, each router maintains a database that describes the topology of its area, and link-state information for each router is flooded throughout that area. All routers maintain summarized topologies of other areas within an AS. Within each area, OSPF routers have identical topological databases. When the AS or area topology changes, OSPF ensures that the contents of all routers’ topological databases converge quickly. All OSPFv2 protocol exchanges can be authenticated. OSPFv3 relies on IPsec to provide this functionality. This means that only trusted routers can participate in the AS’s routing. A variety of authentication schemes can be used. A single authentication scheme is configured for each area, which enables some areas to use stricter authentication than others. Externally derived routing data (for example, routes learned from BGP) is passed transparently throughout the AS. This externally derived data is kept separate from the OSPF link-state data. Each external route can be tagged by the advertising router, enabling the passing of additional information between routers on the boundaries of the AS.

NOTE: By default, Junos OS is compatible with RFC 1583, OSPF Version 2. In Junos OS Release 8.5 and later, you can disable compatibility with RFC 1583 by including the no-rfc-1583 statement. For more information, see “Example: Disabling OSPFv2 Compatibility with RFC 1583” on page 538.

494


Chapter 16: Introduction to OSPF

This topic describes the following information: •

OSPF Default Route Preference Values on page 495

•

OSPF Routing Algorithm on page 495

•

OSPF Three-Way Handshake on page 496

•

OSPF Version 3 on page 497

OSPF Default Route Preference Values The Junos OS routing protocol process assigns a default preference value to each route that the routing table receives. The default value depends on the source of the route. The preference value is from 0 through 4,294,967,295 (232 – 1), with a lower value indicating a more preferred route. Table 10 on page 495 lists the default preference values for OSPF.

Table 10: Default Route Preference Values for OSPF How Route Is Learned

Default Preference


OSPF internal route

10

OSPF preference


150


OSPF Routing Algorithm OSPF uses the shortest-path-first (SPF) algorithm, also referred to as the Dijkstra algorithm, to determine the route to each destination. All routing devices in an area run this algorithm in parallel, storing the results in their individual topological databases. Routing devices with interfaces to multiple areas run multiple copies of the algorithm. This section provides a brief summary of how the SPF algorithm works. When a routing device starts, it initializes OSPF and waits for indications from lower-level protocols that the router interfaces are functional. The routing device then uses the OSPF hello protocol to acquire neighbors, by sending hello packets to its neighbors and receiving their hello packets. On broadcast or nonbroadcast multiaccess networks (physical networks that support the attachment of more than two routing devices), the OSPF hello protocol elects a designated router for the network. This routing device is responsible for sending link-state advertisements (LSAs) that describe the network, which reduces the amount of network traffic and the size of the routing devices’ topological databases. The routing device then attempts to form adjacencies with some of its newly acquired neighbors. (On multiaccess networks, only the designated router and backup designated router form adjacencies with other routing devices.) Adjacencies determine the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies, and topological database updates are sent only along adjacencies. When adjacencies have been established, pairs of adjacent routers synchronize their topological databases.


495


A routing device sends LSA packets to advertise its state periodically and when its state changes. These packets include information about the routing device’s adjacencies, which allows detection of nonoperational routing devices. Using a reliable algorithm, the routing device floods LSAs throughout the area, which ensures that all routing devices in an area have exactly the same topological database. Each routing device uses the information in its topological database to calculate a shortest-path tree, with itself as the root. The routing device then uses this tree to route network traffic. The description of the SPF algorithm up to this point has explained how the algorithm works within a single area (intra-area routing). For internal routers to be able to route to destinations outside the area (interarea routing), the area border routers must inject additional routing information into the area. Because the area border routers are connected to the backbone, they have access to complete topological data about the backbone. The area border routers use this information to calculate paths to all destinations outside its area and then advertise these paths to the area’s internal routers. Autonomous system (AS) boundary routers flood information about external autonomous systems throughout the AS, except to stub areas. Area border routers are responsible for advertising the paths to all AS boundary routers.

OSPF Three-Way Handshake OSPF creates a topology map by flooding LSAs across OSPF-enabled links. LSAs announce the presence of OSPF-enabled interfaces to adjacent OSPF interfaces. The exchange of LSAs establishes bidirectional connectivity between all adjacent OSPF interfaces (neighbors) using a three-way handshake, as shown in Figure 14 on page 496.

Figure 14: OSPF Three-Way Handshake

In Figure 14 on page 496, Router A sends hello packets out all its OSPF-enabled interfaces when it comes online. Router B receives the packet, which establishes that Router B can receive traffic from Router A. Router B generates a response to Router A to acknowledge receipt of the hello packet. When Router A receives the response, it establishes that Router B can receive traffic from Router A. Router A then generates a final response packet to inform Router B that Router A can receive traffic from Router B. This three-way handshake ensures bidirectional connectivity. As new neighbors are added to the network or existing neighbors lose connectivity, the adjacencies in the topology map are modified accordingly through the exchange (or absence) of LSAs. These LSAs advertise only the incremental changes in the network, which helps minimize the amount of OSPF traffic on the network. The adjacencies are shared and used to create the network topology in the topological database.

496



OSPF Version 3 OSPFv3 is a modified version of OSPF that supports IP version 6 (IPv6) addressing. OSPFv3 differs from OSPFv2 in the following ways:


•

All neighbor ID information is based on a 32-bit router ID.

•

The protocol runs per link rather than per subnet.

•

Router and network link-state advertisements (LSAs) do not carry prefix information.

•

Two new LSA types are included: link-LSA and intra-area-prefix-LSA.

•

Flooding scopes are as follows: •

Link-local

•

Area

•

AS

•

Link-local addresses are used for all neighbor exchanges except virtual links.

•

Authentication is removed. The IPv6 authentication header relies on the IP layer.

•

The packet format has changed as follows: •

Version number 2 is now version number 3.

•

The db option field has been expanded to 24 bits.

•

Authentication information has been removed.

•

Hello messages do not have address information.

•

Two new option bits are included: R and V6.

•

Type 3 summary LSAs have been renamed inter-area-prefix-LSAs.

•

Type 4 summary LSAs have been renamed inter-area-router-LSAs.

•

Understanding OSPF Areas and Backbone Areas on page 513

•

OSPF Configuration Overview on page 508

•

Junos OS OSPF Version 3 for IPv6 Feature Guide


497


OSPF Areas and Router Functionality Overview In OSPF, a single autonomous system (AS) can be divided into smaller groups called areas. This reduces the number of link-state advertisements (LSAs) and other OSPF overhead traffic sent on the network, and it reduces the size of the topology database that each router must maintain. The routing devices that participate in OSPF routing perform one or more functions based on their location in the network. This topic describes the following OSPF area types and routing device functions: •

Areas on page 498

•

Area Border Routers on page 498

•

Backbone Areas on page 498

•

AS Boundary Routers on page 499

•

Backbone Router on page 499

•

Internal Router on page 499

•

Stub Areas on page 499

•

Not-So-Stubby Areas on page 500

•

Transit Areas on page 500

Areas An area is a set of networks and hosts within an AS that have been administratively grouped together. We recommend that you configure an area as a collection of contiguous IP subnetted networks. Routing devices that are wholly within an area are called internal routers. All interfaces on internal routers are directly connected to networks within the area. The topology of an area is hidden from the rest of the AS, thus significantly reducing routing traffic in the AS. Also, routing within the area is determined only by the area’s topology, providing the area with some protection from bad routing data. All routing devices within an area have identical topology databases.

Area Border Routers Routing devices that belong to more than one area and connect one or more OSPF areas to the backbone area are called area border routers (ABRs). At least one interface is within the backbone while another interface is in another area. ABRs also maintain a separate topological database for each area to which they are connected.

Backbone Areas An OSPF backbone area consists of all networks in area ID 0.0.0.0, their attached routing devices, and all ABRs. The backbone itself does not have any ABRs. The backbone distributes routing information between areas. The backbone is simply another area, so the terminology and rules of areas apply: a routing device that is directly connected to

498



the backbone is an internal router on the backbone, and the backbone’s topology is hidden from the other areas in the AS. The routing devices that make up the backbone must be physically contiguous. If they are not, you must configure virtual links to create the appearance of backbone connectivity. You can create virtual links between any two ABRs that have an interface to a common nonbackbone area. OSPF treats two routing devices joined by a virtual link as if they were connected to an unnumbered point-to-point network.

AS Boundary Routers Routing devices that exchange routing information with routing devices in non-OSPF networks are called AS boundary routers. They advertise externally learned routes throughout the OSPF AS. Depending on the location of the AS boundary router in the network, it can be an ABR, a backbone router, or an internal router (with the exception of stub areas). Internal routers within a stub area cannot be an AS boundary router because stub areas cannot contain any Type 5 LSAs. Routing devices within the area where the AS boundary router resides know the path to that AS boundary router. Any routing device outside the area only knows the path to the nearest ABR that is in the same area where the AS boundary router resides.

Backbone Router Backbone routers are routing devices that have one or more interfaces connected to the OSPF backbone area (area ID 0.0.0.0).

Internal Router Routing devices that connect to only one OSPF area are called internal routers. All interfaces on internal routers are directly connected to networks within a single area.

Stub Areas Stub areas are areas through which or into which AS external advertisements are not flooded. You might want to create stub areas when much of the topological database consists of AS external advertisements. Doing so reduces the size of the topological databases and therefore the amount of memory required on the internal routers in the stub area. Routing devices within a stub area rely on the default routes originated by the area’s ABR to reach external AS destinations. You must configure the default-metric option on the ABR before it advertises a default route. Once configured, the ABR advertises a default route in place of the external routes that are not being advertised within the stub area, so that routing devices in the stub area can reach destinations outside the area. The following restrictions apply to stub areas: you cannot create a virtual link through a stub area, a stub area cannot contain an AS boundary router, the backbone cannot be a stub area, and you cannot configure an area as both a stub area and a not-so-stubby area.


499


Not-So-Stubby Areas An OSPF stub area has no external routes in it, so you cannot redistribute from another protocol into a stub area. A not-so-stubby area (NSSA) allows external routes to be flooded within the area. These routes are then leaked into other areas. However, external routes from other areas still do not enter the NSSA. The following restriction applies to NSSAs: you cannot configure an area as both a stub area and an NSSA.

Transit Areas Transit areas are used to pass traffic from one adjacent area to the backbone (or to another area if the backbone is more than two hops away from an area). The traffic does not originate in, nor is it destined for, the transit area. Related Documentation

•


•

Packets Overview on page 500

•


•


•

Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas on page 522

Packets Overview There are several types of link-state advertisement (LSA) packets. This topic describes the following information: •

OSPF Packet Header on page 500

•

Hello Packets on page 501

•

Database Description Packets on page 501

•

Link-State Request Packets on page 501

•

Link-State Update Packets on page 502

•

Link-State Acknowledgment Packets on page 502

•

Link-State Advertisement Packet Types on page 502

OSPF Packet Header All OSPFv2 packets have a common 24-byte header, and OSPFv3 packets have a common 16-byte header, that contains all information necessary to determine whether OSPF should accept the packet. The header consists of the following fields:

500

•

Version number—The current OSPF version number. This can be either 2 or 3.

•

Type—Type of OSPF packet.



•

Packet length—Length of the packet, in bytes, including the header.

•

Router ID—IP address of the router from which the packet originated.

•

Area ID—Identifier of the area in which the packet is traveling. Each OSPF packet is associated with a single area. Packets traveling over a virtual link are labeled with the backbone area ID, 0.0.0.0. .

•

Checksum—Fletcher checksum.

•

Authentication—(OSPFv2 only) Authentication scheme and authentication information.

•

Instance ID—(OSPFv3 only) Identifier used when there are multiple OSPFv3 realms configured on a link.

Hello Packets Routers periodically send hello packets on all interfaces, including virtual links, to establish and maintain neighbor relationships. Hello packets are multicast on physical networks that have a multicast or broadcast capability, which enables dynamic discovery of neighboring routers. (On nonbroadcast networks, dynamic neighbor discovery is not possible, so you must configure all neighbors statically as described in “Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network” on page 543.) Hello packets consist of the OSPF header plus the following fields: •

Network mask—(OSPFv2 only) Network mask associated with the interface.

•

Hello interval—How often the router sends hello packets. All routers on a shared network must use the same hello interval.

•

Options—Optional capabilities of the router.

•

Router priority—The router’s priority to become the designated router.

•

Router dead interval—How long the router waits without receiving any OSPF packets from a router before declaring that router to be down. All routers on a shared network must use the same router dead interval.

•

Designated router—IP address of the designated router.

•

Backup designated router—IP address of the backup designated router.

•

Neighbor—IP addresses of the routers from which valid hello packets have been received within the time specified by the router dead interval.

Database Description Packets When initializing an adjacency, OSPF exchanges database description packets, which describe the contents of the topological database. These packets consist of the OSPF header, packet sequence number, and the link-state advertisement’s header.

Link-State Request Packets When a router detects that portions of its topological database are out of date, it sends a link-state request packet to a neighbor requesting a precise instance of the database.


501


These packets consist of the OSPF header plus fields that uniquely identify the database information that the router is seeking.

Link-State Update Packets Link-state update packets carry one or more link-state advertisements one hop farther from their origin. The router multicasts (floods) these packets on physical networks that support multicast or broadcast mode. The router acknowledges all link-state update packets and, if retransmission is necessary, sends the retransmitted advertisements unicast. Link-state update packets consist of the OSPF header plus the following fields: •

Number of advertisements—Number of link-state advertisements included in this packet.

•

Link-state advertisements—The link-state advertisements themselves.

Link-State Acknowledgment Packets The router sends link-state acknowledgment packets in response to link-state update packets to verify that the update packets have been received successfully. A single acknowledgment packet can include responses to multiple update packets. Link-state acknowledgment packets consist of the OSPF header plus the link-state advertisement header.

Link-State Advertisement Packet Types Link-state request, link-state update, and link-state acknowledgment packets are used to reliably flood link-state advertisement packets. OSPF sends the following types of link-state advertisements:

502

•

Router link advertisements—Are sent by all routers to describe the state and cost of the router’s links to the area. These link-state advertisements are flooded throughout a single area only.

•

Network link advertisements—Are sent by designated routers to describe all the routers attached to the network. These link-state advertisements are flooded throughout a single area only.

•

Summary link advertisements—Are sent by area border routers to describe the routes that they know about in other areas. There are two types of summary link advertisements: those used when the destination is an IP network, and those used when the destination is an AS boundary router. Summary link advertisements describe interarea routes, that is, routes to destinations outside the area but within the AS. These link-state advertisements are flooded throughout the advertisement’s associated areas.

•

AS external link advertisement—Are sent by AS boundary routers to describe external routes that they know about. These link-state advertisements are flooded throughout the AS (except for stub areas).



Each link-state advertisement type describes a portion of the OSPF routing domain. All link-state advertisements are flooded throughout the AS. Each link-state advertisement packet begins with a common 20-byte header. Related Documentation

•


•


•


•

OSPF Designated Router Overview on page 509

•

Understanding OSPFv2 Authentication on page 586

•

OSPF Timers Overview on page 609

OSPF External Metrics Overview When OSPF exports route information from external autonomous systems (ASs), it includes a cost, or external metric, in the route. There are two types of external metrics: Type 1 and Type 2. The difference between the two metrics is how OSPF calculates the cost of the route. Type 1 external metrics are equivalent to the link-state metric, where the cost is equal to the sum of the internal costs plus the external cost. Type 2 external metrics use only the external cost assigned by the AS boundary router. By default, OSPF uses the Type 2 external metric.

OSPF Routing Policy Overview All routing protocols store their routing information in the routing table. The routing table uses this collected route information to determine the active routes to destinations. The routing table then installs the active routes into its forwarding table and also exports them back into the routing protocols. It is these exported routes that the protocols advertise. OSPF has a set of default rules that determine which routes it places in the routing table and advertises from the routing table. The default rules for all routing protocols are known as the default routing policy. The default routing policy is always present. You can further control which routes the protocol stores in the routing table and which routes the routing table exports into the protocol by defining a routing policy for that protocol. A routing policy has a major impact on the flow of routing information or packets within or through the device. The match conditions and actions allow you to configure a customized policy to fit your needs. A user-defined routing policy preempts the default routing policy. To create a routing policy, you must define the policy and apply it. You define the policy by specifying the criteria that a route must match and the actions to perform if a match occurs. You then apply the policy to OSPF.

Default OSPF Routing Policy OSPF is a link-state protocol that exchanges routes between systems within an autonomous system (AS). All devices within an AS must share the same link-state


503


database, which includes routes to reachable prefixes and the metrics associated with the prefixes. The default import policy for OSPF is to accept all learned routes and import them into the routing table. The default export policy for OSPF is to reject everything. OSPF does not actually export its internally learned routes (the directly connected routes on interfaces that are running the protocol). OSPF uses link-state advertisement (LSA) flooding to advertise both local routes and learned routes, and LSA flooding is not affected by the export policy. Related Documentation

•

Understanding OSPF Routing Policy on page 679

•

Creating Routing Policies in the Junos OS Routing Policy Configuration Guide

•

Configuring a Routing Policy in the Junos OS Routing Policy Configuration Guide

Supported OSPF and OSPFv3 Standards The Junos OS substantially supports the following RFCs and Internet drafts, which define standards for OSPF and OSPF version 3 (OSPFv3). •

RFC 1583, OSPF Version 2

•

RFC 1793, Extending OSPF to Support Demand Circuits

•

RFC 2328, OSPF Version 2

•

RFC 2370, The OSPF Opaque LSA Option Support is provided by the update-threshold configuration statement at the [edit protocols rsvp interface interface-name ] hierarchy level.

•

RFC 2740, OSPF for IPv6

•

RFC 3101, The OSPF Not-So-Stubby Area (NSSA) Option

•

RFC 3623, Graceful OSPF Restart

•

RFC 3630, Traffic Engineering (TE) Extensions to OSPF Version 2

•

RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol [sic] Label Switching (GMPLS) Only interface switching is supported.

504

•

RFC 4552, Authentication/Confidentiality for OSPFv3

•

RFC 4576, Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)

•

RFC 4577, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

•

RFC 4811, OSPF Out-of-Band Link State Database (LSDB) Resynchronization

•

RFC 4812, OSPF Restart Signaling

•

RFC 4813, OSPF Link-Local Signaling

•

RFC 4915, Multi-Topology (MT) Routing in OSPF



•

RFC 5185, OSPF Multi-Area Adjacency

•

RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates

•

Internet draft draft-ietf-ospf-af-alt-10.txt, Support of address families in OSPFv3

•

Internet draft draft-katz-ward-bfd-02.txt, Bidirectional Forwarding Detection Transmission of echo packets is not supported.

The following RFCs and Internet drafts do not define standards, but provide information about OSPF and related technologies. The IETF classifies them as “Informational.”


•

RFC 3137, OSPF Stub Router Advertisement

•

RFC 3509, Alternative Implementations of OSPF Area Border Routers

•

RFC 5309, Point-to-Point Operation over LAN in Link State Routing Protocols

•

Supported IPv6 Standards

•

OSPF Features in the Junos OS

•

Accessing Standards Documents on the Internet


505


506


CHAPTER 17

OSPF Configuration Guidelines This chapter describes the following tasks for configuring OSPF: •


•

Examples: Configuring OSPF Designated Routers on page 509

•

Examples: Configuring OSPF Areas on page 512

•

Examples: Configuring OSPF Stub and Not-So-Stubby Areas on page 522

•

Example: Configuring OSPF Multiarea Adjacency on page 533

•

Example: Disabling OSPFv2 Compatibility with RFC 1583 on page 538

•

Examples: Configuring OSPF Interfaces on page 539

•

Example: Configuring Multiple Address Families for OSPFv3 on page 554

•

Examples: Configuring OSPF Route Summarization on page 558

•

Examples: Configuring OSPF Traffic Control on page 566

•

Example: Configuring OSPF Overload Mode on page 576

•

Example: Configuring the OSPF Routing Algorithm on page 580

•


•

Examples: Configuring OSPF Authentication on page 586

•

Example: Configuring OSPF Routing Instances on page 601

•

Example: Configuring OSPF Timers on page 609

•

Example: Configuring BFD for OSPF on page 615

•

Example: Configuring BFD Authentication for OSPF on page 621

•

Examples: Configuring Graceful Restart for OSPF on page 626

•

Examples: Configuring Loop-Free Alternate Routes for OSPF on page 641

•

Examples: Configuring OSPF Traffic Engineering on page 648

•

Example: Configuring OSPF Passive Traffic Engineering Mode on page 656

•

Example: Advertising Label-Switched Paths into OSPFv2 on page 659

•

Example: Configuring OSPFv2 Sham Links on page 670

•

Example: Configuring OSPF Database Protection on page 677

•

Examples: Configuring OSPF Routing Policy on page 679

•

Examples: Configuring Routing Policy for Network Summaries on page 695


507


•

Examples: Configuring OSPF and Logical Systems on page 712

•

Example: Configuring OSPF Trace Options on page 737

•

Verifying an OSPF Configuration on page 744

OSPF Configuration Overview To activate OSPF on a network, you must enable the protocol on all interfaces within the network on which OSPF traffic is to travel. To enable OSPF, you must configure one or more interfaces on the device within an OSPF area. Once the interfaces are configured, OSPF link-state advertisements (LSAs) are transmitted on all OSPF-enabled interfaces, and the network topology is shared throughout the network. To complete the minimum device configuration for a node in an OSPF network involves: 1.

Configuring the device interfaces See the Junos OS Network Interfaces Configuration Guide.

2. Configuring the router identifiers for the devices in your OSPF network 3. Creating the backbone area (area 0) for your OSPF network and adding the appropriate

interfaces to the area

NOTE: Once you complete this step, OSPF begins sending LSAs. No additional configuration is required to enable OSPF traffic on the network.

You can further define your OSPF network depending on your network requirements. Some optional configurations involve: •

Adding additional areas to your network and configure area border routers (ABRs)

•

Enabling dial-on-demand routing backup on the OSPF-enabled interface to configure OSPF across a demand circuit such as an ISDN link. (You must have already configured an ISDN interface.) Because demand circuits do not pass all traffic required to maintain an OSPF adjacency (hello packets, for example), you configure dial-on-demand routing so individual nodes in an OSPF network can maintain adjacencies despite the lack of LSA exchanges.

•

Reducing the amount of memory that the nodes use to maintain the topology database by configuring stub and not-so-stubby areas

•

Ensuring that only trusted routing devices participate in the autonomous systems’ routing by enabling authentication

•

Controlling the flow of traffic across the network by configuring path metrics and route selection

When describing how to configure OSPF, the following terms are used as follows:

508

•

OSPF refers to both OSPF version 2 (OSPFv2) and OSPF version 3 (OSPFv3)

•

OSPFv2 refers to OSPF version 2


Chapter 17: OSPF Configuration Guidelines

•

OSPFv3 refers to OSPF version 3

Examples: Configuring OSPF Designated Routers •


•

Example: Configuring an OSPF Router Identifier on page 510

•

Example: Controlling OSPF Designated Router Election on page 511

OSPF Designated Router Overview Large LANs that have many routing devices and therefore many OSPF adjacencies can produce heavy control-packet traffic as link-state advertisements (LSAs) are flooded across the network. To alleviate the potential traffic problem, OSPF uses designated routers on all multiaccess networks (broadcast and nonbroadcast multiaccess [NBMA] networks types). Rather than broadcasting LSAs to all their OSPF neighbors, the routing devices send their LSAs to the designated router. Each multiaccess network has a designated router, which performs two main functions: •

Originate network link advertisements on behalf of the network.

•

Establish adjacencies with all routing devices on the network, thus participating in the synchronizing of the link-state databases.

In LANs, the election of the designated router takes place when the OSPF network is initially established. When the first OSPF links are active, the routing device with the highest router identifier (defined by the router-id configuration value, which is typically the IP address of the routing device, or the loopback address) is elected the designated router. The routing device with the second highest router identifier is elected the backup designated router. If the designated router fails or loses connectivity, the backup designated router assumes its role and a new backup designated router election takes place between all the routers in the OSPF network. OSPF uses the router identifier for two main purposes: to elect a designated router, unless you manually specify a priority value, and to identify the routing device from which a packet is originated. At designated router election, the router priorities are evaluated first, and the routing device with the highest priority is elected designated router. If router priorities tie, the routing device with the highest router identifier, which is typically the routing device’s IP address, is chosen as the designated router. If you do not configure a router identifier, the IP address of the first interface to come online is used. This is usually the loopback interface. Otherwise, the first hardware interface with an IP address is used. At least one routing device on each logical IP network or subnet must be eligible to be the designated router for OSPFv2. At least one routing device on each logical link must be eligible to be the designated router for OSPFv3. By default, routing devices have a priority of 128. A priority of 0 marks the routing device as ineligible to become the designated router. A priority of 1 means the routing device has the least chance of becoming a designated router. A priority of 255 means the routing device is always the designated router.


509


Example: Configuring an OSPF Router Identifier This example shows how to configure an OSPF router identifier. •


•


•


•



Identify the interfaces on the routing device that will participate in OSPF. You must enable OSPF on all interfaces within the network on which OSPF traffic is to travel.

•


Overview In this example, you configure the OSPF router identifier by setting its router ID value to the IP address of the device, which is 177.162.4.24.

NOTE: We strongly recommended that you configure the router identifier under the [edit routing-options] hierarchy level to avoid unpredictable behavior if the interface address on a loopback interface changes.


To quickly configure an OSPF router identifier, copy the following command and paste it into the CLI. [edit] set routing-options router-id 177.162.4.24


To configure an OSPF router identifier: 1.

Configure the OSPF router identifier by entering the [router-id] configuration value. [edit] user@host# set routing-options router-id 177.162.4.24

2.


Results

510

Confirm your configuration by entering the show routing-options router-id command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.



user@host# show routing-options router-id router-id 177.162.4.24;

Verification After you configure the router ID and activate OSPF on the routing device, the router ID is referenced by multiple OSPF operational mode commands that you can use to monitor and troubleshoot the OSPF protocol. The router ID fields are clearly marked in the output.

Example: Controlling OSPF Designated Router Election This example shows how to control OSPF designated router election. •


•


•


•




•


Overview This example shows how to control OSPF designated router election. Within the example, you set the OSPF interface to ge-/0/0/1 and the device priority to 200. The higher the priority value, the greater likelihood the routing device will become the designated router. By default, routing devices have a priority of 128. A priority of 0 marks the routing device as ineligible to become the designated router. A priority of 1 means the routing device has the least chance of becoming a designated router.


To quickly configure an OSPF designated router election, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.3 interface ge-0/0/1 priority 200


To control OSPF designated router election: 1.

Configure an OSPF interface and specify the device priority.

NOTE: To specify an OSPFv3 interface, include the ospf3 statement at the [edit protocols] hierarchy level.


511


[edit] user@host# set protocols ospf area 0.0.0.3 interface ge-0/0/1 priority 200 2.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.3 { interface ge-0/0/1.0 { priority 200; } }

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.


Verifying the Designated Router Election on page 512

Verifying the Designated Router Election Purpose

Based on the priority you configured for a specific OSPF interface, you can confirm the address of the area’s designated router. The DR ID, DR, or DR-ID field displays the address of the area’s designated router. The BDR ID, BDR, or BDR-ID field displays the address of the backup designated router.

Action

From operational mode, enter the show ospf interface and the show ospf neighbor commands for OSPFv2, and enter the show ospf3 interface and the show ospf3 neighbor commands for OSPFv3.


•


•


Examples: Configuring OSPF Areas

512

•


•

Example: Configuring a Single-Area OSPF Network on page 514

•

Example: Configuring a Multiarea OSPF Network on page 516

•

Example: Configuring OSPF Virtual Links on page 519



Understanding OSPF Areas and Backbone Areas OSPF networks in an autonomous system (AS) are administratively grouped into areas. Each area within an AS operates like an independent network and has a unique 32-bit area ID, which functions similar to a network address. Within an area, the topology database contains only information about the area, link-state advertisements (LSAs) are flooded only to nodes within the area, and routes are computed only within the area. The topology of an area is hidden from the rest of the AS, thus significantly reducing routing traffic in the AS. Subnetworks are divided into other areas, which are connected to form the whole of the main network. Routing devices that are wholly within an area are called internal routers. All interfaces on internal routers are directly connected to networks within the area. The central area of an AS, called the backbone area, has a special function and is always assigned the area ID 0.0.0.0. (Within a simple, single-area network, this is also the ID of the area.) Area IDs are unique numeric identifiers, in dotted decimal notation, but they are not IP addresses. Area IDs need only be unique within an AS. All other networks or areas in the AS must be directly connected to the backbone area by a routing device that has interfaces in more than one area. These connecting routing devices are called area border routers (ABRs). Figure 15 on page 513 shows an OSPF topology of three areas connected by two ABRs.

Figure 15: Multiarea OSPF Topology

Because all areas are adjacent to the backbone area, OSPF routers send all traffic not destined for their own area through the backbone area. The ABRs in the backbone area are then responsible for transmitting the traffic through the appropriate ABR to the destination area. The ABRs summarize the link-state records of each area and advertise destination address summaries to neighboring areas. The advertisements contain the ID of the area in which each destination lies, so that packets are routed to the appropriate ABR. For example, in the OSPF areas shown in Figure 15 on page 513, packets sent from Router A to Router C are automatically routed through ABR B.


513


Junos OS supports active backbone detection. Active backbone detection is implemented to verify that ABRs are connected to the backbone. If the connection to the backbone area is lost, then the routing device’s default metric is not advertised, effectively rerouting traffic through another ABR with a valid connection to the backbone. Active backbone detection enables transit through an ABR with no active backbone connection. An ABR advertises to other routing devices that it is an ABR even if the connection to the backbone is down, so that the neighbors can consider it for interarea routes. An OSPF restriction requires all areas to be directly connected to the backbone area so that packets can be properly routed. All packets are routed first to the backbone area by default. Packets that are destined for an area other than the backbone area are then routed to the appropriate ABR and on to the remote host within the destination area. In large networks with many areas, in which direct connectivity between all areas and the backbone area is physically difficult or impossible, you can configure virtual links to connect noncontiguous areas. Virtual links use a transit area that contains two or more ABRs to pass network traffic from one adjacent area to another. For example, Figure 16 on page 514 shows a virtual link between a noncontiguous area and the backbone area through an area connected to both.

Area 0.0.0.0

Virtual lin k

Area 0.0.0.3 Area 0.0.0.2

g015011

Figure 16: OSPF Topology with a Virtual Link

In the topology shown in Figure 16 on page 514, a virtual link is established between area 0.0.0.3 and the backbone area through area 0.0.0.2. All outbound traffic destined for other areas is routed through area 0.0.0.2 to the backbone area and then to the appropriate ABR. All inbound traffic destined for area 0.0.0.3 is routed to the backbone area and then through area 0.0.0.2.

Example: Configuring a Single-Area OSPF Network This example shows how to configure a single-area OSPF network. •


•


•


•


Requirements Before you begin:

514



•


•


Overview To activate OSPF on a network, you must enable the OSPF protocol on all interfaces within the network on which OSPF traffic is to travel. To enable OSPF, you must configure one or more interfaces on the device within an OSPF area. Once the interfaces are configured, OSPF LSAs are transmitted on all OSPF-enabled interfaces, and the network topology is shared throughout the network. In an autonomous system (AS), the backbone area is always assigned area ID 0.0.0.0 (within a simple, single-area network, this is also the ID of the area). Area IDs are unique numeric identifiers, in dotted decimal notation. Area IDs need only be unique within an AS. All other networks or areas in the AS must be directly connected to the backbone area by area border routers that have interfaces in more than one area. You must also create a backbone area if your network consists of multiple areas. In this example, you create the backbone area and add interfaces, such as ge-0/0/0, as needed to the OSPF area. To use OSPF on the device, you must configure at least one OSPF area, such as the one shown in Figure 17 on page 515.

Figure 17: Typical Single-Area OSPF Network Topology


To quickly configure a single-area OSPF network, copy the following command and paste it into the CLI. You repeat this configuration for all interfaces that are part of the OSPF area. [edit] set protocols ospf area 0.0.0.0 interface ge-0/0/0


515



To configure a single-area OSPF network: 1.

Configure the single-area OSPF network by specifying the area ID and associated interface.

NOTE: For a single-area OSPFv3 network, include the ospf3 statement at the [edit protocols] hierarchy level.

[edit] user@host# set protocols ospf area 0.0.0.0 interface ge-0/0/0 2.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.0 { interface ge-0/0/0.0; }



Verifying the Interfaces in the Area on page 516

Verifying the Interfaces in the Area Purpose

Action

Verify that the interface for OSPF or OSPFv3 has been configured for the appropriate area. Confirm that the Area field displays the value that you configured. From operational mode, enter the show ospf interface command for OSPFv2, and enter the show ospf3 interface command for OSPFv3.

Example: Configuring a Multiarea OSPF Network This example shows how to configure a multiarea OSPF network. To reduce traffic and topology maintenance for the devices in an OSPF autonomous system (AS), you can group the OSPF-enabled routing devices into multiple areas.

516

•


•




•


•




•


•


•

Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on page 514.

Overview To activate OSPF on a network, you must enable the OSPF protocol on all interfaces within the network on which OSPF traffic is to travel. To enable OSPF, you must configure one or more interfaces on the device within an OSPF area. Once the interfaces are configured, OSPF LSAs are transmitted on all OSPF-enabled interfaces, and the network topology is shared throughout the network. Each OSPF area consists of routing devices configured with the same area number. In Figure 18 on page 517, Router B resides in the backbone area of the AS. The backbone area is always assigned area ID 0.0.0.0. (All area IDs must be unique within an AS.) All other networks or areas in the AS must be directly connected to the backbone area by a router that has interfaces in more than one area. In this example, these area border routers are A, C, D, and E. You create an additional area (area 2) and assign it unique area ID 0.0.0.2, and then add interface ge-0/0/0 to the OSPF area. To reduce traffic and topology maintenance for the devices in an OSPF AS, you can group them into multiple areas as shown in Figure 18 on page 517.

Figure 18: Typical Multiarea OSPF Network Topology


517



To quickly configure a multiarea OSPF network, copy the following command and paste it into the CLI. You repeat this configuration for all interfaces that are part of the OSPF area. [edit] set protocols ospf area 0.0.0.2 interface ge-0/0/0


To configure a multiarea OSPF network: 1.

Configure an additional area for your OSPF network.

NOTE: For a multiarea OSPFv3 network, include the ospf3 statement at the [edit protocols] hierarchy level.

[edit] user@host# set protocols ospf area 0.0.0.2 interface ge-0/0/0 2.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.2 { interface ge-0/0/0.0; }





Action

518

Verify that the interface for OSPF or OSPFv3 has been configured for the appropriate area. Confirm that the Area field displays the value that you configured. From operational mode, enter the show ospf interface command for OSPFv2, and enter the show ospf3 interface command for OSPFv3.



Example: Configuring OSPF Virtual Links This example shows how to configure an OSPF virtual link to connect noncontiguous areas. •


•


•


•




•


•

Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 516.

Overview If any routing device on the backbone is not physically connected to the backbone, you must establish a virtual connection between that routing device and the backbone to connect the noncontiguous areas. To configure an OSPF virtual link through an area, you specify the router ID (IP address) of the routing devices at each end of the virtual link. These routing devices must be area border routers (ABRs), with one that is physically connected to the backbone. You cannot configure virtual links through stub areas. You must also specify the number of the area through which the virtual link transits (also known as the transit area). You apply these settings to the backbone area (defined by the area 0.0.0.0) configuration on the ABRs that are part of the virtual link. In this example, Device R1 and Device R2 are the routing devices at each end of the virtual link, with Device R1 physically connected to the backbone, as shown in Figure 19 on page 520. You configure the following virtual link settings: •

neighbor-id—Specifies the IP address of the routing device at the other end of the virtual

link. In this example, Device R1 has a router ID of 192.168.0.5, and Device R2 has a router ID of 192.168.0.3. •

transit-area—Specifies the area identifier through which the virtual link transits. In this

example, area 0.0.0.3 is not connected to the backbone, so you configure a virtual link session between area 0.0.0.3 and the backbone area through area 0.0.0.2. Area 0.0.0.2 is the transit area.


519


Figure 19: OSPF Virtual Link

Area 0.0.0.0

Virtual link

R2

Area 0.0.0.2

Area 0.0.0.3

g040876

R1


•

To quickly configure an OSPF virtual link on the local routing device (Device R1), copy the following commands and paste them into the CLI.

NOTE: You must configure both routing devices that are part of the virtual link and specify the applicable neighbor ID on each routing device.

[edit] set routing-options router-id 192.168.0.5 set protocols ospf area 0.0.0.0 virtual-link neighbor-id 192.168.0.3 transit-area 0.0.0.2 •

To quickly configure an OSPF virtual link on the remote routing device (Device R2), copy the following commands and paste them into the CLI. [edit] set routing-options router-id 192.168.0.3 set protocols ospf area 0.0.0.0 virtual-link neighbor-id 192.168.0.5 transit-area 0.0.0.2


To configure an OSPF virtual link on the local routing device (Device R1): 1.

Configure the router ID. [edit] user@R1# set routing-options router-id 192.168.0.5

2.

Enter OSPF configuration mode and specify OSPF area 0.0.0.0.

NOTE: For an OSPFv3 virtual link, include the ospf3 statement at the [edit protocols] hierarchy level.

[edit] user@R1# edit protocols ospf area 0.0.0.0 3.

Configure an OSPF virtual link and specify the transit area 0.0.0.2. This routing device must be an ABR that is physically connected to the backbone. [edit protocols ospf area 0.0.0.0]

520



user@R1# set virtual-link neighbor-id 192.168.0.3 transit-area 0.0.0.2 4.

If you are done configuring the device, commit the configuration. [edit protocols ospf area 0.0.0.0] user@R1# commit


To configure an OSPF virtual link on the remote ABR (Device R2, the routing device at the other end of the link): 1.

Configure the router ID. [edit] user@R2# set routing-options router-id 192.168.0.3

2.

Enter OSPF configuration mode and specify OSPF area 0.0.0.0.

NOTE: For an OSPFv3 virtual link, include the ospf3 statement at the [edit protocols] hierarchy level.

[edit] user@R2# edit protocols ospf area 0.0.0.0 3.

Configure an OSPF virtual link on the remote ABR and specify the transit area 0.0.0.2. This routing device is not physically connected to the backbone. [edit protocols ospf area 0.0.0.0] user@R2# set virtual-link neighbor-id 192.168.0.5 transit-area 0.0.0.2

4.

If you are done configuring the device, commit the configuration. [edit protocols ospf area 0.0.0.0] user@R2# commit

Results

Confirm your configuration by entering the show routing-options and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on the local routing device (Device R1): user@R1#: show routing-options router-id 192.168.0.5; user@R1# show protocols ospf area 0.0.0.0 { virtual-link neighbor-id 192.168.0.3 transit-area 0.0.0.2; }

Configuration on the remote ABR (Device R2): user@R2#: show routing-options router-id 192.168.0.3; user@R2# show protocols ospf area 0.0.0.0 { virtual-link neighbor-id 192.168.0.5 transit-area 0.0.0.2;


521


}



Verifying Entries in the Link-State Database on page 522

•

Verifying OSPF Interface Status and Configuration on page 522

Verifying Entries in the Link-State Database Purpose

Verify that the entries in the OSPFv2 or OSPFv3 link-state database display. The Router field in the OSPFv2 output displays LSA information, including the type of link. If configured as a virtual link, the Type is Virtual. For each router link, the Type field in the OSPFv3 output displays the type of interface. If configured as a virtual link, the Type is Virtual.

Action

From operational mode, enter the show ospf database detail command for OSPFv2, and enter the show ospf3 database detail command for OSPFv3. Verifying OSPF Interface Status and Configuration

Purpose

Verify that the OSPFv2 or OSPFv3 interface is configured and status displays. The Type field displays the type of interface. If the interface is configured as part of a virtual link, the Type is Virtual.

Action

From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3.


•


•


Examples: Configuring OSPF Stub and Not-So-Stubby Areas •

Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas on page 522

•

Example: Configuring OSPF Stub and Totally Stubby Areas on page 524

•

Example: Configuring OSPF Not-So-Stubby Areas on page 528

Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas Figure 20 on page 523 shows an autonomous system (AS) across which many external routes are advertised. If external routes make up a significant portion of a topology database, you can suppress the advertisements in areas that do not have links outside the network. By doing so, you can reduce the amount of memory the nodes use to maintain the topology database and free it for other uses.

522



Figure 20: OSPF AS Network with Stub Areas and NSSAs

Area 0.0.0.0

Static customer routes 192.112.67.14 192.112.67.29 ...

Area 0.0.0:4 g015012

Area 0.0.0.3

To control the advertisement of external routes into an area, OSPF uses stub areas. By designating an area border router (ABR) interface to the area as a stub interface, you suppress external route advertisements through the ABR. Instead, the ABR advertises a default route (through itself) in place of the external routes and generates network summary (Type 3) link-state advertisements (LSAs). Packets destined for external routes are automatically sent to the ABR, which acts as a gateway for outbound traffic and routes the traffic appropriately.

NOTE: You must explicitly configure the ABR to generate a default route when attached to a stub or not-so-stubby-area (NSSA). To inject a default route with a specified metric value into the area, you must configure the default-metric option and specify a metric value.

For example, area 0.0.0.3 in Figure 20 on page 523 is not directly connected to the outside network. All outbound traffic is routed through the ABR to the backbone and then to the destination addresses. By designating area 0.0.0.3 as a stub area, you reduce the size of the topology database for that area by limiting the route entries to only those routes internal to the area. A stub area that only allows routes internal to the area and restricts Type 3 LSAs from entering the stub area is often called a totally stubby area. You can convert area 0.0.0.3 to a totally stubby area by configuring the ABR to only advertise and allow the default route to enter into the area. External routes and destinations to other areas are no longer summarized or allowed into a totally stubby area.

NOTE: If you incorrectly configure a totally stubby area, you might encounter network connectivity issues. You should have advanced knowledge of OSPF and understand your network environment before configuring totally stubby areas.


523


Similar to area 0.0.0.3 in Figure 20 on page 523, area 0.0.0.4 has no external connections. However, area 0.0.0.4 has static customer routes that are not internal OSPF routes. You can limit the external route advertisements to the area and advertise the static customer routes by designating the area an NSSA. In an NSSA, the AS boundary router generates NSSA external (Type 7) LSAs and floods them into the NSSA, where they are contained. Type 7 LSAs allow an NSSA to support the presence of AS boundary routers and their corresponding external routing information. The ABR converts Type 7 LSAs into AS external (Type 5 ) LSAs and leaks them to the other areas, but external routes from other areas are not advertised within the NSSA.

Example: Configuring OSPF Stub and Totally Stubby Areas This example shows how to configure an OSPF stub area and a totally stubby area to control the advertisement of external routes into an area. •


•


•


•




•


•


•


Overview The backbone area, which is 0 in Figure 21 on page 526, has a special function and is always assigned the area ID 0.0.0.0. Area IDs are unique numeric identifiers, in dotted decimal notation. Area IDs need only be unique within an autonomous system (AS). All other networks or areas (such as 3, 7, and 9) in the AS must be directly connected to the backbone area by area border routers (ABRs) that have interfaces in more than one area. Stub areas are areas through which or into which OSPF does not flood AS external link-state advertisements (Type 5 LSAs). You might create stub areas when much of the topology database consists of AS external advertisements and you want to minimize the size of the topology databases on the internal routers in the stub area. The following restrictions apply to stub areas:

524

•

You cannot create a virtual link through a stub area.

•

A stub area cannot contain an AS boundary router.



•

You cannot configure the backbone as a stub area.

•

You cannot configure an area as both a stub area and an not-so-stubby area (NSSA).

In this example, you configure each routing device in area 7 (area ID 0.0.0.7) as a stub router and some additional settings on the ABR: •

stub—Specifies that this area become a stub area and not be flooded with Type 5

LSAs. You must include the stub statement on all routing devices that are in area 7 because this area has no external connections. •

default-metric—Configures the ABR to generate a default route with a specified metric

into the stub area. This default route enables packet forwarding from the stub area to external destinations. You configure this option only on the ABR. The ABR does not automatically generate a default route when attached to a stub. You must explicitly configure this option to generate a default route. •

no-summaries—(Optional) Prevents the ABR from advertising summary routes into

the stub area by converting the stub area into a totally stubby area. If configured in combination with the default-metric statement, a totally stubby area only allows routes internal to the area and advertises the default route into the area. External routes and destinations to other areas are no longer summarized or allowed into a totally stubby area. Only the ABR requires this additional configuration because it is the only routing device within the totally stubby area that creates Type 3 LSAs used to receive and send traffic from outside of the area.

NOTE: In Junos OS Release 8.5 and later, the following applies:


•

A router-identifier interface that is not configured to run OSPF is no longer advertised as a stub network in OSPF LSAs.

•

OSPF advertises a local route with a prefix length of 32 as a stub link if the loopback interface is configured with a prefix length other than 32. OSPF also advertises the direct route with the configured mask length, as in earlier releases.

525


Figure 21: OSPF Network Topology with Stub Areas and NSSAs Area 3

g01503 0

Area 0

0.0.0.7 0.0.0.9 Customer static routes 192.168.47.5 192.168.47.6 ...

Area 7 (Stub)

Area 9 (NSSA)

Customer network


•

To quickly configure an OSPF stub area, copy the following command and paste it into the CLI. You must configure all routing devices that are part of the stub area. [edit] set protocols ospf area 0.0.0.7 stub

•

To quickly configure the ABR to inject a default route into the area, copy the following command and paste it into the CLI. You apply this configuration only on the ABR. [edit] set protocols ospf area 0.0.0.7 stub default-metric 10

•

(Optional) To quickly configure the ABR to restrict all summary advertisements and allow only internal routes and default route advertisements into the area, copy the following command and paste it into the CLI. You apply this configuration only on the ABR. [edit] set protocols ospf area 0.0.0.7 stub no-summaries


To configure OSPF stub areas: 1.

On all routing devices in the area, configure an OSPF stub area.

NOTE: To specify an OSPFv3 stub area, include the ospf3 statement at the [edit protocols] hierarchy level.

[edit] user@host# set protocols ospf area 0.0.0.7 stub 2.

526

On the ABR, inject a default route into the area.



[edit] user@host# set protocols ospf area 0.0.0.7 stub default-metric 10 3.

(Optional) On the ABR, restrict summary LSAs from entering the area. This step converts the stub area into a totally stubby area. [edit] user@host# set protocols ospf area 0.0.0.7 stub no-summaries

4.

If you are done configuring the devices, commit the configuration. [edit] user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on all routing devices: user@host# show protocols ospf area 0.0.0.7 { stub; }

Configuration on the ABR (the output also includes the optional setting): user@host# show protocols ospf area 0.0.0.7 { stub default-metric 10 no-summaries; }




•

Verifying the Type of OSPF Area on page 527


Verify that the interface for OSPF has been configured for the appropriate area. Confirm that the output includes Stub as the type of OSPF area.

Action

From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3. Verifying the Type of OSPF Area

Purpose

Verify that the OSPF area is a stub area. Confirm that the output displays Normal Stub as the Stub type.


527


Action

From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview command for OSPFv3.

Example: Configuring OSPF Not-So-Stubby Areas This example shows how to configure an OSPF not-so-stubby area (NSSA) to control the advertisement of external routes into an area. •


•


•


•




•


•


•


Overview The backbone area, which is 0 in Figure 22 on page 530, has a special function and is always assigned the area ID 0.0.0.0. Area IDs are unique numeric identifiers, in dotted decimal notation. Area IDs need only be unique within an AS. All other networks or areas (such as 3, 7, and 9) in the AS must be directly connected to the backbone area by ABRs that have interfaces in more than one area. An OSPF stub area has no external routes, so you cannot redistribute routes from another protocol into a stub area. OSPF NSSAs allow external routes to be flooded within the area. In addition, you might have a situation when exporting Type 7 LSAs into the NSSA is unnecessary. When an AS boundary router is also an ABR with an NSSA attached, Type 7 LSAs are exported into the NSSA by default. If the ABR is attached to multiple NSSAs, a separate Type 7 LSA is exported into each NSSA by default. During route redistribution, this routing device generates both Type 5 LSAs and Type 7 LSAs. You can disable exporting Type 7 LSAs into the NSSA.

NOTE: The following restriction applies to NSSAs: You cannot configure an area as both a stub area and an NSSA.

528



You configure each routing device in area 9 (area ID 0.0.0.9) with the following setting: •

nssa—Specifies an OSPF NSSA. You must include the nssa statement on all routing

devices in area 9 because this area only has external connections to static routes. You also configure the ABR in area 9 with the following additional settings: •

no-summaries—Prevents the ABR from advertising summary routes into the NSSA. If

configured in combination with the default-metric statement, the NSSA only allows routes internal to the area and advertises the default route into the area. External routes and destinations to other areas are no longer summarized or allowed into the NSSA. Only the ABR requires this additional configuration because it is the only routing device within the NSSA that creates Type 3 LSAs used to receive and send traffic from outside the area. •

default-lsa—Configures the ABR to generate a default route into the NSSA. In this

example, you configure the following: •

default-metric—Specifies that the ABR generate a default route with a specified

metric into the NSSA. This default route enables packet forwarding from the NSSA to external destinations. You configure this option only on the ABR. The ABR does not automatically generate a default route when attached to an NSSA. You must explicitly configure this option for the ABR to generate a default route. •

metric-type—(Optional) Specifies the external metric type for the default LSA, which

can be either Type 1 or Type 2. When OSPF exports route information from external ASs, it includes a cost, or external metric, in the route. The difference between the two metrics is how OSPF calculates the cost of the route. Type 1 external metrics are equivalent to the link-state metric, where the cost is equal to the sum of the internal costs plus the external cost. Type 2 external metrics use only the external cost assigned by the AS boundary router. By default, OSPF uses the Type 2 external metric. •

type-7—(Optional) Floods Type 7 default LSAs into the NSSA if the no-summaries

statement is configured. By default, when the no-summaries statement is configured, a Type 3 LSA is injected into NSSAs for Junos OS release 5.0 and later. To support backward compatibility with earlier Junos OS releases, include the type-7 statement. The second example also shows the optional configuration required to disable exporting Type 7 LSAs into the NSSA by including the no-nssa-abr statement on the routing device that performs the functions of both an ABR and an AS boundary router.


529


Figure 22: OSPF Network Topology with Stub Areas and NSSAs Area 3

g01503 0

Area 0

0.0.0.7 0.0.0.9 Customer static routes 192.168.47.5 192.168.47.6 ...

Area 7 (Stub)

Area 9 (NSSA)

Customer network

Configuration •

Configuring Routing Devices to Participate in a Not-So-Stubby-Area on page 530

•

Disabling the Export of Type 7 Link State Advertisements into Not-So-Stubby Areas on page 532

Configuring Routing Devices to Participate in a Not-So-Stubby-Area CLI Quick Configuration

To quickly configure an OSPF NSSA, copy the following command and paste it into the CLI. You must configure all routing devices that are part of the NSSA. [edit] set protocols ospf area 0.0.0.9 nssa

To quickly configure an ABR that participates in an OSPF NSSA, copy the following commands and paste them into the CLI. [edit] set protocols ospf area 0.0.0.9 nssa default-lsa default-metric 10 set protocols ospf area 0.0.0.9 nssa default-lsa metric-type 1 set protocols ospf area 0.0.0.9 nssa default-lsa type-7 set protocols ospf area 0.0.0.9 nssa no-summaries


To configure OSPF NSSAs: 1.

On all routing devices in the area, configure an OSPF NSSA.

NOTE: To specify an OSPFv3 NSSA area, include the ospf3 statement at the [edit protocols] hierarchy level.

[edit] user@host# set protocols ospf area 0.0.0.9 nssa

530



2.

On the ABR, enter OSPF configuration mode and specify the NSSA area 0.0.0.9 that you already created. [edit ] user@host# edit protocols ospf area 0.0.0.9 nssa

3.

On the ABR, inject a default route into the area. [edit protocols ospf area 0.0.0.9 nssa] user@host# set default-lsa default-metric 10

4.

(Optional) On the ABR, specify the external metric type for the default route. [edit protocols ospf area 0.0.0.9 nssa] user@host# set default-lsa metric-type 1

5.

(Optional) On the ABR, specify the flooding of Type 7 LSAs. [edit protocols ospf area 0.0.0.9 nssa] user@host# set default-lsa type-7

6.

On the ABR, restrict summary LSAs from entering the area. [edit protocols ospf area 0.0.0.9 nssa] user@host# set no-summaries

7.

If you are done configuring the devices, commit the configuration. [edit protocols ospf area 0.0.0.9 nssa] user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on all routing devices in the area: user@host# show protocols ospf area 0.0.0.9 { nssa; }

Configuration on the ABR. The output also includes the optional metric-type and type-7 statements. user@host# show protocols ospf area 0.0.0.9 { nssa { default-lsa { default-metric 10; metric-type 1; type-7; } no-summaries; } }



531


Disabling the Export of Type 7 Link State Advertisements into Not-So-Stubby Areas CLI Quick Configuration

To quickly disable exporting Type 7 LSAs into the NSSA, copy the following command and paste it into the CLI. You configure this setting on an AS boundary router that is also an ABR with an NSSA area attached. [edit] set protocols ospf no-nssa-abr


You can configure this setting if you have an AS boundary router that is also an ABR with an NSSA area attached. 1.

Disable exporting Type 7 LSAs into the NSSA.

NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

[edit] user@host# set protocols ospf no-nssa-abr 2.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf no-nssa-abr;




•

Verifying the Type of OSPF Area on page 533

•

Verifying the Type of LSAs on page 533

Verifying the Interfaces in the Area

532

Purpose

Verify that the interface for OSPF has been configured for the appropriate area. Confirm that the output includes Stub NSSA as the type of OSPF area.

Action




Verifying the Type of OSPF Area Purpose

Verify that the OSPF area is a stub area. Confirm that the output displays Not so Stubby Stub as the Stub type.

Action

From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview command for OSPFv3. Verifying the Type of LSAs

Purpose

Verify the type of LSAs that are in the area. If you disabled exporting Type 7 LSAs into an NSSA, confirm that the Type field does not include NSSA as a type of LSA.

Action

From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview command for OSPFv3.


•


•


Example: Configuring OSPF Multiarea Adjacency •

Multiarea Adjacency for OSPF on page 533

•

Example: Configuring Multiarea Adjacency for OSPF on page 534

Multiarea Adjacency for OSPF By default, a single interface can belong to only one OSPF area. However, in some situations, you might want to configure an interface to belong to more than one area. Doing so allows the corresponding link to be considered an intra-area link in multiple areas and to be preferred over other higher-cost intra-area paths. For example, you can configure an interface to belong to multiple areas with a high-speed backbone link between two area border routers (ABRs) so you can create multiarea adjacencies that belong to different areas. In Junos OS Release 9.2 and later, you can configure a logical interface to belong to more than one OSPFv2 area. Support for OSPFv3 was introduced in Junos OS Release 9.4. As defined in RFC 5185, OSPF Multi-Area Adjacency, the ABRs establish multiple adjacencies belonging to different areas over the same logical interface. Each multiarea adjacency is announced as a point-to-point unnumbered link in the configured area by the routers connected to the link. For each area, one of the logical interfaces is treated as primary, and the remaining interfaces that are configured for the area are designated as secondary. Any logical interface not configured as a secondary interface for an area is treated as the primary interface for that area. A logical interface can be configured as primary interface only for one area. For any other area for which you configure the interface, you must configure it as a secondary interface.


533


Example: Configuring Multiarea Adjacency for OSPF This example shows how to configure multiarea adjacency for OSPF. •


•


•


•


Requirements Before you begin, plan your multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 516.

Overview By default, a single interface can belong to only one OSPF area. You can configure a single interface to belong in multiple OSPF areas. Doing so allows the corresponding link to be considered an intra-area link in multiple areas and to be preferred over other higher-cost intra-area paths. When configuring a secondary interface, consider the following: •

For OSPFv2, you cannot configure point-to-multipoint and nonbroadcast multiaccess (NBMA) network interfaces as a secondary interface because secondary interfaces are treated as a point-to-point unnumbered link.

•

Secondary interfaces are supported for LAN interfaces (the primary interface can be a LAN interface, but any secondary interfaces are treated as point-to-point unnumbered links over the LAN). In this scenario, you must ensure that there are only two routing devices on the LAN or that there are only two routing devices on the LAN that have secondary interfaces configured for a specific OSPF area.

•

Since the purpose of a secondary interface is to advertise a topological path through an OSPF area, you cannot configure a secondary interface or a primary interface with one or more secondary interfaces to be passive. Passive interfaces advertise their address, but do not run the OSPF protocol (adjacencies are not formed and hello packets are not generated).

•

Any logical interface not configured as a secondary interface for an area is treated as a primary interface for that area. A logical interface can be configured as the primary interface only for one area. For any other area for which you configure the interface, you must configure it as a secondary interface.

•

You cannot configure the secondary statement with the interface all statement.

•

You cannot configure a secondary interface by its IP address.

In this example, you configure an interface to be in two areas, creating a multiarea adjacency with a link between two ABRs: ABR R1 and ABR R2. On each ABR, area 0.0.0.1 contains the primary interface and is the primary link between the ABRs, and area 0.0.0.2 contains the secondary logical interface, which you configure by including the secondary

534



statement. You configure interface so-0/0/0 on ABR R1 and interface so-1/0/0 on ABR R2.


To quickly configure a secondary logical interface for an OSPF area, copy the following commands and paste them into the CLI. Configuration on ABR R1: [edit] set interfaces so-0/0/0 unit 0 family inet address 192.168.8.45/30 set routing-options router-id 10.255.0.1 set protocols ospf area 0.0.0.1 interface so-0/0/0 set protocols ospf area 0.0.0.2 interface so-0/0/0 secondary

Configuration on ABR R2: [edit] set interfaces so-1/0/0 unit 0 family inet address 192.168.8.37/30 set routing-options router-id 10.255.0.2 set protocols ospf area 0.0.0.1 interface so-1/0/0 set protocols ospf area 0.0.0.2 interface so-1/0/0 secondary


To configure a secondary logical interface: 1.

Configure the device interfaces.

NOTE: For OSPFv3, on each interface specify the inet6 address family and include the IPv6 address.

[edit] user@R1# set interfaces so-0/0/0 unit 0 family inet address 192.168.8.45/30 [edit] user@R2# set interfaces so-1/0/0 unit 0 family inet address 192.168.8.37/30 2.

Configure the router identifier. [edit] user@R1# set routing-options router-id 10.255.0.1 [edit] user@R2# set routing-options router-id 10.255.0.2

3.

On each ABR, configure the primary interface for the OSPF area.

NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

[edit] user@R1# set protocols ospf 0.0.0.1 interface so-0/0/0


535


[edit ] user@R2# set protocols ospf 0.0.0.2 interface so-1/0/0 4.

On each ABR, configure the secondary interface for the OSPF area. [edit ] user@R1# set protocols ospf area 0.0.0.1 so-0/0/0 secondary [edit ] user@R2# set protocols ospf area 0.0.0.2 so-1/0/0 secondary

5.

If you are done configuring the devices, commit the configuration. [edit protocols ospf area 0.0.0.1 ] user@host# commit

Results

Confirm your configuration by entering the show interfaces, show routing-options, and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on ABR R1: user@R1# show interfaces so-0/0/0 { unit 0 { family inet { address 192.168.8.45/30; } } } user@R1# show routing-options router-id 10.255.0.1; user@R1# show protocols ospf area 0.0.0.1 { interface so-0/0/0.0; } area 0.0.0.2 { interface so-0/0/0.0 { secondary; } }

Configuration on ABR R2: user@R2# show interfaces so-0/0/0 { unit 0 { family inet { address 192.168.8.37/30; } } } user@R2# show routing-options router-id 10.255.0.2; user@R2# show protocols ospf

536



area 0.0.0.1 { interface so-1/0/0.0; } area 0.0.0.2 { interface so-1/0/0.0 { secondary; } }


Verifying the Secondary Interface on page 537

•


•

Verifying Neighbor Adjacencies on page 537

Verifying the Secondary Interface Purpose

Verify that the secondary interface appears for the configured area. The Secondary field displays if the interface is configured as a secondary interface. The output might also show the same interface listed in multiple areas.

Action

From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3. Verifying the Interfaces in the Area

Purpose Action

Verify the interfaces configured for the specified area. From operational mode, enter the show ospf interface area area-id command for OSPFv2, and enter the show ospf3 interface area area-id command for OSPFv3.. Verifying Neighbor Adjacencies

Purpose

Action


Verify the primary and secondary neighbor adjacencies. The Secondary field displays if the neighbor is on a secondary interface. From operational mode, enter the show ospf neighbor detail command for OSPFv2, and enter the show ospf3 neighbor detail command for OSPFv3.

•


•


•



537


Example: Disabling OSPFv2 Compatibility with RFC 1583 •

OSPFv2 Compatibility with RFC 1583 Overview on page 538

•


OSPFv2 Compatibility with RFC 1583 Overview By default, the Junos OS implementation of OSPFv2 is compatible with RFC 1583, OSPF Version 2. This means that Junos OS maintains a single best route to an autonomous system (AS) boundary router in the OSPF routing table, rather than multiple intra-AS paths, if they are available. You can now disable compatibility with RFC 1583. It is preferable to do so when the same external destination is advertised by AS boundary routers that belong to different OSPF areas. When you disable compatibility with RFC 1583, the OSPF routing table maintains the multiple intra-AS paths that are available, which the router uses to calculate AS external routes as defined in RFC 2328, OSPF Version 2. Being able to use multiple available paths to calculate an AS external route can prevent routing loops.

Example: Disabling OSPFv2 Compatibility with RFC 1583 This example shows how to disable OSPFv2 compatibility with RFC 1583 on the routing device. •


•


•


•


Requirements No special configuration beyond device initialization is required before disabling OSPFv2 compatibility with RFC 1583.

Overview The introduction of RFC 2328 changed the method used to calculate the routes in an OSPF network. By default, the Junos OS implementation of OSPFv2 is compatible with RFC 1583, so OSPF uses the minimum cost to determine the route to any of the networks within the specified range. When you disable RFC 1583 compatibility, OSPF uses the maximum cost to determine the route to any of the networks within the specified range. To minimize the potential for routing loops, configure the same RFC compatibility on all OSPF devices in an OSPF domain.


To quickly disable OSPFv2 compatibility with RFC 1583, copy the following command and paste it into the CLI. You configure this setting on all devices that are part of the OSPF domain. [edit] set protocols ospf no-rfc-1583

538




To disable OSPFv2 compatibility with RFC 1583: 1.

Disable RFC 1583. [edit] user@host# set protocols ospf no-rfc-1583

2.


NOTE: Repeat this configuration on each routing device that participates in an OSPF routing domain.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf no-rfc-1583;

Verification Confirm that the configuration is working properly. Verifying the OSPF Routes Purpose

Action


Verify that the OSPF routing table maintains the intra-AS paths with the largest metric, which the router uses to calculate AS external routes. From operational mode, enter the show ospf route detail command.

•


•


Examples: Configuring OSPF Interfaces •

About OSPF Interfaces on page 540

•

Example: Configuring an Interface on a Broadcast or Point-to-Point Network on page 541

•

Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network on page 543

•

Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint Network on page 546

•

Example: Configuring OSPF Demand Circuits on page 547

•

Example: Configuring a Passive OSPF Interface on page 550

•

Example: Configuring OSPFv2 Peer interfaces on page 552


539


About OSPF Interfaces To activate OSPF on a network, you must enable the OSPF protocol on one or more interfaces on each device within the network on which traffic is to travel. How you configure the interface depends on whether the interface is connected to a broadcast or point-to-point network, a point-to-multipoint network, a nonbroadcast multiaccess (NBMA) network, or across a demand circuit. •

A broadcast interface behaves as if the routing device is connected to a LAN.

•

A point-to-point interface provides a connection between a single source and a single destination (there is only one OSPF adjacency).

•

A point-to-multipoint interface provides a connection between a single source and multiple destinations.

•

An NBMA interface behaves in a similar fashion to a point-to-multipoint interface, but you might configure an NBMA interface to interoperate with other equipment.

•

A demand circuit is a connection on which you can limit traffic based on user agreements. The demand circuit can limit bandwidth or access time based on agreements between the provider and user.

You can also configure an OSPF interface to be passive, to operate in passive traffic engineering mode, or to be a peer interface. •

A passive interface advertises its address, but does not run the OSPF protocol (adjacencies are not formed and hello packets are not generated).

•

An interface operating in OSPF passive traffic engineering mode floods link address information within the autonomous system (AS) and makes it available for traffic engineering calculations.

•

A peer interface can be configured for OSPFv2 routing devices. A peer interface is required for Generalized MPLS (GMPLS) to transport traffic engineering information through a link separate from the control channel. You establish this separate link by configuring a peer interface. The peer interface name must match the Link Management Protocol (LMP) peer name. A peer interface is optional for a hierarchy of RSVP label-switched paths (LSPs). After you configure the forwarding adjacency, you can configure OSPFv2 to advertise the traffic engineering properties of a forwarding adjacency to a specific peer.

Point-to-point interfaces differ from multipoint in that only one OSPF adjacency is possible. (A LAN, for instance, can have multiple addresses and can run OSPF on each subnet simultaneously.) As such, when you configure a numbered point-to-point interface to OSPF by name, multiple OSPF interfaces are created. One, which is unnumbered, is the interface on which the protocol is run. An additional OSPF interface is created for each address configured on the interface, if any, which is automatically marked as passive. For OSPFv3, one OSPF-specific interface must be created per interface name configured under OSPFv3. OSPFv3 does not allow interfaces to be configured by IP address.

540



Enabling OSPF on an interface (by including the interface statement), disabling it (by including the disable statement), and not actually having OSPF run on an interface (by including the passive statement) are mutually exclusive states.

NOTE: When you configure OSPFv2 on an interface, you must also include the family inet statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. When you configure OSPFv3 on an interface, you must also include the family inet6 statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. In Junos OS Release 9.2 and later, you can configure OSPFv3 to support address families other than unicast IPv6.

Example: Configuring an Interface on a Broadcast or Point-to-Point Network This example shows how to configure an OSPF interface on a broadcast or point-to-point network. •


•


•


•




•


•


Overview If the interface on which you are configuring OSPF supports broadcast mode (such as a LAN), or if the interface supports point-to-point mode (such as a PPP interface or a point-to-point logical interface on Frame Relay), you specify the interface by including the IP address or the interface name for OSPFv2, or only the interface name for OSPFv3. In Junos OS Release 9.3 and later, an OSPF point-to-point interface can be an Ethernet interface without a subnet. If you configure an interface on a broadcast network, designated router and backup designated router election is performed.

NOTE: Using both the interface name and the IP address of the same interface produces an invalid configuration.


541


In this example, you configure interface ge-0/2/0 as an OSPFv2 interface in OSPF area 0.0.0.1.


To quickly configure an OSPF interface on a broadcast or point-to-point network, copy the following commands and paste them into the CLI. [edit] set interfaces ge-0/2/0 unit 0 family inet address 10.0.0.1 set protocols ospf area 0.0.0.1 interface ge-0/2/0


To configure an OSPF interface on a broadcast or point-to-point network: 1.

Configure the interface.

NOTE: For an OSPFv3 interface, specify an IPv6 address.

[edit] user@host# set interfaces ge-0/2/0 unit 0 family inet address 10.0.0.1 2.

Create an OSPF area.

NOTE: For an OSPFv3 interface, include the ospf3 statement at the [edit protocols] hierarchy level.

[edit] user@host# edit protocols ospf area 0.0.0.1 3.

Assign the interface to the area. [edit protocols ospf area 0.0.0.1 ] user@host# set interface ge-0/2/0

4.

If you are done configuring the device, commit the configuration. [edit protocols ospf area 0.0.0.1 ] user@host# commit

Results

Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces ge-0/2/0 { unit 0 { family inet { address 10.0.0.1/32; } } }

542



user@host# show protocols ospf area 0.0.0.1 { interface ge-0/2/0.0; }

To confirm your OSPFv3 configuration, enter the show interfaces and the show protocols ospf3 commands.

Verification Confirm that the configuration is working properly. Verifying the OSPF Interface Purpose

Action

Verify the interface configuration. Depending on your deployment, the Type field might display LAN or P2P. From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3.

Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network This example shows how to configure an OSPFv2 interface on a nonbroadcast multiaccess (NBMA) network. •


•


•


•




•

Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” on page 511.

•


Overview When you configure OSPFv2 on an NBMA network, you can use nonbroadcast mode rather than point-to-multipoint mode. Using this mode offers no advantages over point-to-multipoint mode, but it has more disadvantages than point-to-multipoint mode. Nevertheless, you might occasionally find it necessary to configure nonbroadcast mode to interoperate with other equipment. Because there is no autodiscovery mechanism, you must configure each neighbor.


543


Nonbroadcast mode treats the NBMA network as a partially connected LAN, electing designated and backup designated routers. All routing devices must have a direct connection to both the designated and backup designated routers, or unpredictable results occur. When you configure the interface, specify either the IP address or the interface name. Using both the IP address and the interface name produces an invalid configuration. For nonbroadcast interfaces, specify the IP address of the nonbroadcast interface as the interface name. In this example, you configure the Asynchronous Transfer Mode (ATM) interface at-0/1/0 as an OSPFv2 interface in OSPF area 0.0.0.1, and you and specify the following settings: •

interface-type nbma—Sets the interface to run in NBMA mode. You must explicitly

configure the interface to run in NBMA mode. •

neighbor address —Specifies the IP address of the neighboring device. OSPF

routing devices normally discover their neighbors dynamically by listening to the broadcast or multicast hello packets on the network. Because an NBMA network does not support broadcast (or multicast), the device cannot discover its neighbors dynamically, so you must configure all the neighbors statically. To configure multiple neighbors, include multiple neighbor statements. If you want the neighbor to be a designated router, include the eligible keyword. •

poll-interval—Specifies the length of time, in seconds, before the routing device sends

hello packets out of the interface before it establishes adjacency with a neighbor. Routing devices send hello packets for a longer interval on nonbroadcast networks to minimize the bandwidth required on slow WAN links. The range is from 1 through 255 seconds. By default, the device sends hello packets out the interface every 120 seconds before it establishes adjacency with a neighbor. Once the routing device detects an active neighbor, the hello packet interval changes from the time specified in the poll-interval statement to the time specified in the hello-interval statement.


To quickly configure an OSPFv2 interface on an NBMA network, copy the following commands and paste them into the CLI. [edit] set interfaces at-0/1/0 unit 0 family inet address 192.0.2.1 set protocols ospf area 0.0.0.1 interface at-0/1/0.0 interface-type nbma set protocols ospf area 0.0.0.1 interface at-0/1/0.0 neighbor 192.0.2.2 eligible set protocols ospf area 0.0.0.1 interface at-0/1/0.0 poll-interval 130


To configure an OSPFv2 interface on an NBMA network: 1.

Configure the interface. [edit] user@host# set interfaces at-0/1/0 unit 0 family inet address 192.0.2.1

2.

544





Assign the interface to the area. In this example, include the eligible keyword to allow the neighbor to be a designated router. [edit protocols ospf area 0.0.0.1 ] user@host# set interface at-0/1/0 interface-type nbma neighbor 192.0.2.2 eligible

4.

Configure the poll interval. [edit protocols ospf area 0.0.0.1 ] user@host# set interface at-0/1/0 poll-interval 130

5.


Results

Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces at-0/1/0 { unit 0 { family inet { address 192.0.2.1/32; } } } user@host# show protocols ospf area 0.0.0.1 { interface at-0/1/0.0 { interface-type nbma; neighbor 192.0.2.2 eligible; poll-interval 130; } }

Verification Confirm that the configuration is working properly. Verifying the OSPF Interface Purpose Action

Verify the interface configuration. Confirm that the Type field displays NBMA. From operational mode, enter the show ospf interface detail command.


545


Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint Network This example shows how to configure an OSPFv2 interface on a point-to-multipoint network. •


•


•


•




•


•


Overview When you configure OSPFv2 on a nonbroadcast multiaccess (NBMA) network, such as a multipoint Asynchronous Transfer Mode (ATM) or Frame Relay, OSPFv2 operates by default in point-to-multipoint mode. In this mode, OSPFv2 treats the network as a set of point-to-point links. Because there is no autodiscovery mechanism, you must configure each neighbor. When you configure the interface, specify either the IP address or the interface name. Using both the IP address and the interface name produces an invalid configuration. In this example, you configure ATM interface at-0/1/0 as an OSPFv2 interface in OSPF area 0.0.0.1, and you and specify 192.0.2.1 as the neighbor’s IP address.


To quickly configure an OSPFv2 interface on a point-to-multipoint network, copy the following commands and paste them into the CLI. [edit] set interfaces at-0/1/0 unit 0 family inet address 192.0.2.2 set protocols ospf area 0.0.0.1 interface at-0/1/0 neighbor 192.0.2.1


To configure an OSPFv2 interface on a point-to-multipoint network: 1.

Configure the interface. [edit] user@host# set interfaces at-0/1/0 unit 0 family inet address 192.0.2.2

2.

546





Assign the interface to the area and specify the neighbor. [edit protocols ospf area 0.0.0.1] user@host# set interface at-0/1/0 neighbor 192.0.2.1

To configure multiple neighbors, include a neighbor statement for each neighbor. 4.

If you are done configuring the device, commit the configuration. [edit protocols ospf area 0.0.0.1] user@host# commit

Results

Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces at-0/1/0 { unit 0 { family inet { address 192.0.2.2/32; } } } user@host# show protocols ospf area 0.0.0.1 { interface at-0/1/0.0 { neighbor 192.0.2.1; } }

Verification Confirm that the configuration is working properly. Verifying the OSPF Interface Purpose Action

Verify the interface configuration. Confirm that the Type field displays P2MP. From operational mode, enter the show ospf interface detail command.

Example: Configuring OSPF Demand Circuits This example shows how to configure an OSPF demand circuit interface. •


•


•


•



547




NOTE: If you are using OSPF demand circuits over an ISDN link, you must configure an ISDN interface and enable dial-on-demand routing. See the Junos OS Network Interfaces Configuration Guide.

•


•


•


Overview OSPF sends periodic hello packets to establish and maintain neighbor adjacencies and uses link-state advertisements (LSAs) to make routing calculations and decisions. OSPF support for demand circuits is defined in RFC 1793, Extending OSPF to Support Demand Circuits, and suppresses the periodic hello packets and LSAs. A demand circuit is a connection on which you can limit traffic based on user agreements. The demand circuit can limit bandwidth or access time based on agreements between the provider and user. You configure demand circuits on an OSPF interface. When the interface becomes a demand circuit, all hello packets and LSAs are suppressed as soon as OSPF synchronization is achieved. LSAs have a DoNotAge bit that stops the LSA from aging and prevents periodic updates from being sent. Hello packets and LSAs are sent and received on a demand-circuit interface only when there is a change in the network topology. This reduces the amount of traffic through the OSPF interface. Consider the following when configuring OSPF demand circuits: •

Periodic hellos are only suppressed on point-to-point and point-to-multipoint interfaces. If you configure demand circuits on an OSPF broadcast network or on an OSPF nonbroadcast multiaccess (NBMA) network, periodic hello packets are still sent.

•

Demand circuit support on an OSPF point-to-multipoint interface resembles that for point-to-point interfaces. If you configure a point-to-multipoint interface as a demand circuit, the device negotiates hello suppression separately on each interface that is part of the point-to-multipoint network.

This example assumes that you have a point-to-point connection between two devices using SONET/SDH interfaces. A demand-circuit interface automatically negotiates the demand-circuit connection with its OSPF neighbor. If the neighbor does not support demand circuits, then no demand circuit connection is established.

548



In this example, you configure OSPF interface so-0/1/0 in OSPF area 0.0.0.1 as a demand circuit.


To quickly configure an OSPF demand circuit interface, copy the following command and paste it into the CLI. You must configure both neighboring interfaces for OSPF demand circuits for the connection to be established. [edit] set protocols ospf area 0.0.0.1 interface so-0/1/0 demand-circuit


To configure an OSPF demand circuit interface on one neighboring interface: 1.



[edit ] user@host# edit protocols ospf area 0.0.0.1 2.

Configure the neighboring interface as a demand circuit. [edit protocols ospf area 0.0.0.1] user@host# set interface so-0/1/0 demand-circuit

3.


NOTE: Repeat this entire configuration on the other neighboring interface.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf { area 0.0.0.1 { interface so-0/1/0.0 { demand-circuit; } } }



549


Verification Confirm that the configuration is working properly. Verifying the Status of Neighboring Interfaces Purpose

Action

Verify information about the neighboring interface. When the neighbor is configured for demand circuits, a DC flag displays. From operational mode, enter the show ospf neighbor detail command for OSPFv2, and enter the show ospf3 neighbor detail command for OSPFv3.

Example: Configuring a Passive OSPF Interface This example shows how to configure a passive OSPF interface. A passive OSPF interface advertises its address but does not run the OSPF protocol. •


•


•


•




•


•


•


Overview By default, OSPF must be configured on an interface for direct interface addresses to be advertised as interior routes. To advertise the direct interface addresses without actually running OSPF on that interface (adjacencies are not formed and hello packets are not generated), you configure that interface as a passive interface. Enabling OSPF on an interface (by including the interface statement), disabling it (by including the disable statement), and not actually having OSPF run on an interface (by including the passive statement) are mutually exclusive states.

550



NOTE: If you do not want to see notifications for state changes in a passive OSPF interface, you can disable the OSPF traps for the interface by including the no-interface-state-traps statement. The no-interface-state-traps statement is supported only for OSPFv2.

In this example, you configure interface ge-0/2/0 as a passive OSPF interface in area 0.0.0.1 by including the passive statement.


To quickly configure a passive OSPF interface, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.1 interface ge-0/2/0 passive


To configure a passive OSPF interface: 1.


NOTE: For an OSPFv3 interface, include the ospf3 statement at the [edit protocols] hierarchy level.


Configure the passive interface. [edit protocols ospf area 0.0.0.1 ] user@host# set interface ge-0/2/0 passive

3.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.1 { interface ge-0/2/0.0 { passive; } }



551


Verification Confirm that the configuration is working properly. Verifying the Status of OSPF Interfaces Purpose

Verify the status of the OSPF interface. If the interface is passive, the Adj count field is 0 because no adjacencies have been formed. Next to this field, you might also see the word Passive.

Action


Example: Configuring OSPFv2 Peer interfaces This example shows how to configure an OSPFv2 peer interface. •


•


•


•




•


•


•


•

Configure Generalized MPLS per your network requirements. See LMP Configuration Overview in the Junos OS MPLS Applications Configuration Guide.

Overview You can configure an OSPFv2 peer interface for many reasons, including when you configure Generalized MPLS (GMPLS). This example configures a peer interface for GMPLS. GMPLS requires traffic engineering information to be transported through a link separate from the control channel. You establish this separate link by configuring a peer interface. The OSPFv2 peer interface name must match the Link Management Protocol (LMP) peer name. You configure GMPLS and the LMP settings separately from OSPF. This example assumes that GMPLS and the LMP peer named oxc1 are already configured, and you need to configure the OSPFv2 peer interface in area 0.0.0.0.

552




To quickly configure an OSPFv2 peer interface, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.0 peer-interface oxc1


To configure a peer OSPFv2 interface used by the LMP: 1.

Create an OSPF area. [edit] user@host# edit protocols ospf area 0.0.0.0

2.

Configure the peer interface. [edit protocols ospf area 0.0.0.0] user@host# set peer-interface oxc1

3.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.0 { peer-interface oxc1; }

Verification Confirm that the configuration is working properly. Verifying the Configured OSPFv2 Peer Purpose

Action


Verify the status of the OSPFv2 peer. When an OSPFv2 peer is configured for GMPLS, the Peer Name field displays the name of the LMP peer that you created for GMPLS, which is also the configured OSPFv2 peer. From operational mode, enter the show link-management command.

•


•



553


Example: Configuring Multiple Address Families for OSPFv3 •

Understanding Multiple Address Families for OSPFv3 on page 554

•


Understanding Multiple Address Families for OSPFv3 By default, OSPFv3 supports only unicast IPv6 routes. In Junos OS Release 9.2 and later, you can configure OSPFv3 to support multiple address families, including IPv4 unicast, IPv4 multicast, and IPv6 multicast. This mutliple address family support allows OSPFv3 to support both IPv6 and IPv4 nodes. Junos OS maps each address family to a separate realm as defined in Internet draft draft-ietf-ospf-af-alt-06.txt, Support for Address Families in OSPFv3. Each realm maintains a separate set of neighbors and link-state database. When you configure multiple address families for OSPFv3, there is a new instance ID field that allows multiple OSPFv3 protocol instances per link. This allows a single link to belong to multiple areas. You configure each realm independently. We recommend that you configure an area and at least one interface for each realm. These are the default import and export routing tables for each of the four address families: •

IPv6 unicast: inet6.0

•

IPv6 multicast: inet6.2

•

IPv4 unicast: inet.0

•

IPv4 multicast: inet.2

With the exception of virtual links, all configurations supported for the default IPv6 unicast family are supported for the address families that have to be configured as realms.

Example: Configuring Multiple Address Families for OSPFv3 This example shows how to configure multiple address families for OSPFv3. •


•


•


•



554




•


•


Overview By default, OSPFv3 supports unicast IPv6 routes, but you can configure OSPFv3 to support multiple address families. To support an address family other than unicast IPv6, you configure a realm that allows OSPFv3 to advertise IPv4 unicast, IPv4 multicast, or IPv6 multicast routes. Junos OS then maps each address family that you configure to a separate realm with its own set of neighbors and link-state database.

NOTE: By default, LDP synchronization is only supported for OSPFv2. If you configure an IPv4 unicast or IPv4 multicast realm, you can also configure LDP synchronization. Since LDP synchronization is only supported for IPv4, this support is only available for OSPFv3 if you configure an IPv4 realm.

When configuring OSPFv3 to support multiple address families, consider the following: •

You configure each realm independently. We recommend that you configure an area and at least one interface for each realm.

•

OSPFv3 uses IPv6 link-local addresses as the source of hello packets and next hop calculations. As such, you must enable IPv6 on the link regardless of the additional realm you configure.

Figure 23 on page 556 shows a connection between Routers R0 and R1. In this example, you configure interface fe-0/1/0 on Router R0 in area 0 to advertise IPv4 unicast routes, in addition to the default unicast IPv6 routes in area 1, by including the realm ipv4-unicast statement. Depending on your network requirements, you can also advertise IPv4 multicast routes by including the realm-ipv4-multicast statement, and you can advertise IPv6 multicast routes by including the realm-ipv6-multicast statement.


555


Figure 23: IPv4 Unicast Realm

Area 1

R1

IPv4 Unicast Realm fe-0/1/0

R2

Area 2

R3

R0

g040877

Area 0


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To quickly configure multiple address families for OSPFv3, copy the following commands and paste them into the CLI. [edit] set interfaces fe-0/1/0 unit 0 family inet address 11.1.2.1/24 set interfaces fe-0/1/0 unit 0 family inet6 set protocols ospf3 area 0.0.0.0 interface fe-0/1/0 set protocols ospf3 realm ipv4-unicast area 0.0.0.0 interface fe-0/1/0


To configure multiple address families for OSPFv3: 1.

Configure the device interface participating in OSPFv3. [edit] user@host# set interfaces fe-0/1/0 unit 0 family inet address 11.1.2.1/24 user@host# set interfaces fe-0/1/0 unit 0 family inet6

2.

Enter OSPFv3 configuration mode. [edit ] user@host# edit protocols ospf3

3.

Add the interface you configured to the OSPFv3 area. [edit protocols ospf3 ] user@host# set area 0.0.0.0 interface fe-0/1/0

4.

Configure an IPv4 unicast realm. This allows OSPFv3 to support both IPv4 unicast and IPv6 unicast routes. [edit protocols ospf3 ] user@host# set realm ipv4-unicast area 0.0.0.0 interface fe-0/1/0

556



5.

If you are done configuring the device, commit the configuration. [edit protocols ospf3 ] user@host# commit

NOTE: Repeat this entire configuration on the neighboring device that is part of the realm.

Results

Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces fe-0/1/0 { unit 0 { family inet { address 11.1.2.1/24; } family inet6; } } user@host# show protocols ospf3 realm ipv4-unicast { area 0.0.0.0 { interface fe-0/1/0.0; } } area 0.0.0.0 { interface fe-0/1/0.0; }


Verifying the Link-State Database on page 557

•

Verifying the Status of OSPFv3 Interfaces with Multiple Address Families on page 557

Verifying the Link-State Database Purpose

Verify the status of the link-state database for the configured realm, or address family.

Action

From operational mode, enter the show ospf3 database realm ipv4-unicast command. Verifying the Status of OSPFv3 Interfaces with Multiple Address Families

Purpose Action

Verify the status of the interface for the specified OSPFv3 realm, or address family. From operational mode, enter the show ospf3 interface realm ipv4-unicast command.


557



•


•


Examples: Configuring OSPF Route Summarization •

Understanding OSPF Route Summarization on page 558

•

Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements on page 558

•

Example: Limiting the Number of Prefixes Exported to OSPF on page 563

•

Configuring OSPF Refresh and Flooding Reduction in Stable Topologies on page 565

Understanding OSPF Route Summarization Area border routers (ABRs) send summary link advertisements to describe the routes to other areas. Depending on the number of destinations, an area can get flooded with a large number of link-state records, which can utilize routing device resources. To minimize the number of advertisements that are flooded into an area, you can configure the ABR to coalesce, or summarize, a range of IP addresses and send reachability information about these addresses in a single link-state advertisement (LSA). You can summarize one or more ranges of IP addresses, where all routes that match the specified area range are filtered at the area boundary, and the summary is advertised in their place. For an OSPF area, you can summarize and filter intra-area prefixes. All routes that match the specified area range are filtered at the area boundary, and the summary is advertised in their place. For an OSPF not-so-stubby area (NSSA), you can only coalesce or filter NSSA external (Type 7) LSAs before they are translated into AS external (Type 5) LSAs and enter the backbone area. All external routes learned within the area that do not fall into the range of one of the prefixes are advertised individually to other areas. In addition, you can also limit the number of prefixes (routes) that are exported into OSPF. By setting a user-defined maximum number of prefixes, you prevent the routing device from flooding an excessive number of routes into an area.

Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements This example shows how to summarize routes sent into the backbone area. •


•


•


•



558




•


•

Configure a static route. See “Examples: Configuring Static Routes” on page 93 in the Junos OS Routing Protocols Configuration Guide.

Overview You can summarize a range of IP addresses to minimize the size of the backbone router’s link-state database. All routes that match the specified area range are filtered at the area boundary, and the summary is advertised in their place. Figure 24 on page 559 shows the topology used in this example. R5 is the ABR between area 0.0.0.4 and the backbone. The networks in area 0.0.0.4 are 10.0.8.4/30, 10.0.8.0/30, and 10.0.8.8/30, which can be summarized as 10.0.8.0/23. R3 is the ABR between NSSA area 0.0.0.3 and the backbone. The networks in area 0.0.0.3 are 10.0.4.4/30, 10.0.4.0/30, and 10.0.4.12/30, which can be summarized as 10.0.4.0/22. Area 0.0.0.3 also contains external static route 3.0.0.0.8 that you will prevent from flooding throughout the network.

Figure 24: Summarizing Ranges of Routes in OSPF Backbone Area 0.0.0.0

R4

Static Route 3.0.0.8 10.0.2.4/30

10.0.2.8/30

NSSA

Stub

R3

10.0.2.0/30

R5

10.0.4.12/30 10.0.4.0/30 10.0.4.4/30

10.0.8.0/30

R2

Area 0.0.0.3

R6

10.0.8.8/30

R7

Area 0.0.0.4

g040889

R1

10.0.8.4/30

In this example, you configure the ABRs for route summarization by including the following settings: •

area-range—For an area, summarizes a range of IP addresses when sending summary

intra-area link advertisements. For an NSSA, summarizes a range of IP addresses when sending NSSA link-state advertisements (Type 7 LSAs). The specified prefixes are used to aggregate external routes learned within the area when the routes are advertised to other areas.


559


•

network/mask-length—Indicates the summarized IP address range and the number of

significant bits in the network mask. •

restrict—On the NSSA ABR, prevents the configured summary from being advertised.

In this example, we do not want to flood the external route outside of area 0.0.0.3.


•

To quickly configure route summarization for an OSPF area, copy the following commands and paste them into the CLI. The following is the configuration on ABR R5: [edit] set interfaces fe-0/0/1 unit 0 family inet address 10.0.8.3 set interfaces fe-0/0/2 unit 0 family inet address 10.0.8.4 set interfaces fe-0/0/0 unit 0 family inet address 10.0.2.3 set interfaces fe-0/0/4 unit 0 family inet address 10.0.2.5 set protocols ospf area 0.0.0.4 stub set protocols ospf area 0.0.0.4 interface fe-0/0/1 set protocols ospf area 0.0.0.4 interface fe-0/0/2 set protocols ospf area 0.0.0.0 interface fe-0/0/0 set protocols ospf area 0.0.0.0 interface fe-0/0/4 set protocols ospf area 0.0.0.4 area-range 10.0.8.0/23

•

To quickly configure route summarization for an OSPF NSSA, copy the following commands and paste them into the CLI. The following is the configuration on ABR R3: [edit] set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.10 set interfaces fe-0/0/2 unit 0 family inet address 10.0.4.1 set interfaces fe-0/0/0 unit 0 family inet address 10.0.2.1 set interfaces fe-0/0/4 unit 0 family inet address 10.0.2.7 set protocols ospf area 0.0.0.3 interface fe-0/0/1 set protocols ospf area 0.0.0.3 interface fe-0/0/2 set protocols ospf area 0.0.0.0 interface fe-0/0/0 set protocols ospf area 0.0.0.0 interface fe-0/0/4 set protocols ospf area 0.0.0.3 area-range 10.0.4.0/22 set protocols ospf area 0.0.0.3 nssa set protocols ospf area 0.0.0.3 nssa area-range 3.0.0.0/8 restrict


To summarize routes sent to the backbone area: 1.

Configure the interfaces.

NOTE: For OSPFv3, include IPv6 addresses.

[edit] user@R5# set interfaces fe-0/0/1 unit 0 family inet address 10.0.8.3 user@R5# set interfaces fe-0/0/2 unit 0 family inet address 10.0.8.4 user@R5# set interfaces fe-0/0/0 unit 0 family inet address 10.0.2.3 user@R5# set interfaces fe-0/0/4 unit 0 family inet address 10.0.2.5 [edit] user@R3# set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.10

560



user@R3# set interfaces fe-0/0/2 unit 0 family inet address 10.0.4.1 user@R3# set interfaces fe-0/0/0 unit 0 family inet address 10.0.2.1 user@R3# set interfaces fe-0/0/4 unit 0 family inet address 10.0.2.7 2.

Configure the type of OSPF area.


[edit] user@R5# set protocols ospf area 0.0.0.4 stub [edit] user@R3# set protocols ospf area 0.0.0.3 nssa 3.

Assign the interfaces to the OSPF areas. user@R5# set protocols ospf area 0.0.0.4 interface fe-0/0/1 user@R5# set protocols ospf area 0.0.0.4 interface fe-0/0/2 user@R5# set protocols ospf area 0.0.0.0 interface fe-0/0/0 user@R5# set protocols ospf area 0.0.0.0 interface fe-0/0/4 user@R3# set protocols ospf area 0.0.0.3 interface fe-0/0/1 user@R3# set protocols ospf area 0.0.0.3 interface fe-0/0/2 user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/0 user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/4

4.

Summarize the routes that are flooded into the backbone. [edit] user@R5# set protocols ospf area 0.0.0.4 area-range 10.0.8.0/23 [edit] user@R3# set protocols ospf area 0.0.0.3 area-range 10.0.4.0/22

5.

On ABR R3, restrict the external static route from leaving area 0.0.0.3. [edit] user@R3# set protocols ospf area 0.0.0.3 nssa area-range 3.0.0.0/8 restrict

6.


Results

Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on ABR R5: user@R5# show interfaces fe-0/0/0 { unit 0 { family inet { address 10.0.2.3/32; }


561


} } fe-0/0/1 { unit 0 { family inet { address 10.0.8.3/32; } } } fe-0/0/2 { unit 0 { family inet { address 10.0.8.4/32; } } } fe-0/0/4 { unit 0 { family inet { address 10.0.2.5/32; } } } user@R5# show protocols ospf area 0.0.0.0 { interface fe-0/0/0.0; interface fe-0/0/4.0; } area 0.0.0.4 { stub; area-range 10.0.8.0/23; interface fe-0/0/1.0; interface fe-0/0/2.0; }

Configuration on ABR R3: user@R3# show interfaces fe-0/0/0 { unit 0 { family inet { address 10.0.2.1/32; } } } fe-0/0/1 { unit 0 { family inet { address 10.0.4.10/32; } } } fe-0/0/2 { unit 0 { family inet { address 10.0.4.1/32;

562



} } } fe-0/0/4 { unit 0 { family inet { address 10.0.2.7/32; } } } user@R3t# show protocols ospf area 0.0.0.0 { interface fe-0/0/0.0; interface fe-0/0/4.0; } area 0.0.0.3 { nssa { area-range 3.0.0.0/8 restrict; } area-range 10.0.4.0/22; interface fe-0/0/1.0; interface fe-0/0/2.0; }

To confirm your OSPFv3 configuration, enter the show interfaces and show protocols ospf3 commands.

Verification Confirm that the configuration is working properly. Verifying the Summarized Route Purpose

Action

Verify that the routes you configured for route summarization are being aggregated by the ABRs before the routes enter the backbone area. Confirm route summarization by checking the entries of the OSPF link-state database for the routing devices in the backbone. From operational mode, enter the show ospf database command for OSPFv2, and enter the show ospf3 database command for OSPFv3.

Example: Limiting the Number of Prefixes Exported to OSPF This example shows how to limit the number of prefixes exported to OSPF. •


•


•


•



563




•


•


•


•


Overview By default, there is no limit to the number of prefixes (routes) that can be exported into OSPF. By allowing any number of routes to be exported into OSPF, the routing device can become overwhelmed and potentially flood an excessive number of routes into an area. You can limit the number of routes exported into OSPF to minimize the load on the routing device and prevent this potential problem. If the routing device exceeds the configured prefix export value, the routing device purges the external prefixes and enters into an overload state. This state ensures that the routing device is not overwhelmed as it attempts to process routing information. The prefix export limit number can be a value from 0 through 4,294,967,295. In this example, you configure a prefix export limit of 100,000 by including the prefix-export-limit statement.


To quickly limit the number of prefixes exported to OSPF, copy the following command and paste it into the CLI. [edit] set protocols ospf prefix-export-limit 100000


To limit the number of prefixes exported to OSPF: 1.

Configure the prefix export limit value.


[edit] user@host# set protocols ospf prefix-export-limit 100000

564



2.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf prefix-export-limit 100000;


Verification Confirm that the configuration is working properly. Verifying the Prefix Export Limit Purpose Action

Verify the prefix export counter that displays the number or routes exported into OSPF. From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview command for OSPFv3.

Configuring OSPF Refresh and Flooding Reduction in Stable Topologies The OSPF standard requires that every link-state advertisement (LSA) be refreshed every 30 minutes. The Juniper implementation refreshes LSAs every 50 minutes. By default, any LSA that is not refreshed expires after 60 minutes. This requirement can result in traffic overhead that makes it difficult to scale OSPF networks. You can override the default behavior by specifying that the DoNotAge bit be set in self-originated LSAs when they are initially sent by the router or switch. Any LSA with the DoNotAge bit set is reflooded only when a change occurs in the LSA. This feature thus reduces protocol traffic overhead while permitting any changed LSAs to be flooded immediately. Routers or switches enabled for flood reduction continue to send hello packets to their neighbors and to age self-originated LSAs in their databases. The Juniper implementation of OSPF refresh and flooding reduction is based on RFC 4136, OSPF Refresh and Flooding Reduction in Stable Topologies. However, the Juniper implementation does not include the forced-flooding interval defined in the RFC. Not implementing the forced-flooding interval ensures that LSAs with the DoNotAge bit set are reflooded only when a change occurs. This feature is supported for the following: •

OSPFv2 and OSPFv3 interfaces

•

OSPFv3 realms

•

OSPFv2 and OSPFv3 virtual links

•

OSPFv2 sham links


565


•

OSPFv2 peer interfaces

•

All routing instances supported by OSPF

•

Logical systems

To configure flooding reduction for an OSPF interface, include the flood-reduction statement at the [edit protocols (ospf | ospf3) area area-id interface interface-id] hierarchy level.

NOTE: If you configure flooding reduction for an interface configured as a demand circuit, the LSAs are not initially flooded, but sent only when their content has changed. Hello packets and LSAs are sent and received on a demand-circuit interface only when a change occurs in the network topology.

In the following example, the OSPF interface so-0/0/1.0 is configured for flooding reduction. As a result, all the LSAs generated by the routes that traverse the specified interface have the DoNotAge bit set when they are initially flooded, and LSAs are refreshed only when a change occurs. [edit] protocols ospf { area 0.0.0.0 { interface so-0/0/1.0 { flood-reduction; } interface lo0.0; interface so-0/0/0.0; } }


•


•


Examples: Configuring OSPF Traffic Control •

Understanding OSPF Traffic Control on page 566

•

Example: Controlling the Cost of Individual OSPF Network Segments on page 568

•

Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth on page 572

•

Example: Controlling OSPF Route Preferences on page 574

Understanding OSPF Traffic Control Once a topology is shared across the network, OSPF uses the topology to route packets between network nodes. Each path between neighbors is assigned a cost based on the throughput, round-trip time, and reliability of the link. The sum of the costs across a particular path between hosts determines the overall cost of the path. Packets are then routed along the shortest path using the shortest-path-first (SPF) algorithm. If multiple equal-cost paths exist between a source and destination address, OSPF routes packets

566



along each path alternately, in round-robin fashion. Routes with lower total path metrics are preferred over those with higher path metrics. You can use the following methods to control OSPF traffic: •

Control the cost of individual OSPF network segments

•

Dynamically adjust OSPF interface metrics based on bandwidth

•

Control OSPF route selection

Controlling the Cost of Individual OSPF Network Segments OSPF uses the following formula to determine the cost of a route: cost = reference-bandwidth / interface bandwidth

You can modify the reference-bandwidth value, which is used to calculate the default interface cost. The interface bandwidth value is not user-configurable and refers to the actual bandwidth of the physical interface. By default, OSPF assigns a default cost metric of 1 to any link faster than 100 Mbps, and a default cost metric of 0 to the loopback interface (lo0). No bandwidth is associated with the loopback interface. To control the flow of packets across the network, OSPF allows you to manually assign a cost (or metric) to a particular path segment. When you specify a metric for a specific OSPF interface, that value is used to determine the cost of routes advertised from that interface. For example, if all routers in the OSPF network use default metric values, and you increase the metric on one interface to 5, all paths through that interface have a calculated metric higher than the default and are not preferred.

NOTE: Any value you configure for the metric overrides the default behavior of using the reference-bandwidth value to calculate the route cost for that interface.

Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth You can specify a set of bandwidth threshold values and associated metric values for an OSPF interface or for a topology on an OSPF interface. When the bandwidth of an interface changes, the Junos OS automatically sets the interface metric to the value associated with the appropriate bandwidth threshold value. Junos OS uses the smallest configured bandwidth threshold value that is equal to or greater than the actual interface bandwidth to determine the metric value. If the interface bandwidth is greater than any of the configured bandwidth threshold values, the metric value configured for the interface is used instead of any of the bandwidth-based metric values configured. The ability to recalculate the metric for an interface when its bandwidth changes is especially useful for aggregate interfaces.


567


NOTE: You must also configure a metric for the interface when you enable bandwidth-based metrics.

Controlling OSPF Route Preferences You can control the flow of packets through the network using route preferences. Route preferences are used to select which route is installed in the forwarding table when several protocols calculate routes to the same destination. The route with the lowest preference value is selected. By default, internal OSPF routes have a preference value of 10, and external OSPF routes have a preference value of 150. Although the default settings are appropriate for most environments, you might want to modify the default settings if all of the routing devices in your OSPF network use the default preference values, or if you are planning to migrate from OSPF to a different interior gateway protocol (IGP). If all of the devices use the default route preference values, you can change the route preferences to ensure that the path through a particular device is selected for the forwarding table any time multiple equal-cost paths to a destination exist. When migrating from OSPF to a different IGP, modifying the route preferences allows you to perform the migration in a controlled manner.

Example: Controlling the Cost of Individual OSPF Network Segments This example shows how to control the cost of individual OSPF network segments. •


•


•


•




•


•


•


Overview All OSPF interfaces have a cost, which is a routing metric that is used in the link-state calculation. Routes with lower total path metrics are preferred to those with higher path metrics. In this example, we explore how to control the cost of OSPF network segments.

568



By default, OSPF assigns a default cost metric of 1 to any link faster than 100 Mbps, and a default cost metric of 0 to the loopback interface (lo0). No bandwidth is associated with the loopback interface. This means that all interfaces faster than 100 Mbps have the same default cost metric of 1. If multiple equal-cost paths exist between a source and destination address, OSPF routes packets along each path alternately, in round-robin fashion. Having the same default metric might not be a problem if all of the interfaces are running at the same speed. If the interfaces operate at different speeds, you might notice that traffic is not routed over the fastest interface because OSPF equally routes packets across the different interfaces. For example, if your routing device has Fast Ethernet and Gigabit Ethernet interfaces running OSPF, each of these interfaces have a default cost metric of 1. In the first example, you set the reference bandwidth to 10g (10 Gbps, as denoted by 10,000,000,000 bits) by including the reference-bandwidth statement. With this configuration, OSPF assigns the Fast Ethernet interface a default metric of 100, and the Gigabit Ethernet interface a metric of 10. Since the Gigabit Ethernet interface has the lowest metric, OSPF selects it when routing packets. The range is 9600 through 1,000,000,000,000 bits. Figure 25 on page 569 shows three routing devices in area 0.0.0.0 and assumes that the link between Device R2 and Device R3 is congested with other traffic. You can also control the flow of packets across the network by manually assigning a metric to a particular path segment. Any value you configure for the metric overrides the default behavior of using the reference-bandwidth value to calculate the route cost for that interface. To prevent the traffic from Device R3 going directly to Device R2, you adjust the metric on the interface on Device R3 that connects with Device R1 so that all traffic goes through Device R1. In the second example, you set the metric to 5 on interface fe-1/0/1 on Device R3 that connects with Device R1 by including the metric statement. The range is 1 through 65,535.

Figure 25: OSPF Metric Configuration

R1

fe-0/0/1

fe-0/0/1

R2

fe-1/0/0

fe-1/0/1

Congested link

fe-1/0/1 fe-1/0/0

Area 0.0.0.0 g040888

R3


569


Configuration •

Configuring the Reference Bandwidth on page 570

•

Configuring a Metric for a Specific OSPF Interface on page 571

Configuring the Reference Bandwidth CLI Quick Configuration

To quickly configure the reference bandwidth, copy the following command and paste it into the CLI. [edit] set protocols ospf reference-bandwidth 10g


To configure the reference bandwidth: 1.

Configure the reference bandwidth to calculate the default interface cost.


[edit] user@host# set protocols ospf reference-bandwidth 10g

TIP: As a shortcut in this example, you enter 10g to specify 10 Gbps reference bandwidth. Whether you enter 10g or 10000000000, the output of show protocols ospf command displays 10 Gbps as 10g, not 10000000000.

2.


NOTE: Repeat this entire configuration on all routing devices in a shared network.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf reference-bandwidth 10g;


570



Configuring a Metric for a Specific OSPF Interface CLI Quick Configuration

To quickly configure a metric for a specific OSPF interface, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.0 interface fe-1/0/1 metric 5


To configure the metric for a specific OSPF interface: 1.




Configure the metric of the OSPF network segment. [edit protocols ospf area 0.0.0.0 ] user@host# set interface fe-1/0/1 metric 5

3.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.0 { interface fe-1/0/1.0 { metric 5; } }



Verifying the Configured Metric on page 571

•

Verifying the Route on page 572

Verifying the Configured Metric Purpose

Verify the metric setting on the interface. Confirm that the Cost field displays the interface’s configured metric (cost). When choosing paths to a destination, OSPF uses the path with the lowest cost.


571


Action

From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3. Verifying the Route

Purpose

Action

When choosing paths to a destination, OSPF uses the path with the lowest total cost. Confirm that OSPF is using the appropriate path. From operational mode, enter the show route command.

Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth This example shows how to dynamically adjust OSPF interface metrics based on bandwidth. •


•


•


•




•


•


•


Overview You can specify a set of bandwidth threshold values and associated metric values for an OSPF interface. When the bandwidth of an interface changes, the Junos OS automatically sets the interface metric to the value associated with the appropriate bandwidth threshold value. When you configure bandwidth-based metric values, you typically configure multiple bandwidth and metric values. In this example, you configure OSPF interface ae0 for bandwidth-based metrics by including the bandwidth-based-metrics statement and the following settings: •

bandwidth—Specifies the bandwidth threshold in bits per second. The range is 9600

through 1,000,000,000,000,000. •

metric—Specifies the metric value to associate with a specific bandwidth value. The

range is 1 through 65,535.

572




To quickly configure bandwidth threshold values and associated metric values for an OSPF interface, copy the following commands, remove any line breaks, and then paste the commands into the CLI. [edit] set protocols ospf area 0.0.0.0 interface ae0.0 metric 5 set protocols ospf area 0.0.0.0 interface ae0.0 bandwidth-based-metrics bandwidth 1g metric 60 set protocols ospf area 0.0.0.0 interface ae0.0 bandwidth-based-metrics bandwidth 10g metric 50

To configure the metric for a specific OSPF interface: 1.



[edit] user@host# edit protocols ospf area 0.0.0.0 2. Configure the metric of the OSPF network segment.

[edit protocols ospf area 0.0.0.0 ] user@host# set interface ae0 metric 5 3. Configure the bandwidth threshold values and associated metric values.

[edit protocols ospf area 0.0.0.0 ] user@host# set interface ae0.0 bandwidth-based-metrics bandwidth 1g metric 60 user@host# set interface ae0.0 bandwidth-based-metrics bandwidth 10g metric 50 4. If you are done configuring the device, commit the configuration.

[edit protocols ospf area 0.0.0.0 ] user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.0 { interface ae0.0 { bandwidth-based-metrics { bandwidth 1g metric 60; bandwidth 10g metric 50; } metric 5; } }



573


Verification Confirm that the configuration is working properly. Verifying the Configured Metric Purpose

Action

Verify the metric setting on the interface. Confirm that the Cost field displays the interface’s configured metric (cost). When choosing paths to a destination, OSPF uses the path with the lowest cost. From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3.

Example: Controlling OSPF Route Preferences This example shows how to control OSPF route selection in the forwarding table. This example also shows how you might control route selection if you are migrating from OSPF to another IGP. •


•


•


•


Requirements This example assumes that OSPF is properly configured and running in your network, and you want to control route selection because you are planning to migrate from OSPF to a different IGP. •


•

Configure the IGP that you want to migrate to. See the Junos OS Routing Protocols Configuration Guide.

Overview Route preferences are used to select which route is installed in the forwarding table when several protocols calculate routes to the same destination. The route with the lowest preference value is selected. By default, internal OSPF routes have a preference value of 10, and external OSPF routes have a preference value of 150. You might want to modify this setting if you are planning to migrate from OSPF to a different IGP. Modifying the route preferences enables you to perform the migration in a controlled manner. This example makes the following assumptions:

574

•

OSPF is already running in your network.

•

You want to migrate from OSPF to IS-IS.



•

You configured IS-IS per your network requirements and confirmed it is working properly.

In this example, you increase the OSPF route preference values to make them less preferred than IS-IS routes by specifying 168 for internal OSPF routes and 169 for external OSPF routes. IS-IS internal routes have a preference of either 15 (for Level1) or 18 (for Level 2), and external routes have a preference of 160 (for Level 1) or 165 (for Level 2). In general, it is preferred to leave the new protocol at its default settings to minimize complexities and simplify any future addition of routing devices to the network. To modify the OSPF route preference values, configure the following settings: •

preference—Specifies the route preference for internal OSPF routes. By default, internal 32

OSPF routes have a value of 10. The range is from 0 through 4,294967,295 (2 •

– 1).

external-preference—Specifies the route preference for external OSPF routes. By default,

external OSPF routes have a value of 150. The range is from 0 through 4,294967,295 32 (2 – 1).


To quickly configure the OSPF route preference values, copy the following command and paste it into the CLI. [edit] set protocols ospf preference 168 external-preference 169

To configure route selection: 1.

Enter OSPF configuration mode and set the external and internal routing preferences.


[edit] user@host# set protocols ospf preference 168 external-preference 169 2. If you are done configuring the device, commit the configuration.

[edit] user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf preference 168; external-preference 169;



575



Verifying the Route on page 576

Verifying the Route Purpose

Action


Verify that the IGP is using the appropriate route. After the new IGP becomes the preferred protocol (in this example, IS-IS), you should monitor the network for any issues. After you confirm that the new IGP is working properly, you can remove the OSPF configuration from the routing device by entering the delete ospf command at the [edit protocols] hierarchy level. From operational mode, enter the show route command.

•


•


Example: Configuring OSPF Overload Mode •

OSPF Overload Function Overview on page 576

•

Example: Configuring OSPF to Make Routing Devices Appear Overloaded on page 577

OSPF Overload Function Overview If the time elapsed after the OSPF instance is enabled is less than the specified timeout, overload mode is set. You can configure the local routing device so that it appears to be overloaded. An overloaded routing device determines it is unable to handle any more OSPF transit traffic, which results in sending OSPF transit traffic to other routing devices. OSPF traffic to directly attached interfaces continues to reach the routing device. You might configure overload mode for many reasons, including: •

If you want the routing device to participate in OSPF routing, but do not want it to be used for transit traffic. This could include a routing device that is connected to the network for analysis purposes, but is not considered part of the production network, such as network management routing devices.

•

If you are performing maintenance on a routing device in a production network. You can move traffic off that routing device so network services are not interrupted during your maintenance window.

You configure or disable overload mode in OSPF with or without a timeout. Without a timeout, overload mode is set until it is explicitly deleted from the configuration. With a timeout, overload mode is set if the time elapsed since the OSPF instance started is less than the specified timeout.

576



A timer is started for the difference between the timeout and the time elapsed since the instance started. When the timer expires, overload mode is cleared. In overload mode, the router link-state advertisement (LSA) is originated with all the transit router links (except stub) set to a metric of 0xFFFF. The stub router links are advertised with the actual cost of the interfaces corresponding to the stub. This causes the transit traffic to avoid the overloaded routing device and to take paths around the routing device. However, the overloaded routing device’s own links are still accessible.

NOTE: The routing device can also dynamically enter the overload state, regardless of configuring the device to appear overloaded. For example, if the routing device exceeds the configured OSPF prefix limit, the routing device purges the external prefixes and enters into an overload state. You can limit the number of routes exported into OSPF to minimize the load on the routing device and prevent this potential problem.

Example: Configuring OSPF to Make Routing Devices Appear Overloaded This example shows how to configure a routing device running OSPF to appear to be overloaded. •


•


•


•




•


•


•


•


Overview You can configure a local routing device running OSPF to appear to be overloaded, which allows the local routing device to participate in OSPF routing, but not for transit traffic. When configured, the transit interface metrics are set to the maximum value of 65535.


577


This example includes the following settings: •

overload—Configures the local routing device so it appears to be overloaded. You might

configure this if you want the routing device to participate in OSPF routing, but do not want it to be used for transit traffic, or you are performing maintenance on a routing device in a production network. •

timeout seconds—(Optional) Specifies the number of seconds at which the overload

is reset. If no timeout interval is specified, the routing device remains in the overload state until the overload statement is deleted or a timeout is set. In this example, you configure 60 seconds as the amount of time the routing device remains in the overload state. By default, the timeout interval is 0 seconds (this value is not configured). The range is from 60 through 1800 seconds.


To quickly configure a local routing device to appear as overloaded, copy the following command and paste it into the CLI. [edit] set protocols ospf overload timeout 60


To configure a local routing device to appear overloaded: 1.

Enter OSPF configuration mode.


[edit] user@host edit protocols ospf 2.

Configure the local routing device to be overloaded. [edit protocols ospf] user@host set overload

3.

(Optional) Configure the number of seconds at which overload is reset. [edit protocols ospf] user@host set overload timeout 60

4.

If you are done configuring the device, commit the configuration. [edit protocols ospf] user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. The output includes the optional timeout statement. user@host# show protocols ospf overload timeout 60;

578





Verifying Traffic Has Moved Off Devices on page 579

•

Verifying Transit Interface Metrics on page 579

•

Verifying the Overload Configuration on page 579

•

Verifying the Viable Next Hop on page 579

Verifying Traffic Has Moved Off Devices Purpose Action

Verify that the traffic has moved off the upstream devices. From operational mode, enter the show interfaces detail command. Verifying Transit Interface Metrics

Purpose

Action

Verify that the transit interface metrics are set to the maximum value of 65535 on the downstream neighboring device. From operational mode, enter the show ospf database router detail advertising-router address command for OSPFv2, and enter the show ospf3 database router detail advertising-router address command for OSPFv3. Verifying the Overload Configuration

Purpose

Action

Verify that overload is configured by reviewing the Configured overload field. If the overload timer is also configured, this field also displays the time that remains before it is set to expire. From operational mode, enter the show ospf overview command for OSPFv2, and the show ospf3 overview command for OSPFv3. Verifying the Viable Next Hop

Purpose

Action


Verify the viable next hop configuration on the upstream neighboring device. If the neighboring device is overloaded, it is not used for transit traffic and is not displayed in the output. From operational mode, enter the show route address command.

•


•



579


Example: Configuring the OSPF Routing Algorithm •

Understanding the SPF Algorithm Options for OSPF on page 580

•

Example: Configuring SPF Algorithm Options for OSPF on page 580

Understanding the SPF Algorithm Options for OSPF OSPF uses the shortest-path-first (SPF) algorithm, also referred to as the Dijkstra algorithm, to determine the route to reach each destination. The SPF algorithm describes how OSPF determines the route to reach each destination, and the SPF options control the timers that dictate when the SPF algorithm runs. Depending on your network environment and requirements, you might want to modify the SPF options. For example, consider a large-scale environment with a large number of devices flooding link-state advertisements (LSAs) through out the area. In this environment, it is possible to receive a large number of LSAs to process, which can consume memory resources. By configuring the SPF options, you continue to adapt to the changing network topology, but you can minimize the amount of memory resources being used by the devices to run the SPF algorithm. You can configure the following SPF options: •

The delay in the time between the detection of a topology change and when the SPF algorithm actually runs.

•

The maximum number of times that the SPF algorithm can run in succession before the hold-down timer begins.

•

The time to hold down, or wait, before running another SPF calculation after the SPF algorithm has run in succession the configured number of times.

Example: Configuring SPF Algorithm Options for OSPF This example shows how to configure the SPF algorithm options. The SPF options control the timers that dictate when the SPF algorithm runs. •


•


•


•



580

•


•


•




•


•


Overview OSPF uses the SPF algorithm to determine the route to reach each destination. All routing devices in an area run this algorithm in parallel, storing the results in their individual topology databases. Routing devices with interfaces to multiple areas run multiple copies of the algorithm. The SPF options control the timers used by the SPF algorithm. Before you modify any of the default settings, you should have a good understanding of your network environment and requirements. This example shows how to configure the options for running the SPF algorithm. You include the spf-options statement and the following options: •

delay—Configures the amount of time (in milliseconds) between the detection of a

topology and when the SPF actually runs. When you modify the delay timer, consider your requirements for network reconvergence. For example, you want to specify a timer value that can help you identify abnormalities in the network, but allow a stable network to reconverge quickly. By default, the SPF algorithm runs 200 milliseconds after the detection of a topology. The range is from 50 through 8000 milliseconds. •

rapid-runs—Configures the maximum number of times that the SPF algorithm can run

in succession before the hold-down timer begins. By default, the number of SPF calculations that can occur in succession is 3. The range is from 1 through 5. Each SPF algorithm is run after the configured SPF delay. When the maximum number of SPF calculations occurs, the hold-down timer begins. Any subsequent SPF calculation is not run until the hold-down timer expires. •

holddown—Configures the time to hold down, or wait, before running another SPF

calculation after the SPF algorithm has run in succession the configured maximum number of times. By default, the hold down time is 5000 milliseconds. The range is from 2000 through 20,000 milliseconds. If the network stabilizes during the holddown period and the SPF algorithm does not need to run again, the system reverts to the configured values for the delay and rapid-runs statements.


To quickly configure the SPF options, copy the following commands and paste them into the CLI. [edit] set protocols ospf spf-options delay 210 set protocols ospf spf-options rapid-runs 4 set protocols ospf spf-options holddown 5050


To configure the SPF options: 1.

Enter OSPF configuration mode.


581



[edit] user@host# edit protocols ospf 2.

Configure the SPF delay time. [edit protocols ospf] user@host# set spf-options delay 210

3.

Configure the maximum number of times that the SPF algorithm can run in succession. [edit protocols ospf] user@host# set spf-options rapid-runs 4

4.

Configure the SPF hold-down timer. [edit protocols ospf] user@host# set spf-options holddown 5050

5.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf spf-options { delay 210; holddown 5050; rapid-runs 4; }


Verification Confirm that the configuration is working properly. Verifying SPF Options Purpose

Action

582

Verify that SPF is operating per your network requirements. Review the SPF delay field, the SPF holddown field, and the SPF rapid runs fields. From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview command for OSPFv3.




•


•


Example: Configuring Synchronization Between LDP and IGPs •

Synchronization Between LDP and IGPs Overview on page 583

•


Synchronization Between LDP and IGPs Overview LDP is a protocol for distributing labels in non-traffic-engineered applications. Labels are distributed along the best path determined by the interior gateway protocol (IGP). If synchronization between LDP and the IGP is not maintained, the label-switch path (LSP) goes down. When LDP is not fully operational on a given link (a session is not established and labels are not exchanged), the IGP advertises the link with the maximum cost metric. The link is not preferred but remains in the network topology. LDP synchronization is supported only on active point-to-point interfaces and LAN interfaces configured as point-to-point under the IGP. LDP synchronization is not supported during graceful restart.

Example: Configuring Synchronization Between LDP and IGPs This example shows how to configure synchronization between LDP and OSPFv2. •


•


•


•




•


•


•


•



583


Overview In this example, configure synchronization between LDP and OSPFv2 by performing the following tasks: •

Enable LDP on interface so-1/0/3, which is a member of OSPF area 0.0.0.0, by including the ldp statement at the [edit protocols] hierarchy level. You can configure one or more interfaces. By default, LDP is disabled on the routing device.

•

Enable LDP synchronization by including the ldp-synchronization statement at the [edit protocols ospf area area-id interface interface-name] hierarchy level. This statement enables LDP synchronization by advertising the maximum cost metric until LDP is operational on the link.

•

Configure the amount of time (in seconds) the routing device advertises the maximum cost metric for a link that is not fully operational by including the hold-time statement at the [edit protocols ospf area area-id interface interface-name ldp-synchronization] hierarchy level. If you do not configure the hold-time statement, the hold-time value defaults to infinity. The range is from 1 through 65,535 seconds. In this example, configure 10 seconds for the hold-time interval.

This example also shows how to disable synchronization between LDP and OSPFv2 by including the disable statement at the [edit protocols ospf area area-id interface interface-name ldp-synchronization] hierarchy level.

Configuration •

Enabling Synchronization Between LDP and OSPFv2 on page 584

•

Disabling Synchronization Between LDP and OSPFv2 on page 585

Enabling Synchronization Between LDP and OSPFv2 CLI Quick Configuration

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To quickly enable synchronization between LDP and OSPFv2, copy the following commands, remove any line breaks, and then paste them into the CLI. [edit] set protocols ldp interface so-1/0/3 set protocols ospf area 0.0.0.0 interface so-1/0/3 ldp-syncrhonization hold-time 10


To enable synchronization between LDP and OSPFv2: 1.

Enable LDP on the interface. [edit] user@host# set protocols ldp interface so-1/0/3

2.

Configure LDP synchronization and optionally configure a time period of 10 seconds to advertise the maximum cost metric for a link that is not fully operational. [edit ] user@host# edit protocols ospf area 0.0.0.0 interface so-1/0/3 ldp-synchronization

584



3.

Configure a time period of 10 seconds to advertise the maximum cost metric for a link that is not fully operational. [edit protocols ospf area 0.0.0.0 interface so-1/0/3 ldp-synchronization ] user@host# set hold-time 10

4.

If you are done configuring the device, commit the configuration. [edit protocols ospf area 0.0.0.0 interface so-1/0/3 ldp-synchronization ] user@host# commit

Results

Confirm your configuration by entering the show protocols ldp and show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ldp interface so-1/0/3.0; user@host# show protocols ospf area 0.0.0.0 { interface so-1/0/3.0 { ldp-synchronization { hold-time 10; } } }

Disabling Synchronization Between LDP and OSPFv2 CLI Quick Configuration

To quickly disable synchronization between LDP and OSPFv2, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.0 interface so-1/0/3 ldp-synchronization disable


To disable synchronization between LDP and OSPF: 1.

Disable synchronization by including the disable statement. [edit ] user@host# set protocols ospf area 0.0.0.0 interface so-1/0/3 ldp-synchronization disable

2.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.0 { interface so-1/0/3.0 { ldp-synchronization { disable;


585


} } }

Verification Confirm that the configuration is working properly. Verifying the LDP Synchronization State of the Interface Purpose

Action


Verify the current state of LDP synchronization on the interface. The LDP sync state displays information related to the current state, and the config holdtime field displays the configured hold-time interval. From operational mode, enter the show ospf interface extensive command.

•


•


Examples: Configuring OSPF Authentication •


•


•

Example: Configuring Simple Authentication for OSPFv2 Exchanges on page 588

•

Example: Configuring MD5 Authentication for OSPFv2 Exchanges on page 590

•

Example: Configuring a Transition of MD5 Keys on an OSPFv2 Interface on page 592

•

Example: Configuring IPsec Authentication for an OSPF Interface on page 595

Understanding OSPFv2 Authentication All OSPFv2 protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in the autonomous system’s routing. By default, OSPFv2 authentication is disabled.

NOTE: OSPFv3 does not have a built-in authentication method and relies on IP Security (IPSec) to provide this functionality.

You can enable the following authentication types:

586

•

Simple authentication—Authenticates by using a plain-text password that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet.

•

MD5 authentication—Authenticates by using an encoded MD5 checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet.



You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts routing updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing device only accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that interface. •

IPsec authentication (beginning with Junos OS Release 8.3)—Authenticates OSPFv2 interfaces, the remote endpoint of a sham link, and the OSPFv2 virtual link by using manual security associations (SAs) to ensure that a packet’s contents are secure between the routing devices. You configure the actual IPsec authentication separately.

NOTE: You can configure IPsec authentication together with either MD5 or simple authentication.

The following restrictions apply to IPsec authentication for OSPFv2: •

Dynamic IKE SAs are not supported.

•

Only IPsec transport mode is supported. Tunnel mode is not supported.

•

Because only bidirectional manual SAs are supported, all OSPFv2 peers must be configured with the same IPsec SA. You configure a manual bidirectional SA at the [edit security ipsec] hierarchy level.

•

You must configure the same IPsec SA for all virtual links with the same remote endpoint address, for all neighbors on OSPF nonbroadcast multiaccess (NBMA) or point-to-multipoint links, and for every subnet that is part of a broadcast link.

•

OSPFv2 peer interfaces are not supported.

Because OSPF performs authentication at the area level, all routing devices within the area must have the same authentication and corresponding password (key) configured. For MD5 authentication to work, both the receiving and transmitting routing devices must have the same MD5 key. In addition, a simple password and MD5 key are mutually exclusive. You can configure only one simple password, but multiple MD5 keys. As part of your security measures, you can change MD5 keys. You can do this by configuring multiple MD5 keys, each with a unique key ID, and setting the date and time to switch to the new key. Each unique MD5 key has a unique ID. The ID is used by the receiver of the OSPF packet to determine which key to use for authentication. The key ID, which is required for MD5 authentication, specifies the identifier associated with the MD5 key.

Understanding OSPFv3 Authentication OSPFv3 does not have a built-in authentication method and relies on IPsec to provide this functionality. OSPFv3 uses the IP authentication header (AH) and the IP Encapsulating Security Payload (ESP) portions of the IPsec Protocol to authenticate routing information. You can secure specific OSPFv3 interfaces and protect OSPFv3 virtual links. Use ESP with NULL encryption to provide authentication to the OSPFv3 protocol headers only. Use AH to provide authentication to the OSPFv3 protocol headers, portions of the


587


IPv6 header, and portions of the extension headers. Use ESP with non-NULL encryption for full confidentiality. You configure the actual IPsec authentication separately. The following restrictions apply to IPsec authentication for OSPFv3: •

Dynamic IKE SAs are not supported.

•

Only IPsec transport mode is supported. Tunnel mode is not supported.

•

Because only bidirectional manual SAs are supported, all OSPFv3 peers must be configured with the same IPsec SA. You configure a manual bidirectional SA at the [edit security ipsec] hierarchy level.

•

You must configure the same IPsec SA for all virtual links with the same remote endpoint address.

Example: Configuring Simple Authentication for OSPFv2 Exchanges This example shows how to enable simple authentication for OSPFv2 exchanges. •


•


•


•




•


•


•


•


Overview Simple authentication uses a plain-text password that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet. Plain-text passwords are not encrypted and might be subject to packet interception. This method is the least secure and should only be used if network security is not your goal. You can configure only one simple authentication key (password) on the routing device. The simple key can be from 1 through 8 characters and can include ASCII strings. If you include spaces, enclose all characters in quotation marks (“ “).

588



In this example, you specify OSPFv2 interface so-0/1/0 in area 0.0.0.0, set the authentication type to simple-password, and define the key as PssWd4.


To quickly configure simple authentication, copy the following command, removing any line breaks, and then paste the command into the CLI. You must configure all routing devices within the area with the same authentication and corresponding password. [edit] set protocols ospf area 0.0.0.0 interface so-0/1/0 authentication simple-password PssWd4


To enable simple authentication for OSPFv2 exchanges: 1.


2.

Specify the interface. [edit protocols ospf area 0.0.0.0] user@host# edit interface so-0/1/0

3.

Set the authentication type and the password. [edit protocols ospf area 0.0.0.0 interface so-0/1/0.0] user@host# set authentication simple-password PssWd4

4.

If you are done configuring the device, commit the configuration. [edit protocols ospf area 0.0.0.0 interface so-0/1/0.0] user@host# commit

NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices in the area.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

NOTE: After you configure the password, you do not see the password itself. The output displays the encrypted form of the password you configured.

user@host# show protocols ospf area 0.0.0.0 { interface so-0/1/0.0 { authentication { simple-password "$9$-3dY4ZUHm5FevX-db2g"; ## SECRET-DATA } }


589


}


Verifying the Configured Authentication Method on page 590

Verifying the Configured Authentication Method Purpose

Action

Verify that the authentication method for sending and receiving OSPF protocol packets is configured. The Authentication Type field displays Password when configured for simple authentication. From operational mode, enter the show ospf interface and the show ospf overview commands.

Example: Configuring MD5 Authentication for OSPFv2 Exchanges This example shows how to enable MD5 authentication for OSPFv2 exchanges. •


•


•


•




•


•


•


•


Overview MD5 authentication uses an encoded MD5 checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet. You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts routing updates only if MD5 authentication succeeds. Otherwise, updates are

590



rejected. The routing device only accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that interface. In this example, you create the backbone area (area 0.0.0.0), specify OSPFv2 interface so-0/2/0, set the authentication type to md5, and then define the authentication key ID as 5 and the password as PssWd8.


To quickly configure MD5 authentication, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.0 interface so-0/2/0 authentication md5 5 key PssWd8


To enable MD5 authentication for OSPFv2 exchanges: 1.


2.


3.

Configure MD5 authentication and set a key ID and an authentication password. [edit protocols ospf area 0.0.0.0 interface s0-0/2/0.0] user@host# set authentication md5 5 key PssWd8

4.

If you are done configuring the device, commit the configuration. [edit protocols ospf area 0.0.0.0 interface s0-0/2/0.0] user@host# commit

NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices.

Results



user@host# show protocols ospf area 0.0.0.0 { interface so-0/2/0.0 { authentication {


591


md5 5 key "$9$pXXhuIhreWx-wQF9puBEh"; ## SECRET-DATA } } }

Verification Confirm that the configuration is working properly. Verifying the Configured Authentication Method Purpose

Action

Verify that the authentication method for sending and receiving OSPF protocol packets is configured. When configured for MD5 authentication, the Authentication Type field displays MD5, the Active key ID field displays the unique number you entered that identifies the MD5 key, and the Start time field displays the date as Start time 1970 Jan 01 00:00:00 PST. Do not be alarmed by this start time. This is the default start time that the routing device displays if the MD5 key is effective immediately. From operational mode, enter the show ospf interface and the show ospf overview commands.

Example: Configuring a Transition of MD5 Keys on an OSPFv2 Interface This example shows how to configure a transition of MD5 keys on an OSPFv2 interface. •


•


•


•




•


•


•


•


Overview MD5 authentication uses an encoded MD5 checksum that is included in the transmitted packet. For MD5 authentication to work, both the receiving and transmitting routing devices must have the same MD5 key.

592



You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts routing updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing device only accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that interface. For increased security, you can configure multiple MD5 keys, each with a unique key ID, and set the date and time to switch to a new key. The receiver of the OSPF packet uses the ID to determine which key to use for authentication. In this example, you configure new keys to take effect at 12:01 AM on the first day of the next three months on OSPFv2 interface fe-0/0/1 in the backbone area (area 0.0.0.0), and you configure the following MD5 authentication settings: •

md5—Specifies the MD5 authentication key ID. The key ID can be set to any value

between 0 and 255, with a default value of 0. The routing device only accepts OSPFv2 packets sent using the same key ID that is defined for that interface. •

key—Specifies the MD5 key. Each key can be a value from 1 through 16 characters long.

Characters can include ASCII strings. If you include spaces, enclose all characters in quotation marks (“ “). •

start-time—Specifies the time to start using the MD5 key. This option enables you to

configure a smooth transition mechanism for multiple keys. The start time is relevant for transmission but not for receiving OSPF packets.

NOTE: You must set the same passwords and transition dates and times on all devices in the area so that OSPFv2 adjacencies remain active.


To quickly configure multiple MD5 keys on an OSPFv2 interface, copy the following commands, remove any line breaks, and then paste the commands into the CLI. [edit] set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 1 key $2010HaL set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 2 key NeWpsswdFEB start-time 2011-02-01.00:01 set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 3 key NeWpsswdMAR start-time 2011-03-01.00:01 set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 4 key NeWpsswdAPR start-time 2011-04-01.00:01


To configure multiple MD5 keys on an OSPFv2 interface: 1.


2.

Specify the interface. [edit protocols ospf area 0.0.0.0] user@host# edit interface fe-0/1/0


593


3.

Configure MD5 authentication and set an authentication password and key ID. [edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] user@host# set authentication md5 1 key $2010HaL

4.

Configure a new key to take effect at 12:01 AM on the first day of February, March, and April. You configure a new authentication password and key ID for each month. a. For the month of February, enter the following: [edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] user@host# set authentication md5 2 key NeWpsswdFEB start-time 2011-02-01.00:01

b. For the month of March, enter the following: [edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] user@host# set authentication md5 3 key NeWpsswdMAR start-time 2011-03-01.00:01

c. For the month of April, enter the following: [edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] user@host# set authentication md5 4 key NeWpsswdAPR start-time 2011-04-01.00:01 5.

If you are done configuring the device, commit the configuration. [edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] user@host# commit

NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices.

Results



user@host# show protocols ospf area 0.0.0.0 { interface fe-0/1/0.0 { authentication { md5 1 key "$9$wzs24JGDjk.2gfTQ3CAp0B1hy"; ## SECRET-DATA md5 2 key "$9$Q9gz39t1IcML7EcwgJZq.RhSylMN-b4oZDi" start-time "2011-2-1.00:01:00 -0800"; ## SECRET-DATA md5 3 key "$9$zjo2nCpIRSWXNhSs4ZG.mEcyreW2gaZGjCt" start-time "2011-3-1.00:01:00 -0800"; ## SECRET-DATA

594



md5 4 key "$9$fQn90OReML1Rds4oiHBIEhSevMLXNVqm" start-time "2011-4-1.00:01:00 -0700"; ## SECRET-DATA } } }

Verification Confirm that the configuration is working properly. Verifying the Configured Authentication Method Purpose

Action

Verify that the authentication method for sending and receiving OSPF protocol packets is configured. When configured for MD5 authentication with a transition of keys, the Auth type field displays MD5, the Active key ID field displays the unique number you entered that identifies the MD5 key, and the Start time field displays the time at which the routing device starts using an MD5 key to authenticate OSPF packets transmitted on the interface you configured. From operational mode, enter the show ospf interface and the show ospf overview commands.

Example: Configuring IPsec Authentication for an OSPF Interface This example shows how to enable IP Security (IPsec) authentication for an OSPF interface. •


•


•


•




•


•


•


•



595


Overview You can use IPsec authentication for both OSPFv2 and OSPFv3. You configure the actual IPsec authentication separately and apply it to the applicable OSPF configuration. OSPFv2 Beginning with Junos OS Release 8.3, you can use IPsec authentication to authenticate OSPFv2 interfaces, the remote endpoint of a sham link, and the OSPFv2 virtual link by using manual security associations (SAs) to ensure that a packet’s contents are secure between the routing devices.

NOTE: You can configure IPsec authentication together with either MD5 or simple authentication.

To enable IPsec authentication, do one of the following: •

For an OSPFv2 interface, include the ipsec-sa name statement for a specific interface: interface interface-name ipsec-sa name;

•

For a remote sham link, include the ispec-sa name statement for the remote end point of the sham link: sham-link-remote address ipsec-sa name;

NOTE: If a Layer 3 VPN configuration has multiple sham links with the same remote endpoint IP address, you must configure the same IPsec security association for all the remote endpoints. You configure a Layer 3 VPN at the [edit routing-instances routing-instance-name instance-type] hierarchy level. For more information about Layer 3 VPNs, see the Junos OS VPNs Configuration Guide.

•

For a virtual link, include the ipsec-sa name statement for a specific virtual link: virtual-link neighbor-id router-id transit-area area-id ipsec-sa name;

OSPFv3 OSPFv3 does not have a built-in authentication method and relies on IPsec to provide this functionality. You use IPsec authentication to secure OSPFv3 interfaces and protect OSPFv3 virtual links by using manual SAs to ensure that a packet’s contents are secure between the routing devices. To apply authentication, do one of the following: •

For an OSPFv3 interface, include the ipsec-sa name statement for a specific interface: interface interface-name ipsec-sa name;

•

596

For a virtual link, include the ipsec-sa name statement for a specific virtual link:



virtual-link neighbor-id router-id transit-area area-id ipsec-sa name;

Tasks to Complete for Both OSPFv2 and OSPFv3 In this example, you perform the following tasks: 1.

Configure IPsec authentication. To do this, define a manual SA named sa1 and specify the processing direction, the protocol used to protect IP traffic, the security parameter index (SPI), and the authentication algorithm and key. a. Configure the following option at the [edit security ipsec security-association sa-name mode] hierarchy level: transport—Specifies transport mode. This mode protects traffic when the

communication endpoint and the cryptographic endpoint are the same. The data portion of the IP packet is encrypted, but the IP header is not. b. Configure the following option at the [edit security ipsec security-association sa-name manual direction] hierarchy level: bidirectional—Defines the direction of IPsec processing. By specifying bidrectional,

the same algorithms, keys, and security paramater index (SPI) values you configure are used in both directions. c. Configure the following options at the [edit security ipsec security-association sa-name manual direction bidirectional] hierarchy level: protocol—Defines the IPsec protocol used by the manual SA to protect IP traffic.

You can specify either the authentication header (AH) or the Encapsulating Security Payload (ESP). If you specify AH, which you do in this example, you cannot configure encryption. spi—Configures the SPI for the manual SA. An SPI is an arbitrary value that uniquely

identifies which SA to use at the receiving host. The sending host uses the SPI to identify and select which SA to use to secure every packet. The receiving host uses the SPI to identify and select the encryption algorithm and key used to decrypt packets. In this example, you specify 256. authentication—Configures the authentication algorithm and key. The algorithm

option specifies the hash algorithm that authenticates packet data. In this example, you specify hmac-md5-96, which produces a 128-bit digest. The key option indicates the type of authentication key. In this example, you specify ascii-text-key, which is 16 ASCII characters for the hmac-md5-96 algorithm. 2. Enable IPsec authentication on OSPF interface so-0/2/0.0 in the backbone area (area

0.0.0.0) by including the name of the manual SA sa1 that you configured at the [edit security ipsec] hierarchy level.

Configuration •

Configuring Security Associations on page 598

•

Enabling IPsec Authentication for an OSPF Interface on page 599


597


Configuring Security Associations CLI Quick Configuration

To quickly configure a manual SA to be used for IPsec authentication on an OSPF interface, copy the following commands, remove any line breaks, and then paste the commands into the CLI. [edit] set security ipsec security-association sa1 set security ipsec security-association sa1 mode transport set security ipsec security-association sa1 manual direction bidirectional set security ipsec security-association sa1 manual direction bidirectional protocol ah set security ipsec security-association sa1 manual direction bidirectional spi 256 set security ipsec security-association sa1 manual direction bidirectional authentication algorithm hmac-md5-96 key ascii-text 123456789012abc


To configure a manual SA to be used on an OSPF interface: 1.

Specify a name for the SA. [edit] user@host# edit security ipsec security-association sa1

2.

Specify the mode of the SA. [edit security ipsec security-association sa1 ] user@host# set mode transport

3.

Configure the direction of the manual SA. [edit security ipsec security-association sa1 ] user@host# set manual direction bidirectional

4.

Configure the IPsec protocol to use. [edit security ipsec security-association sa1 ] user@host# set manual direction bidirectional protocol ah

5.

Configure the value of the SPI. [edit security ipsec security-association sa1 ] user@host# set manual direction bidirectional spi 256

6.

Configure the authentication algorithm and key. [edit security ipsec security-association sa1 ] user@host# set manual direction bidirectional authentication algorithm hmac-md5-96 key ascii-text 123456789012abc

7.

If you are done configuring the device, commit the configuration. [edit security ipsec security-association sa1 ] user@host# commit

NOTE: Repeat this entire configuration on all peer OSPF routing devices.

598



Results

Confirm your configuration by entering the show security ipsec command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.


user@host# show security ipsec security-association sa1 { mode transport; manual { direction bidirectional { protocol ah; spi 256; authentication { algorithm hmac-md5-96; key ascii-text "$9$AP5Hp1RcylMLxSygoZUHk1REhKMVwY2oJx7jHq.zF69A0OR"; ## SECRET-DATA } } } }

Enabling IPsec Authentication for an OSPF Interface CLI Quick Configuration

To quickly apply a manual SA used for IPsec authentication to an OSPF interface, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.0 interface so-0/2/0 ipsec-sa sa1


To enable IPsec authentication for an OSPF interface: 1.





3.

Apply the IPsec manual SA. [edit protocols ospf area 0.0.0.0 interface so-0/2/0.0] user@host# set ipsec-sa sa1


599


4.

If you are done configuring the device, commit the configuration. [edit protocols ospf area 0.0.0.0 interface so-0/2/0.0] user@host# commit

NOTE: Repeat this entire configuration on all peer OSPF routing devices.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.0 { interface so-0/2/0.0 { ipsec-sa sa1; } }



Verifying the IPsec Security Association Settings on page 600

•

Verifying the IPsec Security Association on the OSPF Interface on page 600

Verifying the IPsec Security Association Settings Purpose

Action

Verify the configured IPsec security association settings. Verify the following information: •

The Security association field displays the name of the configured security association.

•

The SPI field displays the value you configured.

•

The Mode field displays transport mode.

•

The Type field displays manual as the type of security association.

From operational mode, enter the show ipsec security-associations command. Verifying the IPsec Security Association on the OSPF Interface

600

Purpose

Verify that the IPsec security association that you configured has been applied to the OSPF interface. Confirm that the IPSec SA name field displays the name of the configured IPsec security association.

Action





•


•


Example: Configuring OSPF Routing Instances •

Introduction to Routing Instances for OSPF on page 601

•

Configuring OSPF Routing Table Groups on page 602

•


Introduction to Routing Instances for OSPF A routing instance is a collection of routing tables, interfaces, and routing protocol parameters. The set of interfaces belongs to the routing tables, and the OSPF routing protocol parameters control the information in the routing tables. You can further install routes learned from OSPF routing instances into routing tables in the OSPF routing table group.

NOTE: The default routing instance, master, refers to the main inet.0 routing table. The master routing instance is reserved and cannot be specified as a routing instance.

You can configure the following types of routing instances: •

OSPFv2—Forwarding, Layer 2 virtual private network (VPN), nonforwarding, VPN routing and forwarding (VRF), virtual router, and virtual private LAN service (VPLS).

•

OSPFv3—Nonforwarding, VRF, and virtual router.

Each routing instance has a unique name and a corresponding IP unicast table. For example, if you configure a routing instance with the name my-instance, the corresponding IP unicast table is my-instance.inet.0. All routes for my-instance are installed into my-instance.inet.0. You can also configure multiple routing instances of OSPF.

Minimum Routing-Instance Configuration for OSPFv2 To configure a routing instance for OSPFv2, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { interface interface-name; instance-type (forwarding | l2vpn | no-forwarding | virtual-router | vpls | vrf); route-distinguisher (as-number:number | ip-address:number); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols {


601


ospf { ... ospf-configuration ... } } } }


Minimum Routing-Instance Configuration for OSPFv3 To configure a routing instance for OSPFv3, you must include at least the following statements in the configuration: [edit] routing-instances { routing-instance-name { interface interface-name; instance-type (no-forwarding | virtual-router | vrf); vrf-import [ policy-names ]; vrf-export [ policy-names ]; protocols { ospf3 { ... ospf3-configuration ... } } } }


Multiple Routing Instances of OSPF Multiple instances of OSPF are used for Layer 3 VPN implementations. The multiple instances of OSPF keep routing information for different VPNs separate. The VRF instance advertises routes from the customer edge (CE) router to the provider edge (PE) router and advertises routes from the PE router to the CE router. Each VPN receives only routing information belonging to that VPN. You can create multiple instances of OSPF by including statements at the following hierarchy levels: •

[edit routing-instances routing-instance-name (ospf | ospf3)]

•

[edit logical-systems logical-system-name routing-instances routing-instance-name (ospf | ospf3)]

Configuring OSPF Routing Table Groups To install routes learned from OSPF routing instances into routing tables in the OSPF routing table group, include the rib-group statement:

602



rib-group group-name;


Example: Configuring Multiple Routing Instances of OSPF This example shows how to configure multiple routing instances of OSPF. •


•


•


•




•


•


Overview When you configure multiple routing instances of OSPF, we recommend that you perform the following tasks: 1.

Configure the OSPFv2 or OSPFv3 default instance at the [edit protocols (ospf | ospf3)] and [edit logical-systems logical-system-name protocols (ospf | ospf3)] hierarchy levels with the statements needed for your network so that routes are installed in inet.0 and in the forwarding table. Make sure to include the routing table group.

2. Configure an OSPFv2 or OSPFv3 routing instance for each additional OSPFv2 or

OSPFv3 routing entity, configuring the following: •

Interfaces

•

Routing options

•

OSPF protocol statements belonging to that entity

•

Routing table group

3. Configure a routing table group to install routes from the default route table, inet.0,

into a routing instance’s route table. 4. Configure a routing table group to install routes from a routing instance into the default

route table, inet.0.


603


NOTE: Nonforwarding routing instances do not have forwarding tables that correspond to their routing tables.

5. Create an export policy to export routes with a specific tag, and use that tag to export

routes back into the instances. For more information, see the Junos OS Routing Policy Configuration Guide. Figure 5 on page 258 shows how you can use multiple routing instances of OSPFv2 or OSPFv3 to segregate prefixes within a large network. The network consists of three administrative entities: voice-policy, other-policy, and the default routing instance. Each entity is composed of several geographically separate sites that are connected by the backbone and managed by the backbone entity.


Site B

4

6

voice-policy

other-policy

so-5/2/2.0

so-2/2/2.0

Backbone 3

1

so-3/2/2.0

so-4/2/2.0

7

5

other-policy

voice-policy

Site C

Site D

g040730

2

Sites A and D belong to the voice-policy routing instance. Sites B and C belong to the other-policy instance. Device 1 and Device 3 at the edge of the backbone connect the routing instances. Each runs a separate OSPF or OSPFv3 instance (one per entity). Device 1 runs three OSPFv2 or OSPFv3 instances: one each for Site A (voice-policy), Site C (other-policy), and the backbone, otherwise known as the default instance. Device 3 also runs three OSPFv2 or OSPFv3 instances: one each for Site B (other-policy), Site D (voice-policy), and the backbone (default instance). When Device 1 runs the OSPFv2 or OSPFv3 instances, the following occur:

604

•


•




•


•


•



To quickly configure multiple routing instances of OSPF, copy the following commands, remove any line breaks, and then paste the commands into the CLI. Configuration on Device 1: [edit] set routing-instances voice-policy interface so-2/2/2 set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface so-2/2/2 set routing-instances other-policy interface so-4/2/2 set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface so-4/2/2 set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ] set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 ] set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0 inet.0 ] set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-2/2/2 set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-4/2/2



To configure multiple routing instances of OSPF: 1.

Configure the routing instances for voice-policy and other-policy.



605


[edit] user@D1# set routing-instances voice-policy interface so-2/2/2 user@D1# set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface so-2/2/2 user@D1# set routing-instances other-policy interface so-4/2/2 user@D1# set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface so-4/2/2 [edit] user@D3# set routing-instances voice-policy interface so-3/2/2 user@D3# set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface so-3/2/2 user@D3#set routing-instances other-policy interface so-5/2/2 user@D3# set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface so-5/2/2 2.

Configure the routing table group inet-to-voice-and-other to take routes from inet.0 (default routing table) and place them in the voice-policy.inet.0 and other-policy.inet.0 routing tables. [edit] user@D1# set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ] [edit] user@D3# set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ]

3.

Configure the routing table group voice-to-inet to take routes from voice-policy.inet.0 and place them in the inet.0 default routing table. [edit] user@D1# set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 ] [edit] user@D3# set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 ]

4.

Configure the routing table group other-to-inet to take routes from other-policy.inet.0 and place them in the inet.0 default routing table. [edit] user@D1# set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0 inet.0 ] [edit] user@D3# set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0 inet.0 ]

5.

Configure the default OSPF instance.


[edit]

606



user@D1# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-2/2/2 user@D1# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-4/2/2 [edit] user@D3# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-3/2/2 user@D3# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-5/2/2 6.


Results

Confirm your configuration by entering the show routing-instances, show routing-options, and show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on Device 1: user@D1# show routing-instances voice-policy { interface so-2/2/2.0; protocols { ospf { rib-group voice-to-inet; area 0.0.0.0 { interface so-2/2/2.0; } } } } other-policy { interface so-4/2/2.0; protocols { ospf { rib-group other-to-inet; area 0.0.0.0 { interface so-4/2/2.0; } } } } user@D1# show routing-options rib-groups { inet-to-voice-and-other { import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ]; } voice-to-inet { import-rib [ voice-policy.inet.0 inet.0 ]; } other-to-inet { import-rib [ other-policy.inet.0 inet.0 ]; }


607


} user@D1# show protocols ospf rib-group inet-to-voice-and-other; area 0.0.0.0 { interface so-2/2/2.0; interface so-4/2/2.0; }

Configuration on Device 3: user@D3# show routing-instances voice-policy { interface so-3/2/2.0; protocols { ospf { rib-group voice-to-inet; area 0.0.0.0 { interface so-3/2/2.0; } } } } other-policy { interface so-5/2/2.0; protocols { ospf { rib-group other-to-inet; area 0.0.0.0 { interface so-5/2/2.0; } } } } user@D3# show routing-options rib-groups { inet-to-voice-and-other { import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 ]; } voice-to-inet { import-rib [ voice-policy.inet.0 inet.0 ]; } other-to-inet { import-rib [ other-policy.inet.0 inet.0 ]; } } user@D3# show protocols ospf rib-group inet-to-voice-and-other; area 0.0.0.0 { interface so-3/2/2.0; interface so-5/2/2.0; }

To confirm your OSPFv3 configuration, enter the show routing-instances, show routing-options, and show protocols ospf3 commands.

608



Verification Confirm that the configuration is working properly. Verifying the Routing Instances Purpose Action


Verify the configured routing instance settings. From operational mode, enter the show route instance detail command.

•


•

Routing Instances Overview on page 235 in the Junos OS Routing Policy Configuration Guide

Example: Configuring OSPF Timers •


•


OSPF Timers Overview OSPF routing devices constantly track the status of their neighbors, sending and receiving hello packets that indicate whether each neighbor still is functioning, and sending and receiving link-state advertisement (LSA) and acknowledgment packets. OSPF sends packets and expects to receive packets at specified intervals. You configure OSPF timers on the interface of the routing device participating in OSPF. Depending on the timer, the configured interval must be the same on all routing devices on a shared network (area). You can configure the following OSPF timers: •

Hello interval—Routing devices send hello packets at a fixed interval on all interfaces, including virtual links, to establish and maintain neighbor relationships. The hello interval specifies the length of time, in seconds, before the routing device sends a hello packet out of an interface. This interval must be the same on all routing devices on a shared network. By default, the routing device sends hello packets every 10 seconds (broadcast and point-to-point networks) and 30 seconds (nonbroadcast multiple access (NBMA) networks).

•

Poll interval—(OSPFv2, Nonbroadcast networks only) Routing devices send hello packets for a longer interval on nonbroadcast networks to minimize the bandwidth required on slow WAN links. The poll interval specifies the length of time, in seconds, before the routing device sends hello packets out of the interface before establishing adjacency with a neighbor. By default, the routing device sends hello packets every 120 seconds until active neighbors are detected. Once the routing device detects an active neighbor, the hello packet interval changes from the time specified in the poll interval to the time specified in the hello interval.


609


•

LSA retransmission interval—When a routing device sends LSAs to its neighbors, the routing device expects to receive an acknowledgment packet from each neighbor within a certain amount of time. The LSA retransmission interval specifies the length of time, in seconds, that the routing device waits to receive an LSA packet before retransmitting the LSA to an interface’s neighbors. By default, the routing device waits 5 seconds for an acknowledgment before retransmitting the LSA.

•

Dead interval—If a routing device does not receive a hello packet from a neighbor within a fixed amount of time, the routing device modifies its topology database to indicate that the neighbor is nonoperational. The dead interval specifies the length of time, in seconds, that the routing device waits before declaring that a neighboring routing device is unavailable. This is an interval during which the routing device receives no hello packets from the neighbor. This interval must be the same on all routing devices on a shared network. By default, this interval is four times the default hello interval, which is 40 seconds (broadcast and point-to-point networks) and 120 seconds (NBMA networks).

•

Transit delay—Before a link-state update packet is propagated out of an interface, the routing device must increase the age of the packet. The transit delay sets the estimated time required to transmit a link-state update on the interface. By default, the transit delay is 1 second. You should never have to modify the transit delay time.

Example: Configuring OSPF Timers This example shows how to configure the OSPF timers. •


•


•


•



610

•


•


•


•


•




Overview The default OSPF timer settings are optimal for most networks. However, depending on your network requirements, you might need to modify the timer settings. This example explains why you might need to modify the following timers: •

Hello interval

•

Dead interval

•

LSA retransmission interval

•

Transit delay

Hello Interval and Dead Interval The hello interval and the dead interval optimize convergence times by efficiently tracking neighbor status. By lowering the values of the hello interval and the dead interval, you can increase the convergence of OSPF routes if a path fails. These intervals must be the same on all routing devices on a shared network. Otherwise, OSPF cannot establish the appropriate adjacencies. In the first example, you lower the hello interval to 2 seconds and the dead interval to 8 seconds on point-to-point OSPF interfaces fe-0/0/1 and fe-1/0/1 in area 0.0.0.0 by configuring the following settings: •

hello-interval—Specifies the length of time, in seconds, before the routing device sends

a hello packet out of an interface. By default, the routing device sends hello packets every 10 seconds. The range is from 1 through 255 seconds. •

dead-interval—Specifies the length of time, in seconds, that the routing device waits

before declaring that a neighboring routing device is unavailable. This is an interval during which the routing device receives no hello packets from the neighbor. By default, the routing device waits 40 seconds (four times the hello interval). The range is 1 through 65,535 seconds. LSA Retransmission Interval The link-state advertisement (LSA) retransmission interval optimizes the sending and receiving of LSA and acknowledgement packets. You must configure the LSA retransmission interval to be equal to or greater than 3 seconds to avoid triggering a retransmit trap because the Junos OS delays LSA acknowledgments by up to 2 seconds. If you have a virtual link, you might find increased performance by increasing the value of the LSA retransmission interval.


611


In the second example, you increase the LSA retransmission timer to 8 seconds on OSPF interface fe-0/0/1 in area 0.0.0.1 by configuring the following setting: •

retransmit-interval—Specifies the length of time, in seconds, that the routing device

waits to receive an LSA packet before retransmitting LSA to an interface’s neighbors. By default, the routing device retransmits LSAs to its neighbors every 5 seconds. The range is from 1 through 65,535 seconds. Transit Delay The transit delay sets the time the routing device uses to age a link-state update packet. If you have a slow link (for example, one with an average propagation delay of multiple seconds), you should increase the age of the packet by a similar amount. Doing this ensures that you do not receive a packet back that is younger than the original copy. In the final example, you increase the transit delay to 2 seconds on OSPF interface fe-1/0/1 in area 0.0.0.1. By configuring the following setting, this causes the routing device to age the link-state update packet by 2 seconds: •

transit-delay—Sets the estimated time required to transmit a link-state update on the

interface. You should never have to modify the transit delay time. By default, the routing device ages the packet by 1 second. The range is from 1 through 65,535 seconds.

Configuration •

Configuring the Hello Interval and the Dead Interval on page 612

•

Controlling the LSA Retransmission Interval on page 613

•

Specifying the Transit Delay on page 614

Configuring the Hello Interval and the Dead Interval CLI Quick Configuration

To quickly configure the hello and dead intervals, copy the following commands and paste them into the CLI. [edit] set protocols ospf area 0.0.0.0 interface fe-0/0/1 hello-interval 2 set protocols ospf area 0.0.0.0 interface fe-0/0/1 dead-interval 8 set protocols ospf area 0.0.0.0 interface fe-1/0/1 hello-interval 2 set protocols ospf area 0.0.0.0 interface fe-1/0/1 dead-interval 8


To configure the hello and dead intervals: 1.




612

Specify the interfaces.



[edit protocols ospf area 0.0.0.0] user@host# set interface fe-0/0/1 user@host# set interface fe-1/0/1 3.

Configure the hello interval. [edit protocols ospf area 0.0.0.0 ] user@host# set interface fe-0/0/1 hello-interval 2 user@host# set interface fe-1/0/1 hello-interval 2

4.

Configure the dead interval. [edit protocols ospf area 0.0.0.0 ] user@host# set interface fe-0/0/1 dead-interval 8 user@host# set interface fe-1/0/1 dead-interval 8

5.


NOTE: Repeat this entire configuration on all routing devices in a shared network.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.0 { interface fe-0/0/1.0 { hello-interval 2; dead-interval 8; } interface fe-1/0/1.0 { hello-interval 2; dead-interval 8; } }

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. Controlling the LSA Retransmission Interval CLI Quick Configuration

To quickly configure the LSA retransmission interval, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.1 interface fe-0/0/1 retransmit-interval 8


To configure the LSA retransmission interval: 1.



613




Specify the interface. [edit protocols ospf area 0.0.0.1] user@host# set interface fe-0/0/1

3.

Configure the LSA retransmission interval. [edit protocols ospf area 0.0.0.1 ] user@host# set interface fe-0/0/1 retransmit-interval 8

4.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.1 { interface fe-0/0/1.0 { retransmit-interval 8; } }

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. Specifying the Transit Delay CLI Quick Configuration

To quickly configure the transit delay, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.1 interface fe-1/0/1 transit-delay 2


To configure the transit delay: 1.



[edit] user@host# edit protocols ospf area 0.0.0.1

614



Specify the interface.

2.

[edit protocols ospf area 0.0.0.1] user@host# set interface fe-1/0/1

Configure the transit delay.

3.

[edit protocols ospf area 0.0.0.1 ] user@host# set interface fe-1/0/1 transit-delay 2

If you are done configuring the device, commit the configuration.

4.

[edit protocols ospf area 0.0.0.1 ] user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.1 { interface fe-1/0/1.0 { transit-delay 2; } }


Verification confirm that the configuration is working properly. Verifying the Timer Configuration Purpose

Action


Verify that the interface for OSPF or OSPFv3 has been configured with the applicable timer values. Confirm that the Hello field, the Dead field, and the ReXmit field display the values that you configured. From operational mode, enter the show ospf interface detail for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3.

•


•


Example: Configuring BFD for OSPF •

BFD for OSPF Overview on page 615

•


BFD for OSPF Overview The Bidirectional Forwarding Detection (BFD) Protocol is a simple hello mechanism that detects failures in a network. BFD works with a wide variety of network environments


615


and topologies. A pair of routing devices exchange BFD packets. Hello packets are sent at a specified, regular interval. A neighbor failure is detected when the routing device stops receiving a reply after a specified interval. The BFD failure detection timers have shorter time limits than the OSPF failure detection mechanisms, providing faster detection. These timers are also adaptive and can be adjusted to be more or less aggressive. For example, the timer can adapt to a higher value if an adjacency fails, or a neighbor can negotiate a higher value than the one configured.

NOTE: BFD is supported for OSPFv3 in Junos OS Release 9.3 and later.

You can configure the following BFD protocol settings: •

detection-time threshold—Detection time threshold. This is a threshold for the

adaptation of the detection time. When the BFD session detection time adapts to a value equal to or greater than the configured threshold, a single trap and a single system log message are sent. •

full-neighbors-only—Full neighbor only adjacency. This provides the ability to establish

BFD sessions only for OSPF neighbors with full neighbor adjacency. The default behavior is to establish BFD sessions for all OSPF neighbors. This setting is available in Junos OS Release 9.5 and later. •

minimum-interval—Minimum transmit and receive interval for failure detection. This

setting configures both the minimum interval at which the local routing device transmits hello packets and the minimum interval at which the routing device expects to receive a reply from the neighbor with which it has established a BFD session. Both intervals are in milliseconds. You can also specify the minimum transmit and receive intervals separately.

616



NOTE: BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD less than 100 ms for Routing Engine-based sessions and 10 ms for distributed BFD sessions can cause undesired BFD flapping. Depending on your network environment, these additional recommendations might apply:

•

•


•

For very large-scale network deployments with a large number of BFD sessions, contact Juniper Networks customer support for more information.

•


minimum-receive-interval—Minimum receive interval for failure detection. This setting

configures only the minimum receive interval, in milliseconds, at which the routing device expects to receive a hello packet from a neighbor with which it has established a BFD session. •

multiplier—Multiplier for hello packets. This setting configures the number of hello

packets that are not received by a neighbor, which causes the originating interface to be declared down. By default, three missed hello packets cause the originating interface to be declared down. •

no-adaptation—Disables BFD adaption. This setting disables BFD sessions from

adapting to changing network conditions. This setting is available in Junos OS Release 9.0 and later.

NOTE: We recommend that you do not disable BFD adaptation unless it is preferable not to have BFD adaptation in your network.

•

transmit-interval minimum-interval—Minimum transmit interval for failure detection.

This setting configures only the minimum transmit interval, in milliseconds, at which the local routing device transmits hello packets to the neighbor with which it has established a BFD session. •

transmit-interval threshold—Transmit interval threshold. This setting configures a

transmit threshold, in milliseconds, that detects the adaptation of the transmit interval. When the BFD session transmit interval adapts to a value greater than the threshold, a single trap and a single system log message are sent. The threshold value must be


617


greater than the minimum transmit interval. If you attempt to commit a configuration with a threshold value less than the minimum transmit interval, the routing device displays an error and does not accept the configuration. •

version—BFD version. This setting configures the BFD version used for detection. You

can explicitly configure BFD version 1, or the routing device can automatically detect the BFD version. By default, the routing device automatically detects the BFD version automatically, which is either 0 or 1. You can also trace BFD operations for troubleshooting purposes.

Example: Configuring BFD for OSPF This example shows how to configure the BFD Protocol for OSPF. •


•


•


•




•


•


•


•


Overview An alternative to adjusting the OSPF hello interval and dead interval settings to increase route convergence is to configure BFD. The BFD Protocol is a simple hello mechanism that detects failures in a network. The BFD failure detection timers have shorter timer limits than the OSPF failure detection mechanisms, thereby providing faster detection. BFD is useful on interfaces that are unable to detect failure quickly, such as Ethernet interfaces. Other interfaces, such as SONET interfaces, already have built-in failure detection. Configuring BFD on those interfaces is unnecessary. You configure BFD on a pair of neighboring OSPF interfaces. Unlike the OSPF hello interval and dead interval settings, you do not have to enable BFD on all interfaces in an OSPF area.

618



In this example, you enable failure detection by including the bfd-liveness-detection statement on the neighbor OSPF interface fe-0/1/0 in area 0.0.0.0 and configure the BFD packet exchange interval to 300 milliseconds, configure 4 as the number of missed hello packets that causes the originating interface to be declared down, and configure BFD sessions only for OSPF neighbors with full neighbor adjacency by including the following settings: •

full-neighbors-only—In Junos OS Release 9.5 and later, configures the BFD Protocol

to establish BFD sessions only for OSPF neighbors with full neighbor adjacency. The default behavior is to establish BFD sessions for all OSPF neighbors. •

minimum-interval—Configures the minimum interval, in milliseconds, at which the local

routing device transmits hello packets as well as the minimum interval at which the routing device expects to receive a reply from the neighbor with which it has established a BFD session. You can configure a number in the range from 1 through 255,000 milliseconds. You can also specify the minimum transmit and receive intervals separately.

NOTE: BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD less than 100 ms for Routing Engine-based sessions and 10 ms for distributed BFD sessions can cause undesired BFD flapping. Depending on your network environment, these additional recommendations might apply:

•

•


•


•


multiplier—Configures the number of hello packets not received by a neighbor that

causes the originating interface to be declared down. By default, three missed hello packets cause the originating interface to be declared down. You can configure a value in the range from 1 through 255.


To quickly configure the BFD protocol for OSPF, copy the following commands, remove any line breaks, and then paste the commands into the CLI.


619


[edit] set protocols ospf area 0.0.0.0 interface fe-0/0/1 bfd-liveness-detection minimum-interval 300 set protocols ospf area 0.0.0.0 interface fe-0/0/1 bfd-liveness-detection multiplier 4 set protocols ospf area 0.0.0.0 interface fe-0/0/1 bfd-liveness-detection full-neighbors-only


To configure the BFD protocol for OSPF on one neighboring interface: 1.




Specify the interface. [edit protocols ospf area 0.0.0.0] user@host# set interface fe-0/0/1

3.

Specify the minimum transmit and receive intervals. [edit protocols ospf area 0.0.0.0 ] user@host# set interface fe-0/0/1 bfd-liveness-detection minimum-interval 300

4.

Configure the number of missed hello packets that cause the originating interface to be declared down. [edit protocols ospf area 0.0.0.0 ] user@host# set interface fe-0/0/1 bfd-liveness-detection multiplier 4

5.

Configure BFD sessions only for OSPF neighbors with full neighbor adjacency. [edit protocols ospf area 0.0.0.0 ] user@host# set interface fe-0/0/1 bfd-liveness-detection full-neighbors-only

6.



Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.0 { interface fe-0/0/1.0 { bfd-liveness-detection {

620



minimum-interval 300; multiplier 4; full-neighbors-only; } } }


Verification Confirm that the configuration is working properly. Verifying the BFD Sessions Purpose

Action


Verify that the OSPF interfaces have active BFD sessions. •

The Address field displays the IP address of the neighbor.

•

The Interface field displays the interface you configured for BFD.

•

The State field displays the state of the neighbor and should show Full to reflect the full neighbor adjacency that you configured.

•

The Transmit Interval field displays the time interval you configured to send BFD packets.

•

The Multiplier field displays the multiplier you configured.

From operational mode, enter the show bfd session detail command.

•


•

BFD Authentication for OSPF Overview on page 621

•

Tracing BFD Protocol Traffic on page 86 in the Junos OS Routing Protocols Configuration Guide

Example: Configuring BFD Authentication for OSPF •

BFD Authentication for OSPF Overview on page 621

•

Configuring BFD Authentication for OSPF on page 623

BFD Authentication for OSPF Overview BFD enables rapid detection of communication failures between adjacent systems. By default, authentication for BFD sessions is disabled. However, when you run BFD over Network Layer protocols, the risk of service attacks can be significant. We strongly recommend using authentication if you are running BFD over multiple hops or through insecure tunnels. Beginning with Junos OS Release 9.6, the Junos OS supports authentication for BFD sessions running over OSPFv2. BFD authentication is not supported on MPLS OAM sessions. BFD authentication is only supported in the domestic image and is not available in the export image.


621


You authenticate BFD sessions by specifying an authentication algorithm and keychain, and then associating that configuration information with a security authentication keychain using the keychain name. The following sections describe the supported authentication algorithms, security keychains, and level of authentication that can be configured: •


•


•




authenticate the BFD session. One or more passwords can be configured. This method is the least secure and should be used only when BFD sessions are not subject to packet interception. •




method works in the same manner as keyed MD5, but the sequence number is updated with every packet. Although more secure than keyed MD5 and simple passwords, this method might take additional time to authenticate the session. •




works in the same manner as keyed SHA, but the sequence number is updated with every packet. Although more secure than keyed SHA and simple passwords, this method might take additional time to authenticate the session.

NOTE: Nonstop active routing (NSR) is not supported with meticulous-keyed-md5 and meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms might go down after a switchover.

622




Strict Versus Loose Authentication By default, strict authentication is enabled and authentication is checked at both ends of each BFD session. Optionally, to smooth migration from nonauthenticated sessions to authenticated sessions, you can configure loose checking. When loose checking is configured, packets are accepted without authentication being checked at each end of the session. This feature is intended for transitional periods only.

Configuring BFD Authentication for OSPF Beginning with Junos OS Release 9.6, you can configure authentication for BFD sessions running over OSPFv2. Routing instances are also supported. The following sections provide instructions for configuring and viewing BFD authentication on OSPF: •


•


Configuring BFD Authentication Parameters Only three steps are needed to configure authentication on a BFD session: 1.

Specify the BFD authentication algorithm for the OSPFv2 protocol.

2. Associate the authentication keychain with the OSPFv2 protocol. 3. Configure the related security authentication keychain.

To configure BFD authentication: 1.

Specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use for BFD authentication on an OSPF route or routing instance. [edit]


623


user@host# set protocols ospf area 0.0.0.1 interface if2-ospf bfd-liveness-detection authentication algorithm keyed-sha-1


2. Specify the keychain to be used to associate BFD sessions on the specified OSPF

route or routing instance with the unique security authentication keychain attributes. This keychain should match the keychain name configured at the [edit security authentication key-chains] hierarchy level. [edit] user@host# set protocols ospf area 0.0.0.1 interface if2-ospf bfd-liveness-detection authentication keychain bfd-ospf



The matching keychain name as specified in Step 2.

•


•

The secret data used to allow access to the session.

•

The time at which the authentication key becomes active, in the format yyyy-mm-dd.hh:mm:ss. [edit security] user@host# authentication-key-chains key-chain bfd-ospf key 53 secret $9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm start-time 2009-06-14.10:00:00


nonauthenticated sessions to authenticated sessions. [edit] user@host> set protocols ospf interface if2-ospf bfd-liveness-detection authentication loose-check 5. (Optional) View your configuration using the show bfd session detail or show bfd

session extensive command. 6. Repeat the steps in this procedure to configure the other end of the BFD session.

624



NOTE: BFD authentication is only supported in the Canada and United States version of the Junos OS image and is not available in the export version.

Viewing Authentication Information for BFD Sessions You can view the existing BFD authentication configuration using the show bfd session detail and show bfd session extensive commands. The following example shows BFD authentication configured for the if2-ospf BGP group. It specifies the keyed SHA-1 authentication algorithm and a keychain name of bfd-ospf. The authentication keychain is configured with two keys. Key 1 contains the secret data “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm” and a start time of June 1, 2009, at 9:46:02 AM PST. Key 2 contains the secret data “$9$a5jiKW9l.reP38ny.TszF2/9” and a start time of June 1, 2009, at 3:29:20 PM PST. [edit protocols ospf] area 0.0.0.1 { interface if2-ospf { bfd-liveness-detection { authentication { algorithm keyed-sha-1; key-chain bfd-ospf; } } } } [edit security] authentication key-chains { key-chain bfd-ospf { key 1 { secret “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm”; start-time “2009-6-1.09:46:02 -0700”; } key 2 { secret “$9$a5jiKW9l.reP38ny.TszF2/9”; start-time “2009-6-1.15:29:20 -0700”; } } }

If you commit these updates to your configuration, you would see output similar to the following. In the output for the show bfd sessions detail command, Authenticate is displayed to indicate that BFD authentication is configured. show bfd sessions detail

user@host# show bfd session detail Detect Transmit Address State Interface Time Interval Multiplier 10.9.1.33 Up so-7/1/0.0 0.600 0.200 3 Client OSPF, TX interval 0.200, RX interval 0.200, multiplier 3, Authenticate Session up time 3d 00:34 Local diagnostic None, remote diagnostic None Remote state Up, version 1 Replicated


625



For more information about the configuration, use the show bfd sessions extensive command. The output for this command provides the keychain name, the authentication algorithm and mode for each client in the session, and the overall BFD authentication configuration status, keychain name, and authentication algorithm and mode. show bfd sessions extensive

user@host# show bfd session extensive Detect Transmit Address State Interface Time Interval Multiplier 10.9.1.33 Up so-7/1/0.0 0.600 0.200 3 Client OSPF, TX interval 0.200, RX interval 0.200, multiplier 3, Authenticate keychain bfd-ospf, algo keyed-md5, mode loose Session up time 3d 00:34 Local diagnostic None, remote diagnostic None Remote state Up, version 1 Replicated Min async interval 0.200, min slow interval 1.000 Adaptive async tx interval 0.200, rx interval 0.200 Local min tx interval 0.200, min rx interval 0.200, multiplier 3 Remote min tx interval 0.100, min rx interval 0.100, multiplier 3 Threshold transmission interval 0.000, Threshold for detection time 0.000 Local discriminator 11, remote discriminator 80 Echo mode disabled/inactive Authentication enabled/active, keychain bfd-ospf, algo keyed-sha-1, mode strict 1 sessions, 1 clients Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps


•


•

BFD for OSPF Overview on page 615

Examples: Configuring Graceful Restart for OSPF •

Graceful Restart for OSPF Overview on page 626

•

Example: Configuring Graceful Restart for OSPF on page 628

•

Example: Configuring the Helper Capability Mode for OSPFv2 Graceful Restart on page 632

•


•

Example: Disabling Strict LSA Checking for OSPF Graceful Restart on page 639

Graceful Restart for OSPF Overview Graceful restart allows a routing device undergoing a restart to inform its adjacent neighbors and peers of its condition. During a graceful restart, the restarting device and its neighbors continue forwarding packets without disrupting network performance. Because neighboring devices assist in the restart (these neighbors are called helper routers), the restarting device can quickly resume full operation without recalculating algorithms.

626



NOTE: On a broadcast link with a single neighbor, when the neighbor initiates an OSPFv3 graceful restart operation, the restart might be terminated at the point when the local routing device assumes the role of a helper. A change in the LSA is considered a topology change, which terminates the neighbor’s restart operation.

Graceful restart is disabled by default. You can either globally enable graceful restart for all routing protocols, or you can enable graceful restart specifically for OSPF. This topic describes the following information: •

Helper Mode for Graceful Restart on page 627

•

Planned and Unplanned Graceful Restart on page 628

Helper Mode for Graceful Restart When a device enabled for OSPF graceful restart restarts, it retains routes learned before the restart in its forwarding table. The device does not allow new OSPF link-state advertisements (LSAs) to update the routing table. This device continues to forward traffic to other OSPF neighbors (or helper routers), and sends only a limited number of LSAs during the restart period. To reestablish OSPF adjacencies with neighbors, the restarting device must send a grace LSA to all neighbors. In response, the helper routers enter helper mode (the ability to assist a neighboring device attempting a graceful restart) and send an acknowledgment back to the restarting device. If there are no topology changes, the helper routers continue to advertise LSAs as if the restarting device had remained in continuous OSPF operation.

NOTE: Helper mode is enabled by default when you start the routing platform, even if graceful restart is not enabled. You can disable helper mode specifically for OSPF.

When the restarting device receives replies from all the helper routers, the restarting device selects routes, updates the forwarding table, and discards the old routes. At this point, full OSPF adjacencies are reestablished and the restarting device receives and processes OSPF LSAs as usual. When the helper routers no longer receive grace LSAs from the restarting device or when the topology of the network changes, the helper routers also resume normal operation. Beginning with Junos OS Release 11.4, you can configure restart signaling-based helper mode for OSPFv2 graceful restart configurations. The Junos OS implementation is based on RFC 4811, OSPF Out-of-Band Link State Database (LSDB) Resynchronization, RFC 4812, OSPF Restart Signaling, and RFC 4813, OSPF Link-Local Signaling. In restart signaling-based helper mode implementations, the restarting device informs its restart status to its neighbors only after the restart is complete. When the restart is complete, the restarting device sends hello messages to its helper routers with the restart signal (RS) bit set in the hello packet header. When a helper router receives a hello packet with the RS bit set in the header, the helper router returns a hello message to the restarting device. The reply


627


hello message from the helper router contains the ResyncState flag and the ResyncTimeout timer that enable the restarting device to keep track of the helper routers that are syncing up with it. When all helpers complete the synchronization, the restarting device exits the restart mode.

NOTE: Restart signaling-based graceful restart helper mode is not supported for OSPFv3 configurations.

Planned and Unplanned Graceful Restart OSPF supports two types of graceful restart: planned and unplanned. During a planned restart, the restarting routing device informs the neighbors before restarting. The neighbors act as if the routing device is still within the network topology, and continue forwarding traffic to the restarting routing device. A grace period is set to specify when the neighbors should consider the restarting routing device as part of the topology. During an unplanned restart, the routing device restarts without warning.

Example: Configuring Graceful Restart for OSPF This example shows how to configure graceful restart specifically for OSPF. •


•


•


•




•


•


•


Overview Graceful restart allows a routing device undergoing a restart to inform its adjacent neighbors and peers of its condition. During a graceful restart, the restarting routing device and its neighbors continue forwarding packets without disrupting network performance. By default, graceful restart is disabled. You can globally enable graceful restart for all routing protocols by including the graceful-restart statement at the [edit routing-options]

628



hierarchy level, or you can enable graceful restart specifically for OSPF by including the graceful-restart statement at the [edit protocols (ospf|ospf3)] hierarchy level. The first example shows how to enable graceful restart and configure the optional settings for the grace period interval. In this example, interfaces fe-1/1/1 and fe-1/1/2 are in OSPF area 0.0.0.0, and you configure those interfaces for graceful restart. The grace period interval for OSPF graceful restart is determined as equal to or less than the sum of the notify-duration time interval and the restart-duration time interval. The grace period is the number of seconds that the routing device’s neighbors continue to advertise the routing device as fully adjacent, regardless of the connection state between the routing device and its neighbors. The notify-duration configures the amount of time (in seconds) the routing device notifies helper routers that it has completed graceful restart by sending purged grace LSAs over all interfaces. By default, the routing device sends grace LSAs for 30 seconds. The range is from 1 through 3600 seconds. The restart-duration configures the amount of time the routing device waits (in seconds) to complete reacquisition of OSPF neighbors from each area. By default, the routing device allows 180 seconds. The range is from 1 through 3600 seconds. The second example shows how to disable graceful restart for OSPF by including the disable statement.

Configuration •

Enabling Graceful Restart for OSPF on page 629

•

Disabling Graceful Restart for OSPF on page 631

Enabling Graceful Restart for OSPF CLI Quick Configuration

To quickly enable graceful restart for OSPF, copy the following commands and paste them into the CLI. [edit] set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4 set interfaces fe-1/1/2 unit 0 family inet address 10.0.0.5 set protocols ospf area 0.0.0.0 interface fe-1/1/1 set protocols ospf area 0.0.0.0 interface fe-1/1/2 set protocols ospf graceful-restart restart-duration 190 set protocols ospf graceful-restart notify-duration 40


To enable graceful restart for OSPF: 1.


NOTE: For OSPFv3, use IPv6 addresses.

[edit] user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4 user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.5


629


2.

Configure OSPF on the interfaces


[edit] user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/1 user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/2 3.

Configure OSPF graceful restart. [edit] user@host# edit protocols ospf graceful-restart

4.

(Optional) Configure the restart duration time. [edit protocols ospf graceful-restart] user@host# set restart-duration 190

5.

(Optional) Configure the notify duration time. [edit protocols ospf graceful-restart] user@host# set notify-duration 40

6.

If you are done configuring the device, commit the configuration. [edit protocols ospf graceful-restart] user@host# commit

Results

Confirm your configuration by entering the show interfaces and show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces fe-1/1/1 { unit 0 { family inet { address 10.0.0.4/32; } } } fe-1/1/2 { unit 0 { family inet { address 10.0.0.5/32; } } } user@host# show protocols ospf graceful-restart { restart-duration 190; notify-duration 40; } area 0.0.0.0 { interface fe-1/1/1.0;

630



interface fe-1/1/2.0; }

To confirm your OSPFv3 configuration, enter the show interfaces and the show protocols ospf3 commands. Disabling Graceful Restart for OSPF CLI Quick Configuration

To quickly disable graceful restart for OSPF, copy the following command and paste it into the CLI. [edit] set protocols ospf graceful-restart disable


To disable graceful restart for OSPF: 1.

Disable graceful restart for only the OSPF Protocol. This command does not affect the global graceful restart configuration setting.


[edit] user@host# set protocols ospf graceful-restart disable 2.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf graceful-restart disable;



Verifying the OSPF Graceful Restart Configuration on page 631

•

Verifying Graceful Restart Status on page 632

Verifying the OSPF Graceful Restart Configuration Purpose

Verify information about your OSPF graceful restart configuration. The Restart field displays the status of graceful restart as either enabled or disabled, the Restart duration field displays the time period for complete reacquisition of OSPF neighbors, and the


631


Restart grace period displays the time period for which the neighbors should consider the restart routing device as part of the topology. Action

From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview command for OSPFv3. Verifying Graceful Restart Status

Purpose

Action

Verify the status of graceful restart. The Restart State field displays Pending if the restart has not completed or Complete if the restart has finished, and the Path selection timeout field indicates the amount of time remaining until graceful restart is declared complete. There is a more detailed Restart State field that displays a list of protocols that have completed graceful restart or have not yet completed graceful restart for the specified routing table. From operational mode, enter the show route instance detail command.

Example: Configuring the Helper Capability Mode for OSPFv2 Graceful Restart This example shows how to disable and reenable the helper mode capability for OSPFv2 graceful restart. •


•


•


•




•


•


•


Overview The OSPF graceful restart helper capability assists a neighboring routing device attempting a graceful restart. By default, the helper capability is globally enabled when you start the routing platform. This means that the helper capability is enabled when you start OSPF, even if graceful restart is not globally enabled or specifically enabled for OSPF. You can further modify your graceful restart configuration to disable the helper capability.

632



Beginning with Junos OS Release 11.4, you can configure restart signaling-based helper mode for OSPFv2 graceful restart configurations. Both the standard and restart signaling-based helper modes are enabled by default. In the first example, interfaces fe-1/1/1 and fe-1/1/2 are in OSPFv2 area 0.0.0.0, and you configure those interfaces for graceful restart. You then disable the standard OSPFv2 graceful restart helper capability by including the helper-disable standard statement. This configuration is useful if you have an environment that contains other vendor equipment that is configured for restart signaling-based graceful restart.

NOTE: The helper-disable statement and the no-strict-lsa-checking statement cannot be configured at the same time. If you attempt to configure both statements at the same time, the routing device displays a warning message when you enter the show protocols ospf command.

The second example shows how to reenable the standard OSPFv2 restart helper capability that you disabled in the first example.

Configuration •

Disabling Helper Mode for OSPFv2 on page 633

•

Reenabling Helper Mode for OSPFv2 on page 634

Disabling Helper Mode for OSPFv2 CLI Quick Configuration

To quickly enable graceful restart for OSPFv2 with helper mode disabled, copy the following commands and paste them into the CLI. [edit] set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4 set interfaces fe-1/1/2 unit 0 family inet address 10.0.0.5 set protocols ospf area 0.0.0.0 interface fe-1/1/1 set protocols ospf area 0.0.0.0 interface fe-1/1/2 set protocols ospf graceful-restart helper-disable standard


To enable graceful restart for OSPFv2 with helper mode disabled: 1.

Configure the interfaces. [edit] user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4 user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.5

2.

Configure OSPFv2 on the interfaces [edit] user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/1 user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/2

3.

Disable the OSPFv2 graceful restart helper capability. If you disable the OSPFv2 graceful restart helper capability, you cannot disable strict LSA checking. [edit]


633


user@host# set protocols ospf graceful-restart helper-disable standard 4.


Results

Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces fe-1/1/1 { unit 0 { family inet { address 10.0.0.4/32; } } } fe-1/1/2 { unit 0 { family inet { address 10.0.0.5/32; } } } user@host# show protocols ospf graceful-restart { helper-disable { standard; } } area 0.0.0.0 { interface fe-1/1/1.0; interface fe-1/1/2.0; }

Reenabling Helper Mode for OSPFv2 CLI Quick Configuration

To quickly reenable standard helper-mode for OSPFv2, copy the following command and paste it into the CLI. [edit] delete protocols ospf graceful-restart helper-disable standard

NOTE: To reenable restart signaling-based helper mode, include the restart-signaling statement. To reenable both standard and restart signaling-based helper mode, include the both statement.


To reenable standard helper mode for OSPFv2: 1.

634

Delete the standard helper-mode statement from the OSPFv2 configuration.



[edit] user@host# delete protocols ospf graceful-restart helper-disable standard 2.


Results

After you reenable standard helper mode, the show protocols ospf command no longer displays the graceful restart configuration.


Verifying the OSPFv2 Graceful Restart Configuration on page 635

•


Verifying the OSPFv2 Graceful Restart Configuration Purpose

Action

Verify information about your OSPFv2 graceful restart configuration. The Restart field displays the status of graceful restart as either enabled or disabled, the Graceful restart helper mode field displays the status of the standard helper mode capability as enabled or disabled, and the Restart-signaling helper mode field displays the status of the restart signaling-based helper mode as enabled or disabled. By default, both standard and restart signaling-based helper modes are enabled. From operational mode, enter the show ospf overview command. Verifying Graceful Restart Status

Purpose

Action

Verify the status of graceful restart. The Restart State field displays Pending if the restart has not completed, or Complete if the restart has finished. The Path selection timeout field indicates the amount of time remaining until graceful restart is declared complete. There is a more detailed Restart State field that displays a list of protocols that have completed graceful restart or have not yet completed graceful restart for the specified routing table. From operational mode, enter the show route instance detail command.

Example: Configuring the Helper Capability Mode for OSPFv3 Graceful Restart This example shows how to disable and reenable the helper mode capability for OSPFv3 graceful restart. •


•


•


•



635




•


•


•


Overview The OSPF graceful restart helper capability assists a neighboring routing device attempting a graceful restart. By default, the helper capability is globally enabled when you start the routing platform. This means that the helper capability is enabled when you start OSPF, even if graceful restart is not globally enabled or specifically enabled for OSPF. You can further modify your graceful restart configuration to disable the helper capability. In the first example, interfaces fe-1/1/1 and fe-1/1/2 are in OSPFv3 area 0.0.0.0, and you configure those interfaces for graceful restart. You then disable the OSPFv3 graceful restart helper capability by including the helper-disable statement.


The second example shows how to reenable the OSPFv3 restart helper capability that you disabled in the first example.

Configuration •

Disabling Helper Mode for OSPFv3 on page 636

•

Reenabling Helper Mode for OSPFv3 on page 638

Disabling Helper Mode for OSPFv3 CLI Quick Configuration

To quickly enable graceful restart for OSPFv3 with helper mode disabled, copy the following commands and paste them into the CLI. [edit] set interfaces fe-1/1/1 unit 0 family inet6 address 2002:0a00:0004:: set interfaces fe-1/1/2 unit 0 family inet6 address 2002:0a00:0005:: set protocols ospf3 area 0.0.0.0 interface fe-1/1/1 set protocols ospf3 area 0.0.0.0 interface fe-1/1/2 set protocols ospf3 graceful-restart helper-disable

636




To enable graceful restart for OSPFv3 with helper mode disabled: 1.

Configure the interfaces. [edit] user@host# set interfaces fe-1/1/1 unit 0 family inet6 address 2002:0a00:0004:: user@host# set interfaces fe-1/1/1 unit 0 family inet address 2002:0a00:0005::

2.

Configure OSPFv3 on the interfaces [edit] user@host# set protocols ospf3 area 0.0.0.0 interface fe-1/1/1 user@host# set protocols ospf3 area 0.0.0.0 interface fe-1/1/2

3.

Disable the OSPFv3 graceful restart helper capability. If you disable the OSPFv3 graceful restart helper capability, you cannot disable strict LSA checking. [edit] user@host# set protocols ospf3 graceful-restart helper-disable

4.


Results

Confirm your configuration by entering the show interfaces and the show protocols ospf3 commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces fe-1/1/1 { unit 0 { family inet6 { address 2002:0a00:0004::/128; } } } fe-1/1/2 { unit 0 { family inet6 { address 2002:0a00:0005::/128; } } } user@host# show protocols ospf3 graceful-restart { helper-disable; } area 0.0.0.0 { interface fe-1/1/1.0; interface fe-1/1/2.0; }


637


Reenabling Helper Mode for OSPFv3 CLI Quick Configuration

To quickly reenable helper-mode for OSPFv3, copy the following command and paste it into the CLI. [edit] delete protocols ospf3 graceful-restart helper-disable


To reenable helper mode for OSPFv3: 1.

Delete the standard helper-mode statement from the OSPFv3 configuration. [edit] user@host# delete protocols ospf3 graceful-restart helper-disable

2.


Results

After you reenable standard helper mode, the show protocols ospfs command no longer displays the graceful restart configuration.


Verifying the OSPFv3 Graceful Restart Configuration on page 638

•


Verifying the OSPFv3 Graceful Restart Configuration Purpose

Action

Verify information about your OSPFv3 graceful restart configuration. The Restart field displays the status of graceful restart as either enabled or disabled, and the Helper mode field displays the status of the helper mode capability as either enabled or disabled. From operational mode, enter the show ospf3 overview command. Verifying Graceful Restart Status

Purpose

Action

638




Example: Disabling Strict LSA Checking for OSPF Graceful Restart This example shows how to disable strict link-state advertisement (LSA) checking for OSPF graceful restart. •


•


•


•




•


•


•


Overview You can disable strict LSA checking to prevent the termination of graceful restart by a helping router. You might configure this option for interoperability with other vendor devices. The OSPF graceful restart helper capability must be enabled if you disable strict LSA checking. By default, LSA checking is enabled. In this example, interfaces fe-1/1/1 and fe-1/1/2 are in OSPF area 0.0.0.0, and you configure those interfaces for graceful restart. You then disable strict LSA checking by including the no-strict-lsa-checking statement.



To quickly enable graceful restart for OSPF with strict LSA checking disabled, copy the following commands and paste them into the CLI. [edit] set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4 set interfaces fe-1/1/2 unit 0 family inet address 10.0.0.5


639


set protocols ospf area 0.0.0.0 interface fe-1/1/1 set protocols ospf area 0.0.0.0 interface fe-1/1/2 set protocols ospf graceful-restart no-strict-lsa-checking


To enable graceful restart for OSPF with strict LSA checking disabled: 1.



[edit] user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4 user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.5 2.

Configure OSPF on the interfaces



Disable strict LSA checking. If you disable the strict LSA checking, OSPF graceful restart helper capability must be enabled (which is the default behavior). [edit] user@host# set protocols ospf graceful-restart no-strict-lsa-checking

4.

If you are done configuring the device, commit the configuration. [edit ] user@host# commit

Results

Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces fe-1/1/1 { unit 0 { family inet { address 10.0.0.4/32; } } } fe-1/1/2 { unit 0 { family inet { address 10.0.0.5/32;

640



} } } user@host# show protocols ospf graceful-restart { no-strict-lsa-checking; } area 0.0.0.0 { interface fe-1/1/1.0; interface fe-1/1/2.0; }

To confirm your OSPFv3 configuration, enter the show interfaces and the show protocols ospf3 commands.


Verifying the OSPF Graceful Restart Configuration on page 641

•


Verifying the OSPF Graceful Restart Configuration Purpose

Action

Verify information about your OSPF graceful restart configuration. The Restart field displays the status of graceful restart as either enabled or disabled. From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview command for OSPFv3. Verifying Graceful Restart Status

Purpose

Action



•


•


•

Graceful Restart Concepts in the Junos OS High Availability Configuration Guide

Examples: Configuring Loop-Free Alternate Routes for OSPF •

Loop-Free Alternate Routes for OSPF Overview on page 642

•

Configuring Link Protection for OSPF on page 643


641


•

Configuring Node-Link Protection for OSPF on page 644

•

Excluding an OSPF Interface as a Backup for a Protected Interface on page 645

•

Configuring Backup SPF Options for Protected OSPF Interfaces on page 645

•

Configuring RSVP Label-Switched Paths as Backup Paths for OSPF on page 647

Loop-Free Alternate Routes for OSPF Overview Support for OSPF loop-free alternate routes essentially adds IP fast-reroute capability for OSPF. Junos OS precomputes loop-free backup routes for all OSPF routes. These backup routes are preinstalled in the Packet Forwarding Engine, which performs a local repair and implements the backup path when the link for a primary next hop for a particular route is no longer available. With local repair, the Packet Forwarding Engine can correct a path failure before it receives precomputed paths from the Routing Engine. Local repair reduces the amount of time needed to reroute traffic to less than 50 milliseconds. In contrast, global repair can take up to 800 milliseconds to compute a new route. Local repair enables traffic to continue to be routed using a backup path until global repair is able to calculate a new route. A loop-free path is one that does not forward traffic back through the routing device to reach a given destination. That is, a neighbor whose shortest path first to the destination traverses the routing device that is not used as a backup route to that destination. To determine loop-free alternate paths for OSPF routes, Junos OS runs shortest-path-first (SPF) calculations on each one-hop neighbor. You can enable support for alternate loop-free routes on any OSPF interface. Because it is common practice to enable LDP on an interface for which OSPF is already enabled, this feature also provides support for LDP label-switched paths (LSPs.)

NOTE: If you enable support for alternate loop-free routes on an interface configured for both LDP and OSPF, you can use the traceroute command to trace the active path to the primary next hop.

The level of backup coverage available through OSPF routes depends on the actual network topology and is typically less than 100 percent for all destinations on any given routing device. You can extend backup coverage to include RSVP LSP paths. Junos OS provides two mechanisms for route redundancy for OSPF through alternate loop-free routes:

642

•

Link protection—Offers per-link traffic protection. Use link protection when you assume that only a single link might become unavailable but that the neighboring node on the primary path would still be available through another interface.

•

Node-link protection—Establishes an alternate path through a different routing device altogether. Use node-link protection when you assume that access to a node is lost when a link is no longer available. As a result, Junos OS calculates a backup path that avoids the primary next-hop routing device.



When you enable link protection or node-link protection on an OSPF interface, Junos OS creates an alternate path to the primary next hop for all destination routes that traverse a protected interface.

Configuring Link Protection for OSPF You can configure link protection for any interface for which OSPF is enabled. When you enable link protection, Junos OS creates an alternate path to the primary next hop for all destination routes that traverse a protected interface. Use link protection when you assume that only a single link might become unavailable but that the neighboring node would still be available through another interface. Link protection is supported on: •


•

OSPFv3 unicast realms

•

OSPFv2 unicast topologies, except for multicast topologies

•

All routing instances supported by OSPFv2 and OSPFv3

•

Logical systems

To configure link protection for an OSPF interface: •

Include the link-protection statement at the [edit protocols (ospf | ospf3) area area-id interface interface-name] hierarchy level.

BEST PRACTICE: When you configure link protection for OSPF, you must also configure a per-packet load-balancing routing policy to ensure that the routing protocol process installs all the next hops for a given route in the routing table.

In the following example, the OSPF interface so-0/0/0.0 in area 0.0.0.0 is configured for link protection. If a link for a destination route that traverses this interface becomes unavailable, Junos OS creates a loop-free backup path through another interface on the neighboring node, thus avoiding the link that is no longer available. [edit] protocols { ospf { area 0.0.0.0 { interface so-0/0/0.0 { link-protection; } } } }


643


Configuring Node-Link Protection for OSPF You can configure node-link protection on any interface for which OSPF is enabled. Node-link protection establishes an alternative path through a different routing device altogether for all destination routes that traverse a protected interface. Node-link protection assumes that the entire routing device, or node, has failed. Junos OS therefore calculates a backup path that avoids the primary next-hop routing device. Node-link protection is supported on: •


•

OSPFv3 unicast realms

•

OSPFv2 unicast topologies

•


•

Logical systems

To configure node-link protection for an OSPF interface: •

Include the node-link-protection statement at the [edit protocols (ospf | ospf3) area area-id interface interface-name] hierarchy level.

BEST PRACTICE: You must also configure a per-packet load-balancing routing policy to ensure that the routing protocol process installs all the next hops for a given route in the routing table.

In the following example, the OSPF interface so-0/0/0.0 in area 0.0.0.0 is configured for node-link protection. If a link for a destination route that traverses this interface becomes unavailable, Junos OS creates a loop-free backup path through a different routing device altogether, thus avoiding the primary next-hop routing device. [edit] protocols { ospf { area 0.0.0.0 { interface so-0/0/0.0 { node-link-protection; } } } }

644



Excluding an OSPF Interface as a Backup for a Protected Interface By default, all OSPF interfaces that belong to the default instance or to a specific routing instance are eligible as a backup interface for interfaces configured with link-protection or node-link protection. You can specify that any OSPF interface be excluded from functioning as a backup interface to protected interfaces. To exclude an OSPF interface as a backup interface for a protected interface: •

Include the no-eligible-backup statement at the [edit protocols (ospf | ospf3) area area-id interface interface-name] hierarchy level.

In the following example, interface so-0/0/0.0 has been configured to prohibit backup traffic for traffic destined for a protected interface. This means that if a neighboring next-hop path or node for a protected interface fails, interface so-0/0/0.0 cannot be used to transmit traffic to a backup path. [edit] protocols { ospf { area 0.0.0.0 { interface so-0/0/0.0 { no-eligible-backup; } } } }

Configuring Backup SPF Options for Protected OSPF Interfaces By default, if at least one OSPF interface is configured for link-protection or node-link protection, Junos OS calculates backup next hops for all the topologies in an OSPF instance. You can configure the following backup shortest-path-first (SPF) options to override the default behavior: •

Disable the calculation of backup next hops for an OSPF instance or a specific topology in an instance.

•

Prevent the installation of backup next hops in the routing table or the forwarding table for an OSPF instance or a specific topology in an instance.

•

Limit the calculation of backup next hops to a subset of paths as defined in RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates.

You can disable the backup SPF algorithm for an OSPF instance or specific topology in an instance. Doing so prevents the calculation of backup next hops for that OSPF instance or topology.


645


To disable the calculation of backup next hops for an OSPF instance or topology: •

Include the disable statement at the [edit protocols (ospf | ospf3) backup-spf-options] or [edit protocols ospf backup-spf-options topology topology-name] hierarchy level.

In the following example, the calculation of backup next hops is disabled for the OSPF topology voice: [edit] protocols { ospf { topology voice { backup-spf-options { disable; } } } }

You can configure the routing device to prevent the installation of backup next hops in the routing table or the forwarding table for an OSPF instance, or a specific topology in an OSPF instance. The SPF algorithm continues to calculate backup next hops, but they are not installed. To prevent the routing device from installing backup next hops in the routing table or the forwarding table: •

Include the no-install statement at the [edit protocols (ospf | ospf3) backup-spf-options] or the [edit protocols ospf topology topology-name] hierarchy level.

In the following example, backup next hops for the OSPF topology voice are not installed in the routing table or forwarding table. Any calculated backup next hops for other OSPF instances or topologies continue to be installed. [edit] protocols { ospf { topology voice { backup-spf-options { no-install; } } } }

You can limit the calculation of backup next hops to downstream paths, as defined in RFC 5286. You can specify for Junos OS to use only downstream paths as backup next hops for protected interfaces for an OSPF instance or a specific topology in an OSPF instance. In a downstream path, the distance from the backup neighbor to the destination must be smaller than the distance from the calculating routing device to the destination. Using only downstream paths as loop-free alternate paths for protected interfaces ensures that these paths do not result in microloops. However, you might experience less than optimal backup coverage for your network.

646



To limit the calculation of backup next hops to downstream paths: •

Include the downstream-paths-only statement at the [edit protocols (ospf | ospf3) backup-spf-options] or [edit protocols ospf backup-spf-options topology topology-name] hierarchy level.

In the following example, only downstream paths are calculated as backup next hops for the topology voice: [edit] protocols { ospf { topology voice { backup-spf-options { downstream-paths-only; } } } }

Configuring RSVP Label-Switched Paths as Backup Paths for OSPF When configuring an OSPF interface for link protection or node-link protection, relying on the shortest-path-first (SPF) calculation of backup paths for one-hop neighbors might result in less than 100 percent backup coverage for a specific network topology. You can enhance coverage of OSPF and LDP label-switched-paths (LSPs) by configuring RSVP LSPs as backup paths. When configuring an LSP, you must specify the IP address of the egress router.

NOTE: RSVP LSPs can be used as backup paths only for the default topology for OSPFv2 and not for a configured topology. Additionally, RSVP LSP cannot be used a backup paths for non-default instances for OSPFv2 or OSPFv3.

To configure a specific RSVP LSP as a backup path: 1.

Include the backup statement at the [edit protocols mpls labeled-switched-path lsp-name] hierarchy level.

2. Specify the address of the egress router by including the to ip-address statement at

the [edit protocols mpls label-switched-path] hierarchy level. In the following example, the RSVP LSP f-to-g is configured as a backup LSP for protected OSPF interfaces. The egress router is configured with the IP address 192.168.1.4. [edit] protocols { mpls { label-switched-path f-to-g { to 192.168.1.4; backup; } }


647


}


•


Examples: Configuring OSPF Traffic Engineering •

OSPF Support for Traffic Engineering on page 648

•

Example: Enabling OSPF Traffic Engineering Support on page 650

•

Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface on page 654

OSPF Support for Traffic Engineering Traffic engineering allows you to control the path that data packets follow, bypassing the standard routing model, which uses routing tables. Traffic engineering moves flows from congested links to alternate links that would not be selected by the automatically computed destination-based shortest path. To help provide traffic engineering and MPLS with information about network topology and loading, extensions have been added to the Junos OS implementation of OSPF. When traffic engineering is enabled on the routing device, you can enable OSPF traffic engineering support. When you enable traffic engineering for OSPF, the shortest-path-first (SPF) algorithm takes into account the various label-switched paths (LSPs) configured under MPLS and configures OSPF to generate opaque link-state advertisements (LSAs) that carry traffic engineering parameters. The parameters are used to populate the traffic engineering database. The traffic engineering database is used exclusively for calculating explicit paths for the placement of LSPs across the physical topology. The Constrained Shortest Path First (CSPF) algorithm uses the traffic engineering database to compute the paths that MPLS LSPs take. RSVP uses this path information to set up LSPs and to reserve bandwidth for them. By default, traffic engineering support is disabled. To enable traffic engineering, include the traffic-engineering statement. You can also configure the following OSPF traffic engineering extensions: •

advertise-unnumbered-interfaces—(OSPFv2 only) Advertises the link-local identifier

in the link-local traffic engineering LSA packet. You do not need to include this statement if RSVP is able to signal unnumbered interfaces as defined in RFC 3477, Signalling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE). •

credibility-protocol-preference—(OSPFv2 only) Assigns a credibility value to OSPF

routes in the traffic engineering database. By default, Junos OS prefers IS-IS routes in the traffic engineering database over other interior gateway protocol (IGP) routes even if the routes of another IGP are configured with a lower, that is, more preferred, preference value. The traffic engineering database assigns a credibility value to each IGP and prefers the routes of the IGP with the highest credibility value. In Junos OS Release 9.4 and later, you can configure OSPF to take protocol preference into account to determine the traffic engineering database credibility value. When protocol

648



preference is used to determine the credibility value, IS-IS routes are not automatically preferred by the traffic engineering database, depending on your configuration. •

ignore-lsp-metrics—Ignores RSVP LSP metrics in OSPF traffic engineering shortcut

calculations or when you configure LDP over RSVP LSPs. This option avoids mutual dependency between OSPF and RSVP, eliminating the time period when the RSVP metric used for tunneling traffic is not up to date. In addition, If you are using RSVP for traffic engineering, you can run LDP simultaneously to eliminate the distribution of external routes in the core. The LSPs established by LDP are tunneled through the LSPs established by RSVP. LDP effectively treats the traffic-engineered LSPs as single hops. •

multicast-rpf-routes—(OSPFv2 only) Installs unicast IPv4 routes (not LSPs) in the

multicast routing table (inet.2) for multicast reverse-path forwarding (RPF) checks. The inet.2 routing table consists of unicast routes used for multicast RPF lookup. RPF is an antispoofing mechanism used to check if the packet is coming in on an interface that is also sending data back to the packet source. •

no-topology—(OSPFv2 only) To disable the dissemination of link-state topology

information. If disabled, traffic engineering topology information is no longer distributed within the OSPF area. •

shortcuts—Configures IGP shortcuts, which allows OSPF to use an LSP as the next

hop as if it were a logical interface from the ingress routing device to the egress routing device. The address specified in the to statement at the [edit protocols mpls label-switched-path lsp-path-name] hierarchy level on the ingress routing device must match the router ID of the egress routing device for the LSP to function as a direct link to the egress routing device and to be used as input to the OSPF SPF calculations. When used in this way, LSPs are no different from Asynchronous Transfer Mode (ATM) and Frame Relay virtual circuits (VCs), except that LSPS carry only IPv4 traffic. OSPFv2 installs the prefix for IPv4 routes in the inet.0 routing table, and the LSPs are installed by default in the inet.3 routing table. OSPFv3 LSPs used for shortcuts continue to be signaled using IPv4. However, by default, shortcut IPv6 routes calculated through OSPFv3 are added to the inet6.3 routing table. The default behavior is for BGP only to use LSPs in its calculations. If you configure MPLS so that both BGP and IGPs use LSPs for forwarding traffic, IPv6 shortcut routes calculated through OSPFv3 are added to the inet6.0 routing table.

NOTE: Whenever possible, use OSPF IGP shortcuts instead of traffic engineering shortcuts.

•

lsp-metric-info-summary—Advertises the LSP metric in summary LSAs to treat the

LSP as a link. This configuration allows other routing devices in the network to use this LSP. To accomplish this, you need to configure MPLS and OSPF traffic engineering to advertise the LSP metric in summary LSAs. When you enable traffic engineering on the routing device, you can also configure an OSPF metric that is used exclusively for traffic engineering. The traffic engineering metric


649


is used for information injected into the traffic engineering database. Its value does not affect normal OSPF forwarding.

Example: Enabling OSPF Traffic Engineering Support This example shows how to enable OSPF traffic engineering support to advertise the label-switched path (LSP) metric in summary link-state advertisements (LSAs). •


•


•


•




•

Configure BGP per your network requirements. See the Junos OS Routing Protocols Configuration Guide

•

Configure MPLS per your network requirements. See the Junos OS MPLS Applications Configuration Guide.

Overview You can configure OSPF to treat an LSP as a link and have other routing devices in the network use this LSP. To accomplish this, you configure MPLS and OSPF traffic engineering to advertise the LSP metric in summary LSAs. In this example, there are four routing devices in area 0.0.0.0, and you want OSPF to treat the LSP named R1-to-R4 that goes from the ingress Device R1 to the egress Device R4 as a link. For OSPF, you enable traffic engineering on all four routing devices in the area by including the traffic-engineering statement. This configuration ensures that the shortest-path-first (SPF) algorithm takes into account the LSPs configured under MPLS and configures OSPF to generate LSAs that carry traffic engineering parameters. You further ensure that OSPF uses the MPLS LSP as the next hop and advertises the LSP metric in summary LSAs, by including the optional shortcuts lsp-metric-into-summary statement on the ingress Device R1. For MPLS, you enable traffic engineering so that MPLS performs traffic engineering on both BGP and IGP destinations by including the traffic-engineering bgp-igp statement, and you include the LSP named R1-to-R4 by including the label-switched-path lsp-path-name to address statement on the ingress Device R1. The address specified in the to statement on the ingress Device R1 must match the router ID of the egress Device R4 for the LSP to function as a direct link to the egress routing device and to be used as input to the OSPF SPF calculations. In this example, the router ID of the egress Device R4 is 10.0.0.4.

650



Configuration The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. CLI Quick Configuration

To quickly enable OSPF traffic engineering support to advertise the LSP metric in summary LSAs, copy the following commands and paste them into the CLI. Configuration on R1: [edit] set routing-options router-id 10.0.0.1 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf traffic-engineering shortcuts lsp-metric-into-summary set protocols mpls traffic-engineering bgp-igp set protocols mpls label-switched-path R1-to-R4 to 10.0.0.4

Configuration on R2: [edit] set routing-options router-id 10.0.0.2 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf traffic-engineering




To enable OSPF traffic engineering support to advertise LSP metrics in summary LSAs: 1.

Configure the router ID. [edit] user@R1# set routing-options router-id 10.0.0.1 [edit] user@R2# set routing-options router-id 10.0.0.2 [edit] user@R3# set routing-options router-id 10.0.0.3 [edit] user@R4# set routing-options router-id 10.0.0.4


651


2.

Configure the OSPF area and add the interfaces.


[edit] user@R1# set protocols ospf area 0.0.0.0 interface all user@R1# set protocols ospf area 0.0.0.0 interface fxp0.0 disable [edit] user@R2# set protocols ospf area 0.0.0.0 interface all user@R2# set protocols ospf area 0.0.0.0 interface fxp0.0 disable [edit] user@R3# set protocols ospf area 0.0.0.0 interface all user@R3# set protocols ospf area 0.0.0.0 interface fxp0.0 disable [edit] user@R4# set protocols ospf area 0.0.0.0 interface all user@R4# set protocols ospf area 0.0.0.0 interface fxp0.0 disable 3.

Enable OSPF traffic engineering. [edit] user@R1 set protocols ospf traffic-engineering shortcuts lsp-metric-into-summary [edit] user@R2 set protocols ospf traffic-engineering [edit] user@R3 set protocols ospf traffic-engineering [edit] user@R4 set protocols ospf traffic-engineering

4.

On Device R1, configure MPLS traffic engineering. [edit ] user@R1 set protocol mpls traffic-engineering bgp-igp user@R1 set protocols mpls label-switched-path R1-to-R4 to 10.0.0.4

5.


Results

Confirm your configuration by entering the show routing-options, show protocols ospf, and show protocols mpls commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Output for R1: user@host# show routing-options router-id 10.0.0.1; user@host# show protocols ospf traffic-engineering { shortcuts lsp-metric-into-summary;

652



} area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } user@host# show protocols mpls traffic-engineering bgp-igp; label-switched-path R1-to-R4 { to 10.0.0.4; }

Output for R2: user@host# show routing-options router-id 10.0.0.2; user@host# show protocols ospf traffic-engineering; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } }



To confirm your OSPFv3 configuration, enter the show routing-options, show protocols ospf3, and show protocols mpls commands.


653



Verifying the Traffic Engineering Capability for OSPF on page 654

•

Verifying OSPF Entries in the Traffic Engineering Database on page 654

•

Verifying That the Traffic Engineering Database Is Learning Node Information from OSPF on page 654

Verifying the Traffic Engineering Capability for OSPF Purpose

Verify that traffic engineering has been enabled for OSPF. By default, traffic engineering is disabled.

Action

From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview for OSPFv3. Verifying OSPF Entries in the Traffic Engineering Database

Purpose

Action

Verify the OSPF information in the traffic engineering database. The Protocol field displays OSPF and the area from which the information was learned. From operational mode, enter the show ted database command. Verifying That the Traffic Engineering Database Is Learning Node Information from OSPF

Purpose

Action

Verify that OSPF is reporting node information. The Protocol name field displays OSPF and the area from which the information was learned. From operational mode, enter the show ted protocol command.

Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface This example shows how to configure the OSPF metric value used for traffic engineering. •


•


•


•



654

•


•

Configure OSPF for traffic engineering. See “Example: Enabling OSPF Traffic Engineering Support” on page 650



Overview You can configure an OSPF metric that is used exclusively for traffic engineering. To modify the default value of the traffic engineering metric, include the te-metric statement. The OSPF traffic engineering metric does not affect normal OSPF forwarding. By default, the traffic engineering metric is the same value as the OSPF metric. The range is 1 through 65,535. In this example, you configure the OSPF traffic engineering metric on OSPF interface fe-0/1/1 in area 0.0.0.0.


To quickly configure the OSPF traffic engineering metric for a specific interface, copy the following command and paste it into the CLI. [edit] set protocols ospf area 0.0.0.0 interface fe-0/1/1 te-metric 10


To configure an OSPF traffic engineering metric for a specific interface used only for traffic engineering: 1.




Configure the traffic engineering metric of the OSPF network segments. [edit protocols ospf area 0.0.0.0] user@host set interface fe-0/1/1 te-metric 10

3.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.0 { interface fe-0/1/1.0 { te-metric 10; } }



655


Verification Confirm that the configuration is working properly. Verifying the Configured Traffic Engineering Metric Purpose

Action


Verify the traffic engineering metric value. Confirm that Metric field displays the configured traffic engineering metric. From operational mode, enter the show ted database extensive command.

•


•


Example: Configuring OSPF Passive Traffic Engineering Mode •

OSPF Passive Traffic Engineering Mode on page 656

•


OSPF Passive Traffic Engineering Mode Ordinarily, interior routing protocols such as OSPF are not run on links between autonomous systems. However, for inter-AS traffic engineering to function properly, information about the inter-AS link—in particular, the address on the remote interface—must be made available inside the autonomous system (AS). This information is not normally included either in the external BGP (EBGP) reachability messages or in the OSPF routing advertisements. To flood this link address information within the AS and make it available for traffic engineering calculations, you must configure OSPF passive mode for traffic engineering on each inter-AS interface. You must also supply the remote address for OSPF to distribute and include it in the traffic engineering database. OSPF traffic engineering mode allows MPLS label-switched paths (LSPs) to dynamically discover OSPF AS boundary routers and to allow routers to establish a traffic engineering LSP across multiple autonomous systems.

Example: Configuring OSPF Passive Traffic Engineering Mode This example shows how to configure OSPF passive mode for traffic engineering on an inter-AS interface. The AS boundary router link between the EBGP peers must be a directly connected link and must be configured as a passive traffic engineering link.

656

•


•


•


•






•

Configure BGP per your network requirements. See the Junos OS Routing Protocols Configuration Guide.

•

Configure the LSP per your network requirements. See the Junos OS MPLS Applications Configuration Guide.

•


•


•


•


Overview You can configure OSPF passive mode for traffic engineering on an inter-AS interface. The address used for the remote node of the OSPF passive traffic engineering link must be the same as the address used for the EBGP link. In this example, you configure interface so-1/1/0 in area 0.0.0.1 as the inter-AS link to distribute traffic engineering information with OSPF within the AS and include the following settings: •

passive—Advertises the direct interface addresses on an interface without actually

running OSPF on that interface. A passive interface is one for which the address information is advertised as an internal route in OSPF, but on which the protocol does not run. •

traffic-engineering—Configures an interface in OSPF passive traffic-engineering mode

to enable dynamic discovery of OSPF AS boundary routers. By default, OSPF passive traffic-engineering mode is disabled. •

remote-node-id—Specifies the IP address at the far end of the inter-AS link. In this

example, the remote IP address is 192.168.207.2.

Configuration To quickly configure OSPF passive mode for traffic engineering, copy the following command, remove any line breaks, and paste it into the CLI. [edit] set protocols ospf area 0.0.0.1 interface so-1/1/0 passive traffic-engineering remote-node-id 192.168.207.2


657



To configure OSPF passive traffic engineering mode: 1.



[edit] user@host# set protocols ospf area 0.0.0.1 2.

Configure interface so-1/1/0 as a passive interface configured for traffic engineering, and specify the IP address at the far end of the inter-AS link. [edit protocols ospf area 0.0.0.1] user@host# set interface so-1/1/0 passive traffic-engineering remote-node-id 192.168.207.2

3.


Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf area 0.0.0.1 { interface so-1/1/0.0 { passive { traffic-engineering { remote-node-id 192.168.207.2; } } } }


Verification Confirm that the configuration is working properly. Verifying the Status of OSPF Interfaces

658

Purpose

Verify the status of OSPF interfaces. If the interface is passive, the Adj count field is 0 because no adjacencies have been formed. Next to this field, you might also see the word Passive.

Action





•


•


•


Example: Advertising Label-Switched Paths into OSPFv2 •

Advertising Label-Switched Paths into OSPFv2 on page 659

•


Advertising Label-Switched Paths into OSPFv2 One main reason to configure label-switched paths (LSPs) in your network is to control the shortest path between two points on the network. You can advertise LSPs into OSPFv2 as point-to-point links so that all participating routing devices can take the LSP into account when performing SPF calculations. The advertisement contains a local address (the from address of the LSP), a remote address (the to address of the LSP), and a metric with the following precedence: 1.

Use the LSP metric defined under OSPFv2.

2. Use the LSP metric configured for the label-switched path under MPLS. 3. If you do not configure any of the above, use the default OSPFv2 metric of 1.

NOTE: If you want an LSP that is announced into OSPFv2 to be used in SPF calculations, there must be a reverse link (that is, a link from the tail end of the LSP to the head end). You can accomplish this by configuring an LSP in the reverse direction and also announcing it in OSPFv2.

Example: Advertising Label-Switched Paths into OSPFv2 This example shows how to advertise LSPs into OSPFv2. •


•


•


•


Requirements Before you begin, configure the device interfaces. See the Junos OS Network Interfaces Configuration Guide.

Overview To advertise an LSP into OSPFv2, you define the LSP and configure OSPFv2 to route traffic using the LSP. By doing this, you can use the LSP to control the shortest path between two points on the network. You might choose to do this if you want to have


659


OSPF traffic routed along the LSP instead of having OSPF use the default best-effort routing. In this example, you configure the following to advertise an LSP into OSPFv2: •

BGP For all routing devices, configure the local AS number 65000 and define the IBGP group that recognizes the specified BGP systems as peers. All members are internal to the local AS, so you configure an internal group with a full list of peers. You also include the peer AS group, which is the same as the local AS number that you configure.

•

MPLS For all routing devices, configure the protocol family on each transit logical interface and enable MPLS on all interfaces, except for the management interface (fxp0.0). Specify the mpls protocol family type.

•

RSVP For all routing devices, enable RSVP on all interfaces, except for the management interface (fxp0.0). You enable RSVP on the devices in this network to ensure that the interfaces can signal the LSP.

•

OSPFv2 For all routing devices, use the loopback address to assign the router ID, administratively group all of the devices into OSPF area 0.0.0.0, add all of the interfaces participating in OSPF to area 0.0.0.0, and disable OSPF on the management interface (fxp0.0).

•

Label-switched path On the ingress routing device R1, which is the beginning (or head end) of the LSP, configure an LSP with an explicit path. The explicit path indicates that the LSP must go to the next specified IP address in the path without traversing other nodes. In this example, you create an LSP named R1-to-R6, and you specify the IP address of the egress routing device R6.

•

Advertise the LSP in OSPFv2 On the ingress routing device R1, you advertise the LSP as a point-to-point link into OSPFv2. You can optionally assign a metric to have the LSP be the more or less preferred path to the destination.

Figure 27 on page 661 shows a sample network topology that consists of the following: •

660

BGP is configured on all routing devices, with one local autonomous system (AS) 65000 that contains three routing devices: •

R1—Device R1 is the ingress device with a router ID of 10.0.0.1. Interface so-0/0/2 connects to Device R3.

•

R3—Device R3 is the transit device with a router ID of 10.0.0.3. Interface so-0/0/2 connects to Device R1, and interface so-0/0/3 connects to Device R6.



•

R6—Device R6 is the egress device with a router ID of 10.0.0.6. Interface so-0/0/3 connects to Device R3.

•

OSPFv2 is configured on all routing devices.

•

MPLS and RSVP are enabled on all routing devices.

•

One RSVP-signaled LSP is configured on Device R1.

Figure 27: Advertising an LSP into OSPFv2 AS 65000

Ingress device

R1

Transit device

so-0/0/2

so-0/0/2

R3

Egress device

so-0/0/3

so-0/0/3

R6

Area 0.0.0.0

g040908

LSP R1-to-R6

Configuration The following examples require you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To configure the devices to advertise an LSP into OSPFv2, perform the following tasks: •

Configuring BGP on page 661

•

Configuring MPLS on page 663

•

Configuring RSVP on page 665

•

Configuring OSPF on page 667

•

Configuring the LSP on page 669

•

Advertising the LSP into OSPFv2 on page 669

Configuring BGP CLI Quick Configuration

To quickly configure BGP on each routing device, copy the following commands and paste them into the CLI. Configuration on Device R1: [edit] set routing-options autonomous-system 65000 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 10.0.0.1 set protocols bgp group internal-peers neighbor 10.0.0.3


661


set protocols bgp group internal-peers neighbor 10.0.0.6 set protocols bgp group internal-peers peer-as 65000

Configuration on Device R3: [edit] set routing-options autonomous-system 65000 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 10.0.0.3 set protocols bgp group internal-peers neighbor 10.0.0.1 set protocols bgp group internal-peers neighbor 10.0.0.6 set protocols bgp group internal-peers peer-as 65000

Configuration on Device R6: [edit] set routing-options autonomous-system 65000 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 10.0.0.6 set protocols bgp group internal-peers neighbor 10.0.0.1 set protocols bgp group internal-peers neighbor 10.0.0.3 set protocols bgp group internal-peers peer-as 65000


To configure BGP: 1.

On each routing device, configure the local AS number. [edit] user@R1# set routing-options autonomous-system 65000 [edit] user@R3# set routing-options autonomous-system 65000 [edit] user@R6# set routing-options autonomous-system 65000

2.

On each routing device, configure the internal BGP neighbor connections. [edit] user@R1# set protocols bgp group internal-peers type internal user@R1# set protocols bgp group internal-peers local-address 10.0.0.1 user@R1# set protocols bgp group internal-peers neighbor 10.0.0.3 user@R1# set protocols bgp group internal-peers neighbor 10.0.0.6 user@R1# set protocols bgp group internal-peers peer-as 65000 [edit] user@R3# set protocols bgp group internal-peers type internal user@R3# set protocols bgp group internal-peers local-address 10.0.0.3 user@R3# set protocols bgp group internal-peers neighbor 10.0.0.1 user@R3# set protocols bgp group internal-peers neighbor 10.0.0.6 user@R3# set protocols bgp group internal-peers peer-as 65000 [edit] user@R6# set protocols bgp group internal-peers type internal user@R6# set protocols bgp group internal-peers local-address 10.0.0.6 user@R6# set protocols bgp group internal-peers neighbor 10.0.0.1 user@R6# set protocols bgp group internal-peers neighbor 10.0.0.3 user@R6# set protocols bgp group internal-peers peer-as 65000

3.

662

If you are done configuring the devices, commit the configuration.



[edit] user@host# commit

Results

Confirm your configuration by entering the show routing-options and show protocols bgp commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on R1: user@R1# show routing-options autonomous-system 65000; user@R1# show protocols bgp group internal-peers { type internal; local-address 10.0.0.1; peer-as 65000; neighbor 10.0.0.3; neighbor 10.0.0.6; }

Configuration on R3: user@R3# show routing-options autonomous-system 65000; user@R3# show protocols bgp group internal-peers { type internal; local-address 10.0.0.3; peer-as 65000; neighbor 10.0.0.1; neighbor 10.0.0.6; }

Configuration on R6: user@R6# show routing-options autonomous-system 65000; user@R6# show protocols bgp group internal-peers { type internal; local-address 10.0.0.6; peer-as 65000; neighbor 10.0.0.1; neighbor 10.0.0.3; }

Configuring MPLS CLI Quick Configuration

To quickly configure MPLS on all of the routing devices in AS 65000, copy the following commands and paste them into the CLI. Configuration on Device R1: [edit]


663


set interfaces so-0/0/2 unit 0 family mpls set protocols mpls interface all set protocols mpls interface fxp0.0 disable

Configuration on Device R3: [edit] set interfaces so-0/0/2 unit 0 family mpls set interfaces so-0/0/3 unit 0 family mpls set protocols mpls interface all set protocols mpls interface fxp0.0 disable

Configuration on Device R6: [edit] set interfaces so-0/0/3 unit 0 family mpls set protocols mpls interface all set protocols mpls interface fxp0.0 disable


To configure MPLS: 1.

Configure the transit interfaces for MPLS. [edit ] user@R1# set interfaces so-0/0/2 unit 0 family mpls [edit ] user@R3# set interfaces so-0/0/2 unit 0 family mpls user@R3# set interfaces so-0/0/3 unit 0 family mpls [edit ] user@R6# set interfaces so-0/0/3 unit 0 family mpls

2.

Enable MPLS. [edit ] user@R1# set protocols mpls interface all [edit ] user@R3# set protocols mpls interface all [edit ] user@R6# set protocols mpls interface all

3.

Disable MPLS on the management interface (fxp0.0). [edit ] user@R1# set protocols mpls interface fxp0.0 disable [edit ] user@R3# set protocols mpls interface fxp0.0 disable [edit ] user@R6# set protocols mpls interface fxp0.0 disable

4.


664



Results

Confirm your configuration by entering the show interfaces and show protocols mpls commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on Device R1: user@R1# show interfaces so-0/0/2 { unit 0 { family mpls; } } user@R1# show protocols mpls interface all; interface fxp0.0 { disable; }

Configuration on Device R3: user@R3# show interfaces so-0/0/2 { unit 0 { family mpls; } } so-0/0/3 { unit 0 { family mpls; } } user@R3# show protocols mpls interface all; interface fxp0.0 { disable; }

Configuration on Device R6: user@R6# show interfaces so-0/0/3 { unit 0 { family mpls; } } user@R6# show protocols mpls interface all; interface fxp0.0 { disable; }

Configuring RSVP CLI Quick Configuration

To quickly configure RSVP on all of the routing devices in AS 65000, copy the following commands and paste them into the CLI.


665


Configuration on Device R1: [edit] set protocols rsvp interface so-0/0/2 set protocols rsvp interface fxp0.0 disable

Configuration on Device R3: [edit] set protocols rsvp interface so-0/0/2 set protocols rsvp interface so-0/0/3 set protocols rsvp interface fxp0.0 disable

Configuration on Device R6: [edit] set protocols rsvp interface so-0/0/3 set protocols rsvp interface fxp0.0 disable


To configure RSVP: 1.

Enable RSVP. [edit ] user@R1# set protocols rsvp interface so-0/0/2 [edit ] user@R3# set protocols rsvp interface so-0/0/2 user@R3# set protocols rsvp interface so-0/0/3 [edit ] user@R6# set protocols rsvp interface so-0/0/3

2.

Disable RSVP on the management interface (fxp0.0). [edit ] user@R1# set protocols rsvp interface fxp0.0 disable [edit ] user@R3# set protocols rsvp interface fxp0.0 disable [edit ] user@R6# set protocols rsvp interface fxp0.0 disable

3.


Results

Confirm your configuration by entering the show protocols rsvp command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on Device R1: user@R1# show protocols rsvp interface so-0/0/2.0; interface fxp0.0 { disable; }

666



Configuration on Device R3: user@R3# show protocols rsvp interface so-0/0/2.0; interface so-0/0/3.0; interface fxp0.0 { disable; }

Configuration on Device R6: user@R3# show protocols rsvp interface so-0/0/3.0; interface fxp0.0 { disable; }

Configuring OSPF CLI Quick Configuration

To quickly configure OSPF, copy the following commands and paste them into the CLI. Configuration on Device R1: [edit] set routing-options router-id 10.0.0.1 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable

Configuration on Device R3: [edit] set routing-options router-id 10.0.0.3 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable

Configuration on Device R6: [edit] set routing-options router-id 10.0.0.6 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable


To configure OSPF: 1.

Configure the router ID. [edit] user@R1# set routing-options router-id 10.0.0.1 [edit] user@R3# set routing-options router-id 10.0.0.3 [edit] user@R6# set routing-options router-id 10.0.0.6

2.

Configure the OSPF area and the interfaces. [edit] user@R1# set protocols ospf area 0.0.0.0 interface all


667


[edit] user@R3# set protocols ospf area 0.0.0.0 interface all [edit] user@R6# set protocols ospf area 0.0.0.0 interface all 3.

Disable OSPF on the management interface (fxp0.0). [edit] user@R1# set protocols ospf area 0.0.0.0 interface fxp0.0 disable [edit] user@R3# set protocols ospf area 0.0.0.0 interface fxp0.0 disable [edit] user@R6# set protocols ospf area 0.0.0.0 interface fxp0.0 disable

4.

If you are done configuring the devices, commit the configuration. [edit ] user@host# commit

Results

Confirm your configuration by entering the show routing-options and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Configuration on Device R1: user@R1# show routing-options router-id 10.0.0.1; user@R1# show protocols ospf area 0.0.0.0 { interface all; interface fxp0.0 { disable; } }

Configuration on Device R3: user@R3# show routing-options router-id 10.0.0.3; user@R3# show protocols ospf area 0.0.0.0 { interface all; interface fxp0.0 { disable; } }

Configuration on Device R6: user@R6# show routing-options router-id 10.0.0.6; user@R6# show protocols ospf area 0.0.0.0 { interface all;

668



interface fxp0.0 { disable; } }

Configuring the LSP CLI Quick Configuration

To quickly configure the LSP on the ingress routing device Router R1, copy the following command and paste it into the CLI. [edit] set protocols mpls label-switched-path R1-to-R6 to 10.0.0.6


To configure the LSP on Device R1: 1.

Enter MPLS configuration mode. [edit] user@R1# edit protocols mpls

2.

Create the LSP. [edit protocols mpls] user@R1# set label-switched-path R1-to-R6 to 10.0.0.6

3.

If you are done configuring the device, commit the configuration. [edit ] user@R1# commit

Results

Confirm your configuration by entering the show protocols mpls command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show protocols mpls label-switched-path R1-to-R6 { to 10.0.0.6; }

Advertising the LSP into OSPFv2 CLI Quick Configuration

To quickly advertise the LSP into OSPFv2 and optionally include a metric for the LSP on Device R1, copy the following commands and paste them into the CLI. [edit] set protocols ospf area 0.0.0.0 label-switched-path R1-to-R6 set protocols ospf area 0.0.0.0 label-switched-path R1-to-R6 metric 2


To advertise the LSP into OSPFv2 on Router R1: 1.

Enter OSPF configuration mode. [edit] user@R1# edit protocols ospf

2.

Include the label-switched-path statement, and specify the LSP R1-to-R6 that you created.


669


[edit protocols ospf] user@R1# set protocols ospf area 0.0.0.0 label-switched-path R1-to-R6 3.

(Optional) Specify a metric for the LSP. [edit ] user@R1# set protocols ospf area 0.0.0.0 label-switched-path R1-to-R6 metric 2

4.

If you are done configuring the device, commit the configuration. [edit ] user@R1# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show protocols ospf area 0.0.0.0 { label-switched-path R1-to-R6 { metric 2; } }

Verification Confirm that the configuration is working properly. Verifying the OSPF Neighbor Purpose

Action


Verify that another neighbor is listed and is reachable over the LSP. The interface field indicates the name of the LSP. From operational mode, enter the show ospf neighbor command.

•


•


Example: Configuring OSPFv2 Sham Links •

OSPFv2 Sham Links Overview on page 670

•


OSPFv2 Sham Links Overview You can create an intra-area link or sham link between two provider edge (PE) routing devices so that the VPN backbone is preferred over the back-door link. The sham link is an unnumbered point-to-point intra-area link and is advertised using Type 1 link-state advertisements (LSAs). Sham links are valid only for routing instances and OSPFv2. Each sham link is identified by the combination of a local endpoint address and a remote endpoint address. Figure 28 on page 671 shows an OSPFv2 sham link. Router CE1 and

670



Router CE2 are located in the same OSPFv2 area. These customer edge (CE) routing devices are linked together by a Layer 3 VPN over Router PE1 and Router PE2. In addition, Router CE1 and Router CE2 are connected by an intra-area link used as a backup.

Figure 28: OSPFv2 Sham Link

OSPFv2 treats the link through the Layer 3 VPN as an interarea link. By default, OSPFv2 prefers intra-area links to interarea links, so OSPFv2 selects the backup intra-area link as the active path. This is not acceptable in a configuration where the intra-area link is not the expected primary path for traffic between the CE routing devices. You can configure the metric for the sham link to ensure that the path over the Layer 3 VPN is preferred to a backup path over an intra-area link connecting the CE routing devices. For the remote endpoint, you can configure the OSPFv2 interface as a demand circuit, configure IPsec authentication (you configure the actual IPsec authentication separately), and define the metric value. You should configure an OSPFv2 sham link under the following circumstances: •

Two CE routing devices are linked together by a Layer 3 VPN.

•

These CE routing devices are in the same OSPFv2 area.

•

An intra-area link is configured between the two CE routing devices.

If there is no intra-area link between the CE routing devices, you do not need to configure an OSPFv2 sham link.

NOTE: In Junos OS Release 9.6 and later, an OSPFv2 sham link is installed in the routing table as a hidden route. Additionally, a BGP route is not exported to OSPFv2 if a corresponding OSPF sham link is available.

Example: Configuring OSPFv2 Sham Links This example shows how to enable OSPFv2 sham links on a PE routing device. •


•


•


•



671




•

Configure the Layer 3 VPN per your network requirements. See the Junos OS VPNs Configuration Guide.

•

Configure the VPN import and VPN export policies per your network requirements. See the Junos OS VPNs Configuration Guide.

•


•

If required, control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” on page 511

Overview The sham link is an unnumbered point-to-point intra-area link and is advertised by means of a type 1 link-state advertisement (LSA). Sham links are valid only for routing instances and OSPFv2. Each sham link is identified by a combination of the local endpoint address and a remote endpoint address and the OSPFv2 area to which it belongs. You manually configure the sham link between two PE devices, both of which are within the same VPN routing and forwarding (VRF) routing instance, and you specify the address for the local end point of the sham link. This address is used as the source for the sham link packets and is also used by the remote PE routing device as the sham link remote end point. You can also include the optional metric option to set a metric value for the remote end point. The metric value specifies the cost of using the link. Routes with lower total path metrics are preferred over those with higher path metrics. To enable OSPFv2 sham links on a PE routing device: •

Configure the loopback address on the PE routing device.

•

Configure the VRF routing instance that supports Layer 3 VPNs on the PE routing device, and associate the sham link with an existing OSPF area. The OSPFv2 sham link configuration is also included in the routing instance. You configure the sham link’s local endpoint address, which is the loopback address of the local VPN, and the remote endpoint address, which is the loopback address of the remote VPN. In this example, the VRF routing instance is named example-sham-links.

Figure 29 on page 673 shows an OSPFv2 sham link.

672



Figure 29: OSPFv2 Sham Link Example

The devices in the figure represent the following functions: •

CE1 and CE2 are the customer edge devices.

•

PE1 and PE2 are the provider edge devices.

•

P is the provider device.

This example shows the configuration of the PE devices.


To quickly enable OSPFv2 sham links on PE1, copy the following commands, remove any line breaks, and then paste the commands into the CLI. [edit] set interfaces lo0 unit 1 family inet address 10.1.1.1/32 set routing-instances example-sham-links instance-type vrf set routing-instances example-sham-links interface fe-0/1/0 set routing-instances example-sham-links interface lo0.1 set routing-instances example-sham-links route-distinguisher 1.1.1.1:1 set routing-instances example-sham-links vrf-import vpn-test-import set routing-instances example-sham-links vrf-export vpn-test-export set routing-instances example-sham-links protocols ospf sham-link local 10.1.1.1 set routing-instances example-sham-links protocols ospf area 0.0.0.0 sham-link-remote 10.2.2.2 metric 10 set routing-instances example-sham-links protocols ospf area 0.0.0.0 interface fe-0/1/0 set routing-instances example-sham-links protocols ospf area 0.0.0.0 interface lo0.1

To quickly enable OSPFv2 sham links on PE2, copy the following commands, remove any line breaks, and then paste the commands into the CLI. [edit] set interfaces lo0 unit 1 family inet address 10.2.2.2/32 set routing-instances example-sham-links instance-type vrf set routing-instances example-sham-links interface fe-0/2/0 set routing-instances example-sham-links interface lo0.1 set routing-instances example-sham-links route-distinguisher 1.1.1.1:1 set routing-instances example-sham-links vrf-import vpn-test-import set routing-instances example-sham-links vrf-export vpn-test-export set routing-instances example-sham-links protocols ospf sham-link local 10.2.2.2 set routing-instances example-sham-links protocols ospf area 0.0.0.0 sham-link-remote 10.1.1.1 metric 10 set routing-instances example-sham-links protocols ospf area 0.0.0.0 interface fe-0/2/0 set routing-instances example-sham-links protocols ospf area 0.0.0.0 interface lo0.1


673



The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To configure OSPFv2 sham links on each PE device: 1.

Configure the loopback interface. [edit] user@PE1# set interfaces lo0 unit 1 family inet address 10.1.1.1/32 [edit] user@PE2# set interfaces lo0 unit 1 family inet address 10.2.2.2/32

2.

Configure the VRF routing instance. [edit] user@PE1# edit routing instances example-sham-links [edit routing instances example-sham-links] user@PE1#set instance-type vrf [edit routing instances example-sham-links] user@PE1#set interface fe-0/1/0 [edit routing instances example-sham-links] user@PE1#set interface lo0.1 [edit routing instances example-sham-links] user@PE1#set route-distinguisher 1.1.1.1:1 [edit routing instances example-sham-links] user@PE1#set vrf-import vpn-test-import [edit routing instances example-sham-links] user@PE1#set vrf-export vpn-test-export [edit] user@PE2# edit routing instances example-sham-links [edit routing instances example-sham-links] user@PE2# set instance-type vrf [edit routing instances example-sham-links] user@PE2# set interface fe-0/2/0 [edit routing instances example-sham-links] user@PE2# set interface lo0.1 [edit routing instances example-sham-links] user@PE2# set route-distinguisher 1.1.1.1:1 [edit routing instances example-sham-links] user@PE2# set vrf-import vpn-test-import [edit routing instances example-sham-links] user@PE2# set vrf-export vpn-test-export [edit routing instances example-sham-links]

3.

Configure the OSPFv2 sham link. [edit routing instances example-sham-links] user@PE1# set protocols ospf sham-link local 10.1.1.1 [edit routing instances example-sham-links] user@PE1#set protocols ospf area 0.0.0.0 sham-link-remote 10.2.2.2 metric 10 [edit routing instances example-sham-links] user@PE1#set protocols ospf area 0.0.0.0 interface fe-0/1/0 [edit routing instances example-sham-links] user@PE1#set protocols ospf area 0.0.0.0 interface lo0.1 [edit routing instances example-sham-links]

674



user@PE2# set protocols ospf sham-link local 10.2.2.2 [edit routing instances example-sham-links] user@PE2# set protocols ospf area 0.0.0.0 sham-link-remote 10.1.1.1 metric 10 [edit routing instances example-sham-links] user@PE2# set protocols ospf area 0.0.0.0 interface fe-0/2/0 [edit routing instances example-sham-links] user@PE2# set protocols ospf area 0.0.0.0 interface lo0.1 4.

If you are done configuring the devices, commit the configuration. [edit routing instances example-sham-links] user@host# commit

Results

Confirm your configuration by entering the show interfaces and the show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Output for PE1: user@PE1# show interfaces lo0 { unit 1 { family inet { address 10.1.1.1/32; } } } user@PE1# show routing-instances example-sham-links { instance-type vrf; interface fe-0/1/0.0; interface lo0.1; route-distinguisher 1.1.1.1:1; vrf-import vpn-test-import; vrf-export vpn-test-export; protocols { ospf { sham-link local 10.1.1.1; area 0.0.0.0 { sham-link-remote 10.2.2.2 metric 10; interface fe-0/1/0.0; interface lo0.1; } } } }

Output for PE2: user@PE2# show interfaces lo0 { unit 1 { family inet { address 10.2.2.2/32; } }


675


} user@PE2# show routing-instances example-sham-links { instance-type vrf; interface fe-0/2/0.0; interface lo0.1; route-distinguisher 1.1.1.1:1; vrf-import vpn-test-import; vrf-export vpn-test-export; protocols { ospf { sham-link local 10.2.2.2; area 0.0.0.0 { sham-link-remote 10.1.1.1 metric 10; interface fe-0/2/0.0; interface lo0.1; } } } }


Verifying the Sham Link Interfaces on page 676

•

Verifying the Local and Remote End Points of the Sham Link on page 676

•

Verifying the Sham Link Adjacencies on page 676

•

Verifying the Link-State Advertisement on page 677

Verifying the Sham Link Interfaces Purpose

Action

Verify the sham link interface. The sham link is treated as an interface in OSPFv2, with the named displayed as shamlink., where the unique identifier is a number. For example, shamlink.0. The sham link appears as a point-to-point interface. From operational mode, enter the show ospf interface instance instance-name command. Verifying the Local and Remote End Points of the Sham Link

Purpose

Action

Verify the local and remote end points of the sham link. The MTU for the sham link interface is always zero. From operational mode, enter the show ospf interface instance instance-name detail command. Verifying the Sham Link Adjacencies

Purpose Action

676

Verify the adjacencies between the configured sham links. From operational mode, enter the show ospf neighbor instance instance-name command.



Verifying the Link-State Advertisement Purpose

Verify that the router LSA originated by the instance carries the sham link adjacency as an unnumbered point-to-point link. The link data for sham links is a number ranging from 0x80010000 through 0x8001ffff.

Action

From operational mode, enter the show ospf database instance instance-name command.


•


•


Example: Configuring OSPF Database Protection •

OSPF Database Protection Overview on page 677

•

Configuring OSPF Database Protection on page 678

OSPF Database Protection Overview OSPF database protection allows you to limit the number of link-state advertisements (LSAs) not generated by the local router in a given OSPF routing instance, helping to protect the link-state database from being flooded with excessive LSAs. This feature is particularly useful if VPN routing and forwarding is configured on your provider edge and customer edge routers using OSPF as the routing protocol. An overrun link-state database on the customer edge router can exhaust resources on the provider edge router and impact the rest of the service provider network. When you enable OSPF database protection, the maximum number of LSAs you specify includes all LSAs whose advertising router ID is not equal to the local router ID (nonself-generated LSAs). These might include external LSAs as well as LSAs with any scope such as the link, area, and autonomous system (AS). Once the specified maximum LSA count is exceeded, the database typically enters into the ignore state. In this state, all neighbors are brought down, and nonself-generated LSAs are destroyed. In addition, the database sends out hellos but ignores all received packets. As a result, the database does not form any full neighbors, and therefore does not learn about new LSAs. However, if you have configured the warning-only option, only a warning is issued and the database does not enter the ignore state but continues to operate as before. You can also configure one or more of the following options: •

A warning threshold for issuing a warning message before the LSA limit is reached.

•

An ignore state time during which the database must remain in the ignore state and after which normal operations can be resumed.

•

An ignore state count that limits the number of times the database can enter the ignore state, after which it must enter the isolate state. The isolate state is very similar to the ignore state, but has one important difference: once the database enters the isolate


677


state, it must remain there until you issue a command to clear database protection before it can return to normal operations. •

A reset time during which the database must stay out of the ignore or isolate state before it is returned to a normal operating state.

Configuring OSPF Database Protection By configuring OSPF database protection, you can help prevent your OSPF link-state database from being overrun with excessive LSAs that are not generated by the local router. You specify the maximum number of LSAs whose advertising router ID is not the same as the local router ID in an OSPF instance. This feature is particularly useful if your provider edge and customer edge routers are configured with VPN routing and forwarding using OSPF. OSPF database protection is supported on: •

Logical systems

•


•

OSPFv2 and OSPFv3 topologies

•

OSPFv3 realms

To configure OSPF database protection: 1.

Include the database-protection statement at one of the following hierarchy levels: •

[edit protocols ospf | ospf3]

•

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf |ospf3)]

•

[edit routing-instances routing-instance-name protocols (ospf |ospf3)]

•

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-unicast | ipv6-multicast)]

2. Include the maximum-lsa number statement.

NOTE: The maximum-lsa statement is mandatory, and there is no default value for it. If you omit this statement, you cannot configure OSPF database protection.

3. (Optional) Include the following statements: •

ignore-count number—Specify the number of times the database can enter the

ignore state before it goes into the isolate state. •

ignore-time seconds—Specify the time limit the database must remain in the ignore

state before it resumes regular operations.

678



•

reset-time seconds—Specify the time during which the database must operate

without being in either the ignore or isolate state before it is reset to a normal operating state. •

warning-threshold percent—Specify the percent of the maximum LSA number that

must be exceeded before a warning message is issued. 4. (Optional) Include the warning-only statement to prevent the database from entering

the ignore state or isolate state when the maximum LSA count is exceeded.

NOTE: If you include the warning-only statement, values for the other optional statements at the same hierarchy level are not used when the maximum LSA number is exceeded.

5. Verify your configuration by checking the database protection fields in the output of

the show ospf overview command. Related Documentation

•


•


Examples: Configuring OSPF Routing Policy •


•

Example: Injecting OSPF Routes into the BGP Routing Table on page 681

•

Example: Redistributing Static Routes into OSPF on page 684

•

Example: Configuring an OSPF Import Policy on page 687

•

Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through OSPF on page 691

Understanding OSPF Routing Policy Each routing policy is identified by a policy name. The name can contain letters, numbers, and hyphens (-) and can be up to 255 characters long. To include spaces in the name, enclose the entire name in double quotation marks. Each routing policy name must be unique within a configuration. Once a policy is created and named, it must be applied before it is active. In the import statement, you list the name of the routing policy used to filter OSPF external routes from being installed into the routing tables of OSPF neighbors. You can filter the routes, but not link-state address (LSA) flooding. An external route is a route that is outside the OSPF Autonomous System (AS). The import policy does not impact the OSPF database. This means that the import policy has no impact on the link-state advertisements. In the export statement, you list the name of the routing policy to be evaluated when routes are being exported from the routing table into OSPF.


679


By default, if a routing device has multiple OSPF areas, learned routes from other areas are automatically installed into area 0 of the routing table. To specify more than one policy and create a policy chain, you list the policies using a space as a separator. If multiple policies are specified, the policies are evaluated in the order in which they are specified. As soon as an accept or reject action is executed, the policy chain evaluation ends. This topic describes the following information: •

Routing Policy Terms on page 680

•

Routing Policy Match Conditions on page 680

•

Routing Policy Actions on page 681

Routing Policy Terms Routing policies are made up of one or more terms. A term is a named structure in which match conditions and actions are defined. You can define one or more terms. The name can contain letters, numbers, and hyphens ( - ) and can be up to 255 characters long. To include spaces in the name, enclose the entire name in double quotation marks. Each term contains a set of match conditions and a set of actions: •

Match conditions are criteria that a route must match before the actions can be applied. If a route matches all criteria, one or more actions are applied to the route.

•

Actions specify whether to accept or reject the route, control how a series of policies are evaluated, and manipulate the characteristics associated with a route.

Routing Policy Match Conditions A match condition defines the criteria that a route must match for an action to take place. You can define one or more match conditions for each term. If a route matches all of the match conditions for a particular term, the actions defined for that term are processed. Each term can include two statements, from and to, that define the match conditions: •

In the from statement, you define the criteria that an incoming route must match. You can specify one or more match conditions. If you specify more than one, they all must match the route for a match to occur. The from statement is optional. If you omit the from and the to statements, all routes are considered to match.

NOTE: In export policies, omitting the from statement from a routing policy term might lead to unexpected results. For more information, see Applying Routing Policies and Policy Chains to Routing Protocols in the Junos OS Routing Policy Configuration Guide.

680



•

In the to statement, you define the criteria that an outgoing route must match. You can specify one or more match conditions. If you specify more than one, they all must match the route for a match to occur.

The order of the match conditions in a term is not important because a route must match all match conditions in a term for an action to be taken. For a complete list of match conditions, see Configuring Match Conditions in Routing Policy Terms in the Junos OS Routing Policy Configuration Guide.

Routing Policy Actions An action defines what the routing device does with the route when the route matches all the match conditions in the from and to statements for a particular term. If a term does not have from and to statements, all routes are considered to match and the actions apply to all routes. Each term can have one or more of the following types of actions. The actions are configured under the then statement. •

Flow control actions, which affect whether to accept or reject the route and whether to evaluate the next term or routing policy.

•

Actions that manipulate route characteristics.

•

Trace action, which logs route matches.

The then statement is optional. If you omit it, one of the following occurs: •

The next term in the routing policy, if one exists, is evaluated.

•

If the routing policy has no more terms, the next routing policy, if one exists, is evaluated.

•

If there are no more terms or routing policies, the accept or reject action specified by the default policy is executed.

For a complete list of routing policy actions, see Configuring Actions in Routing Policy TermsJunos OS Routing Policy Configuration Guide

Example: Injecting OSPF Routes into the BGP Routing Table This example shows how to create a policy that injects OSPF routes into the BGP routing table. •


•


•


•


•

Troubleshooting on page 684



681


•

Configure network interfaces.

•

Configure external peer sessions. See “Example: Configuring External BGP Point-to-Point Peer Sessions” on page 983.

•

Configure interior gateway protocol (IGP) sessions between peers.

Overview In this example, you create a routing policy called injectpolicy1 and a routing term called injectterm1. The policy injects OSPF routes into the BGP routing table.

Configuration •

Configuring the Routing Policy on page 682

•

Configuring Tracing for the Routing Policy on page 683

Configuring the Routing Policy CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set policy-options policy-statement injectpolicy1 term injectterm1 from protocol ospf set policy-options policy-statement injectpolicy1 term injectterm1 from area 0.0.0.1 set policy-options policy-statement injectpolicy1 term injectterm1 then accept set protocols bgp export injectpolicy1


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To inject OSPF routes into a BGP routing table: 1.

Create the policy term. [edit policy-options policy-statement injectpolicy1] user@host# set term injectterm1

2.

Specify OSPF as a match condition. [edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from protocol ospf

3.

Specify the routes from an OSPF area as a match condition. [edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from area 0.0.0.1

4.

Specify that the route is to be accepted if the previous conditions are matched. [edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set then accept

5.

Apply the routing policy to BGP. [edit]

682



user@host# set protocols bgp export injectpolicy1

Results

Confirm your configuration by entering the show policy-options and show protocols bgp commands from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show policy-options policy-statement injectpolicy1 { term injectterm1 { from { protocol ospf; area 0.0.0.1; } then accept; } } user@host# show protocols bgp export injectpolicy1;

If you are done configuring the device, enter commit from configuration mode. Configuring Tracing for the Routing Policy CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set policy-options policy-statement injectpolicy1 term injectterm1 then trace set routing-options traceoptions file ospf-bgp-policy-log set routing-options traceoptions file size 5m set routing-options traceoptions file files 5 set routing-options traceoptions flag policy


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. 1.

Include a trace action in the policy. [edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# then trace

2.

Configure the tracing file for the output. [edit routing-options traceoptions] user@host# set file ospf-bgp-policy-log user@host# set file size 5m user@host# set file files 5 user@host# set flag policy

Results

Confirm your configuration by entering the show policy-options and show routing-options commands from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.


683


user@host# show policy-options policy-statement injectpolicy1 { term injectterm1 { then { trace; } } } user@host# show routing-options traceoptions { file ospf-bgp-policy-log size 5m files 5; flag policy; }


Verification Confirm that the configuration is working properly. Verifying That the Expected BGP Routes Are Present Purpose Action

Verify the effect of the export policy. From operational mode, enter the show route command.

Troubleshooting Using the show log Command to Examine the Actions of the Routing Policy Problem

The routing table contains unexpected routes, or routes are missing from the routing table.

Solution

If you configure policy tracing as shown in this example, you can run the show log ospf-bgp-policy-log command to diagnose problems with the routing policy. The show log ospf-bgp-policy-log command displays information about the routes that the injectpolicy1 policy term analyzes and acts upon.

Example: Redistributing Static Routes into OSPF This example shows how to create a policy that redistributes static routes into OSPF. •


•


•


•



684




•

Configure static routes. See “Examples: Configuring Static Routes” on page 93 in the Junos OS Routing Protocols Configuration Guide.

Overview In this example, you create a routing policy called exportstatic1 and a routing term called exportstatic1. The policy injects static routes into OSPF. This example includes the following settings: •

policy-statement—Defines the routing policy. You specify the name of the policy and

further define the elements of the policy. The policy name must be unique and can contain letters, numbers, and hyphens ( - ) and be up to 255 characters long. •

term—Defines the match condition and applicable actions for the routing policy. The

term name can contain letters, numbers, and hyphens ( - ) and be up to 255 characters long. You specify the name of the term and define the criteria that an incoming route must match by including the from statement and the action to take if the route matches the conditions by including the then statement. In this example you specify the static protocol match condition and the accept action. •

export—Applies the export policy you created to be evaluated when routes are being

exported from the routing table into OSPF.


To quickly create a policy that injects static routes into OSPF, copy the following commands and paste them into the CLI. [edit] set policy-options policy-statement exportstatic1 term exportstatic1 from protocol static set policy-options policy-statement exportstatic1 term exportstatic1 then accept set protocols ospf export exportstatic1


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To inject static routes into OSPF: 1.

Create the routing policy. [edit] user@host# edit policy-options policy-statement exportstatic1

2.

Create the policy term. [edit policy-options policy-statement exportstatic1] user@host# set term exportstatic1

3.

Specify static as a match condition. [edit policy-options policy-statement exportstatic1 term exportstatic1] user@host# set from protocol static

4.

Specify that the route is to be accepted if the previous condition is matched.


685


[edit policy-options policy-statement exportstatic1 term exportstatic1] user@host# set then accept 5.

Apply the routing policy to OSPF.


[edit] user@host# set protocols ospf export exportstatic1 6.


Results

Confirm your configuration by entering the show policy-options and show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show policy-options policy-statement exportstatic1 { term exportstatic1 { from protocol static; then accept; } } user@host# show protocols ospf export exportstatic1;

To confirm your OSPFv3 configuration, enter the show policy-options and the show protocols ospf3 commands.


Verifying That the Expected Static Routes Are Present on page 686

•

Verifying That AS External LSAs Are Added to the Routing Table on page 686

Verifying That the Expected Static Routes Are Present Purpose Action

Verify the effect of the export policy. From operational mode, enter the show route command. Verifying That AS External LSAs Are Added to the Routing Table

Purpose

686

On the routing device where you configured the export policy, verify that the routing device originates an AS external LSA for the static routes that are added to the routing table.



Action

From operational mode, enter the show ospf database command for OSPFv2, and enter the show ospf3 database command for OSPFv3.

Example: Configuring an OSPF Import Policy This example shows how to create an OSPF import policy. OSPF import policies apply to external routes only. An external route is a route that is outside the OSPF autonomous system (AS). •


•


•


•



Configure static routes. See “Examples: Configuring Static Routes” on page 93 in the Junos OS Routing Protocols Configuration Guide.

•


•


•

Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on page 514 .

Overview External routes are learned by AS boundary routers. External routes can be advertised throughout the OSPF domain if you configure the AS boundary router to redistribute the route into OSPF. An external route might be learned by the AS boundary router from a routing protocol other than OSPF, or the external route might be a static route that you configure on the AS boundary router. For OSPFv3, the link-state advertisement (LSA) is referred to as the interarea prefix LSA and performs the same function as a network-summary LSA performs for OSPFv2. An area border router (ABR) originates an interarea prefix LSA for each IPv6 prefix that must be advertised into an area. OSPF import policy allows you to prevent external routes from being added to the routing tables of OSPF neighbors. The import policy does not impact the OSPF database. This means that the import policy has no impact on the link-state advertisements. The filtering is done only on external routes in OSPF. The intra-area and interarea routes are not considered for filtering. The default action is to accept the route when the route does not match the policy.


687


This example includes the following OSPF policy settings: •

policy-statement—Defines the routing policy. You specify the name of the policy and

further define the elements of the policy. The policy name must be unique and can contain letters, numbers, and hyphens ( - ) and be up to 255 characters long. •

export—Applies the export policy you created to be evaluated when network summary

LSAs are flooded into an area. In this example, the export policy is named export_static. •

import—Applies the import policy you created to prevent external routes from being

added to the routing table. In this example, the import policy is named filter_routes. The devices you configure in this example represent the following functions: •

R1—Device R1 is in area 0.0.0.0 and has a direct connection to device R2. R1 has an OSPF export policy configured. The export policy redistributes static routes from R1’s routing table into R1’s OSPF database. Because the static route is in R1’s OSPF database, the route is advertised in an LSA to R1’s OSPF neighbor. R1’s OSPF neighbor is device R2.

•

R2—Device R2 is in area 0.0.0.0 and has a direct connection to device R1. R2 has an OSPF import policy configured that matches the static route to the 10.0.16.0/30 network and prevents the static route from being installed in R2’s routing table. R2’s OSPF neighbor is device R1.


To quickly configure an OSPF import policy, copy the following commands, removing any line breaks, and then paste the commands into the CLI. Configuration on Device R1: [edit] set interfaces so-0/2/0 unit 0 family inet address 10.0.2.1/30 set protocols ospf export export_static set protocols ospf area 0.0.0.0 interface so-0/2/0 set policy-options policy-statement export_static from protocol static set policy-options policy-statement export_static then accept

Configuration on Device R2: [edit] set interfaces so-0/2/0 unit 0 family inet address 10.0.2.2/30 set protocols ospf import filter_routes set protocols ospf area 0.0.0.0 interface so-0/2/0 set policy-options policy-statement filter_routes from route-filter 10.0.16.0/30 exact set policy-options policy-statement filter_routes then reject


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To configure an OSPF import policy: 1.

688




[edit] user@R1# set interfaces so-0/2/0 unit 0 family inet address 10.0.2.1/30 [edit] user@R2# set interfaces so-0/2/0 unit 0 family inet address 10.0.2.2/30 2.

Enable OSPF on the interfaces.


[edit] user@R1# set protocols ospf area 0.0.0.0 interface so-0/2/0 [edit] user@R2# set protocols ospf area 0.0.0.0 interface so-0/2/0 3.

On R1, redistribute the static route into OSPF. [edit] user@R1# set protocols ospf export export_static user@R1# set policy-options policy-statement export_static from protocol static user@R1# set policy-options policy-statement export_static then accept

4.

On R2, configure the OSPF import policy. [edit] user@R2# set protocols ospf import filter_routes user@R2# set policy-options policy-statement filter_routes from route-filter 10.0.16.0/30 exact user@R2# set policy-options policy-statement filter_routes then reject

5.


Results

Confirm your configuration by entering the show interfaces, show policy-options, and show protocols ospf commands on the appropriate device. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Output for R1: user@R1# show interfaces so-0/2/0 { unit 0 { family inet { address 10.0.2.1/30; } } } user@R1# show policy-options policy-statement export_static { from protocol static;


689


then accept; } user@R1# show protocols ospf export export_static; area 0.0.0.0 { interface so-0/2/0.0; }

Output for R2: user@R2# show interfaces so-0/2/0 { unit 0 { family inet { address 10.0.2.2/30; } } } user@R2# show policy-options policy-statement filter_routes { from { route-filter 10.0.16.0/30 exact; } then reject; } user@R2# show protocols ospf import filter_routes; area 0.0.0.0 { interface so-0/2/0.0; }

To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, show routing-options, and show protocols ospf3 commands on the appropriate device.


Verifying the OSPF Database on page 690

•

Verifying the Routing Table on page 690

Verifying the OSPF Database Purpose Action

Verify that OSPF is advertising the static route in the OSPF database. From operational mode, enter the show ospf database for OSPFv2, and enter the show ospf3 database command for OSPFv3. Verifying the Routing Table

Purpose Action

690

Verify the entries in the routing table. From operational mode, enter the show route command.



Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through OSPF This example shows how to create an OSPF import policy that prioritizes specific prefixes learned through OSPF. •


•


•


•




•


•

Control OSPF designated router election See “Example: Controlling OSPF Designated Router Election” on page 511

•

Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on page 514 .

•


Overview In a network with a large number of OSPF routes, it can be useful to control the order in which routes are updated in response to a network topology change. In Junos OS Release 9.3 and later, you can specify a priority of high, medium, or low for prefixes included in an OSPF import policy. In the event of an OSPF topology change, high priority prefixes are updated in the routing table first, followed by medium and then low priority prefixes. OSPF import policy can only be used to set priority or to filter OSPF external routes. If an OSPF import policy is applied that results in a reject terminating action for a nonexternal route, then the reject action is ignored and the route is accepted anyway. By default, such a route is now installed in the routing table with a priority of low. This behavior prevents traffic black holes, that is, silently discarded traffic, by ensuring consistent routing within the OSPF domain. In general, OSPF routes that are not explicitly assigned a priority are treated as priority medium, except for the following: •

Summary discard routes have a default priority of low.

•

Local routes that are not added to the routing table are assigned a priority of low.


691


•

External routes that are rejected by import policy and thus not added to the routing table are assigned a priority of low.

Any available match criteria applicable to OSPF routes can be used to determine the priority. Two of the most commonly used match criteria for OSPF are the route-filter and tag statements. In this example, the routing device is in area 0.0.0.0, with interfaces fe-0/1/0 and fe-1/1/0 connecting to neighboring devices. You configure an import routing policy named ospf-import to specify a priority for prefixes learned through OSPF. Routes associated with these prefixes are installed in the routing table in the order of the prefixes’ specified priority. Routes matching 200.3.0.0/16 orlonger are installed first because they have a priority of high. Routes matching 200.2.0.0/16 orlonger are installed next because they have a priority of medium. Routes matching 200.1.0.0/16 orlonger are installed last because they have a priority of low. You then apply the import policy to OSPF.

NOTE: The priority value takes effect when a new route is installed, or when there is a change to an existing route.


To quickly configure an OSPF import policy that prioritizes specific prefixes learned through OSPF, copy the following commands, removing any line breaks, and then paste the commands into the CLI. [edit] set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.4/30 set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.5/30 set policy-options policy-statement ospf-import term t1 from route-filter 200.1.0.0/16 orlonger set policy-options policy-statement ospf-import term t1 then priority low set policy-options policy-statement ospf-import term t1 then accept set policy-options policy-statement ospf-import term t2 from route-filter 200.2.0.0/16 orlonger set policy-options policy-statement ospf-import term t2 then priority medium set policy-options policy-statement ospf-import term t2 then accept set policy-options policy-statement ospf-import term t3 from route-filter 200.3.0.0/16 orlonger set policy-options policy-statement ospf-import term t3 then priority high set policy-options policy-statement ospf-import term t3 then accept set protocols ospf import ospf-import set protocols ospf area 0.0.0.0 interface fe-0/1/0 set protocols ospf area 0.0.0.0 interface fe-1/1/0


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To configure an OSPF import policy that prioritizes specific prefixes: 1.

692




[edit] user@host# set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.4/30 user@host# set interfaces fe-0/2/0 unit 0 family inet address 192.168.8.5/30 2.




Configure the policy to specify the priority for prefixes learned through OSPF. [edit ] user@host# set policy-options policy-statement ospf-import term t1 from route-filter 200.1.0.0/16 orlonger user@host# set policy-options policy-statement ospf-import term t1 then priority low user@host# set policy-options policy-statement ospf-import term t1 then accept user@host# set policy-options policy-statement ospf-import term t2 from route-filter 200.2.0.0/16 orlonger user@host# set policy-options policy-statement ospf-import term t2 then priority medium user@host# set policy-options policy-statement ospf-import term t2 then accept user@host# set policy-options policy-statement ospf-import term t3 from route-filter 200.3.0.0/16 orlonger user@host# set policy-options policy-statement ospf-import term t3 then priority high user@host# set policy-options policy-statement ospf-import term t3 then accept

4.

Apply the policy to OSPF. [edit] user@host# set protocols ospf import ospf-import

5.


Results

Confirm your configuration by entering the show interfaces, show policy-options, and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces fe-0/1/0 { unit 0 { family inet { address 192.168.8.4/30; } } } fe-0/2/0 {


693


unit 0 { family inet { address 192.168.8.5/30; } } } user@host# show policy-options policy-statement ospf-import { term t1 { from { route-filter 200.1.0.0/16 orlonger; } then { priority low; accept; } } term t2 { from { route-filter 200.2.0.0/16 orlonger; } then { priority medium; accept; } } term t3 { from { route-filter 200.3.0.0/16 orlonger; } then { priority high; accept; } } } user@host# show protocols ospf import ospf-import; area 0.0.0.0 { interface fe-0/1/0.0; interface fe-0/2/0.0; }

To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show protocols ospf3 commands.

Verification Confirm that the configuration is working properly. Verifying the Prefix Priority in the OSPF Routing Table Purpose

694

Verify the priority assigned to the prefix in the OSPF routing table.



Action


From operational mode, enter the show ospf route detail for OSPFv2, and enter the show ospf3 route detail command for OSPFv3.

•


•


•

Configuring Match Conditions in Routing Policy Terms in the Junos OS Routing Policy Configuration Guide

•

Configuring Actions in Routing Policy Terms in the Junos OS Routing Policy Configuration Guide

Examples: Configuring Routing Policy for Network Summaries •

Import and Export Policies for Network Summaries Overview on page 695

•

Example: Configuring an OSPF Export Policy for Network Summaries on page 695

•

Example: Configuring an OSPF Import Policy for Network Summaries on page 704

Import and Export Policies for Network Summaries Overview By default, OSPF uses network-summary link-state advertisements (LSAs) to transmit route information across area boundaries. Each area border router (ABR) floods network-summary LSAs to other routing devices in the same area. The ABR also controls which routes from the area are used to generate network-summary LSAs into other areas. Each ABR maintains a separate topological database for each area to which they are connected. In Junos OS Release 9.1 and later, you can configure export and import policies for OSPFv2 and OSPFv3 that enable you to control how network-summary LSAs, which contain information about interarea OSPF prefixes, are distributed and generated. For OSPFv3, the LSA is referred to as the interarea prefix LSA and performs the same function as a network-summary LSA performs for OSPFv2. An ABR originates an interarea prefix LSA for each IPv6 prefix that must be advertised into an area. The export policy enables you to specify which summary LSAs are flooded into an area. The import policy enables you to control which routes learned from an area are used to generate summary LSAs into other areas. You define a routing policy at the [edit policy-options policy-statement policy-name] hierarchy level. As with all OSPF export policies, the default for network-summary LSA export policies is to reject everything. Similarly, as with all OSPF import policies, the default for network-summary LSA import policies is to accept all OSPF routes.

Example: Configuring an OSPF Export Policy for Network Summaries This example shows how to create an OSPF export policy to control the network-summary (Type 3) LSAs that the ABR floods into an OSPF area. •


•



695


•


•




•


Overview OSPF uses network-summary LSAs to transmit route information across area boundaries. Depending on your network environment, you might want to further filter the network-summary LSAs between OSPF areas. For example, if you create OSPF areas to define administrative boundaries, you might not want to advertise internal route information between those areas. To further improve the control of route distribution between multiple OSPF areas, you can configure network summary policies on the ABR for the area that you want to filter the advertisement of network-summary LSAs.

NOTE: For OSPFv3, the LSA is referred to as the interarea prefix LSA and performs the same function as a network-summary LSA performs for OSPFv2. An ABR originates an interarea prefix LSA for each IPv6 prefix that must be advertised into an area. In this topic, the terms network summary policy and network-summary policy are used to describe both OSPFv2 and OSPFv3 functionality.

The following guidelines apply to export network summary policies: •

You should have a thorough understanding of your network before configuring these policies. Incorrect network summary policy configuration might result in an unintended result such as suboptimal routing or dropped traffic.

•

We recommend that you use the route-filter policy match condition for these types of policies.

•

We recommend that you use the accept and reject routing policy terms for these types of policies.

Figure 30 on page 697 shows a sample topology with three OSPF areas. R4 generates network summaries for the routes in area 4 and sends them out of area 4 to area 0. R3 generates network summaries for the routes in area 3 and sends them out of area 3 to area 0.

696



Figure 30: Sample Topology Used for an OSPF Export Network Summary Policy Area 0.0.0.3

Area 0.0.0.4

Area 0.0.0.0

R5

R1 fe-0/0/1

fe-1/1/0

fe-0/1/0

10.0.8.8

fe-1/1/0

10.0.4.4

fe-1/0/0 fe-0/0/1

10.0.8.4

10.0.4.12 R3

10.0.4.0 fe-1/0/0

fe-0/0/1

R4

fe-1/0/0 10.0.8.8 fe-1/0/0 R6 g040906

R2

fe-0/0/1

fe-1/1/0

In this example, you configure R4 with an export network summary policy named export-policy that only allows routes that match the 10.0.4.4 prefix from area 3 into area 4. The export policy controls the network-summary LSAs that R4 floods into area 4. This results in only the allowed interarea route to enter area 4, and all other interarea routes to be purged from the OSPF database and the routing table of the devices in area 4. You first define the policy and then apply it to the ABR by including the network-summary-export statement for OSPFv2 or the inter-area-prefix-export statement for OSPFv3. The devices operate as follows: •

R1—Device R1 is an internal router in area 3. Interface fe-0/1/0 has an IP address of 10.0.4.13/30 and connects to R3. Interface fe-0/0/1 has an IP address of 10.0.4.5/30 and connects to R2.

•

R2—Device R2 is an internal router in area 3. Interface fe-0/0/1 has an IP address of 10.0.4.6/30 and connects to R1. Interface fe-1/0/0 has an IP address of 10.0.4.3 and connects to R3.

•

R3—Device R3 participates in area 3 and area 0. R3 is the ABR between area 3 and area 0, and passes network-summary LSAs between the areas. Interface fe-1/0/0 has an IP address of 10.0.4.2/30 and connects to R2. Interface fe-1/1/0 has an IP address of 10.0.4.14/30 and connects to R1. Interface fe-0/0/1 has an IP address of 10.0.2.3/30 and connects to R4.

•


•

R5—Device R5 is an internal router in area 4. Interface fe-1/1/0 has an IP address of 10.0.8.5/30 and connects to R4.

•



697



To quickly configure an OSPF export policy for network summaries, copy the following commands, removing any line breaks, and then paste the commands into the CLI. Configuration on Device R1: [edit] set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30 set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30 set protocols ospf area 0.0.0.3 interface fe-0/1/0 set protocols ospf area 0.0.0.3 interface fe-0/0/1

Configuration on Device R2: [edit] set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30 set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.3/30 set protocols ospf area 0.0.0.3 interface fe-0/1/0 set protocols ospf area 0.0.0.3 interface fe-1/0/0

Configuration on Device R3: [edit] set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30 set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30 set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.3/30 set protocols ospf area 0.0.0.3 interface fe-1/0/0 set protocols ospf area 0.0.0.3 interface fe-1/1/0 set protocols ospf area 0.0.0.0 interface fe-0/0/1

Configuration on Device R4: [edit] set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.4/30 set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.3/30 set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.6/30 set policy-options policy-statement export-policy term term1 from route-filter 10.0.4.4/30 prefix-length-range /30-/30 set policy-options policy-statement export-policy term term1 then accept set protocols ospf area 0.0.0.0 interface fe-0/0/1 set protocols ospf area 0.0.0.4 interface fe-0/1/0 set protocols ospf area 0.0.0.4 interface fe-1/0/0 set protocols ospf area 0.0.0.4 network-summary-export export-policy

Configuration on Device R5: [edit] set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30 set protocols ospf area 0.0.0.4 interface fe-0/1/0


698




The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To configure an configure an OSPF export policy for network summaries: 1.



[edit] user@R1# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30 user@R1# set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30 [edit] user@R2# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30 user@R2# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.3/30 [edit] user@R3# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30 user@R3# set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30 user@R3#set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.3/30 [edit] user@R4# set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.4/30 user@R4# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.3/30 user@R4# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.6/30 [edit] user@R5# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30 [edit] user@R6# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.7/30 2.



[edit] user@R1# set protocols ospf area 0.0.0.3 interface fe-0/1/0 user@R1# set protocols ospf area 0.0.0.3 interface fe-0/0/1 [edit] user@R2# set protocols ospf area 0.0.0.3 interface fe-0/1/0 user@R2# set protocols ospf area 0.0.0.3 interface fe-1/0/0 [edit] user@R3# set protocols ospf area 0.0.0.3 interface fe-1/0/0 user@R3# set protocols ospf area 0.0.0.3 interface fe-1/1/0 user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/1 [edit] user@R4# set protocols ospf area 0.0.0.0 interface fe-0/0/1


699


user@R4# set protocols ospf area 0.0.0.4 interface fe-1/1/0 user@R4# set protocols ospf area 0.0.0.4 interface fe-1/0/0 [edit] user@R5# set protocols ospf area 0.0.0.4 interface fe-1/1/0 [edit] user@R6# set protocols ospf area 0.0.0.4 interface fe-1/0/0 3.

On R4, configure the export network summary policy. [edit ] user@R4# set policy-options policy-statement export-policy term term1 from route-filter 10.0.4.4/30 prefix-length-range /30-/30 user@R4# set policy-options policy-statement export-policy term term1 then accept

4.

On R4, apply the export network summary policy to OSPF.

NOTE: For OSPFv3, include the inter-area-prefix-export statement at the [edit protocols ospf3 area area-id] hierarchy level.

[edit] user@R4# set protocols ospf area 0.0.0.4 network-summary-export export-policy 5.


Results

Confirm your configuration by entering the show interfaces, show policy-options, and show protocols ospf commands on the appropriate device. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Output for R1: user@R1# show interfaces fe-0/0/1 { unit 0 { family inet { address 10.0.4.5/30; } } } fe-1/1/0 { unit 0 { family inet { address 10.0.4.13/30; } } } user@R1# show protocols ospf area 0.0.0.3 { interface fe-0/1/0.0;

700




Output for R2: user@R2# show interfaces fe-0/1/0 { unit 0 { family inet { address 10.0.4.6/30; } } } fe-1/0/0 { unit 0 { family inet { address 10.0.4.3/30; } } } user@R2# show protocols ospf area 0.0.0.3 { interface fe-0/1/0.0; interface fe-1/0/0.0; }

Output for R3: user@R3# show interfaces fe-0/0/1 { unit 0 { family inet { address 10.0.2.3/30; } } } fe-1/0/0 { unit 0 { family inet { address 10.0.4.2/30; } } } fe-1/1/0 { unit 0 { family inet { address 10.0.4.14/30; } } } user@R3# show protocols ospf area 0.0.0.0 { interface fe-0/0/1.0; } area 0.0.0.3 { interface fe-1/0/0.0;


701



Output for R4: user@R4# show interfaces fe-0/0/1 { unit 0 { family inet { address 10.0.2.4/30; } } } fe-1/0/0 { unit 0 { family inet { address 10.0.8.6/30; } } } fe-1/1/0 { unit 0 { family inet { address 10.0.8.3/30; } } } user@R4# show protocols ospf area 0.0.0.0 { interface fe-0/0/1.0; } area 0.0.0.4 { network-summary-export export-policy; interface fe-1/0/0.0; interface fe-1/1/0.0; } user@R4# show policy-options policy-statement export-policy { term term1 { from { route-filter 10.0.4.4/30 prefix-length-range /30-/30; } then accept; } }

Output for R5: user@R5# show interfaces fe-1/1/0 { unit 0 { family inet { address 10.0.8.5/30; } } }

702



user@R5# show protocols ospf area 0.0.0.4 { interface fe-1/1/0.0; }

Output for R6: user@R6# show interfaces fe-1/0/0 { unit 0 { family inet { address 10.0.8.7/30; } } } user@R6# show protocols ospf area 0.0.0.4 { interface fe-1/0/0.0; }

To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show protocols ospf3 commands on the appropriate device.



•


Verifying the OSPF Database Purpose

Verify that the OSPF database for the devices in area 4 includes the interarea route that we permitted on the ABR R4. The other interarea routes that are not specified should age out or no longer be present in the OSPF database.

Action

From operational mode, enter the show ospf database netsummary area 0.0.0.4 command for OSPFv2, and enter the show ospf3 database netsummary area 0.0.0.4 command for OSPFv3. Verifying the Routing Table

Purpose

Action

Verify that the routes corresponding to the rejected network summaries are no longer present in R4’s, R5’s, or R6’s routing table. From operational mode, enter the show route protocol ospf command for both OSPFv2 and OSPFv3.


703


Example: Configuring an OSPF Import Policy for Network Summaries This example shows how to create an OSPF import policy to control the network-summary (Type 3) LSAs that the ABR advertises out of an OSPF area. •


•


•


•




•


Overview OSPF uses network-summary LSAs to transmit route information across area boundaries. Depending on your network environment, you might want to further filter the network-summary LSAs between OSPF areas. For example, if you create OSPF areas to define administrative boundaries, you might not want to advertise internal route information between those areas. To further improve the control of route distribution between multiple OSPF areas, you can configure network summary policies on the ABR for the area that you want to filter the advertisement of network-summary LSAs.

NOTE: For OSPFv3, the LSA is referred to as the interarea prefix LSA and performs the same function as a network-summary LSA performs for OSPFv2. An ABR originates an interarea prefix LSA for each IPv6 prefix that must be advertised into an area. In this topic, the terms network summary policy and network-summary policy are used to describe both OSPFv2 and OSPFv3 functionality.

The following guidelines apply to import network summary policies:

704

•

You should have a thorough understanding of your network before configuring these policies. Incorrect network summary policy configuration might result in an unintended result such as suboptimal routing or dropped traffic.

•

We recommend that you use the route-filter policy match condition for these types of policies.

•

We recommend that you use the accept and reject routing policy terms for these types of policies.



Figure 31 on page 705 shows a sample topology with three OSPF areas. R4 generates network summaries for the routes in area 4 and sends them out of area 4 to area 0. R3 generates network summaries for the routes in area 3 and sends them out of area 3 to area 0.

Figure 31: Sample Topology Used for an OSPF Import Network Summary Policy Area 0.0.0.3

Area 0.0.0.4

Area 0.0.0.0

R5

R1 fe-0/0/1

fe-1/1/0

fe-0/1/0

10.0.8.8

fe-1/1/0

10.0.4.4

fe-1/0/0 fe-0/0/1

10.0.8.4

10.0.4.12 R3

10.0.4.0 fe-1/0/0

fe-0/0/1

R4

fe-1/0/0 10.0.8.8 fe-1/0/0 R6 g040906

R2

fe-0/0/1

fe-1/1/0

In this example, you configure R3 with an import network summary policy named import-policy so R3 only generates network summaries for the route 10.0.4.12/30. The import policy controls the routes and therefore the network summaries that R3 advertises out of area 3, so applying this policy means that R3 only advertises route 10.0.4.12/30 out of area 3. This results in existing network summaries from other interarea routes getting purged from the OSPF database in area 0 and area 4, as well as the routing tables of the devices in areas 0 and area 4. You first define the policy and then apply it to the ABR by including the network-summary-import statement for OSPFv2 or the inter-area-prefix-import statement for OSPFv3. The devices operate as follows: •

R1—Device R1 is an internal router in area 3. Interface fe-0/1/0 has an IP address of 10.0.4.13/30 and connects to R3. Interface fe-0/0/1 has an IP address of 10.0.4.5/30 and connects to R2.

•

R2—Device R2 is an internal router in area 3. Interface fe-0/0/1 has an IP address of 10.0.4.6/30 and connects to R1. Interface fe-1/0/0 has an IP address of 10.0.4.3 and connects to R3.

•


•



705


•


•



To quickly configure an OSPF import policy for network summaries, copy the following commands, removing any line breaks, and then paste the commands into CLI. Configuration on Device R1: [edit] set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30 set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30 set protocols ospf area 0.0.0.3 interface fe-0/1/0 set protocols ospf area 0.0.0.3 interface fe-0/0/1

Configuration on Device R2: [edit] set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30 set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.3/30 set protocols ospf area 0.0.0.3 interface fe-0/1/0 set protocols ospf area 0.0.0.3 interface fe-1/0/0

Configuration on Device R3: [edit] set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30 set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30 set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.3/30 set policy-options policy-statement import-policy term term1 from route-filter 10.0.4.12/30 prefix-length-range /30-/30 set policy-options policy-statement import-policy term term1 then accept set protocols ospf area 0.0.0.3 interface fe-1/0/0 set protocols ospf area 0.0.0.3 interface fe-1/1/0 set protocols ospf area 0.0.0.0 interface fe-0/0/1 set protocols ospf area 0.0.0.3 network-summary-import import-policy

Configuration on Device R4: [edit] set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.4/30 set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.3/30 set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.6/30 set protocols ospf area 0.0.0.0 interface fe-0/0/1 set protocols ospf area 0.0.0.4 interface fe-1/1/0 set protocols ospf area 0.0.0.4 interface fe-1/0/0


Configuration on Device R6:

706



[edit] set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.7/30 set protocols ospf area 0.0.0.4 interface fe-1/0/0


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To configure an configure an OSPF export policy for network summaries: 1.



[edit] user@R1# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30 user@R1# set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30 [edit] user@R2# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30 user@R2# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.3/30 [edit] user@R3# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30 user@R3# set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30 user@R3#set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.3/30 [edit] user@R4# set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.4/30 user@R4# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.3/30 user@R4# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.6/30 [edit] user@R5# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30 [edit] user@R6# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.7/30 2.



[edit] user@R1# set protocols ospf area 0.0.0.3 interface fe-0/1/0 user@R1# set protocols ospf area 0.0.0.3 interface fe-0/0/1 [edit] user@R2# set protocols ospf area 0.0.0.3 interface fe-0/1/0 user@R2# set protocols ospf area 0.0.0.3 interface fe-1/0/0 [edit] user@R3# set protocols ospf area 0.0.0.3 interface fe-1/0/0


707


user@R3# set protocols ospf area 0.0.0.3 interface fe-1/1/0 user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/1 [edit] user@R4# set protocols ospf area 0.0.0.0 interface fe-0/0/1 user@R4# set protocols ospf area 0.0.0.4 interface fe-1/1/0 user@R4# set protocols ospf area 0.0.0.4 interface fe-1/0/0 [edit] user@R5# set protocols ospf area 0.0.0.4 interface fe-1/1/0 [edit] user@R6# set protocols ospf area 0.0.0.4 interface fe-1/0/0 3.

On R3, configure the import network summary policy. [edit ] user@R3# set policy-options policy-statement import-policy term term1 from route-filter 10.0.4.12/30 prefix-length-range /30-/30 user@R3# set policy-options policy-statement export-policy term term1 then accept

4.

On R3, apply the import network summary policy to OSPF.

NOTE: For OSPFv3, include the inter-area-prefix-export statement at the [edit protocols ospf3 area area-id] hierarchy level.

[edit] user@R3# set protocols ospf area 0.0.0.4 network-summary-import import-policy 5.


Results

Confirm your configuration by entering the show interfaces, show policy-options, and show protocols ospf commands on the appropriate device. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. Output for R1: user@R1# show interfaces fe-0/0/1 { unit 0 { family inet { address 10.0.4.5/30; } } } fe-0/1/0 { unit 0 { family inet { address 10.0.4.13/30; } }

708



} user@R1# show protocols ospf area 0.0.0.3 { interface fe-0/1/0.0; interface fe-0/0/1.0; }

Output for R2: user@R2# show interfaces fe-0/1/0 { unit 0 { family inet { address 10.0.4.6/30; } } } fe-1/0/0 { unit 0 { family inet { address 10.0.4.3/30; } } } user@R2# show protocols ospf area 0.0.0.3 { interface fe-0/1/0.0; interface fe-1/0/0.0; }

Output for R3: user@R3# show interfaces fe-0/0/1 { unit 0 { family inet { address 10.0.2.3/30; } } } fe-1/0/0 { unit 0 { family inet { address 10.0.4.2/30; } } } fe-1/1/0 { unit 0 { family inet { address 10.0.4.14/30; } } } user@R3# show protocols ospf


709


area 0.0.0.0 { interface fe-0/0/1.0; } area 0.0.0.3 { network-summary-export export-policy; interface fe-1/0/0.0; interface fe-1/1/0.0; } user@R3# show policy-options policy-statement export-policy { term term1 { from { route-filter 10.0.4.12/30 prefix-length-range /30-/30; } then accept; } }

Output for R4: user@R4# show interfaces fe-0/0/1 { unit 0 { family inet { address 10.0.2.4/30; } } } fe-1/0/0 { unit 0 { family inet { address 10.0.8.6/30; } } } fe-1/1/0 { unit 0 { family inet { address 10.0.8.3/30; } } } user@R4# show protocols ospf area 0.0.0.0 { interface fe-0/0/1.0; } area 0.0.0.4 { interface fe-0/1/0.0; interface fe-1/0/0.0; }

Output for R5: user@R5# show interfaces fe-1/1/0 { unit 0 {

710



family inet { address 10.0.8.5/30; } } } user@R5# show protocols ospf area 0.0.0.4 { interface fe-1/1/0.0; }

Output for R6: user@R6# show interfaces fe-1/0/0 { unit 0 { family inet { address 10.0.8.7/30; } } } user@R6# show protocols ospf area 0.0.0.4 { interface fe-1/0/0.0; }

To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show protocols ospf3 commands on the appropriate device.



•


Verifying the OSPF Database Purpose

Verify that the OSPF database for the devices in area 4 includes the interarea route that we are advertising from R3. Any other routes from area 3 should not be advertised into area 4, so those entries should age out or no longer be present in the OSPF database.

Action

From operational mode, enter the show ospf database netsummary area 0.0.0.4 command for OSPFv2, and enter the show ospf3 database netsummary area 0.0.0.4 command for OSPFv3. Verifying the Routing Table

Purpose

Action

Verify that the specified route is included in R4’s, R5’s, or R6’s routing table. Any other routes from area 3 should not be advertised into area 4. From operational mode, enter the show route protocol ospf command for both OSPFv2 and OSPFv3.


711



•


•


•

Configuring Match Conditions in Routing Policy Terms in the Junos OS Routing Policy Configuration Guide

•

Configuring Actions in Routing Policy Terms in the Junos OS Routing Policy Configuration Guide

Examples: Configuring OSPF and Logical Systems •

OSPF Support for Logical Systems on page 712

•

Example: Configuring OSPF on Logical Systems Within the Same Router on page 713

•

Example: Configuring a Conditional OSPF Default Route Policy on Logical Systems on page 719

•

Example: Configuring an OSPF Default Route Policy on Logical Systems on page 725

•

Example: Configuring an OSPF Import Policy on Logical Systems on page 730

OSPF Support for Logical Systems This topic describes the following information: •

Introduction to Logical Systems on page 712

•

OSPF and Logical Systems on page 712

Introduction to Logical Systems With Junos OS, you can partition a single physical router into multiple logical devices that perform independent routing tasks. Because logical systems perform a subset of the tasks once handled by the main router, logical systems offer an effective way to maximize the use of a single routing or switching platform. Logical systems have their own unique routing tables, interfaces, policies, and routing instances.

OSPF and Logical Systems You can configure both OSPF Version 2 (OSPFv2) and OSPF Version 3 (OSPFv3) for logical systems. In the case of OSPFv3, you can also configure OSPFv3 realms for logical systems, which allows OSPFv3 to advertise address families other than unicast IPv6. You configure OSPF for logical systems at the following hierarchy levels: •

[edit logical-systems logical-system-name protocols (ospf | ospf3)]

•

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

•


•

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

712



Example: Configuring OSPF on Logical Systems Within the Same Router This example shows how to configure an OSPF network using multiple logical systems that are running on a single physical router. The logical systems are connected by logical tunnel interfaces. •


•


•


•


Requirements You must connect the logical systems by using logical tunnel (lt) interfaces. See Example: Connecting Logical Systems Within the Same Router Using Logical Tunnel Interfaces.

Overview This example shows the configuration of a single OSPF area with three logical systems running on one physical router. Each logical system has its own routing table. The configuration enables the protocol on all logical system interfaces that participate in the OSPF domain and specifies the area that the interfaces are in. Figure 32 on page 713 shows the sample network.

Figure 32: OSPF on Logical Systems Router 1

Area 0.0.0.0

LS1

lt-1/2/0.0 10.0.1.2

lt-1/2/0.2 10.0.0.1

lt-1/2/0.5 10.0.1.1 LS3 lt-1/2/0.3 10.0.2.1

lt-1/2/0.1 10.0.0.2 lt-1/2/0.4 10.0.2.2

g040567

LS2


713



To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems LS1 interfaces lt-1/2/0 unit 0 description LS1->LS3 set logical-systems LS1 interfaces lt-1/2/0 unit 0 encapsulation ethernet set logical-systems LS1 interfaces lt-1/2/0 unit 0 peer-unit 5 set logical-systems LS1 interfaces lt-1/2/0 unit 0 family inet address 10.0.1.2/30 set logical-systems LS1 interfaces lt-1/2/0 unit 2 description LS1->LS2 set logical-systems LS1 interfaces lt-1/2/0 unit 2 encapsulation ethernet set logical-systems LS1 interfaces lt-1/2/0 unit 2 peer-unit 1 set logical-systems LS1 interfaces lt-1/2/0 unit 2 family inet address 10.0.0.1/30 set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.0 set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.2 set logical-systems LS2 interfaces lt-1/2/0 unit 1 description LS2->LS1 set logical-systems LS2 interfaces lt-1/2/0 unit 1 encapsulation ethernet set logical-systems LS2 interfaces lt-1/2/0 unit 1 peer-unit 2 set logical-systems LS2 interfaces lt-1/2/0 unit 1 family inet address 10.0.0.2/30 set logical-systems LS2 interfaces lt-1/2/0 unit 4 description LS2->LS3 set logical-systems LS2 interfaces lt-1/2/0 unit 4 encapsulation ethernet set logical-systems LS2 interfaces lt-1/2/0 unit 4 peer-unit 3 set logical-systems LS2 interfaces lt-1/2/0 unit 4 family inet address 10.0.2.2/30 set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.1 set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.4 set logical-systems LS3 interfaces lt-1/2/0 unit 3 description LS3->LS2 set logical-systems LS3 interfaces lt-1/2/0 unit 3 encapsulation ethernet set logical-systems LS3 interfaces lt-1/2/0 unit 3 peer-unit 4 set logical-systems LS3 interfaces lt-1/2/0 unit 3 family inet address 10.0.2.1/30 set logical-systems LS3 interfaces lt-1/2/0 unit 5 description LS3->LS1 set logical-systems LS3 interfaces lt-1/2/0 unit 5 encapsulation ethernet set logical-systems LS3 interfaces lt-1/2/0 unit 5 peer-unit 0 set logical-systems LS3 interfaces lt-1/2/0 unit 5 family inet address 10.0.1.1/30 set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.5 set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.3


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure OSPF on logical systems: 1.

Configure the logical tunnel interface on Logical System LS1 connecting to Logical System LS2. [edit] user@host# set logical-systems LS1 interfaces lt-1/2/0 unit 2 description LS1->LS2 user@host# set logical-systems LS1 interfaces lt-1/2/0 unit 2 encapsulation ethernet user@host# set logical-systems LS1 interfaces lt-1/2/0 unit 2 peer-unit 1 user@host# set logical-systems LS1 interfaces lt-1/2/0 unit 2 family inet address 10.0.0.1/30

714



2.


3.


4.


5.


6.


7.

Configure OSPF on all the interfaces. [edit] user@host# set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.0 user@host# set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.2 user@host# set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.1 user@host# set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.4 user@host# set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.5 user@host# set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.3


715


8.


Results

Confirm your configuration by issuing the show logical-systems command. show logical-systems LS1 { interfaces { lt-1/2/0 { unit 0 { description LS1->LS3; encapsulation ethernet; peer-unit 5; family inet { address 10.0.1.2/30; } } unit 2 { description LS1->LS2; encapsulation ethernet; peer-unit 1; family inet { address 10.0.0.1/30; } } } } protocols { ospf { area 0.0.0.0 { interface lt-1/2/0.0; interface lt-1/2/0.2; } } } } LS2 { interfaces { lt-1/2/0 { unit 1 { description LS2->LS1; encapsulation ethernet; peer-unit 2; family inet { address 10.0.0.2/30; } } unit 4 { description LS2->LS3; encapsulation ethernet; peer-unit 3; family inet { address 10.0.2.2/30;

716



} } } } protocols { ospf { area 0.0.0.0 { interface lt-1/2/0.1; interface lt-1/2/0.4; } } } } LS3 { interfaces { lt-1/2/0 { unit 3 { description LS3->LS2; encapsulation ethernet; peer-unit 4; family inet { address 10.0.2.1/30; } } unit 5 { description LS3->LS1; encapsulation ethernet; peer-unit 0; family inet { address 10.0.1.1/30; } } } } protocols { ospf { area 0.0.0.0 { interface lt-1/2/0.5; interface lt-1/2/0.3; } } } }


Verifying That the Logical Systems Are Up on page 717

•

Verifying Connectivity Between the Logical Systems on page 718

Verifying That the Logical Systems Are Up Purpose

Make sure that the interfaces are properly configured.


717


Action

user@host> show interfaces terse Interface Admin ... lt-1/2/0 up lt-1/2/0.0 up lt-1/2/0.1 up lt-1/2/0.2 up lt-1/2/0.3 up lt-1/2/0.4 up lt-1/2/0.5 up ...

Link Proto

Local

up up up up up up up

10.0.1.2/30 10.0.0.2/30 10.0.0.1/30 10.0.2.1/30 10.0.2.2/30 10.0.1.1/30

inet inet inet inet inet inet

Remote

Verifying Connectivity Between the Logical Systems Purpose

Action

Make sure that the OSPF adjacencies are established by checking the OSPF neighbor tables, checking the routing tables, and pinging the logical systems. user@host> show ospf neighbor logical-system LS1 Address Interface State 10.0.1.1 lt-1/2/0.0 Full 10.0.0.2 lt-1/2/0.2 Full

ID 10.0.1.1 10.0.0.2

Pri 128 128

Dead 37 33

user@host> show ospf neighbor logical-system LS2 Address Interface State 10.0.0.1 lt-1/2/0.1 Full 10.0.2.1 lt-1/2/0.4 Full

ID 10.0.0.1 10.0.1.1

Pri 128 128

Dead 32 36

user@host> show ospf neighbor logical-system LS3 Address Interface State 10.0.2.2 lt-1/2/0.3 Full 10.0.1.2 lt-1/2/0.5 Full

ID 10.0.0.2 10.0.0.1

Pri 128 128

Dead 36 37

user@host> show route logical-system LS1 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30 10.0.0.1/32 10.0.1.0/30 10.0.1.2/32 10.0.2.0/30

224.0.0.5/32

*[Direct/0] 00:28:00 > via lt-1/2/0.2 *[Local/0] 00:28:00 Local via lt-1/2/0.2 *[Direct/0] 00:28:00 > via lt-1/2/0.0 *[Local/0] 00:28:00 Local via lt-1/2/0.0 *[OSPF/10] 00:27:05, metric 2 > to 10.0.1.1 via lt-1/2/0.0 to 10.0.0.2 via lt-1/2/0.2 *[OSPF/10] 00:28:03, metric 1 MultiRecv


718

*[Direct/0] 00:28:31 > via lt-1/2/0.1 *[Local/0] 00:28:32 Local via lt-1/2/0.1 *[OSPF/10] 00:27:38, metric 2



10.0.2.0/30 10.0.2.2/32 224.0.0.5/32

> to 10.0.0.1 via lt-1/2/0.1 to 10.0.2.1 via lt-1/2/0.4 *[Direct/0] 00:28:32 > via lt-1/2/0.4 *[Local/0] 00:28:32 Local via lt-1/2/0.4 *[OSPF/10] 00:28:34, metric 1 MultiRecv

user@host> show route logical-system LS3 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30

10.0.1.0/30 10.0.1.1/32 10.0.2.0/30 10.0.2.1/32 224.0.0.5/32

From LS1, Ping LS3

*[OSPF/10] 00:28:23, metric 2 > to 10.0.2.2 via lt-1/2/0.3 to 10.0.1.2 via lt-1/2/0.5 *[Direct/0] 00:29:13 > via lt-1/2/0.5 *[Local/0] 00:29:15 Local via lt-1/2/0.5 *[Direct/0] 00:29:14 > via lt-1/2/0.3 *[Local/0] 00:29:15 Local via lt-1/2/0.3 *[OSPF/10] 00:29:16, metric 1 MultiRecv

user@host> set cli logical-system LS1 user@host:LS1> ping 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=1.215 ms 64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=1.150 ms 64 bytes from 10.0.2.1: icmp_seq=2 ttl=64 time=1.134 ms

From LS3, Ping LS1

user@host> set cli logical-system LS3 user@host:LS3> ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=1.193 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=1.114 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=1.190 ms

Example: Configuring a Conditional OSPF Default Route Policy on Logical Systems This example shows how to configure a conditional default route on one logical system and inject the default route into OSPF area 0. •


•


•


•



719




•

Enable OSPF on the interfaces. See “Example: Configuring OSPF on Logical Systems Within the Same Router” on page 713.

Overview In this example, OSPF area 0 contains three logical systems that are configured on a single physical router. One logical system has a default route to an external peer, for example, an ISP. The route policy is conditional such that if the connection to the external peer goes down, the default route is no longer active in the routing tables of the logical systems in area 0. This policy prevents blackholing of traffic. Blackholing occurs when packets are dropped without notification. In this example, the default route is not used for forwarding traffic. The no-install statement prevents the route from being installed in the forwarding table of Logical System LS3. If you configure a route so it is not installed in the forwarding table, the route is still eligible to be exported from the routing table to other protocols. Figure 33 on page 720 shows the sample network.

Figure 33: OSPF with a Conditional Default Route to an ISP Router 1

Area 0.0.0.0

LS1

lt-1/2/0.0 10.0.1.2

lt-1/2/0.2 10.0.0.1

lt-1/2/0.5 10.0.1.1

so-0/0/2 10.0.45.2

LS3 lt-1/2/0.3 10.0.2.1

ISP

so-0/0/2 10.0.45.2

lt-1/2/0.1 10.0.0.2 lt-1/2/0.4 10.0.2.2

g040570

LS2

720




To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems LS3 interfaces so-0/0/2 unit 0 family inet address 10.0.45.2/30 set logical-systems LS3 routing-options static route 0.0.0.0/0 next-hop 10.0.45.1 set logical-systems LS3 routing-options static route 0.0.0.0/0 no-install set logical-systems LS3 policy-options policy-statement ospf-default from protocol static set logical-systems LS3 policy-options policy-statement ospf-default from route-filter 0.0.0.0/0 exact set logical-systems LS3 policy-options policy-statement ospf-default then accept set logical-systems LS3 protocols ospf export ospf-default


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure an OSPF conditional default route policy on logical systems: 1.

On Logical System LS3, configure the ISP peering interface. [edit] user@host# set logical-systems LS3 interfaces so-0/0/2 unit 0 family inet address 10.0.45.2/30

2.

Change the context to Logical System LS3. [edit] user@host> set cli logical-system LS3

3.

Configure the default route on Logical System LS3. [edit] user@host:LS3# set routing-options static route 0.0.0.0/0 next-hop 10.0.45.1 user@host:LS3# set routing-options static route 0.0.0.0/0 no-install

4.

Configure the policy on Logical System LS3. [edit] user@host:LS3# set policy-options policy-statement ospf-default from protocol static user@host:LS3# set policy-options policy-statement ospf-default from route-filter 0.0.0.0/0 exact user@host:LS3# set policy-options policy-statement ospf-default then accept

5.

Apply the export policy to OSPF on Logical System LS3. [edit] user@host:LS3# set protocols ospf export ospf-default

6.

If you are done configuring the device, commit the configuration. [edit]


721


user@host:LS3# commit

Results

Confirm your configuration by issuing the show logical-systems LS3 command. show logical-systems LS3 interfaces { so-0/0/2 { unit 0 { family inet { address 10.0.45.2/30; } } } lt-1/2/0 { unit 3 { description LS3->LS2; encapsulation ethernet; peer-unit 4; family inet { address 10.0.2.1/30; } } unit 5 { description LS3->LS1; encapsulation ethernet; peer-unit 0; family inet { address 10.0.1.1/30; } } } } protocols { ospf { export ospf-default; area 0.0.0.0 { interface lt-1/2/0.5; interface lt-1/2/0.3; } } } policy-options { policy-statement ospf-default { from { protocol static; route-filter 0.0.0.0/0 exact; } then accept; } } routing-options { static { route 0.0.0.0/0 { next-hop 10.0.45.1; no-install;

722



} } }


Verifying that the Route to the ISP Is Working on page 723

•

Verifying That the Static Route Is Redistributed on page 723

•

Testing the Policy Condition on page 724

Verifying that the Route to the ISP Is Working Purpose Action

Make sure connectivity is established between Logical System LS3 and the ISP’s router. user@host> show route logical-system LS3 inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.0.0.0/30

10.0.1.0/30 10.0.1.1/32 10.0.2.0/30 10.0.2.1/32 10.0.45.0/30 10.0.45.2/32 224.0.0.5/32

*[Static/5] 00:00:01 > to 10.0.45.1 via so-0/0/2.0 *[OSPF/10] 2d 15:02:55, metric 2 to 10.0.2.2 via lt-1/2/0.3 > to 10.0.1.2 via lt-1/2/0.5 *[Direct/0] 2d 15:03:50 > via lt-1/2/0.5 *[Local/0] 2d 15:03:54 Local via lt-1/2/0.5 *[Direct/0] 2d 15:03:50 > via lt-1/2/0.3 *[Local/0] 2d 15:03:54 Local via lt-1/2/0.3 *[Direct/0] 00:00:01 > via so-0/0/2.0 *[Local/0] 04:12:09 Local via so-0/0/2.0 *[OSPF/10] 2d 15:05:55, metric 1 MultiRecv

user@host>set cli logical-system LS3 Logical system: LS3 user@host:LS3>ping 10.0.45.1 PING 10.0.45.1 (10.0.45.1): 56 data 64 bytes from 10.0.45.1: icmp_seq=0 64 bytes from 10.0.45.1: icmp_seq=1 64 bytes from 10.0.45.1: icmp_seq=2

Meaning

bytes ttl=64 time=1.185 ms ttl=64 time=1.199 ms ttl=64 time=1.186 ms

The routing table shows that the route to the 10.0.45.0 network is reachable. The ping command confirms reachability. Verifying That the Static Route Is Redistributed

Purpose

Make sure that the OSPF policy is redistributing the static route by checking the routing tables of Logical System LS1 and Logical System LS2.


723


Action

user@host> show route logical-system LS1 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.0.0.0/30 10.0.0.1/32 10.0.1.0/30 10.0.1.2/32 10.0.2.0/30

224.0.0.5/32

*[OSPF/150] 00:16:33, metric 0, tag 0 > to 10.0.1.1 via lt-1/2/0.0 *[Direct/0] 2d 15:20:23 > via lt-1/2/0.2 *[Local/0] 2d 15:20:27 Local via lt-1/2/0.2 *[Direct/0] 2d 15:20:23 > via lt-1/2/0.0 *[Local/0] 2d 15:20:27 Local via lt-1/2/0.0 *[OSPF/10] 2d 15:19:33, metric 2 > to 10.0.1.1 via lt-1/2/0.0 to 10.0.0.2 via lt-1/2/0.2 *[OSPF/10] 2d 15:22:27, metric 1 MultiRecv

user@host> show route logical-system LS2 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.0.0.0/30 10.0.0.2/32 10.0.1.0/30

10.0.2.0/30 10.0.2.2/32 224.0.0.5/32

Meaning

*[OSPF/150] 00:15:44, metric 0, tag 0 > to 10.0.2.1 via lt-1/2/0.4 *[Direct/0] 2d 15:19:34 > via lt-1/2/0.1 *[Local/0] 2d 15:19:38 Local via lt-1/2/0.1 *[OSPF/10] 2d 15:18:39, metric 2 > to 10.0.0.1 via lt-1/2/0.1 to 10.0.2.1 via lt-1/2/0.4 *[Direct/0] 2d 15:19:34 > via lt-1/2/0.4 *[Local/0] 2d 15:19:38 Local via lt-1/2/0.4 *[OSPF/10] 2d 15:21:38, metric 1 MultiRecv

The routing tables on Logical System LS1 and Logical System LS2 contain the default 0.0.0.0/0 route from protocol OSPF. If Logical System LS1 and Logical System LS2 receive packets destined for networks not specified in their routing tables, those packets will be sent to Logical System LS3 for further processing. Testing the Policy Condition

Purpose

Action

Deactivate the interface to make sure that the route is removed from the routing tables if the external network becomes unreachable. user@host> deactivate logical-system LS3 interface so-0/0/2 user@host> commit user@host> show route logical-system LS1 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both

724



10.0.0.0/30 10.0.0.1/32 10.0.1.0/30 10.0.1.2/32 10.0.2.0/30

224.0.0.5/32

*[Direct/0] 2d 15:22:37 > via lt-1/2/0.2 *[Local/0] 2d 15:22:41 Local via lt-1/2/0.2 *[Direct/0] 2d 15:22:37 > via lt-1/2/0.0 *[Local/0] 2d 15:22:41 Local via lt-1/2/0.0 *[OSPF/10] 2d 15:21:47, metric 2 > to 10.0.1.1 via lt-1/2/0.0 to 10.0.0.2 via lt-1/2/0.2 *[OSPF/10] 2d 15:24:41, metric 1 MultiRecv


10.0.2.0/30 10.0.2.2/32 224.0.0.5/32

Meaning

*[Direct/0] 2d 15:22:17 > via lt-1/2/0.1 *[Local/0] 2d 15:22:21 Local via lt-1/2/0.1 *[OSPF/10] 2d 15:21:22, metric 2 > to 10.0.0.1 via lt-1/2/0.1 to 10.0.2.1 via lt-1/2/0.4 *[Direct/0] 2d 15:22:17 > via lt-1/2/0.4 *[Local/0] 2d 15:22:21 Local via lt-1/2/0.4 *[OSPF/10] 2d 15:24:21, metric 1 MultiRecv

The routing tables on Logical System LS1 and Logical System LS2 do not contain the default 0.0.0.0/0. This verifies that the default route is no longer present in the OSPF domain. To reactivate the so-0/0/2 interface, issue the activate logical-systems LS3 interfaces so-0/0/2 configuration-mode command.

Example: Configuring an OSPF Default Route Policy on Logical Systems This example shows how to configure a default route on one logical system and inject the default route into OSPF area 0. In this example, OSPF area 0 contains three logical systems that are configured on a single physical router. •


•


•


•





725


•

Enable OSPF on the interfaces. See “Example: Configuring OSPF on Logical Systems Within the Same Router” on page 713.

Overview This example shows a logical system redistributing a default route to other logical systems. All logical systems are running OSPF. A common reason for a default route is to provide a path for sending traffic destined outside the OSPF domain. In this example, the default route is not used for forwarding traffic. The no-install statement prevents the route from being installed in the forwarding table of Logical System LS3. If you configure a route so it is not installed in the forwarding table, the route is still eligible to be exported from the routing table to other protocols. The discard statement silently drops packets without notice. Figure 34 on page 726 shows the sample network.

Figure 34: OSPF with a Default Route to an ISP Router 1

Area 0.0.0.0

LS1

lt-1/2/0.0 10.0.1.2

lt-1/2/0.2 10.0.0.1

lt-1/2/0.5 10.0.1.1 LS3 lt-1/2/0.3 10.0.2.1

lt-1/2/0.1 10.0.0.2 lt-1/2/0.4 10.0.2.2

g040569

LS2

ISP


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems LS3 routing-options static route 0.0.0.0/0 discard set logical-systems LS3 routing-options static route 0.0.0.0/0 no-install set logical-systems LS3 policy-options policy-statement ospf-default from protocol static

726



set logical-systems LS3 policy-options policy-statement ospf-default from route-filter 0.0.0.0/0 exact set logical-systems LS3 policy-options policy-statement ospf-default then accept set logical-systems LS3 protocols ospf export ospf-default


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure an OSPF default route policy on logical systems: 1.

Change the context to Logical System LS3. [edit] user@host> set cli logical-system LS3

2.

Configure the default route on Logical System LS3. [edit] user@host:LS3# set routing-options static route 0.0.0.0/0 discard user@host:LS3# set routing-options static route 0.0.0.0/0 no-install

3.

Configure the policy on Logical System LS3. [edit] user@host:LS3# set policy-options policy-statement ospf-default from protocol static user@host:LS3# set policy-options policy-statement ospf-default from route-filter 0.0.0.0/0 exact user@host:LS3# set policy-options policy-statement ospf-default then accept

4.

Apply the export policy to OSPF on Logical System LS3. [edit] user@host:LS3# set protocols ospf export ospf-default

5.

If you are done configuring the device, commit the configuration. [edit] user@host:LS3# commit

Results

Confirm your configuration by issuing the show logical-systems LS3 command. show logical-systems LS3 interfaces { lt-1/2/0 { unit 3 { description LS3->LS2; encapsulation ethernet; peer-unit 4; family inet { address 10.0.2.1/30; } } unit 5 { description LS3->LS1; encapsulation ethernet;


727


peer-unit 0; family inet { address 10.0.1.1/30; } } } } protocols { ospf { export ospf-default; area 0.0.0.0 { interface lt-1/2/0.5; interface lt-1/2/0.3; } } } policy-options { policy-statement ospf-default { from { protocol static; route-filter 0.0.0.0/0 exact; } then accept; } } routing-options { static { route 0.0.0.0/0 { discard; no-install; } } }

Verification Confirm that the configuration is working properly. Verifying That the Static Route Is Redistributed Purpose Action

Make sure that the OSPF policy is working by checking the routing tables. user@host> show route logical-system LS3 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.0.0.0/30

10.0.1.0/30 10.0.1.1/32 10.0.2.0/30

728

*[Static/5] 01:04:38 Discard *[OSPF/10] 11:53:55, metric 2 to 10.0.2.2 via lt-1/2/0.3 > to 10.0.1.2 via lt-1/2/0.5 *[Direct/0] 11:54:50 > via lt-1/2/0.5 *[Local/0] 11:54:54 Local via lt-1/2/0.5 *[Direct/0] 11:54:50 > via lt-1/2/0.3



10.0.2.1/32 224.0.0.5/32

*[Local/0] 11:54:54 Local via lt-1/2/0.3 *[OSPF/10] 11:56:55, metric 1 MultiRecv

user@host> show route logical-system LS1 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.0.0.0/30 10.0.0.1/32 10.0.1.0/30 10.0.1.2/32 10.0.2.0/30

224.0.0.5/32

*[OSPF/150] 01:02:34, metric 0, tag 0 > to 10.0.1.1 via lt-1/2/0.0 *[Direct/0] 11:52:46 > via lt-1/2/0.2 *[Local/0] 11:52:50 Local via lt-1/2/0.2 *[Direct/0] 11:52:46 > via lt-1/2/0.0 *[Local/0] 11:52:50 Local via lt-1/2/0.0 *[OSPF/10] 11:51:56, metric 2 > to 10.0.1.1 via lt-1/2/0.0 to 10.0.0.2 via lt-1/2/0.2 *[OSPF/10] 11:54:50, metric 1 MultiRecv

user@host> show route logical-system LS2 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.0.0.0/30 10.0.0.2/32 10.0.1.0/30

10.0.2.0/30 10.0.2.2/32 224.0.0.5/32

Meaning

*[OSPF/150] 01:05:20, metric 0, tag 0 > to 10.0.2.1 via lt-1/2/0.4 *[Direct/0] 11:55:32 > via lt-1/2/0.1 *[Local/0] 11:55:36 Local via lt-1/2/0.1 *[OSPF/10] 11:54:37, metric 2 > to 10.0.0.1 via lt-1/2/0.1 to 10.0.2.1 via lt-1/2/0.4 *[Direct/0] 11:55:32 > via lt-1/2/0.4 *[Local/0] 11:55:36 Local via lt-1/2/0.4 *[OSPF/10] 11:57:36, metric 1 MultiRecv

The routing table on Logical System LS3 contains the default 0.0.0.0/0 route from protocol Static. The routing tables on Logical System LS1 and Logical System LS2 contain the default 0.0.0.0/0 route from protocol OSPF. If Logical System LS1 and Logical System LS2 receive packets destined for networks not specified in their routing tables, those packets will be sent to Logical System LS3 for further processing. This configuration assumes that Logical System LS3 has a connection to an ISP or another external network.


729


Example: Configuring an OSPF Import Policy on Logical Systems This example shows how to configure an OSPF import policy on logical systems. OSPF import policies apply to external routes only. An external route is a route that is outside the OSPF AS. •


•


•


•


Requirements This example shows logical systems that are configured within a single physical router. The logical systems connect to each other by using logical tunnel (lt) interfaces. See Example: Connecting Logical Systems Within the Same Router Using Logical Tunnel Interfaces. Alternatively, you can use multiple physical routers.

Overview External routes are learned by Autonomous System Border Routers (ASBRs). External routes can be advertised throughout the OSPF domain if you configure the ASBR to redistribute the route into OSPF. An external route might be learned by the ASBR from a routing protocol other than OSPF, or the external route might be a static route that you configure on the ASBR. OSPF import policy allows you to prevent external routes from being added to the routing tables of OSPF neighbors. The import policy does not impact the OSPF database. This means that the import policy has no impact on the link-state advertisements. OSPF import policies have practical applications. Suppose, for example, that you are using OSPF to advertise a static route to the devices in your datacenter because you want some of the devices in the datacenter to use the static route. However, you want other devices in the datacenter to ignore the static route. So, you apply the OSPF import policy on the devices that you want to ignore the static route. The filtering is done only on external routes in OSPF. The intra-area and inter-area routes are not considered for filtering. The default action is to accept the route when the route does not match the policy. Figure 35 on page 731 shows the sample network.

730



Figure 35: OSPF Import Policy on Logical Systems R1

Area 0.0.0.0 LS1 lt-1/2/0.2 10.0.0.1 LS3

R2

10.0.16.0/30

lt-1/2/0.3 10.0.2.1

lt-1/2/0.1 10.0.0.2 lt-1/2/0.4 10.0.2.2

g040580

LS2

10.0.60.1/30 10.0.60.2/30

In this example, the logical systems operate as follows: 1.

LS3—Logical System LS3 has a static route to the 10.0.16.0/30 network. The next hop for the static route is 10.0.60.1. LS3 has an OSPF export policy configured. The export policy redistributes static routes from LS3’s routing table into LS3’s OSPF database. Because the static route is in LS3’s OSPF database, the route is advertised in a link state advertisement (LSA) to LS3’s OSPF neighbor. LS3’s OSPF neighbor is Logical System LS2.

2. LS2—Logical System LS2 receives the route advertisement from LS3. LS2 then installs

the route into LS2’s OSPF database. LS2 has an OSPF import policy configured that matches the static route to the 10.0.16.0/30 network and prevents the static route from being installed in LS2’s routing table. However, because the route is in LS2’s OSPF database, LS2 advertises the route to its OSPF neighbor, Logical System LS1. 3. LS1—Logical System LS1 receives the route advertisement from LS2. LS1 then installs

the route into LS1’s OSPF database. LS1 does not have an OSPF import policy configured that matches the static route to the 10.0.16.0/30 network . Therefore, the route gets installed in LS1’s routing table.

Configuration •


LS3


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems LS3 interfaces so-0/0/0 unit 0 family inet address 10.0.60.2/30 set logical-systems LS3 interfaces lt-1/2/0 unit 3 description LS3->LS2 set logical-systems LS3 interfaces lt-1/2/0 unit 3 encapsulation ethernet set logical-systems LS3 interfaces lt-1/2/0 unit 3 peer-unit 4 set logical-systems LS3 interfaces lt-1/2/0 unit 3 family inet address 10.0.2.1/30


731


set logical-systems LS3 protocols ospf export export_static set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.3 set logical-systems LS3 policy-options policy-statement export_static from protocol static set logical-systems LS3 policy-options policy-statement export_static then accept set logical-systems LS3 routing-options static route 10.0.16.0/30 next-hop 10.0.60.1

LS2

set logical-systems LS2 interfaces lt-1/2/0 unit 1 description LS2->LS1 set logical-systems LS2 interfaces lt-1/2/0 unit 1 encapsulation ethernet set logical-systems LS2 interfaces lt-1/2/0 unit 1 peer-unit 2 set logical-systems LS2 interfaces lt-1/2/0 unit 1 family inet address 10.0.0.2/30 set logical-systems LS2 interfaces lt-1/2/0 unit 4 description LS2->LS3 set logical-systems LS2 interfaces lt-1/2/0 unit 4 encapsulation ethernet set logical-systems LS2 interfaces lt-1/2/0 unit 4 peer-unit 3 set logical-systems LS2 interfaces lt-1/2/0 unit 4 family inet address 10.0.2.2/30 set logical-systems LS2 protocols ospf import filter_routes set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.1 set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.4 set logical-systems LS2 policy-options policy-statement filter_routes from route-filter 10.0.16.0/30 exact set logical-systems LS2 policy-options policy-statement filter_routes then reject

LS1

set logical-systems LS1 interfaces lt-1/2/0 unit 2 description LS1->LS2 set logical-systems LS1 interfaces lt-1/2/0 unit 2 encapsulation ethernet set logical-systems LS1 interfaces lt-1/2/0 unit 2 peer-unit 1 set logical-systems LS1 interfaces lt-1/2/0 unit 2 family inet address 10.0.0.1/30 set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.2


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure an OSPF import policy on logical systems: 1.

Configure the interfaces. [edit] user@R1# set logical-systems LS3 interfaces so-0/0/0 unit 0 family inet address 10.0.60.2/30 user@R1# set logical-systems LS3 interfaces lt-1/2/0 unit 3 description LS3->LS2 user@R1# set logical-systems LS3 interfaces lt-1/2/0 unit 3 encapsulation ethernet user@R1# set logical-systems LS3 interfaces lt-1/2/0 unit 3 peer-unit 4 user@R1# set logical-systems LS3 interfaces lt-1/2/0 unit 3 family inet address 10.0.2.1/30 user@R1# set logical-systems LS2 interfaces lt-1/2/0 unit 1 description LS2->LS1 user@R1# set logical-systems LS2 interfaces lt-1/2/0 unit 1 encapsulation ethernet user@R1# set logical-systems LS2 interfaces lt-1/2/0 unit 1 peer-unit 2 user@R1# set logical-systems LS2 interfaces lt-1/2/0 unit 1 family inet address 10.0.0.2/30 user@R1# set logical-systems LS2 interfaces lt-1/2/0 unit 4 description LS2->LS3 user@R1# set logical-systems LS2 interfaces lt-1/2/0 unit 4 encapsulation ethernet user@R1# set logical-systems LS2 interfaces lt-1/2/0 unit 4 peer-unit 3 user@R1# set logical-systems LS2 interfaces lt-1/2/0 unit 4 family inet address 10.0.2.2/30 user@R1# set logical-systems LS1 interfaces lt-1/2/0 unit 2 description LS1->LS2

732



user@R1# set logical-systems LS1 interfaces lt-1/2/0 unit 2 encapsulation ethernet user@R1# set logical-systems LS1 interfaces lt-1/2/0 unit 2 peer-unit 1 user@R1# set logical-systems LS1 interfaces lt-1/2/0 unit 2 family inet address 10.0.0.1/30 2.

Enable OSPF on the interfaces. [edit] user@R1# set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.3 user@R1# set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.1 user@R1# set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.4 user@R1# set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.2

3.

Configure the static route on Logical System LS3. [edit] user@R1# set logical-systems LS3 routing-options static route 10.0.16.0/30 next-hop 10.0.60.1

4.

On Logical System LS3, redistribute the static route into OSPF. [edit] user@R1# set logical-systems LS3 protocols ospf export export_static user@R1# set logical-systems LS3 policy-options policy-statement export_static from protocol static user@R1# set logical-systems LS3 policy-options policy-statement export_static then accept

5.

On Logical System LS2, configure the OSPF import policy. [edit] user@R1# set logical-systems LS2 protocols ospf import filter_routes user@R1# set logical-systems LS2 policy-options policy-statement filter_routes from route-filter 10.0.16.0/30 exact user@R1# set logical-systems LS2 policy-options policy-statement filter_routes then reject

6.

If you are done configuring the device, commit the configuration. [edit] user@R1# commit

Results

Confirm your configuration by issuing the show logical-systems command. user@R1# show logical-systems LS1 { interfaces { lt-1/2/0 { unit 2 { description LS1->LS2; encapsulation ethernet; peer-unit 1; family inet { address 10.0.0.1/30; } } } }


733


protocols { ospf { area 0.0.0.0 { interface lt-1/2/0.2; } } } } LS2 { interfaces { lt-1/2/0 { unit 1 { description LS2->LS1; encapsulation ethernet; peer-unit 2; family inet { address 10.0.0.2/30; } } unit 4 { description LS2->LS3; encapsulation ethernet; peer-unit 3; family inet { address 10.0.2.2/30; } } } } protocols { ospf { import filter_routes; area 0.0.0.0 { interface lt-1/2/0.1; interface lt-1/2/0.4; } } } policy-options { policy-statement filter_routes { from { route-filter 10.0.16.0/30 exact; } then reject; } } } LS3 { interfaces { so-0/0/0 { unit 0 { family inet { address 10.0.60.2/30; } } }

734



lt-1/2/0 { unit 3 { description LS3->LS2; encapsulation ethernet; peer-unit 4; family inet { address 10.0.2.1/30; } } } } protocols { ospf { export export_static; area 0.0.0.0 { interface lt-1/2/0.3; } } } policy-options { policy-statement export_static { from protocol static; then accept; } } routing-options { static { route 10.0.16.0/30 next-hop 10.0.60.1; } } }


Viewing the OSPF Databases of the Logical Systems on page 735

•

Viewing the Routing Tables of the Logical Systems on page 736

Viewing the OSPF Databases of the Logical Systems Purpose Action

Verify that OSPF is advertising the static route. user@R1> show ospf database logical-system all logical-system: LS2 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Router 10.0.0.1 10.0.0.1 Router *10.0.0.2 10.0.0.2 Router 10.0.2.1 10.0.2.1 Network 10.0.0.1 10.0.0.1 Network 10.0.2.1 10.0.2.1 OSPF AS SCOPE link state database Type ID Adv Rtr Extern 10.0.16.0 10.0.2.1


Seq 0x8000001f 0x80000025 0x80000018 0x80000001 0x8000000c

Age 107 101 107 107 190

Seq 0x80000007

Age 1785

Opt 0x22 0x22 0x22 0x22 0x22

Cksum Len 0x8f59 36 0x4074 48 0xab3a 36 0x7b94 32 0x53ab 32

Opt Cksum Len 0x22 0x4147 36

735


----logical-system: LS1 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Router *10.0.0.1 10.0.0.1 Router 10.0.0.2 10.0.0.2 Router 10.0.2.1 10.0.2.1 Network *10.0.0.1 10.0.0.1 Network 10.0.2.1 10.0.2.1 OSPF AS SCOPE link state database Type ID Adv Rtr Extern 10.0.16.0 10.0.2.1 -----

Seq 0x8000001f 0x80000025 0x80000018 0x80000001 0x8000000c

Age 107 103 109 107 192

Seq 0x80000007

Age 1787

Seq 0x8000001f 0x80000025 0x80000018 0x80000001 0x8000000c

Age 109 103 107 109 190

Seq 0x80000007

Age 1785

Opt 0x22 0x22 0x22 0x22 0x22



logical-system: LS3 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Router 10.0.0.1 10.0.0.1 Router 10.0.0.2 10.0.0.2 Router *10.0.2.1 10.0.2.1 Network 10.0.0.1 10.0.0.1 Network *10.0.2.1 10.0.2.1 OSPF AS SCOPE link state database Type ID Adv Rtr Extern *10.0.16.0 10.0.2.1 ...

Meaning

Opt 0x22 0x22 0x22 0x22 0x22



The Extern *10.0.16.0 output shows that OSPF is advertising the external route. Viewing the Routing Tables of the Logical Systems

Purpose

Action

Make sure that Logical System LS3 and Logical System LS1 have the route to the 10.0.16.0/30 network installed in their respective routing tables. Make sure that Logical System LS2 does not have the route installed in its routing table. user@R1> show route logical-system all logical-system: LS2 inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30 10.0.0.2/32

*[Direct/0] 04:22:19 > via lt-1/2/0.1 *[Local/0] 04:22:19 Local via lt-1/2/0.1 *[Direct/0] 04:22:19 > via lt-1/2/0.4 *[Local/0] 04:22:19 Local via lt-1/2/0.4 *[OSPF/10] 04:22:23, metric 1 MultiRecv

10.0.2.0/30 10.0.2.2/32 224.0.0.5/32 ----logical-system: LS1

736



inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30 10.0.0.1/32

*[Direct/0] 04:22:19 > via lt-1/2/0.2 *[Local/0] 04:22:19 Local via lt-1/2/0.2 *[OSPF/10] 00:07:52, metric 2 > to 10.0.0.2 via lt-1/2/0.2 *[OSPF/150] 00:07:52, metric 0, tag 0 > to 10.0.0.2 via lt-1/2/0.2 *[OSPF/10] 04:22:23, metric 1 MultiRecv

10.0.2.0/30 10.0.16.0/30 224.0.0.5/32 ----logical-system: LS3

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30 10.0.2.0/30 10.0.2.1/32 10.0.16.0/30 10.0.60.0/30 10.0.60.2/32 224.0.0.5/32

Meaning


*[OSPF/10] 00:07:57, metric 2 > to 10.0.2.2 via lt-1/2/0.3 *[Direct/0] 04:22:19 > via lt-1/2/0.3 *[Local/0] 04:22:19 Local via lt-1/2/0.3 *[Static/5] 03:51:18 > to 10.0.60.1 via so-0/0/0.0 *[Direct/0] 03:53:52 > via so-0/0/0.0 *[Local/0] 03:53:58 Local via so-0/0/0.0 *[OSPF/10] 04:22:23, metric 1 MultiRecv

The route to 10.0.16.0/30 is not installed in Logical System LS2’s routing table. The route to 10.0.16.0/30 is installed in Logical System LS1’s routing table as a route learned from OSPF. Because it is an OSPF external route, it has a preference value of 150 (instead of 10). By default, routes resulting from OSPF external LSAs are installed with a preference value of 150. The route to 10.0.16.0/30 is installed in Logical System LS3’s routing table as a static route.

•

OSPF Support for Logical Systems on page 712

•


•

Introduction to Logical Systems in the Junos OS Logical Systems Configuration Guide.

Example: Configuring OSPF Trace Options •

Tracing OSPF Protocol Traffic on page 738

•

Example: Tracing OSPF Protocol Traffic on page 739


737


Tracing OSPF Protocol Traffic Tracing operations record detailed messages about the operation of OSPF. You can trace OSPF protocol traffic to help debug OSPF protocol issues. When you trace OSPF protocol traffic, you specify the name of the file and the type of information you want to trace. You can specify the following OSPF protocol-specific trace options: •

database-description—All database description packets, which are used in synchronizing

the OSPF topological database •

error—OSPF error packets

•

event—OSPF state transitions

•

flooding—Link-state flooding packets

•

graceful-restart—Graceful-restart events

•

hello—Hello packets, which are used to establish neighbor adjacencies and to determine

whether neighbors are reachable •

ldp-synchronization—Synchronization events between OSPF and LDP

•

lsa-ack—Link-state acknowledgment packets, which are used in synchronizing the

OSPF topological database •

lsa-analysis—Link-state analysis. Specific to the Juniper Networks implementation of

OSPF, Junos OS performs LSA analysis before running the shortest-path-first (SPF) algorithm. LSA analysis helps to speed the calculations performed by the SPF algorithm. •

lsa-request—Link-state request packets, which are used in synchronizing the


lsa-update—Link-state updates packets, which are used in synchronizing the


nsr-synchronization—Nonstop routing synchronization events

•

on-demand—Trace demand circuit extensions

•

packet-dump—Dump the contents of selected packet types

•

packets—All OSPF packets

•

restart-signaling—(OSPFv2 only) Restart-signaling graceful restart events

•

spf—Shortest path first (SPF) calculations

You can optionally specify one or more of the following flag modifiers:

738

•


•


•




NOTE: Use the detail flag modifier with caution as it might cause the CPU to become very busy.

Global tracing options are inherited from the configuration set by the traceoptions statement at the [edit routing-options] hierarchy level. You can override the following global trace options for the OSPF protocol using the traceoptions flag statement included at the [edit protocols ospf] hierarchy level: •


•




•


•


•


•


•


NOTE: Use the trace flag all with caution as it might cause the CPU to become very busy.

Example: Tracing OSPF Protocol Traffic This example shows how to trace OSPF protocol traffic. •


•


•


•


Requirements This example assumes that OSPF is properly configured and running in your network, and you want to trace OSPF protocol traffic for debugging purposes.

Overview You can trace OSPF protocol traffic to help debug OSPF protocol issues. When you trace OSPF protocol traffic, you specify the name of the file and the type of information you want to trace. All files are placed in a directory on the routing device’s hard disk. On M Series and T Series routers, trace files are stored in the /var/log directory. This example shows a few configurations that might be useful when debugging OSPF protocol issues. The verification output displayed is specific to each configuration.


739


TIP: To keep track of your log files, create a meaningful and descriptive name so it is easy to remember the content of the trace file. We recommend that you place global routing protocol tracing output in the file routing-log, and OSPF tracing output in the file ospf-log.

In the first example, you globally enable tracing operations for all routing protocols that are actively running on your routing device to the file routing-log. With this configuration, you keep the default settings for the trace file size and the number of trace files. After enabling global tracing operations, you enable tracing operations to provide detailed information about OSPF packets, including link-state advertisements, requests, and updates, database description packets, and hello packets to the file ospf-log, and you configure the following options: •

size—Specifies the maximum size of each trace file, in KB, MB, or GB. In this example,

you configure 10 KB as the maximum size. When the file reaches its maximum size, it is renamed with a .0 extension. When the file again reaches its maximum size, it is renamed with a .1 extension, and the newly created file is renamed with a .0 extension. This renaming scheme continues until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum file size, you must also specify a maximum number of trace files with the files option. You specify k for KB, m for MB, and g for GB. By default, the trace file size is 128 KB. The file size range is 10 KB through the maximum file size supported on your system. •

files—Specifies the maximum number of trace files. In this example, you configure a

maximum of 5 trace files. When a trace file reaches its maximum size, it is renamed with a .0 extension, then a .1 extension, and so on until the maximum number of trace files is reached. When the maximum number of files is reached, the oldest trace file is overwritten. If you specify a maximum number of files, you must also specify a maximum file size with the size option. By default, there are 10 files. The range is 2 through 1000 files. In the second example, you trace all SPF calculations to the file ospf-log by including the spf flag. You keep the default settings for the trace file size and the number of trace files. In the third example, you trace the creation, receipt, and retransmission of all LSAs to the file ospf-log by including the lsa-request, lsa-update, and lsa-ack flags. You keep the default settings for the trace file size and the number of trace files.

Configuration •

Configuring Global Tracing Operations and Tracing OSPF Packet Information on page 740

•

Tracing SPF Calculations on page 742

•

Tracing Link-State Advertisements on page 743

Configuring Global Tracing Operations and Tracing OSPF Packet Information CLI Quick Configuration

740

To quickly enable global tracing operations for all routing protocols actively running on your routing device and to trace detailed information about OSPF packets, copy the following commands and paste them into the CLI.



[edit] set routing-options traceoptions file routing-log set protocols ospf traceoptions file ospf-log set protocols ospf traceoptions file files 5 size 10k set protocols ospf traceoptions flag lsa-ack set protocols ospf traceoptions flag database-description set protocols ospf traceoptions flag hello set protocols ospf traceoptions flag lsa-update set protocols ospf traceoptions flag lsa-request


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in Junos OS CLI, Release 11.4. To configure global routing tracing operations and tracing operations for OSPF packets: 1.

Configure tracing at the routing options level to collect information about the active routing protocols on your routing device. [edit] user@host# edit routing-options traceoptions

2.

Configure the filename for the global trace file. [edit routing-options traceoptions] user@host# set file routing-log

3.

Configure the filename for the OSPF trace file.


[edit] user@host# edit protocols ospf traceoptions user@host# set file ospf-log 4.

Configure the maximum number of trace files. [edit protocols ospf traceoptions] user@host# set file files 5

5.

Configure the maximum size of each trace file. [edit protocols ospf traceoptions] user@host# set file size 10k

6.

Configure tracing flags. [edit protocols ospf traceoptions] user@host# set flag lsa-ack user@host# set flag database-description user@host# set flag hello user@host# set flag lsa-update user@host# set flag lsa-request

7.

If you are done configuring the device, commit the configuration.


741


[edit protocols ospf traceoptions] user@host# commit

Results

Confirm your configuration by entering the show routing-options and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show routing-options traceoptions { file routing-log; } user@host# show protocols ospf traceoptions { file ospf-log size 10k files 5; flag lsa-ack; flag database-description; flag hello; flag lsa-update; flag lsa-request; }

To confirm your OSPFv3 configuration, enter the show routing-options and the show protocols ospf3 commands. Tracing SPF Calculations CLI Quick Configuration

To quickly trace SPF calculations, copy the following commands and paste them into the CLI. [edit] set protocols ospf traceoptions file ospf-log set protocols ospf traceoptions flag spf


To configure SPF tracing operations for OSPF: 1.




Configure the SPF tracing flag. [edit protocols ospf traceoptions] user@host# set flag spf

3.

If you are done configuring the device, commit the configuration. [edit protocols ospf traceoptions] user@host# commit

742



Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf traceoptions { file ospf-log ; flag spf; }

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. Tracing Link-State Advertisements CLI Quick Configuration

To quickly trace the creation, receipt, and retransmission of all LSAs, copy the following commands and paste them into the CLI. [edit] set protocols ospf traceoptions file ospf-log set protocols ospf traceoptions flag lsa-request set protocols ospf traceoptions flag lsa-update set protocols ospf traceoptions flag lsa-ack


To configure link-state advertisement tracing operations for OSPF: 1.




Configure the link-state advertisement tracing flags. [edit protocols ospf traceoptions] user@host# set flag lsa-request user@host# set flag lsa-update user@host# set flag lsa-ack

3.

If you are done configuring the device, commit the configuration. [edit protocols ospf traceoptions] user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show protocols ospf traceoptions { file ospf-log;


743


flag lsa-request; flag lsa-update; flag lsa-ack; }


Verification Confirm that the configuration is working properly. Verifying Trace Operations Purpose

Action


Verify that the Trace options field displays the configured trace operations, and verify that the Trace file field displays the location on the routing device where the file is saved, the name of the file to receive the output of the tracing operation, and the size of the file. From operational mode, enter the show ospf overview extensive command for OSPFv2, and enter the show ospf3 overview extensive command for OSPFv3.

•


•


•

Junos OS Tracing and Logging Operations in the Junos OS System Basics Configuration Guide

•

Tracing Global Routing Protocol Operations on page 138 in the Junos OS Routing Protocols Configuration Guide

Verifying an OSPF Configuration To verify an OSPF configuration, perform these tasks: •

Verifying OSPF-Enabled Interfaces on page 744

•

Verifying OSPF Neighbors on page 745

•

Verifying the Number of OSPF Routes on page 746

•

Verifying Reachability of All Hosts in an OSPF Network on page 747

Verifying OSPF-Enabled Interfaces Purpose

Action

Verify that OSPF is running on a particular interface and that the interface is in the desired area. From the CLI, enter the show ospf interface command.

Sample Output user@host> show ospf interface Intf State Area at-5/1/0.0 PtToPt 0.0.0.0 ge-2/3/0.0 DR 0.0.0.0

744

DR ID 0.0.0.0 192.168.4.16

BDR ID 0.0.0.0 192.168.4.15

Nbrs 1 1



lo0.0 so-0/0/0.0 so-6/0/1.0 so-6/0/2.0 so-6/0/3.0

Meaning

DR Down PtToPt Down PtToPt

0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

192.168.4.16 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

0 0 1 0 1

The output shows a list of the device interfaces that are configured for OSPF. Verify the following information: •

Each interface on which OSPF is enabled is listed.

•

Under Area, each interface shows the area for which it was configured.

•

Under Intf and State, the device loopback (lo0.0) interface and LAN interface that are linked to the OSPF network's designated router (DR) are identified.

•

Under DR ID, the IP address of the OSPF network's designated router appears.

•

Under State, each interface shows a state of PtToPt to indicate a point-to-point connection. If the state is Waiting, check the output again after several seconds. A state of Down indicates a problem.

•

The designated router addresses always show a state of DR.

Verifying OSPF Neighbors Purpose

Action

OSPF neighbors are interfaces that have an immediate adjacency. On a point-to-point connection between the device and another router running OSPF, verify that each router has a single OSPF neighbor. From the CLI, enter the show ospf neighbor command.

Sample Output user@host> show ospf neighbor Address Intf 192.168.254.225 fxp3.0 192.168.254.230 fxp3.0 192.168.254.229 fxp3.0 10.1.1.129 fxp2.0 10.1.1.131 fxp2.0 10.1.2.1 fxp1.0 10.1.2.81 fxp0.0

Meaning

State 2Way Full Full Full Full Full Full

ID 10.250.240.32 10.250.240.8 10.250.240.35 10.250.240.12 10.250.240.11 10.250.240.9 10.250.240.10

Pri Dead 128 36 128 38 128 33 128 37 128 38 128 32 128 33

The output shows a list of the device's OSPF neighbors and their addresses, interfaces, states, router IDs, priorities, and number of seconds allowed for inactivity (“dead” time). Verify the following information: •

Each interface that is immediately adjacent to the device is listed.

•

The device's own loopback address and the loopback addresses of any routers with which the device has an immediate adjacency are listed.

•

Under State, each neighbor shows a state of Full. Because full OSPF connectivity is established over a series of packet exchanges between clients, the OSPF link might


745


take several seconds to establish. During that time, the state might be displayed as Attempt, Init, or 2way, depending on the stage of negotiation. If, after 30 seconds, the state is not Full, the OSPF configuration between the neighbors is not functioning correctly.

Verifying the Number of OSPF Routes Purpose

Verify that the OSPF routing table has entries for the following: •

Each subnetwork reachable through an OSPF link

•

Each loopback address reachable on the network

For example, Figure 36 on page 746 shows a sample network with an OSPF topology.

Figure 36: Sample OSPF Network Topology

In this topology, OSPF is being run on all interfaces. Each segment in the network is identified by an address with a /24 prefix, with interfaces on either end of the segment being identified by unique IP addresses. Action

From the CLI, enter the show ospf route command.

Sample Output user@host> show ospf route Prefix Path Type 10.10.10.1/24 Intra 10.10.10.2/24 Intra 10.10.10.4/24 Intra 10.10.10.5/24 Intra 10.10.10.6/24 Intra 10.10.10.10/24 Intra 10.10.10.11/24 Intra 10.10.10.13/24 Intra 10.10.10.16/24 Intra 10.10.10.19/24 Intra 10.10.10.20/24 Intra 10.10.10.21/24 Intra

746

Route Type Network Network Network Network Network Network Network Network Network Network Network Network

NH Type IP IP IP IP IP IP IP IP IP IP IP IP

Metric 1 1 1 1 1 1 1 1 1 1 1 1

NextHop Interface ge-0/0/2.0 ge-0/0/2.0 ge-0/0/1.0 ge-0/0/2.0 ge-0/0/1.0 ge-0/0/2.0 ge-0/0/1.0 ge-0/0/1.0 ge-0/0/1.0 ge-0/0/1.0 ge-0/0/2.0 ge-0/0/2.0

Nexthop addr/label 10.0.21.1 10.0.21.1 10.0.13.1 10.0.21.1 10.0.13.1 10.0.21.1 10.0.13.1 10.0.13.1 10.0.13.1 10.0.21.1



192.168.5.1 192.168.5.2 192.168.5.3 192.168.5.4 192.168.5.5 192.168.5.6 192.168.5.7 192.168.5.8 192.168.5.9

Meaning

Intra Intra Intra Intra Intra Intra Intra Intra Intra

Router Router Router Router Router Router Router Router Router

IP IP IP IP IP IP IP IP IP

1 1 1 1 1 1 1 1 1

ge-0/0/2.0 lo0 ge-0/0/1.0 ge-0/0/1.0 ge-0/0/1.0 ge-0/0/2.0 ge-0/0/2.0 ge-0/0/2.0 ge-0/0/1.0

10.0.21.1 10.0.13.1 10.0.13.1 10.0.13.1 10.0.21.1 10.0.21.1 10.0.21.1 10.0.13.1

The output lists each route, sorted by IP address. Routes are shown with a route type of Network, and loopback addresses are shown with a route type of Router. For the example shown in Figure 36 on page 746, verify that the OSPF routing table has 21 entries, one for each network segment and one for each router's loopback address.

Verifying Reachability of All Hosts in an OSPF Network Purpose

Action

By using the traceroute tool on each loopback address in the network, verify that all hosts in the network are reachable from each device. For each device in the OSPF network: 1.

In the J-Web interface, select Troubleshoot>Traceroute.

2. In the Host Name box, type the name of a host for which you want to verify reachability

from the device. 3. Click Start. Output appears on a separate page.

Sample Output 1 172.17.40.254 (172.17.40.254) 0.362 ms 0.284 ms 0.251 ms 2 routera-fxp0.englab.mycompany.net (192.168.71.246) 0.251 ms 0.235 ms 0.200 ms

Meaning

Each numbered row in the output indicates a routing “hop” in the path to the host. The three-time increments indicate the round-trip time (RTT) between the device and the hop, for each traceroute packet. To ensure that the OSPF network is healthy, verify the following information: •

The final hop in the list is the host you want to reach.

•

The number of expected hops to the host matches the number of hops in the traceroute output. The appearance of more hops than expected in the output indicates that a network segment is likely not reachable. In this case, verify the routes with the show ospf route command.

For information about show ospf route, see “Verifying the Number of OSPF Routes” on page 746


•

Junos OS Feature Support Reference for SRX Series and J Series Devices

•



747


•

748

traceroute in the Junos OS System Basics and Services Command Reference


CHAPTER 18

Summary of OSPF Configuration Statements The following sections explain each of the OSPF configuration statements, which are organized alphabetically. The term OSPF refers to both OSPF version 2 (OSPFv2) and OSPF version 3 (OSPFv3).


749


area Syntax Hierarchy Level

Release Information

Description

area area-id; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the area identifier for this routing device to use when participating in OSPF routing. All routing devices in an area must use the same area identifier to establish adjacencies. Specify multiple area statements to configure the routing device as an area border router. An area border router does not automatically summarize routes between areas. Use the area-range statement to configure route summarization. By definition, an area border router must be connected to the backbone area either through a physical link or through a virtual link. To create a virtual link, include the virtual-link statement. To specify that the routing device is directly connected to the OSPF backbone, include the area 0.0.0.0 statement. All routing devices on the backbone must be contiguous. If they are not, use the virtual-link statement to create the appearance of connectivity to the backbone.

Options

area-id—Area identifier. The identifier can be up to 32 bits. It is common to specify the

area number as a simple integer or an IP address. Area number 0.0.0.0 is reserved for the OSPF backbone area. Required Privilege Level Related Documentation

750



•

Understanding Multiple Address Families for OSPFv3 on page 554

•

virtual-link on page 834


Chapter 18: Summary of OSPF Configuration Statements

area-range Syntax Hierarchy Level

Release Information

Description

area-range network/mask-length ; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa], [edit logical-systems logical-system-name realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa], [edit logical-systems logical-system-name routing-instances routing-instance-name realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit protocols (ospf | ospf3) area area-id], [edit protocols (ospf | ospf3) area area-id nssa], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa], [edit routing-instances routing-instance-name realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. (Area border routers only) For an area, summarize a range of IP addresses when sending summary link advertisements (within an area). To summarize multiple ranges, include multiple area-range statements. For a not-so-stubby area (NSSA), summarize a range of IP addresses when sending NSSA link-state advertisements. The specified prefixes are used to aggregate external routes learned within the area when the routes are advertised to other areas. To specify multiple prefixes, include multiple area-range statements. All external routes learned within the area that do not fall into one of the prefixes are advertised individually to other areas.

Default

Options

By default, area border routers do not summarize routes being sent from one area to other areas, but rather send all routes explicitly. exact—(Optional) Summarization of a route is advertised only when an exact match is

made with the configured summary range. mask-length—Number of significant bits in the network mask. network—IP address. You can specify one or more IP addresses. override-metric metric—(Optional) Override the metric for the IP address range and

configure a specific metric value.


751


restrict—(Optional) Do not advertise the configured summary. This hides all routes that

are contained within the summary, effectively creating a route filter. Range: 1 through 16,777,215 Required Privilege Level Related Documentation


Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements on page 558

authentication Syntax

Hierarchy Level


authentication { md5 key-identifier { key key-value; start-time YYYY-MM-DD.hh:mm; } simple-password key; } [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf area area-id virtual-link], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id virtual-link], [edit protocols ospf area area-id interface interface-name], [edit protocols ospf area area-id virtual-link], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id virtual-link]

Statement introduced before Junos OS Release 7.4. Configure an authentication key (password). Neighboring routers use the password to verify the authenticity of packets sent from this interface. All routers that are connected to the same IP subnet must use the same authentication scheme and password. The remaining statements are explained separately.


752



•


•


•




backup-spf-options Syntax

Hierarchy Level

Release Information

backup-spf options { disable; downstream-paths-only; no-install; } [edit protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit protocols ospf topology (default | name)], [edit logical-systems logical-system-name protocols ospf topology (default | name)], [edit routing-instances routing-instance-name protocols ospf topology (default | name)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default | name)]; [edit protocols ospf3 realm ipv4-unicast], [edit logical-systems logical-system-name protocols ospf3 realm ipv4-unicast], [edit routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast]

Statement introduced in Junos OS Release 10.0. Statement introduced in Junos OS Release 11.3 for the QFX Series.

Description

Configure options for running the shortest-path-first (SPF) algorithm for backup next hops for protected OSPF interfaces. Use these options to override the default behavior of having Junos OS calculate backup paths for all the topologies in an OSPF instance when at least one OSPF interface is configured with link protection or node-link protection. These options also enable you to change the default behavior for a specific topology in an OSPF instance.

Options

disable—Do not calculate backup next hops for the specified OSPF instance or topology. downstream-paths-only—Calculate and install only downstream paths as defined in

RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates for the specified OSPF instance or topology. no-install—Do not install the backup next hops for the specified OSPF instance or topology.


routing—To view this statement in the configuration. routing-control-level—To add this statement to the configuration. •

Configuring Backup SPF Options for Protected OSPF Interfaces on page 645

•


•



753


bandwidth-based-metrics Syntax

Hierarchy Level

Release Information

Description

Options

bandwidth-based-metrics { bandwidth value; metric number; } [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology topology-name], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology topology-name], [edit logical-systems logical-system-name routing-instances routing-instances protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name topology topology-name], [edit protocols ospf3 realm (ivp4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology topology-name], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced in Junos OS Release 9.5. Statement introduced in Junos OS Release 9.5 for EX Series switches. Specify a set of bandwidth threshold values and associated metric values for an OSPF interface or for a topology on an OSPF interface. When the bandwidth of an interface changes, Junos OS automatically sets the interface metric to the value associated with the appropriate bandwidth threshold value. bandwidth value—Specify the bandwidth threshold in bits per second.

Range: 9600 through 1,000,000,000,000,000 metric number—Specify a metric value to associate with a specific bandwidth value.

Range: 1 through 65,535

NOTE: You must also configure a static metric value for the OSPF interface or topology with the metric statement. Junos OS uses this value to calculate the cost of a route from the OSPF interface or topology if the bandwidth for the interface is higher than of any bandwidth threshold values configured for bandwidth-based metrics.

754






•

metric on page 789

•



755



bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } full-neighbors-only minimum-interval milliseconds; minimum-receive-interval milliseconds; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (1 | automatic); }

Hierarchy Level

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Release Information

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. detection-time threshold and transmit-interval threshold options added in Junos OS Release 8.2. Support for logical systems introduced in Junos OS Release 8.3. no-adaptation statement introduced in Junos OS Release 9.0. no-adaptation statement introduced in Junos OS Release 9.0 for EX Series switches. Support for OSPFv3 introduced in Junos OS Release 9.3. Support for OSPFv3 introduced in Junos OS Release 9.3 for EX Series switches. full-neighbors-only statement introduced in Junos OS Release 9.5. full-neighbors-only statement introduced in Junos OS Release 9.5 for EX Series switches.

756



authentication algorithm, authentication key-chain, and authentication loose-check

statements introduced in Junos OS Release 9.6. Description

Configure bidirectional failure detection timers and authentication.


757


Options

authentication algorithm algorithm-name —Configure the algorithm used to authenticate



BFD session. Use only for transitional periods when authentication may not be configured at both ends of the BFD session. detection-time threshold milliseconds—Configure a threshold. When the BFD session

detection time adapts to a value equal to or greater than the threshold, a single trap and a single system log message are sent. full-neighbors-only—Establish BFD sessions only for OSPF neighbors in the full state. The

default behavior is to establish BFD sessions for all OSPF neighbors. minimum-interval milliseconds—Configure the minimum intervals at which the local

routing device transmits a hello packet and then expects to receive a reply from the neighbor with which it has established a BFD session. Range: 1 through 255,000 milliseconds minimum-receive-interval milliseconds—Configure only the minimum interval at which

the routing device expects to receive a reply from a neighbor with which it has established a BFD session. Range: 1 through 255,000 milliseconds multiplier number—Configure the number of hello packets not received by a neighbor

that causes the originating interface to be declared down. Range: 1 through 255 Default: 3 no-adaptation—Specify that BFD sessions should not adapt to changing network

conditions. We recommend that you not disable BFD adaptation unless it is preferable not to have BFD adaptation enabled in your network. transmit-interval threshold milliseconds—Configure a threshold. When the BFD session


Range: 0 through 4,294,967,295 (2

– 1)

transmit-interval minimum-interval milliseconds—Configure the minimum interval at which

the routing device transmits hello packets to a neighbor with which it has established a BFD session. Range: 1 through 255,000 version—Specify the BFD version to detect.

758



Range: 1 (BFD version 1) or automatic (autodetect version) Default: automatic The remaining statements are explained separately. Required Privilege Level Related Documentation



•

Configuring BFD Authentication for OSPF on page 623


759


database-protection Syntax

Hierarchy Level

Release Information

Description

Default Options

database-protection { ignore-count number; ignore-time seconds; maximum-lsa number; reset-time seconds; warning-only; warning-threshold percent; } [edit protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-unicast | ipv6-multicast)]

Statement introduced in Junos OS Release 10.2. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure the maximum number of link-state advertisements (LSAs) that are not generated by the router or switch in a given OSPF instance. By default, OSPF database protection is not enabled. ignore-count number—Configure the number of times the database can enter the ignore

state. When the ignore count is exceeded, the database enters the isolate state. Range: 1 through 32 Default: 5 ignore-time seconds—Configure the time the database must remain in the ignore state

before it resumes regular operations (enters retry state). Range: 30 through 3,600 seconds Default: 300 seconds maximum-lsa number—Configure the maximum number of LSAs whose advertising router

ID is different from the local router ID in a given OSPF instance. This includes external LSAs as well as LSAs with any scope, such as the link, area, and autonomous system (AS). This value is mandatory. Range: 1 through 1,000,000 Default: None reset-time seconds—Configure the time period during which the database must operate

without being in the ignore or isolate state before it is reset to a normal operating state. Range: 60 through 86,400 seconds Default: 600 seconds

760



warning-only—Specify that only a warning should be issued when the maximum LSA

number is exceeded. If configured, no other action is taken against the database. warning-threshold percent—Configure the percentage of the maximum number of LSAs

to be exceeded before a warning message is logged. Range: 30 through 100 percent Default: 75 percent Required Privilege Level Related Documentation


OSPF Database Protection Overview on page 677

•

Configuring OSPF Database Protection on page 678


761


dead-interval Syntax Hierarchy Level

Release Information

Description

Options

dead-interval seconds; [edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols ospf area area-id peer-interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id virtual-link], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Specify how long OSPF waits before declaring that a neighboring routing device is unavailable. This is an interval during which the routing device receives no hello packets from the neighbor. seconds—Interval to wait.

Range: 1 through 65,535 seconds Default: Four times the hello interval—40 seconds (broadcast and point-to-point networks); 120 seconds (nonbroadcast multiple access (NBMA) networks) Required Privilege Level Related Documentation

762



•

hello-interval on page 774



default-lsa Syntax

Hierarchy Level

Release Information

Description

default-lsa { default-metric metric; metric-type type; type-7; } [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa], [edit protocols (ospf | ospf3) area area-id nssa], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. On area border routers only, for a not-so-stubby area (NSSA), inject a default link-state advertisement (LSA) with a specified metric value into the area. The default route matches any destination that is not explicitly reachable from within the area. The remaining statements are explained separately.




•

nssa on page 800

•

stub on page 821

•

Configuring OSPF Areas


763


default-metric Syntax Hierarchy Level

Release Information

Description

Options

default-metric metric; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa default-lsa], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id stub], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa default-lsa], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id stub], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa default-lsa], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id stub], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa default-lsa], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id stub], [edit protocols (ospf | ospf3) area area-id nssa default-lsa], [edit protocols (ospf | ospf3) area area-id stub], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa default-lsa], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id stub], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa default-lsa], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id stub], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa default-lsa], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id stub]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. On area border routers only, for a stub area, inject a default route with a specified metric value into the area. The default route matches any destination that is not explicitly reachable from within the area. metric—Metric value.


764



•

nssa on page 800



•

stub on page 821

demand-circuit Syntax Hierarchy Level

Release Information


demand-circuit; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id sham-link-remote], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Support for the realm statement introduced in Junos OS Release 9.2. Configure an interface as a demand circuit. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Example: Configuring OSPF Demand Circuits on page 547

•



765


disable See the following sections: •

disable (LDP Synchronization) on page 766

•

disable (OSPF) on page 767

disable (LDP Synchronization) Syntax Hierarchy Level


766

disable; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name]

Statement introduced in Junos OS Release 7.5. Disable LDP for OSPF. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




disable (OSPF) Syntax Hierarchy Level

Release Information

Description Default Required Privilege Level

disable; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) virtual-link], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) virtual-link], [edit logical-systems logical-system-name routing-instances routing-instances protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols (ospf | ospf3)], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) virtual-link], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) virtual-link], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Disable OSPF, an OSPF interface, or an OSPF virtual link. The configured object is enabled (operational) unless explicitly disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration.


767



•


domain-id Syntax Hierarchy Level

Release Information

Description

Options

domain-id domain-id; [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify a domain ID for a route. The domain ID identifies the OSPF domain from which the route originated. domain-id—You can specify either an IP address or an IP address and a local identifier

using the following format: ip-address:local-identifier. If you do not specify a local identifier with the IP address, the identifier is assumed to have a value of 0. Default: If the router ID is not configured in the routing instance, the router ID is derived from an interface address belonging to the routing instance. Required Privilege Level Related Documentation



domain-vpn-tag Syntax Hierarchy Level

Release Information

Description


768

domain-vpn-tag number; [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Set a virtual private network (VPN) tag for OSPFv2 external routes generated by the provider edge (PE) router. number—VPN tag.






Release Information


export [ policy-names ]; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Apply one or more policies to routes being exported from the routing table into OSPF. policy-names—Name of one or more policies.



•


•

import on page 776

•



769


external-preference Syntax Hierarchy Level

Release Information

Description Options

external-preference preference; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ip4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast } ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Set the route preference for OSPF external routes. preference—Preference value. 32

Range: 0 through 4,294,967,295 (2

– 1)


770



•




flood-reduction Syntax Hierarchy Level



flood-reduction; [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interfaces interface-name], [edit protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interfaces interface-name], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interfaces interface-name], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interfaces interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interfaces interface-name], [edit protocols (ospf | ospf3) area area-id virtual-link neighbor-id router-id transit-area area-id], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link neighbor-id router-id transit–area transit-area area-id], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link neighbor-id router-id transit-area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link neighbor-id router-id transit-area area-id], [edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote address ], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id sham-link-remote address], [edit protocols ospf area area-id peer-interface interface-name], [edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name]

Statement introduced in Junos OS Release 9.6. Specify to send self-generated link-state advertisements (LSAs) with the DoNotAge bit set. As a result, self-originated LSAs are not reflooded every 30 minutes, as required by OSPF by default. An LSA is refreshed only when the content of the LSA changes, which reduces OSPF traffic overhead in stable topologies. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



771



graceful-restart { disable; helper-disable ; no-strict-lsa-checking; notify-duration seconds; restart-duration seconds; }

Hierarchy Level

[edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit protocols (ospf | ospf3)] [edit routing-instances routing-instance-name protocols ospf]

Release Information

Statement introduced before Junos OS Release 7.4. Support for the no-strict-lsa-checking statement introduced in Junos OS Release 8.5. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the helper mode standard, restart-signaling, and both options introduced in Junos OS Release 11.4.

Description Options

Configure graceful restart for OSPF. disable—Disable graceful restart for OSPF. helper-disable —Disable helper mode for graceful

restart. When helper mode is disabled, a device cannot help a neighboring device that is attempting to restart. Beginning with Junos OS Release 11.4, you can configure restart signaling-based helper mode for OSPFv2 graceful restart configurations. The standard, restart-signaling, and both options are only supported for OSPFv2. Specify standard to disable helper mode for standard graceful restart (based on RFC 3623). Specify restart-signaling to disable helper mode for restart signaling-based graceful restart (based on RFC 4811, RFC 4812, and RFC 4813). Specify both to disable helper mode for both standard and restart signaling-based graceful restart. The last committed statement takes precedence over the previously-configured statement. Default: Helper mode is enabled by default. For OSPFv2, both standard and restart-signaling based helper modes are enabled by default. no-strict-lsa-checking—Disable strict OSPF link-state advertisement (LSA) checking to

prevent the termination of graceful restart by a helping router. LSA checking is enabled by default.

NOTE: The helper-disable statement and the no-strict-lsa-checking statement cannot be configured at the same time. If you attempt to configure both statements at the same time, the routing device displays a warning message when you enter the show protocols (ospf | ospf3) command.

772



notify-duration seconds—Estimated time to send out purged grace LSAs over all the

interfaces. Range: 1 through 3600 seconds Default: 30 seconds restart-duration seconds—Estimated time to reacquire a full OSPF neighbor from each

area. Range: 1 through 3600 seconds Default: 180 seconds Required Privilege Level Related Documentation


Example: Configuring Graceful Restart for OSPF on page 628

•


•


•

Example: Disabling Strict LSA Checking for OSPF Graceful Restart on page 639

•



773


hello-interval Syntax Hierarchy Level

Release Information

Description

Options

hello-interval seconds; [edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols ospf area area-id peer-interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id virtual-link], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Specify how often the routing device sends hello packets out the interface. The hello interval must be the same for all routing devices on a shared logical IP network. seconds—Time between hello packets, in seconds.

Range: 1 through 255 seconds Default: 10 seconds (broadcast and point-to-point networks); 30 seconds (nonbroadcast multiple access [NBMA] networks) Required Privilege Level Related Documentation

774



•

dead-interval on page 762



hold-time Syntax Hierarchy Level


Options

hold-time seconds; [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name]

Statement introduced in Junos OS Release 7.5. Configure the time period to advertise the maximum cost metric for a link that is not fully operational. seconds—Hold-time value.

Range: 1 through 65,535 seconds Default: Infinity Required Privilege Level Related Documentation



ignore-lsp-metrics Syntax Hierarchy Level

Release Information


ignore-lsp-metrics; [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf traffic-engineering shortcuts], [edit protocols ospf traffic-engineering shortcuts], [edit routing-instances routing-instance-name protocols ospf traffic-engineering shortcuts]

Statement introduced in Junos OS Release 7.5. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for (OSPFv3) introduced in Junos OS Release 9.4. Support for (OSPFv3) introduced in Junos OS Release 9.4 for EX Series switches. Ignore RSVP LSP metrics in OSPF traffic engineering shortcut calculations. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



775



Release Information


776

import [ policy-names ]; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Filter OSPF routes from being added to the routing table. policy-names—Name of one or more policies.



•


•

export on page 769

•




inter-area-prefix-export Syntax Hierarchy Level

Release Information

Description

Options

inter-area-prefix-export [ policy-names ]; [edit logical-systems logical-system-name protocols ospf3 area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ip4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit protocols ospf3 area area-id], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit routing-instances routing-instance-name protocols ospf3 area area-id], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-muticast | ipv6-multicast) area area-id]

Statement introduced in Junos OS Release 9.1. Statement introduced in Junos OS Release 9.1 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Apply an export policy for OSPFv3 to specify which interarea prefix link-state advertisements (LSAs) are flooded into an area. policy-name—Name of a policy configured at the [edit policy-options policy-statement policy-name term term-name] hierarchy level.




•

inter-area-prefix-import on page 778

•



777


inter-area-prefix-import Syntax Hierarchy Level

Release Information

Description

Options

inter-area-prefix-import [ policy-names ]; [edit logical-systems logical-system-name protocols ospf3 area area-id], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit protocols ospf3 area area-id], [edit protocols ospf3 realm (ip4-unicast | ipv4-multicast | ipv6-multicast)], area area-id], [edit routing-instances routing-instance-name protocols ospf3 area area-id], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id]

Statement introduced in Junos OS Release 9.1. Statement introduced in Junos OS Release 9.1 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Apply an import policy for OSPFv3 to specify which routes learned from an area are used to generate interarea prefixes into other areas. policy-name—Name of a policy configured at the [edit policy-options policy-statement policy-name term term-name] hierarchy level.


778



•

inter-area-prefix-export on page 777

•




interface Syntax

Hierarchy Level

interface interface-name { disable; authentication key ; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; } dead-interval seconds; demand-circuit; hello-interval seconds; ipsec-sa name; interface-type type; ldp-synchronization { disable; hold-time seconds; } metric metric; neighbor address ; no-interface-state-traps; passive; poll-interval seconds; priority number; retransmit-interval seconds; te-metric metric; topology (ipv4-multicast | name) { metric metric; } transit-delay seconds; transmit-interval seconds; } [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit protocols (ospf | ospf3) area area-id],


779


[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id]

Release Information

Description

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the topology statement introduced in Junos OS Release 9.0. Support for the topology statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Support for the no-interface-state-traps statement introduced in Junos OS Release 10.3. This statement is supported only for OSPFv2. Enable OSPF routing on a routing device interface. You must include at least one interface statement in the configuration to enable OSPF on the routing device.

Options

interface-name—Name of the interface. Specify the interface by IP address or interface

name for OSPFv2, or only the interface name for OSPFv3. Using both the interface name and IP address of the same interface produces an invalid configuration. To configure all interfaces, you can specify all. Specifying a particular interface and all produces an invalid configuration.

NOTE: For nonbroadcast interfaces, specify the IP address of the nonbroadcast interface as interface-name.

The remaining statements are explained separately.

NOTE: You cannot run both OSPF and ethernet-tcc encapsulation between two Juniper Networks routing devices.


780



•

Configuring Multitopology Routing in OSPF on page 314

•


•

neighbor on page 792



interface-type Syntax

interface-type (nbma | p2mp | p2p);

Hierarchy Level

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interface interface-name]

Release Information

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for OSPFv3 for interface type p2p only introduced in Junos OS Release 9.4. You cannot configure other interface types for OSPFv3. Support for OSPFv3 for interface type p2p only introduced in Junos OS Release 9.4 for EX Series switches.

Description

Specify the type of interface. By default, the software chooses the correct interface type based on the type of physical interface. Therefore, you should never have to set the interface type. The exception to this is for NBMA interfaces, which default to an interface type of point-to-multipoint. To have these interfaces explicitly run in Nonbroadcast multiaccess (NBMA) mode, configure the nbma interface type, using the IP address of the local ATM interface. In Junos OS Release 9.3 and later, a point-to-point interface can be an Ethernet interface without a subnet.

Default Options

The software chooses the correct interface type based on the type of physical interface. nbma (OSPFv2 only)—Nonbroadcast multiaccess (NBMA) interface. p2mp (OSPFv2 only)—Point-to-multipoint interface. p2p—Point-to-point interface.




781



782

•


•




ipsec-sa Syntax Hierarchy Level

Release Information

Description


ipsec-sa name; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id sham-link-remote address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id virtual-link], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote address], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Support for OSPFv2 authentication added in Junos OS Release 8.3. Support for the realm statement introduced in Junos OS Release 9.2. Apply IPsec authentication to an OSPF interface or virtual link or to an OSPFv2 remote sham link. name—Name of the IPsec authentication scheme.



•


•

Example: Configuring IPsec Authentication for an OSPF Interface on page 595

•


•



783


label-switched-path Syntax Hierarchy Level


label-switched-path name metric metric; [edit logical-systems logical-system-name protocols ospf area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], [edit protocols ospf area area-id], [edit routing-instances routing-instance-name protocols ospf area area-id]

Statement introduced before Junos OS Release 7.4. Advertise label-switched paths into OSPF as point-to-point links. The label-switched path is advertised in the appropriate OSPF levels as a point-to-point link and contains a local address and a remote address.

Options

name—Name of the label-switched path. metric—Metric value.

Range: 1 through 65,535 Default: 1 Required Privilege Level Related Documentation

784





ldp-synchronization Syntax

ldp-synchronization { disable; hold-time seconds; }

Hierarchy Level

[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name], [edit protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name]

Release Information

Statement introduced in Junos OS Release 7.5. Support for the realm statement introduced in Junos OS Release 9.2. Only the ipv4-unicast option is supported with this statement.

Description

Enable synchronization by advertising the maximum cost metric until LDP is operational on the link. The remaining statements are explained separately.





785


link-protection Syntax Hierarchy Level


link-protection; [edit protocols (ospf | ospf3) area area-name interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-name interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-name interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-name interface interface-name], [edit protocols ospf3 realm ipv4-unicast area area-id], [edit logical-systems logical-system-name protocols ospf3 realm ipv4-unicast area area-id], [edit routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id], [edit protocols ospf area area-id interface interface-name topology (default | name)], [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology (default | name)], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology (default | name)]

Statement introduced in Junos OS Release 10.0. Enable link protection on the specified OSPF interface. Junos OS creates a backup loop-free alternate path to the primary next hop for all destination routes that traverse the protected interface.

NOTE: This feature calculates alternate next hop paths for unicast routes only. Therefore, this statement is not supported with the OSPF IPv4 multicast topology or with the OSPFv3 IPv4 multicast and IPv6 multicast realms.


786


Configuring Link Protection for OSPF on page 643

•




lsp-metric-into-summary Syntax Hierarchy Level

Release Information


lsp-metric-into-summary; [edit logical-systems logical-system-name protocols (ospf | ospf3) traffic-engineering shortcuts], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) traffic-engineering shortcuts], [edit protocols (ospf | ospf3) traffic-engineering shortcuts], [edit routing-instances routing-instance-name protocols (ospf | ospf3) traffic-engineering shortcuts]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4. Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4 for EX Series switches. Advertise the LSP metric in summary LSAs. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

OSPF Support for Traffic Engineering on page 648

•



787


md5 Syntax

Hierarchy Level


md5 key-identifier { key key-values; start-time time; } [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name authentication], [edit logical-systems logical-system-name protocols ospf area area-id virtual-link authentication], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name authentication], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id virtual-link authentication], [edit protocols ospf area area-id interface interface-name authentication], [edit protocols ospf area area-id virtual-link authentication], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name authentication], [edit routing-instances routing-instance-name protocols ospf area area-id virtual-link authentication]

Statement introduced before Junos OS Release 7.4. Configure an MD5 authentication key (password). key-identifier—MD5 key identifier.

Range: 0 through 255 Default: 0 key key-values—One or more MD5 key strings. The MD5 key values can be from 1 through

16 characters long. You can specify more than one key value within the list. Characters can include ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”). start-time time—MD5 start time.


788



•


•




metric Syntax Hierarchy Level

Release Information

Description

metric metric; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology (ipv4-multicast | name)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id sham-link-remote], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology (ipv4-multicast | name)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name topology (ipv4-multicast | name)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology (ipv4-multicast | name)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for Multitopology Routing introduced in Junos OS Release 9.0. Support for Multitopology Routing introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Specify the cost of an OSPF interface. The cost is a routing metric that is used in the link-state calculation. To set the cost of routes exported into OSPF, configure the appropriate routing policy.

Options

metric—Cost of the route.

Range: 1 through 65,535 Default: By default, the cost of an OSPF route is calculated by dividing the reference-bandwidth value by the bandwidth of the physical interface. Any specific value you configure for the metric overrides the default behavior of using the reference-bandwidth value to calculate the cost of the route for that interface.


789



790



•


•


•

bandwidth-based-metrics on page 754

•

reference-bandwidth on page 812



metric-type Syntax Hierarchy Level

Release Information

Description Options Usage Guidelines


metric-type type; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa default-lsa], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id nssadefault-lsa], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa default-lsa], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id nssa default-lsa], [edit protocols (ospf | ospf3) area area-id nssa default-lsa], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id nssa default-lsa], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa default-lsa], [edit routing-instances routing-instances protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id nssa default-lsa]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Specify the external metric type for the default LSA. type—Metric type: 1 or 2

The configured metric determines the method used to compute the cost to a destination: •

The Type 1 external metric is equivalent to the link-state metric. The path cost uses the advertised external path cost and the path cost to the AS boundary router (the route is equal to the sum of all internal costs and the external cost).

•

The Type 2 external metric uses the cost assigned by the AS boundary router (the route is equal to the external cost alone). By default, OSPF uses the Type 2 external metric.



•



791


neighbor Syntax Hierarchy Level


Options

neighbor address ; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. For nonbroadcast interfaces only, specify neighboring routers. On a nonbroadcast interface, you must specify neighbors explicitly because OSPF does not send broadcast packets to dynamically discover their neighbors. To specify multiple neighbors, include multiple neighbor statements. address—IP address of a neighboring router. eligible—(Optional) Allow the neighbor to become a designated router.

Default: If you omit this option, the neighbor is not considered eligible to become a designated router. Required Privilege Level Related Documentation

792



•




network-summary-export Syntax Hierarchy Level


Options

network-summary-export policy-name; [edit logical-systems logical-system-name protocols ospf area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], [edit protocols ospf area area-id], [edit routing-instances routing-instance-name protocols ospf area area-id]

Statement introduced in Junos OS Release 9.1. Apply an export policy that specifies which network-summary link-state advertisements (LSAs) are flooded into an OSPFv2 area. policy-name—Name of a policy configured at the [edit policy-options policy-statement policy-name term term-name] hierarchy level.




•

Example: Configuring an OSPF Export Policy for Network Summaries on page 695

•

network-summary-import on page 794

•



793


network-summary-import Syntax Hierarchy Level


Options

network-summary-import policy-name; [edit logical-systems logical-system-name protocols ospf area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], [edit protocols ospf area area-id], [edit routing-instances routing-instance-name protocols ospf area area-id]

Statement introduced in Junos OS Release 9.1. Apply an import policy that specifies which routes learned from an OSPFv2 area are used to generate network-summary link-state advertisements to other areas. policy-name—Name of a policy configured at the [edit policy-options policy-statement policy-name term term-name] hierarchy level.




•

Example: Configuring an OSPF Import Policy for Network Summaries on page 704

•

network-summary-export on page 793

•


no-domain-vpn-tag Syntax Hierarchy Level



794

no-domain-vpn-tag; [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)]

Statement introduced in Junos OS Release 10.3. Disable the virtual private network (VPN) tag for OSPFv2 and OSPFv3 external routes generated by the provider edge (PE) router when the VPN tag is no longer needed. None. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




no-eligible-backup Syntax Hierarchy Level



no-eligbile-backup; [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name topology (default | name)], [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology (default | name)], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology (default | name)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology (default | name)],

Statement introduced in Junos OS Release 10.0. Exclude the specified interface as a backup interface for OSPF interfaces on which link protection or node-link protection is enabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Excluding an OSPF Interface as a Backup for a Protected Interface on page 645

•


•



795


no-interface-state-traps Syntax Hierarchy Level


no-interface-state-traps; [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name],

Statement introduced in Junos OS Release 10.3. Disable the OSPF traps for interface state changes. This statement is particularly useful for OSPF interfaces in passive mode.

NOTE: The no-interface-state-traps statement is supported only for OSPFv2.

Default


This statement is disabled by default. You must include the no-interface-state-traps statement to disable OSPF traps for interface state changes. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


•

passive on page 805

no-neighbor-down-notification Syntax Hierarchy Level



796

no-neighbor-down-notification; [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name]

Statement introduced in Junos OS Release 8.0. Disable neighbor down notification for OSPF to allow for migration from OSPF to IS-IS without disruption of the RSVP neighbors and associated RSVP-signaled LSPs. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




no-nssa-abr Syntax Hierarchy Level

Release Information

Description


no-nssa-abr; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced in Junos OS Release 7.6. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Disable exporting Type 7 link-state advertisements into not-so-stubby-areas (NSSAs) for an autonomous system boundary router (ASBR) or an area border router (ABR). routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



797


no-rfc-1583 Syntax Hierarchy Level

Release Information

Description


no-rfc-1583; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced in Junos OS Release 8.5. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Disable compatibility with RFC 1583, OSPF Version 2. If the same external destination is advertised by AS boundary routers that belong to different OSPF areas, disabling compatibility with RFC 1583 can prevent routing loops. Compatibility with RFC 1583 is enabled by default. routing—To view this statement in the configuration. routing-control-level—To add this statement to the configuration. •


no-summaries See

798

summaries



node-link-protection Syntax Hierarchy Level


node-link-protection; [edit protocols (ospf | ospf3) protocols area area-id interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name],

Statement introduced in Junos OS Release 10.0. Enable node-link protection on the specified OSPF interface. Junos OS creates an alternate loop-free path to the primary next hop for all destination routes that traverse a protected interface. This alternate path avoids the primary next-hop router altogether and establishes a path through a different router.

NOTE: This feature is not supported for the OSPF IPv4 multicast topology or for the OSPFv3 IPv4 multicast or IPv6 multicast topologies because node-link protection creates alternate next-hop paths only for unicast routes.



Configuring Node-Link Protection for OSPF on page 644

•



799


nssa Syntax

Hierarchy Level

Release Information

Description

nssa { area-range network/mask-length ; default-lsa { default-metric metric; metric-type type; type-7; } (no-summaries | summaries); } [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3) area area-id], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Configure a not-so-stubby area (NSSA). An NSSA allows external routes to be flooded within the area. These routes are then leaked into other areas. You cannot configure an area as being both a stub area and an NSSA. The remaining statements are explained separately.


800



•


•

stub on page 821



ospf Syntax Hierarchy Level

Release Information

Description

ospf { ... } [edit logical-systems logical-system-name protocols], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols], [edit protocols], [edit routing-instances routing-instance-name protocols]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable OSPF routing on the routing device. You must include the ospf statement to enable OSPF on the routing device.


OSPF is disabled on the routing device. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


•

[edit protocols ospf] Hierarchy Level


801


ospf3 Syntax Hierarchy Level

Release Information

Description

ospf3 { ... } [edit logical-systems logical-system-name protocols], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols], [edit protocols], [edit routing-instances routing-instance-name protocols]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable OSPFv3 routing on the routing device. You must include the ospf3 statement to enable OSPFv3.


802

OSPFv3 is disabled on the routing device. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


•

[edit protocols ospf3] Hierarchy Level



overload Syntax

Hierarchy Level

Release Information

Description

overload { timeout seconds; } [edit logical-systems logical-system-name protocols (oospf | ospf3)], [edit logical-systems logical-system-name protocols ospf topology (default | ipv4-multicast | name)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default | ipv4-multicast | name)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf topology (default | ipv4-multicast | name)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf topology (default | ipv4-multicast | name], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)],

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for Multitopology Routing introduced in Junos OS Release 9.0. Support for Multitopology Routing introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure the local routing device so that it appears to be overloaded. You might do this when you want the routing device to participate in OSPF routing, but do not want it to be used for transit traffic.

NOTE: Traffic destined to directly attached interfaces continues to reach the routing device.

Options

timeout seconds—(Optional) Number of seconds at which the overloading is reset. If no

timeout interval is specified, the routing device remains in overload state until the overload statement is deleted or a timeout is set. Range: 60 through 1800 seconds Default: 0 seconds


803


NOTE: Multitopology Routing does not support the timeout option.


804


Example: Configuring OSPF to Make Routing Devices Appear Overloaded on page 577

•

Configuring a Topology to Appear Overloaded on page 316



passive Syntax

Hierarchy Level

Release Information

Description

passive { traffic-engineering { remote-node-id address; } } [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. traffic-engineering and remote-node-id address statements introduced in Junos OS Release 8.0. traffic-engineering and remote-node-id address statements introduced in Junos OS Release 8.0 for EX Series switches. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Advertise the direct interface addresses on an interface without actually running OSPF on that interface. A passive interface is one for which the address information is advertised as an internal route in OSPF, but on which the protocol does not run. To configure an interface in OSPF passive traffic engineering mode, include the traffic-engineering statement. Configuring OSPF passive traffic engineering mode enables the dynamic discovery of OSPF AS boundary routers. Enable OSPF on an interface by including the interface statement at the [edit protocols (ospf | ospf3) area area-id] or the [edit routing-instances routing-instance-name protocols ospf area area-id] hierarchy levels. Disable it by including the disable statement, To prevent OSPF from running on an interface, include the passive statement. These three states are mutually exclusive.




805



•


•


•

disable on page 767

peer-interface Syntax

Hierarchy Level


peer-interface interface-name { disable; dead-interval seconds; hello-interval seconds; retransmit-interval seconds; transit-delay seconds; } [edit logical-systems logical-system-name protocols ospf area area-id], [edit protocols ospf area area-id]

Statement introduced before Junos OS Release 7.4. Configure a peer interface. interface-name—Name of the peer interface. To configure all interfaces, you can specify all.


806


Example: Configuring OSPFv2 Peer interfaces on page 552



poll-interval Syntax Hierarchy Level


Options

poll-interval seconds; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. For nonbroadcast interfaces only, specify how often the router sends hello packets out of the interface before it establishes adjacency with a neighbor. seconds—Frequency at which to send hello packets.




•



807



Release Information

Description Options

preference preference; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Set the route preference for OSPF internal routes. preference—Preference value. 32

Range: 0 through 4,294,967,295 (2

– 1)


808



•

external-preference on page 770



prefix-export-limit Syntax Hierarchy Level

Release Information

Description Options

prefix-export-limit number; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf topology (default | ipv4-multicast | name)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default | ipv4-multicast | name)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf topology (default | ipv4-multicast | name)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf topology (default | ipv4-multicast | name)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for Multitopology Routing introduced in Junos OS Release 9.0. Support for Multitopology Routing introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure a limit to the number of prefixes exported into OSPF. number—Prefix limit. 32

Range: 0 through 4,294,967,295 (2

– 1)

Default: None Required Privilege Level Related Documentation


Example: Limiting the Number of Prefixes Exported to OSPF on page 563

•

Configuring a Prefix Export Limit for MT-OSPF on page 316


809



Release Information

Description

Options

priority number; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Specify the routing device’s priority for becoming the designated routing device. The routing device that has the highest priority value on the logical IP network or subnet becomes the network’s designated router. You must configure at least one routing device on each logical IP network or subnet to be the designated router. You also should specify a routing device’s priority for becoming the designated router on point-to-point interfaces. number—Routing device’s priority for becoming the designated router. A priority value

of 0 means that the routing device never becomes the designated router. A value of 1 means that the routing device has the least chance of becoming a designated router. Range: 0 through 255 Default: 128 Required Privilege Level Related Documentation

810



•

Example: Controlling OSPF Designated Router Election on page 511



realm Syntax

Hierarchy Level

Release Information

Description

Options

realm (ipv4-unicast | ipv4-multicast | ipv6-unicast) { area area-id { interface interface-name; } } [edit logical-systems logical-system-name protocols ospf3], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3], [edit protocols ospf3], [edit routing-instances routing-instance-name protocols ospf3]

Statement introduced in Junos OS Release 9.2. Statement introduced in Junos OS Release 9.2 for EX Series switches. Configure OSPFv3 to advertise address families other than unicast IPv6. Junos OS maps each address family you configure to a separate realm with its own set of neighbors and link-state database. ipv4-unicast—Configure a realm for IPv4 unicast routes. ipv4-multicast—Configure a realm for IPv4 multicast routes. ipv6-multicast—Configure a realm for IPv6 multicast routes.





811


reference-bandwidth Syntax Hierarchy Level

Release Information

Description

reference-bandwidth reference-bandwidth; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Set the reference bandwidth used in calculating the default interface cost. The cost is calculated using the following formula: cost = ref-bandwidth/bandwidth

Options

reference-bandwidth—Reference bandwidth, in bits per second.

Range: 9600 through 1,000,000,000,000 bits Default: 100 Mbps (100,000,000 bits)

NOTE: The default behavior is to use the reference-bandwidth value to calculate the cost of OSPF interfaces. You can override this behavior for any OSPF interface by configuring a specific cost with the metric statement.


812



•

metric on page 789



retransmit-interval Syntax Hierarchy Level

Release Information

Description

Options

retransmit-interval seconds; [edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols ospf area area-id peer-interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id virtual-link], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Specify how long the routing device waits to receive a link-state acknowledgment packet before retransmitting link-state advertisements (LSAs) to an interface’s neighbors. seconds—Interval to wait.

Range: 1 through 65,535 seconds Default: 5 seconds

NOTE: You must configure LSA retransmit intervals to be equal to or greater than 3 seconds to avoid triggering a retransmit trap, because Junos OS delays LSA acknowledgments by up to 2 seconds.


813






Release Information

Description


814

rib-group group-name; [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Install routes learned from OSPF routing instances into routing tables in the OSPF routing table group. group-name—Name of the routing table group.



•


•


•


•




route-type-community Syntax Hierarchy Level

Release Information

Description

Options

route-type-community (iana | vendor); [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify an extended community value to encode the OSPF route type. Each extended community is coded as an eight-octet value. This statement sets the most significant bit to either an IANA or vendor-specific route type. iana—Encode a route type with the value 0x0306. This is the default value. vendor—Encode the route type with the value 0x8000.




secondary Syntax Hierarchy Level



secondary; [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name]

Statement introduced in Junos OS Release 9.2. Configure an interface to belong to another OSPF area. A logical interface can be configured as primary interface only for one area. For any other area for which you configure the interface, you must configure it as a secondary interface. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

interface on page 779

•

Example: Configuring Multiarea Adjacency for OSPF on page 534

•

interface on page 779


815


sham-link Syntax

Hierarchy Level


sham-link { local address; } [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf], [edit routing-instances routing-instance-name protocols ospf]

Statement introduced before Junos OS Release 7.4. Configure the local endpoint of a sham link. local address—Local endpoint address.

routing—To view this statement in the configuration. routing-control—To add this statement to the configuration •


sham-link-remote Syntax

Hierarchy Level

Release Information

Description

sham-link-remote address { demand-circuit; ipsec-sa name; metric metric; } [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], [edit routing-instances routing-instance-name protocols ospf area area-id]

Statement introduced before Junos OS Release 7.4. Support for ipsec-sa statement added in Junos OS Release 8.3. Configure the remote endpoint of a sham link. The remaining statements are explained separately.


816



•




shortcuts Syntax

Hierarchy Level

shortcuts { lsp-metric-into-summary; } [edit logical-systems logical-system-name protocols (ospf | ospf3) traffic-engineering], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) traffic-engineering], [edit protocols (ospf | ospf3) traffic-engineering], [edit routing-instances routing-instance-name protocols (ospf | ospf3)traffic-engineering]

Release Information

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4. Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4 for EX Series switches.

Description

Configure OSPF to use MPLS label-switched paths (LSPs) as shortcut next hops. By default, shortcut routes calculated through OSPFv2 are installed in the inet.3 routing table, and shortcut routes calculated through OSPFv3 are installed in the inet6.3 routing table.





817


simple-password Syntax Hierarchy Level

simple-password key; [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name authentication], [edit logical-systems logical-system-name protocols ospf area area-id virtual-link authentication], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name authentication], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id virtual-link authentication], [edit protocols ospf area area-id interface interface-name authentication], [edit protocols ospf area area-id virtual-link authentication], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name authentication], [edit routing-instances routing-instance-name protocols ospf area area-id virtual-link authentication]

Release Information


Description

Configure a simple authentication key (password).


818

key—Password string.



•




spf-options Syntax

Hierarchy Level

Release Information

Description

Options

spf-options { delay milliseconds; holddown milliseconds; rapid-runs number; } [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf topology (default | ipv4-multicast | name)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default | ipv4-multicast | name)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf topology (default | ipv4-multicast | name)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf topology (default | ipv4-multicast | name)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced in Junos OS Release 8.5. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for Multitopology Routing introduced in Junos OS Release 9.0. Support for Multitopology Routing introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure options for running the shortest-path-first (SPF) algorithm. You can configure the following: •

A delay for when to run the SPF algorithm after a network topology change is detected.

•

The maximum number of times the SPF algorithm can run in succession.

•

A hold-down interval after the SPF algorithm runs the maximum number of times.

delay milliseconds—Time interval between the detection of a topology change and when

the SPF algorithm runs. Range: 50 through 8000 milliseconds Default: 200 milliseconds


819


holddown milliseconds—Time interval to hold down, or to wait before a subsequent SPF

algorithm runs after the SPF algorithm has run the configured maximum number of times in succession. Range: 2000 through 20,000 milliseconds Default: 5000 milliseconds rapid-runs number—Maximum number of times the SPF algorithm can run in succession.

After the maximum is reached, the hold down interval begins. Range: 1 through 5 Default: 3 Required Privilege Level Related Documentation

820


Example: Configuring SPF Algorithm Options for OSPF on page 580

•




stub Syntax Hierarchy Level

Release Information

Description

stub ; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3) area area-id], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Specify that this area not be flooded with AS external link-state advertisements (LSAs). You must include the stub statement when configuring all routing devices that are in the stub area. The backbone cannot be configured as a stub area. You cannot configure an area to be both a stub area and a not-so-stubby area (NSSA).

Options

no-summaries—(Optional) Do not advertise routes into the stub area. If you include the default-metric option, only the default route is advertised. summaries—(Optional) Flood summary LSAs into the stub area.




•

Example: Configuring OSPF Stub and Totally Stubby Areas on page 524

•

nssa on page 800


821


summaries Syntax Hierarchy Level

Release Information

Description

(summaries | no-summaries); [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa], [edit protocols (ospf | ospf3) area area-id nssa], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id nssa], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Configure whether or not area border routers advertise summary routes into an not-so-stubby area (NSSA): •

summaries—Flood summary link-state advertisements (LSAs) into the NSSA.

•

no-summaries—Prevent area border routers from advertising summaries into an NSSA.

If default-metric is configured for an NSSA, a Type 3 LSA is injected into the area by default. Required Privilege Level Related Documentation

822



•


•

nssa on page 800

•

stub on page 821

•

Configuring OSPF Areas



te-metric Syntax Hierarchy Level


Options

te-metric metric; [edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], [edit protocols ospf area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Metric value used by traffic engineering for information injected into the traffic engineering database. The value of the traffic engineering metric does not affect normal OSPF forwarding. metric—Metric value.

Range: 1 through 65,535 Default: Value of the IGP metric Required Privilege Level Related Documentation


Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface on page 654


823


traceoptions Syntax

Hierarchy Level

Release Information

Description

traceoptions { file filename ; flag flag ; } [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit protocols (ospf | ospf3)], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure OSPF protocol-level tracing options. To specify more than one tracing operation, include multiple flag statements.

NOTE: The traceoptions statement is not supported on QFabric switches.

Default

The default OSPF protocol-level tracing options are those inherited from the routing protocols traceoptions statement included at the [edit routing-options] hierarchy level.

Options

disable—(Optional) Disable the tracing operation. You can use this option to disable a


name within quotation marks. All files are placed in the directory /var/log. We recommend that you place OSPF tracing output in the file ospf-log. files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and

so on, until the maximum number of trace files is reached. Then, the oldest trace file is overwritten.

824



If you specify a maximum number of files, you also must specify a maximum file size with the size option. Range: 2 through 1000 files Default: 10 files flag flag—Tracing operation to perform. To specify more than one tracing operation,

include multiple flag statements. OSPF Tracing Flags •

database-description—Database description packets, which are used in synchronizing

the OSPF and OSPFv3 topological database. •

error—OSPF and OSPFv3 error packets.

•

event—OSPF and OSPFv3 state transitions.

•

flooding—Link-state flooding packets.

•

graceful-restart—Graceful-restart events.

•

hello—Hello packets, which are used to establish neighbor adjacencies and to determine

whether neighbors are reachable. •

ldp-synchronization—Synchronization events between OSPF and LDP.

•

lsa-ack—Link-state acknowledgment packets, which are used in synchronizing the

OSPF topological database. •

lsa-analysis—Link-state analysis. Specific to the Juniper Networks implementation of

OSPF, Junos OS performs LSA analysis before running the shortest-path-first (SPF) algorithm. LSA analysis helps to speed the calculations performed by the SPF algorithm. •

lsa-request—Link-state request packets, which are used in synchronizing the

OSPF topological database. •

lsa-update—Link-state updates packets, which are used in synchronizing the OSPF

topological database. •

nsr-synchronization—Nonstop routing synchronization events.

•

on-demand—Trace demand circuit extensions.

•

packet-dump—Content of selected packet types.

•

packets—All OSPF packets.

•

restart-signaling—(OSPFv2 only) Restart-signaling graceful restart events.

•

spf—Shortest-path-first (SPF) calculations.

Global Tracing Flags


825


•

all—All tracing operations.

•

general—A combination of the normal and route trace operations.

•

normal—All normal operations. If you do not specify this option, only unusual or

abnormal operations are traced. •

policy—Policy operations and actions.

•

route—Routing table changes.

•

state—State transitions.

•

task—Routing protocol task processing.

•

timer—Routing protocol timer processing.



detail—Detailed trace information.

•

receive—Packets being received.

•

send—Packets being transmitted.




826


Example: Tracing OSPF Protocol Traffic on page 739



traffic-engineering See the following sections: •

traffic-engineering (OSPF) on page 828

•

traffic-engineering (Passive TE Mode) on page 830


827


traffic-engineering (OSPF) Syntax

Hierarchy Level

Release Information


traffic-engineering { ; ; ignore-lsp-metrics; multicast-rpf-routes; no-topology; shortcuts { lsp-metric-into-summary; } } [edit logical-systems logical-system-name protocols (ospf | ospf3)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], [edit protocols (ospf | ospf3)], [edit routing-instances routing-instance-name protocols (ospf | ospf3)]

Statement introduced before Junos OS Release 7.4. multicast-rpf-routes option introduced in Junos OS Release 7.5. advertise-unnumbered-interfaces option introduced in Junos OS Release 8.5. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4. Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4 for EX Series switches. credibility-protocol-preference statement introduced in Junos OS Release 9.4. credibility-protocol-preference statement introduced in Junos OS Release 9.4 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable the OSPF traffic engineering features. Traffic engineering support is disabled. advertise-unnumbered-interfaces—(Optional) (OSPFv2 only) Include the link-local

identifier in the link-local traffic-engineering link-state advertisement. You do not need to include this statement if RSVP is able to signal unnumbered interfaces as defined in RFC 3477. credibility-protocol-preference—(Optional) (OSPFv2 only) Use the configured preference

value for OSPF routes to calculate the traffic engineering database credibility value used to select IGP routes. Use this statement to override the default behavior, in which the traffic engineering database prefers IS-IS routes even if OSPF routes are configured with a lower, that is, preferred, preference value. For example, OSPF routes have a default preference value of 10, whereas IS-IS Level 1 routes have a default preference value of 15. When protocol preference is enabled, the credibility value is determined by deducting the protocol preference value from a base value of 512. Using default protocol preference values, OSPF has a credibility value of 502, whereas IS-IS has a credibility value of 497. Because the traffic engineering database prefers IGP routes with the highest credibility value, OSPF routes are now preferred.

828



multicast-rpf-routes—(Optional) (OSPFv2 only) Install routes for multicast RPF checks

into the inet.2 routing table. The inet.2 routing table consists of unicast routes used for multicast RPF lookup. RPF is an antispoofing mechanism used to check whether the packet is coming in on an interface that is also sending data back to the packet source.

NOTE: You must enable OSPF traffic engineering shortcuts to use the multicast-rpf-routes statement. You must not allow LSP advertisements into OSPF when configuring the multicast-rpf-routes statement.

no-topology—(Optional) (OSPFv2 only) Disable the dissemination of the link-state

topology information. The remaining statements are explained separately. Required Privilege Level Related Documentation




829


traffic-engineering (Passive TE Mode) Syntax

Hierarchy Level

Release Information

Description

Default Options Required Privilege Level Related Documentation

830

traffic-engineering { remote-node-id address; } [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name passive], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name passive], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name passive], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name passive], [edit protocols (ospf | ospf3) area area-id interface interface-name passive], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name passive], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name passive], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name passive]

Statement introduced in Junos OS Release 8.0. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Configure an interface in OSPF passive traffic engineering mode to enable dynamic discovery of OSPF AS boundary routers. OSPF passive traffic-engineering mode is disabled. remote-node-id address—The IP address at the far end of the inter-AS link.



•




transit-delay Syntax Hierarchy Level

Release Information

Description

transit-delay seconds; [edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id virtual-link], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], [edit protocols ospf area area-id peer-interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id virtual-link], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name], [edit routing-instances routing-instance-name protocols ospf area area-id virtual-link], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Set the estimated time required to transmit a link-state update on the interface. When calculating this time, make sure to account for transmission and propagation delays. You should never have to modify the transit delay time.

Options

seconds—Estimated time, in seconds.

Range: 1 through 65,535 seconds Default: 1 second Required Privilege Level Related Documentation




831


transmit-interval Syntax Hierarchy Level


transmit-interval milliseconds; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], [edit protocols (ospf | ospf3) area area-id interface interface-name], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name]

Statement introduced before Junos OS Release 7.4. Set the interval at which OSPF packets are transmitted on an interface. milliseconds—Transmission interval, in milliseconds.

Range: 1 through 4,294,967 milliseconds Default: 30 milliseconds Required Privilege Level Related Documentation

832





type-7 Syntax Hierarchy Level

Release Information

Description

type-7; [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa default-lsa], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa default-lsa], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa default-lsa], [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa default-lsa], [edit protocols (ospf | ospf3) area area-id nssa default-lsa], [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa default-lsa], [edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa default-lsa], [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa default-lsa]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for the realm statement introduced in Junos OS Release 9.2. Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. Flood Type 7 default link-state advertisements (LSAs) if the no-summaries statement is configured. By default, when the no-summaries statement is configured, a Type 3 LSA is injected into not-so-stubby areas (NSSAs) for Junos OS Release 5.0 and later. To support backward compatibility with earlier Junos OS releases, include the type-7 statement. This statement enables NSSA ABRs to advertise a Type 7 default LSA into the NSSA if you have also included the no-summaries statement in the configuration.




•


•

no-summaries on page 822


833


virtual-link Syntax

Hierarchy Level

Release Information

Description

Options

virtual-link neighbor-id router-id transit-area area-id { disable; authentication key ; dead-interval seconds; hello-interval seconds; ipsec-sa name; retransmit-interval seconds; transit-delay seconds; } [edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], [edit protocols (ospf | ospf3) area area-id], [edit routing-instances routing-instance-name protocols ospf area area-id]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. For backbone areas only, create a virtual link to use in place of an actual physical link. All area border routers and other routing devices on the backbone must be contiguous. If this is not possible and there is a break in OSPF connectivity, use virtual links to create connectivity to the OSPF backbone. When configuring virtual links, you must configure links on the two routing devices that form the end points of the link, and both of these routing devices must be area border routers. You cannot configure links through stub areas. neighbor-id router-id—IP address of the routing device at the remote end of the virtual

link. transit-area area-id—Area identifier of the area through which the virtual link transits.

Virtual links are not allowed to transit the backbone area. The remaining statements are explained separately. Required Privilege Level Related Documentation

834



•

Example: Configuring OSPF Virtual Links on page 519


CHAPTER 19

Introduction to RIP This chapter discusses the following topics that provide background information about RIP: •

RIP Overview on page 835

•

RIP Standards on page 836

RIP Overview RIP is an interior gateway protocol (IGP) that uses a distance-vector algorithm to determine the best route to a destination, using the hop count as the metric. This section discusses the following topics: •

RIP Protocol Overview on page 835

•

RIP Packets on page 836

RIP Protocol Overview The RIP IGP uses the Bellman-Ford, or distance-vector, algorithm to determine the best route to a destination. RIP uses the hop count as the metric. RIP allows hosts and routers to exchange information for computing routes through an IP-based network. RIP is intended to be used as an IGP in reasonably homogeneous networks of moderate size. The Junos OS supports RIP versions 1 and 2.

NOTE: RIP is not supported for multipoint interfaces.

RIP version 1 packets contain the minimal information necessary to route packets through a network. However, this version of RIP does not support authentication or subnetting. RIP uses User Datagram Protocol (UDP) port 520. RIP has the following architectural limitations: •

The longest network path cannot exceed 15 hops (assuming that each network, or hop, has a cost of 1).


835


•

RIP depends on counting to infinity to resolve certain unusual situations—When the network consists of several hundred routers, and when a routing loop has formed, the amount of time and network bandwidth required to resolve a next hop might be great.

•

RIP uses only a fixed metric to select a route. Other IGPs use additional parameters, such as measured delay, reliability, and load.

RIP Packets RIP packets contain the following fields: •

Command—Indicates whether the packet is a request or response message. Request messages seek information for the router’s routing table. Response messages are sent periodically and also when a request message is received. Periodic response messages are called update messages. Update messages contain the command and version fields and 25 destinations (by default), each of which includes the destination IP address and the metric to reach that destination.

NOTE: Beginning with Junos OS Release 11.1, three additional command field types are available to support RIP demand circuits. When you configure an interface for RIP demand circuits, the command field indicates whether the packet is an update request, update response, or update acknowledge message. Neighbor interfaces send updates on demand, not periodically. These command field types are only valid on interfaces configured for RIP demand circuits. For more detailed information, see “RIP Demand Circuits Overview” on page 857.

•

Version number—Version of RIP that the originating router is running.

•

Address family identifier—Address family used by the originating router. The family is always IP.

•

Address—IP address included in the packet.

•

Metric—Value of the metric advertised for the address.

•

Mask—Mask associated with the IP address (RIP version 2 only).

•

Next hop—IP address of the next-hop router (RIP version 2 only).

RIP Standards RIP is defined in the following documents:

836

•

RFC 1058, Routing Information Protocol

•

RFC 2082, RIP-2 MD-5 Authentication

•

RFC 2091, Triggered Extensions to RIP to Support Demand Circuits

•

RFC 2453, RIP Version 2


Chapter 19: Introduction to RIP

To access Internet Requests for Comments (RFCs) and drafts, go to the Internet Engineering Task Force (IETF) Web site at http://www.ietf.org.


837


838


CHAPTER 20

RIP Configuration Guidelines This chapter discusses the following topics: •

Configuring RIP on page 839

•

Minimum RIP Configuration on page 841

•

Overview of RIP Global Properties on page 842

•

Overview of RIP Neighbor Properties on page 842

•

Configuring Authentication for RIP on page 843

•

Configuring BFD for RIP on page 844

•

Overview of BFD Authentication for RIP on page 846

•

Configuring BFD Authentication for RIP on page 848

•

Accepting RIP Packets with Nonzero Values in Reserved Fields on page 851

•

Applying Policies to RIP Routes Imported from Neighbors on page 852

•

Configuring the Number of Route Entries in RIP Update Messages on page 852

•

Configuring the Metric Value Added to Imported RIP Routes on page 852

•

Configuring RIP Update Messages on page 853

•

Configuring Routing Table Groups for RIP on page 853

•

Configuring RIP Timers on page 853

•

Configuring Group-Specific RIP Properties on page 854

•

Configuring Graceful Restart for RIP on page 856

•

Disabling Strict Address Checking for RIP Messages on page 857

•

RIP Demand Circuits on page 857

•

Tracing RIP Protocol Traffic on page 863

•

Example: Configuring RIP on page 864

Configuring RIP To configure RIP, you include the following statements: protocols { rip { any-sender;


839


authentication-key password; authentication-type type; (check-zero | no-check-zero); graceful-restart { disable; restart-time seconds; } holddown seconds; import [ policy-names ]; message-size number; metric-in metric; receive receive-options; rib-group group-name; route-timeout seconds; send send-options; update-interval seconds; traceoptions { file filename ; flag flag ; } group group-name { bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } demand-circuit; export [ policy-names ]; max-retrans-time seconds; metric-out metric; preference number; route-timeout seconds; update-interval seconds; neighbor neighbor-name { authentication-key password; authentication-type type; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; }

840


Chapter 20: RIP Configuration Guidelines

detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); } (check-zero | no-check-zero); demand-circuit; import [ policy-names ]; max-retrans-time seconds; message-size number; metric-in metric; metric-out metric; receive receive-options; route-timeout seconds; send send-options; update-interval seconds; } } } }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. By default, RIP is disabled. To have a router exchange routes with other routers, you must configure RIP groups and neighbors. RIP routes received from routers not configured as RIP neighbors are ignored. Likewise, RIP routes are advertised only to routers configured as RIP neighbors, with an appropriate RIP export policy applied.

Minimum RIP Configuration For a routing device to accept RIP routes, you must include at least the rip, group, and neighbor statements. Routes received from routing devices that are not configured as neighbors are ignored. All other RIP configuration statements are optional. This minimum configuration defines one neighbor. Include one neighbor statement for each interface on which you want to receive routes. The local routing device imports all routes by default from this neighbor and does not advertise routes. The routing device can receive both version 1 and version 2 update messages, with 25 route entries per message. For routing instances, include the statements at the [edit routing-instances routing-instance-name protocols rip] hierarchy level. protocols { rip { group group-name { neighbor interface-name {


841


} } } }

NOTE: When you configure RIP on an interface, you must also include the family inet statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level.

Overview of RIP Global Properties To define RIP global properties, which apply to all RIP neighbors, include one or more of the following statements. authentication-key password; authentication-type type; (check-zero | no-check-zero); import [ policy-names ]; message-size number; metric-in metric; receive receive-options; rib-group group-name; send send-options;

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. For more information about configuring RIP global properties, see the following topics: •


•


•


•


•


•


•


Overview of RIP Neighbor Properties To define neighbor-specific properties, include one or more of the following statements. neighbor neighbor-name { authentication-key password; authentication-type type; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name;

842



loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (0 | 1 | automatic); } (check-zero | no-check-zero); import [ policy-names ]; message-size number; metric-in metric; receive receive-options; send send-options; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. For more information about configuring RIP neighbor properties, see the following topics: •


•


•


•


•


•


•


Configuring Authentication for RIP You can configure the router to authenticate RIP route queries. By default, authentication is disabled. You can use the following authentication method: •

Simple authentication—Uses a text password that is included in the transmitted packet. The receiving router uses an authentication key (password) to verify the packet.

•

MD5 authentication—Creates an encoded checksum that is included in the transmitted packet. The receiving router uses an authentication key (password) to verify the packet’s MD5 checksum.

To enable authentication and specify an authentication method and password, include the authentication-key and authentication-type statements: authentication-key password;


843


authentication-type type;

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. The password can be up to 16 contiguous characters and can include any ASCII strings.

Configuring BFD for RIP The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures in a network. Hello packets are sent at a specified, regular interval. A neighbor failure is detected when the routing device stops receiving a reply after a specified interval. BFD works with a wide variety of network environments and topologies. BFD failure detection times are shorter than RIP detection times, providing faster reaction times to various kinds of failures in the network. These timers are also adaptive. For example, a timer can adapt to a higher value if the adjacency fails, or a neighbor can negotiate a higher value for a timer than the one configured.

NOTE: To enable BFD for RIP, both sides of the connection must receive an update message from the peer. By default, RIP does not export any routes. Therefore you must enable update messages to be sent by configuring an export policy for routes before a BFD session is triggered.

To enable failure detection, include the bfd-liveness-detection statement: bfd-liveness-detection { detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); }

To specify the threshold for the adaptation of the detection time, include the threshold statement: detection-time { threshold milliseconds; }

When the BFD session detection time adapts to a value equal to or higher than the threshold, a single trap and a system log message are sent. To specify the minimum transmit and receive interval for failure detection, include the minimum-interval statement:

844



minimum-interval milliseconds;

This value represents the minimum interval at which the local routing device transmits hello packets as well as the minimum interval at which the routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a value in the range from 1 through 255,000 milliseconds. You can also specify the minimum transmit and receive intervals separately.



•


•


To specify only the minimum receive intervals for failure detection, include the minimum-receive-interval statement: minimum-receive-interval milliseconds;

This value represents the minimum interval at which the local routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a value in the range from 1 through 255,00 milliseconds. To specify the number of hello packets not received by a neighbor that causes the originating interface to be declared down, include the multiplier statement: multiplier number;

The default is 3, and you can configure a value in the range from 1 through 255. To specify only the minimum transmit interval for failure detection, include the minimum-interval statement: transmit-interval { minimum-interval milliseconds; }


845


This value represents the minimum interval at which the local routing device transmits hello packets to the neighbor with which it has established a BFD session. You can configure a value in the range from 1 through 255,000 milliseconds. To specify the threshold for detecting the adaptation of the transmit interval, include the threshold statement: transmit-interval { threshold milliseconds; }

The threshold value must be greater than the transmit interval. To specify the BFD version used for detection, include the version statement: version (1 | automatic);

The default is to have the version detected automatically. You can trace BFD operations by including the traceoptions statement at the [edit protocols bfd] hierarchy level. For more information, see “Tracing BFD Protocol Traffic” on page 86. In Junos OS Release 9.0 and later, you can configure BFD sessions not to adapt to changing network conditions. To disable BFD adaptation, include the no-adaptation statement: no-adaptation;

NOTE: We recommend that you not disable BFD adaptation unless it is preferable not to have BFD adaptation enabled in your network.


Overview of BFD Authentication for RIP BFD enables rapid detection of communication failures between adjacent systems. By default, authentication for BFD sessions is disabled. However, when running BFD over Network Layer protocols, the risk of service attacks can be significant. We strongly recommend using authentication if you are running BFD over multiple hops or through insecure tunnels. Beginning with Junos OS Release 9.6, the Junos OS supports authentication for BFD sessions running over RIP. BFD authentication is only supported in the domestic image and is not available in the export image. You authenticate BFD sessions by specifying an authentication algorithm and keychain, and then associating that configuration information with a security authentication keychain using the keychain name.

846



The following sections describe the supported authentication algorithms, security keychains, and the level of authentication that can be configured: •


•


•















847




•


•


•


•


•


Configuring BFD Authentication for RIP Beginning with Junos OS Release 9.6, you can configure authentication for BFD sessions running over RIP. Only three steps are needed to configure authentication on a BFD session: 1.

Specify the BFD authentication algorithm for the RIP protocol.

2. Associate the authentication keychain with the RIP protocol. 3. Configure the related security authentication keychain.

The following sections provide instructions for configuring and viewing BFD authentication on RIP:

848

•


•




Configuring BFD Authentication Parameters BFD authentication can be configured for the entire RIP protocol, or a specific RIP group, neighbor, or routing instance. To configure BFD authentication: 1.

Specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use. [edit] user@host# set protocols rip bfd-liveness-detection authentication algorithm keyed-sha-1 user@host# set protocols rip group rip-gr2 bfd-liveness-detection authentication algorithm keyed-sha-1 user@host# set protocols rip group rip-gr2 neighbor 10.10.32.7 bfd-liveness-detection authentication algorithm keyed-sha-1


2. Specify the keychain to be used to associate BFD sessions on RIP with the unique

security authentication keychain attributes. The keychain you specify must match a keychain name configured at the [edit security authentication key-chains] hierarchy level. [edit] user@host# set protocols rip bfd-liveness-detection authentication keychain bfd-rip user@host# set protocols rip group rip-gr2 bfd-liveness-detection authentication keychain bfd-rip user@host# set protocols rip group rip-gr2 neighbor 10.10.32.7 bfd-liveness-detection authentication keychain bfd-rip



The matching key-chain-name as specified in Step 2.

•


•


•

The time at which the authentication key becomes active, yyyy-mm-dd.hh:mm:ss. [edit security]


849


user@host# authentication-key-chains key-chain bfd-bgp key 53 secret $9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm start-time 2009-06-14.10:00:00 4. (Optional) Specify loose authentication checking if you are transitioning from

nonauthenticated sessions to authenticated sessions. [edit] user@host> set protocols rip bfd-liveness-detection authentication loose-check user@host> set protocols rip group rip-gr2 bfd-liveness-detection authentication loose-check user@host> set protocols rip group rip-gr2 neighbor 10.10.32.7 bfd-liveness-detection authentication loose-check 5. (Optional) View your configuration using the show bfd session detail or show bfd



Viewing Authentication Information for BFD Sessions You can view the existing BFD authentication configuration using the show bfd session detail and show bfd session extensive commands. The following example shows BFD authentication configured for the rip-gr2 BGP group. It specifies the keyed SHA-1 authentication algorithm and a keychain name of bfd-rip. The authentication keychain is configured with two keys. Key 1 contains the secret data “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm” and a start time of June 1, 2009 at 9:46:02 AM PST. Key 2 contains the secret data “$9$a5jiKW9l.reP38ny.TszF2/9” and a start time of June 1, 2009 at 3:29:20 PM PST. [edit protocols rip] group rip-gr2 { bfd-liveness-detection { authentication { algorithm keyed-sha-1; key-chain bfd-rip; } } } [edit security] authentication key-chains { key-chain bfd-rip { key 1 { secret “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm”; start-time “2009-6-1.09:46:02 -0700”; } key 2 { secret “$9$a5jiKW9l.reP38ny.TszF2/9”; start-time “2009-6-1.15:29:20 -0700”; }

850



} }


user@host# show bfd session detail Detect Transmit Address State Interface Time Interval 50.0.0.2 Up ge-0/1/5.0 0.900 0.300 Client RIP, TX interval 0.300, RX interval 0.300, Authenticate Session up time 3d 00:34 Local diagnostic None, remote diagnostic NbrSignal Remote state Up, version 1 Replicated



Multiplier 3

user@host# show bfd session extensive Detect Transmit Address State Interface Time Interval Multiplier 50.0.0.2 Up ge-0/1/5.0 0.900 0.300 3 Client RIP, TX interval 0.300, RX interval 0.300, Authenticate keychain bfd-rip, algo keyed-sha-1, mode strict Session up time 00:04:42 Local diagnostic None, remote diagnostic NbrSignal Remote state Up, version 1 Replicated Min async interval 0.300, min slow interval 1.000 Adaptive async TX interval 0.300, RX interval 0.300 Local min TX interval 0.300, minimum RX interval 0.300, multiplier 3 Remote min TX interval 0.300, min RX interval 0.300, multiplier 3 Local discriminator 2, remote discriminator 2 Echo mode disabled/inactive Authentication enabled/active, keychain bfd-rip, algo keyed-sha-1, mode strict

•

Overview of BFD Authentication for RIP on page 846

•


•


•


•


Accepting RIP Packets with Nonzero Values in Reserved Fields Some of the reserved fields in RIP version 1 packets must be zero, while in RIP version 2 packets most of these reserved fields can contain nonzero values. By default, RIP discards version 1 packets that have nonzero values in the reserved fields and version 2 packets


851


that have nonzero values in the fields that must be zero. This default behavior implements the RIP version 1 and version 2 specifications. If you find that you are receiving RIP version 1 packets with nonzero values in the reserved fields or RIP version 2 packets with nonzero values in the fields that must be zero, you can configure RIP to receive these packets in spite of the fact that they are being sent in violation of the specifications in RFC 1058 and RFC 2453. To receive packets whose reserved fields are nonzero, include the no-check-zero statement: no-check-zero;


Applying Policies to RIP Routes Imported from Neighbors To filter routes being imported by the local routing device from its neighbors, include the import statement and list the names of one or more policies to be evaluated. If you specify more than one policy, they are evaluated in order (first to last) and the first matching policy is applied to the route. If no match is found, the local routing device does not import any routes. import [ policy-names ];


•


Configuring the Number of Route Entries in RIP Update Messages By default, RIP includes 25 route entries in each update message. To change the number of route entries in an update message, include the message-size statement: message-size number;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement

NOTE: To ensure interoperability with routers from other vendors, do not change the default number of route entries in a RIP update message.

Configuring the Metric Value Added to Imported RIP Routes By default, RIP imports routes from the neighbors configured with the neighbor statement. These routes include those learned from RIP as well as those learned from other protocols. By default, the current route metric of routes that RIP imports from its neighbors is incremented by 1.

852



To change the default metric to be added to incoming routes, include the metric-in statement: metric-in metric; metric can be a value from 1 through 16.


•


Configuring RIP Update Messages You can configure whether the RIP update messages conform to RIP version 1 only, to RIP version 2 only, or to both versions. You can also disable the sending or receiving of update messages. To configure the sending and receiving of update messages, include the receive and send statements: receive receive-options; send send-options;

For a list of hierarchy levels at which you can include these statements and a list of the valid options, see the statement summary sections for these statements.

Configuring Routing Table Groups for RIP You can install routes learned through RIP into multiple routing tables by configuring a routing table group. RIP routes are installed into each routing table that belongs to that routing table group. To configure a routing table group for RIP routes, include the rib-group statement: rib-group group-name;


Configuring RIP Timers You can configure various timers for RIP. RIP routes expire when either a route timeout limit is met or a route metric reaches infinity, and the route is no longer valid. However, the expired route is retained in the routing table for a time period so that neighbors can be notified that the route has been dropped. This time period is set by configuring the hold-down timer. Upon expiration of the hold-down timer, the route is removed from the routing table. To configure the hold-down timer for RIP, include the holddown statement: holddown seconds; seconds can be a value from 10 through 180. The default value is 120 seconds.


853


For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. You can set a route timeout interval. If a route is not refreshed after being installed into the routing table by the specified time interval, the route is removed from the routing table. To configure the route timeout for RIP, include the route-timeout statement: route-timeout seconds; seconds can be a value from 30 through 360. The default value is 180 seconds.

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. You can set an update time interval to periodically send out routes learned by RIP to neighbors. To configure the update time interval, include the update-interval statement: update-interval seconds; seconds can be a value from 10 through 60. The default value is 30 seconds.


NOTE: Beginning with Junos OS Release 11.1, a retransmission timer is available for RIP demand circuits. For information about this and the other timers used for RIP demand circuits, see “RIP Demand Circuits Overview” on page 857.

Configuring Group-Specific RIP Properties You can group together neighbors that share the same export policy and export metric defaults. You configure group-specific RIP properties by including the group statement at the [edit protocols rip] hierarchy level. Each group must contain at least one neighbor. You should create a group for every export policy you have. To configure neighbors, see “Overview of RIP Neighbor Properties” on page 842. [edit protocols rip] group group-name { bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; }

854



minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (0 | 1 | automatic); } export [ policy-names ]; preference number; metric-out metric; neighbor neighbor-options; }

This section discusses the following tasks: •

Applying Policies to Routes Exported by RIP on page 855

•

Configuring the Default Preference Value for RIP on page 855

•

Configuring the Metric for Routes Exported by RIP on page 856

Applying Policies to Routes Exported by RIP By default, RIP does not export routes it has learned to its neighbors. To enable RIP to export routes, apply one or more export policies. To apply export policies and to filter routes being exported from the local routing device to its neighbors, include the export statement and list the name of the policy to be evaluated: export [ policy-names ];

To configure export policy globally for all RIP neighbors, include the export statement. For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. You can define one or more export policies. If no routes match the policies, the local routing device does not export any routes to its neighbors. Export policies override any metric values determined through calculations involving the values configured with the metric-in and metric-out statements (discussed in “Configuring the Metric Value Added to Imported RIP Routes” on page 852 and “Configuring Group-Specific RIP Properties” on page 854, respectively).

NOTE: The export policy on RIP does not support manipulating routing information of the next hop.

For more information about creating policies, see the Junos OS Routing Policy Configuration Guide.

Configuring the Default Preference Value for RIP By default, the Junos OS assigns a preference of 100 to routes that originate from RIP. When the Junos OS determines a route’s preference to become the active route, the


855


software selects the route with the lowest preference and installs this route into the forwarding table. (For more information about preferences, see “Route Preferences Overview” on page 6.) To modify the default RIP preference value, include the preference statement: preference preference;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. 32

preference can be a value from 0 through 4,294,967,295 (2

– 1).

Configuring the Metric for Routes Exported by RIP If you have included the export statement, RIP exports routes it has learned to the neighbors configured by including the neighbor statement. For more information about those statements, see“Configuring Group-Specific RIP Properties” on page 854. The metric associated with a RIP route (unless modified by an export policy) is the normal RIP metric. For example, a RIP route with a metric of 5 learned from a neighbor configured with a metric-in value of 2 is advertised with a combined metric of 7 when advertised to RIP neighbors in the same group. However, if this route was learned from a RIP neighbor in a different group or from a different protocol, the route is advertised with the metric value configured for that group with the metric-out statement. The default value for the metric-out statement is 1. The metric for a route may be modified with an export policy. That metric is seen when the route is exported to the next hop. To increase the metric for routes advertised outside a group, include the metric-out statement: metric-out metric;


Configuring Graceful Restart for RIP Graceful restart is disabled by default. You can globally enable graceful restart for all routing protocols at the [edit routing-options] hierarchy level. You can configure graceful restart parameters specifically for RIP. To do this, include the graceful-restart statement: graceful-restart { restart-time seconds; }


856



To disable graceful restart for RIP, specify the disable statement. To configure a time period for the restart to finish, specify the restart-time statement.

Disabling Strict Address Checking for RIP Messages If the sender of a RIP message does not belong to the subnet of the interface, the message is discarded. This situation may cause problems with dropped packets when RIP is running on point-to-point interfaces, or when the addresses on the interfaces do not fall in the same subnet. You can resolve this by disabling strict address checks on the RIP traffic. To disable strict address checks, include the any-sender statement: any-sender;


NOTE: The any-sender statement is supported only for peer-to-peer interfaces.

RIP Demand Circuits •

RIP Demand Circuits Overview on page 857

•

Example: Configuring RIP Demand Circuits on page 860

RIP Demand Circuits Overview RIP periodically sends routing information (RIP packets) to neighboring devices. These periodic broadcasts can consume bandwidth resources and interfere with network traffic by preventing WAN circuits from being closed. Demand circuits for RIP is defined in RFC 2091 and overcomes these issues by exchanging incremental updates on demand. A demand circuit is a point-to-point connection between two neighboring interfaces configured for RIP. Demand circuits preserve bandwidth by establishing a link when data needs to be transferred, and terminating the link when the data transfer is complete. Demand circuits increase the efficiency of RIP on the configured interfaces by offering minimal network overhead in terms of messages passed between the demand circuit end points, conserving resources, and reducing costs. By configuring RIP demand circuits, a specific event triggers the device to send an update, thereby eliminating the periodic transmission of RIP packets over the neighboring interface. To save overhead, the device sends RIP information only when changes occur in the routing database, such as: •

The device is first powered on

•

The device receives a request for route update information

•

A change occurs in the network

•

The demand circuit goes down or comes up


857


The device sends update requests, update responses, and acknowledgments. In addition, the device retransmits updates and requests until valid acknowledgments are received. The device dynamically learns RIP neighbors. If the neighboring interface goes down, RIP flushes routes learned from the neighbor’s IP address. Routes learned from demand circuits do not age like other RIP entries because demand circuits are in a permanent state. Routes in a permanent state are only removed under the following conditions: •

A formerly reachable route changes to unreachable in an incoming response

•

The demand circuit is down due to an excessive number of unacknowledged retransmissions

You can also set the RIP hold-down timer and the RIP demand circuit retransmission timer to regulate performance. The demand circuit uses these timers to determine if there is a change that requires update messages to be sent. There is also a database timer that runs only when RIP flushes learned routes from the routing table. This topic includes the following sections: •

RIP Demand Circuit Packets on page 858

•

Timers Used by RIP Demand Circuits on page 859

RIP Demand Circuit Packets When you configure an interface for RIP demand circuits, the supported command field packet types are different than those for RIP version 1 and RIP version 2. RIP packets for RIP demand circuits contain three additional packet types and an extended 4-byte update header. Both RIP version 1 and RIP version 2 support the three packet types and the extended 4-byte header. Table 11 on page 858 describes the three packet types.

Table 11: RIP Demand Circuit Packet Types

858

Packet Type

Description

Update Request

Update request messages seek information for the device’s routing table. This message is sent when the device is first powered on or when a down demand circuit comes up. The device sends this message every 5 seconds (by default) until an update response message is received.

Update Response

Update response messages are sent in response to an update request message, which occurs when the device is first powered on or when a down demand circuit comes up. Each update response message contains a sequence number that the neighbor uses to acknowledge the update request.

Update Acknowledge

Update acknowledge messages are sent in response to every update response message received by the neighbor.



NOTE: These packets are only valid on interfaces configured for RIP demand circuits. If a demand circuit receives a RIP packet that does not contain these packet types, it silently discards the packet and logs an error message similar to the following: Ignoring RIP packet with invalid version 0 from neighbor 10.0.0.0 and source 10.0.0.1


•

RIP Packets on page 836

•

demand-circuit on page 873

Timers Used by RIP Demand Circuits RIP demand circuits use the RIP hold-down timer and the RIP demand circuit retransmission timer to regulate performance and to determine if there is a change in the network that requires the device to send update messages. The hold-down timer is a global RIP timer that affects the entire RIP configuration; whatever range you configure for RIP applies to RIP demand circuits. The retransmission timer affects only RIP demand circuits. In addition, there is a database timer that runs only when RIP flushes learned routes from the routing table. •

Hold-down timer (global RIP timer)—Use the hold-down timer to configure the number of seconds that RIP waits before updating the routing table. The value of the hold-down timer affects the entire RIP configuration, not just the demand circuit interfaces. The hold-down timer starts when a route timeout limit is met, when a formerly reachable route is unreachable, or when a demand circuit interface is down. When the hold-down timer is running, routes are advertised as unreachable on other interfaces. When the hold-down timer expires, the route is removed from the routing table if all destinations are aware that the route is unreachable or the remaining destinations are down. By default, RIP waits 120 seconds between routing table updates. The range is from 10 to 180 seconds.

•

Retransmission timer (RIP demand circuit timer)—RIP demand circuits send update messages every 5 seconds to an unresponsive peer. Use the retransmission timer to limit the number of times a demand circuit resends update messages to an unresponsive peer. If the configured retransmission threshold is reached, routes from the next hop router are marked as unreachable and the hold-down timer starts. The value of the retransmission timer affects only the demand circuit interfaces. To determine the number of times to resend the update message, use the following calculation: 5 seconds * number of retransmissions = retransmission seconds

The retransmission range is from 5 through 180 seconds, which corresponds to sending an update message a minimum of 1 time (5 seconds) and a maximum of 36 times (180 seconds). •

Database timer (global timeout timer)—Routes learned from demand circuits do not age like other RIP entries because demand circuits are in a permanent state. On a RIP demand circuit, the database timer starts upon receipt of the update response message


859


with the flush flag sent from a RIP demand circuit peer. When the neighbor receives this message, all routes from that peer are flushed, and the database timer starts and runs for the configured route timeout interval. When the database timer is running, routes are still advertised as reachable on other interfaces. When the database timer expires, the device advertises all routes from its peer as unreachable. Related Documentation

•


•


•

holddown on page 878

•

max-retrans-time on page 880

Example: Configuring RIP Demand Circuits This example describes how to configure the interface as a RIP demand circuit. •


•


•


•


Requirements Before you begin, configure the device interfaces. See the Junos OS Network Interfaces Configuration Guide.

Overview A demand circuit is a point-to-point connection between two neighboring interfaces configured for RIP. Demand circuits increase the efficiency of RIP on the configured interfaces by eliminating the periodic transmission of RIP packets. Demand circuits preserve bandwidth by establishing a link when data needs to be transferred, and terminating the link when the data transfer is complete. This example assumes you have two devices connected using SONET/SDH interfaces.

NOTE: When you configure RIP demand circuits, any silent removal of the RIP configuration will go unnoticed by the RIP peer and lead to stale entries in the routing table. To clear the stale entries, deactivate and reactivate RIP on the neighboring devices.

In this example, you configure interface so-0/1/0 with the following settings:

860

•

demand-circuit—Configures the interface as a demand circuit. To complete the demand circuit, you must configure both ends of the pair as demand circuits.

•

max-retrans-time—RIP demand circuits send update messages every 5 seconds to an unresponsive peer. Use the retransmission timer to limit the number of times a demand circuit resends update messages to an unresponsive peer. If the configured



retransmission threshold is reached, routes from the next hop router are marked as unreachable and the hold-down timer starts. The value of the retransmission timer affects only the demand circuit interfaces. To determine the number of times to resend the update message, use the following calculation: 5 seconds * retransmissions = retransmission seconds

For example, if you want the demand circuit to send only two update messages to an unresponsive peer, the calculation is: 5 * 2 = 10. When you configure the retransmission timer, you enter 10 seconds. The retransmission range is from 5 through 180 seconds, which corresponds to sending an update message a minimum of 1 time (5 seconds) and a maximum of 36 times (180 seconds).

Configuration In the following example, you configure a neighboring interface to be a RIP demand circuit and save the configuration. CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set interfaces so-0/1/0 unit 0 family inet address 192.0.2.0/24 set protocols rip group group1 neighbor so-0/1/0 demand-circuit set protocols rip group group1 neighbor so-0/1/0 max-retrans-time 10


The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure a RIP demand circuit on one neighboring interface: 1.

Configure the interface. [edit] user@host# set interfaces so-0/1/0 unit 0 family inet address 192.0.2.0/24

2.

Enter RIP configuration mode. [edit] user@host# edit protocols rip

3.

Configure the neighbor as a demand circuit. [edit protocols rip] user@host# set group group1 neighbor so-0/1/0 demand-circuit

4.

Configure the demand circuit retransmission timer. [edit protocols rip] user@host# set group group1 neighbor so-0/1/0 max-retrans-time 10

5.

If you are done configuring the device, commit the configuration. [edit protocols rip]


861


user@host# commit


Results

Confirm your configuration by entering the show interfaces and show protocols rip commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show interfaces so-0/1/0 { unit 0 { family inet { address 192.0.2.0/24; } } } user@host# show protocols rip group group1 { neighbor so-0/1/0 { demand-circuit; max-retrans-time 10; } }

Verification Verifying a Demand Circuit Configuration Purpose Action

Verify that the demand circuit configuration is working. To verify that the demand circuit configuration is in effect, run the show rip neighbor operational mode command. user@host# show rip neighbor Source Neighbor State Address ------------ ------so-0/1/0.0(DC) Up 10.10.10.2

Destination Address ----------224.0.0.9

Send Mode ---mcast

Receive Mode ------both

In Met --1

When you configure demand circuits, the show rip neighbor command displays a DC flag next to the neighboring interface configured for demand circuits.

NOTE: If you configure demand circuits at the RIP neighbor hierarchy level, the output shows only the neighboring interface that you specifically configured as a demand circuit. If you configure demand circuits at the RIP group hierarchy level, all of the interfaces in the group are configured as demand circuits. Therefore, the output shows all of the interfaces in that group as demand circuits.

862




•


Tracing RIP Protocol Traffic You can trace various types of RIP protocol traffic to help debug RIP protocol issues. To trace RIP protocol traffic include the traceoptions statement at the [edit protocols rip] hierarchy level: traceoptions { file filename ; flag flag ; }

You can specify the following RIP protocol-specific trace options using the flag statement: •

auth—RIP authentication

•

error—RIP error packets

•

expiration—RIP route expiration processing

•

holddown—RIP hold-down processing

•

nsr-synchronization—Nonstop active routing synchronization events

•

packets—All RIP packets

•

request—RIP information packets

•

trigger—RIP triggered updates

•

update—RIP update packets



•


•


NOTE: Use the detail flag modifier with caution as this may cause the CPU to become very busy.

Global tracing options are inherited from the configuration set by the traceoptions statement at the [edit routing-options] hierarchy level. You can override the following global trace options for the RIP protocol using the traceoptions flag statement included at the [edit protocols rip] hierarchy level: •


•





863


•


•


•


•


•


NOTE: Use the trace flag all with caution because this may cause the CPU to become very busy.

Example: Tracing RIP Protocol Traffic Trace only unusual or abnormal operations to /var/log/routing-log, and trace detailed information about all RIP packets to /var/log/rip-log: [edit] routing-options { traceoptions { file /var/log/routing-log; flag errors; } } protocols { rip { traceoptions { file /var/log/rip-log; flag packets detail; } } }


•


•

For general information about tracing and global tracing options, see Tracing Global Routing Protocol Operations on page 138.

Example: Configuring RIP Configure RIP (for routing instances, include the statements at the [edit routing-instances routing-instance-name protocols rip] hierarchy level): [edit policy-options] policy-statement redist-direct { from protocol direct; then accept; } [edit] interfaces { so-0/0/0 { unit 0 {

864



family inet; } } at-1/1/0 { unit 0 { family inet; } } at-1/1/0 { unit 42 { family inet; } } at-1/1/1 { unit 42 { family inet; } } } policy-statement redist-direct { from protocol direct; then accept; } [edit protocols rip] metric-in 3; receive both; group wan { metric-out 2; export redist-direct; neighbor so-0/0/0.0; neighbor at-1/1/0.0; neighbor at-1/1/0.42; neighbor at-1/1/1.42 { receive version-2; } } group local { neighbor ge-2/3/0.0 { metric-in 1; send broadcast; } }


865


866


CHAPTER 21

Summary of RIP Configuration Statements The following sections explain each of the individual RIP statements in the [edit protocols rip] hierarchy. The statements are organized alphabetically.

any-sender Syntax Hierarchy Level

Release Information


any-sender; [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced in Junos OS Release 8.0. Statement introduced in Junos OS Release 9.0 for EX Series switches. Disable strict sender address checks. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Disabling Strict Address Checking for RIP Messages on page 857


867



Release Information

Description Options

authentication-key password; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Require authentication for RIP route queries received on an interface. password—Authentication password. If the password does not match, the packet is

rejected. The password can be from 1 through 16 contiguous characters long and can include any ASCII strings. Required Privilege Level Related Documentation

868




Chapter 21: Summary of RIP Configuration Statements

authentication-type Syntax Hierarchy Level

Release Information

Description Default

Options

authentication-type type; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the type of authentication for RIP route queries received on an interface. If you do not include this statement and the authentication-key statement, RIP authentication is disabled. type—Authentication type: •

md5—Use the MD5 algorithm to create an encoded checksum of the packet. The

encoded checksum is included in the transmitted packet. The receiving routing device uses the authentication key to verify the packet, discarding it if the digest does not match. This algorithm provides a more secure authentication scheme. •

none—Disable authentication. If none is configured, the configured authentication key

is ignored. •

simple—Use a simple password. The password is included in the transmitted packet,

which makes this method of authentication relatively insecure. The password can be from 1 through 16 contiguous letters or digits long. Required Privilege Level Related Documentation



•



869



bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; ; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; no-adaptation; version (1 | automatic); }

Hierarchy Level

[edit logical-systems logical-system-name protocols rip group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name] [edit protocols rip group group-name], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Release Information

Statement introduced in Junos OS Release 8.0. detection-time threshold and transmit-interval threshold options introduced in Junos OS Release 8.2. Support for logical systems introduced in Junos OS Release 8.3. no-adaptation statement introduced in Junos OS Release 9.0. Statement introduced in Junos OS Release 9.0 for EX Series switches. authentication algorithm, authentication key-chain, and authentication loose-check statements introduced in Junos OS Release 9.6. authentication algorithm, authentication key-chain, and authentication loose-check statements introduced in Junos OS Release 9.6 for EX Series switches.

Description Options

Configure bidirectional failure detection timers and authentication. authentication algorithm algorithm-name —Configure the algorithm used to authenticate


BFD session using the name of the security keychain. The name you specify must match one of the keychains configured in the authentication-key-chains key-chain statement at the [edit security] hierarchy level.

870



authentication loose-check—(Optional) Configure loose authentication checking on the

BFD session. Use only for transitional periods when authentication may not be configured at both ends of the BFD session. detection-time threshold milliseconds—Configure a threshold. When the BFD session

detection time adapts to a value equal to or greater than the threshold, a single trap and a single system log message are sent. minimum-interval milliseconds—Configure the minimum intervals at which the local

routing device transmits a hello packet and then expects to receive a reply from the neighbor with which it has established a BFD session. Range: 1 through 255,000 milliseconds minimum-receive-interval milliseconds—Configure only the minimum interval at which

the local routing device expects to receive a reply from a neighbor with which it has established a BFD session. Range: 1 through 255,000 milliseconds multiplier number—Configure the number of hello packets not received by a neighbor

that causes the originating interface to be declared down. Range: 1 through 255 Default: 3 no-adaptation—Configure BFD sessions not to adapt to changing network conditions.



Range: 0 through 4,294,967,295 (2

– 1)

transmit-interval minimum-interval milliseconds—Configure only a minimum interval at

which the local routing device transmits hello packets to a neighbor. Range: 1 through 255,000 version—Specify the BFD version to detect.

Range: (BFD version 1), or automatic (autodetect the version) Default: automatic The remaining statements are explained separately. Required Privilege Level Related Documentation



•



871


check-zero Syntax Hierarchy Level

Release Information

Description

(check-zero | no-check-zero); [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Check whether the reserved fields in a RIP packet are zero: •

check-zero—Discard version 1 packets that have nonzero values in the reserved fields

and version 2 packets that have nonzero values in the fields that must be zero. This default behavior implements the RIP version 1 and version 2 specifications. •

no-check-zero—Receive RIP version 1 packets with nonzero values in the reserved fields

or RIP version 2 packets with nonzero values in the fields that must be zero. This is in spite of the fact that they are being sent in violation of the specifications in RFC 1058 and RFC 2453. Default Required Privilege Level Related Documentation

872

check-zero





demand-circuit Syntax Hierarchy Level

Release Information

demand-circuit; [edit logical-systems logical-system-name protocols rip group group-name], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip group group-name], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip group group-name], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]


Description

Configure a neighboring interface to act as a RIP demand circuit. To complete the demand circuit, you must configure both ends of the pair as demand circuits. When configured, the device sends RIP information only when changes occur in the routing database.

Default

Disabled. You must explicitly configure two neighboring interfaces to act as a RIP demand circuit.




•


•

max-retrans-time on page 880


873



Release Information


874

export [ policy-names ]; [edit logical-systems logical-system-name protocols rip group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name], [edit protocols rip group group-name], [edit routing-instances routing-instance-name protocols rip group group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Apply a policy to routes being exported to the neighbors. policy-names—Name of one or more policies.


import on page 879

•

Applying Policies to Routes Exported by RIP on page 855

•





Hierarchy Level

Release Information

Description Options

graceful-restart { disable; restart-time seconds; } [edit logical-systems logical-system-name protocols rip], [edit protocols rip]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure graceful restart for RIP. disable—Disables graceful restart for RIP. seconds—Estimated time for the restart to finish, in seconds.

Range: 1 through 600 seconds Default: 60 seconds The remaining statements are explained separately. Required Privilege Level Related Documentation



•

Configuring Graceful Restart for RIP on page 856


875


group Syntax

876

group group-name { bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (0 | 1 | automatic); } demand-circuit; export policy; max-retrans-time seconds; metric-out metric; preference number; route-timeout seconds; update-interval seconds; neighbor neighbor-name { authentication-key password; authentication-type type; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (0 | 1 | automatic); } (check-zero | no-check-zero); demand-circuit; import policy-name; max-retrans-time seconds; message-size number;



metric-in metric; metric-out metric; receive receive-options; route-timeout seconds; send send-options; update-interval seconds; } }

Hierarchy Level

Release Information

Description

Options

[edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit protocols rip], [edit routing-instances routing-instance-name protocols rip]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure a set of RIP neighbors that share an export policy and metric. The export policy and metric govern what routes to advertise to neighbors in a given group. group-name—Name of a group, up to 16 characters long.



Configuring Group-Specific RIP Properties on page 854


877


holddown Syntax Hierarchy Level

Release Information

Description

holddown seconds; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit protocols rip], [edit routing-instances routing-instance-name protocols rip]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the time period the expired route is retained in the routing table before being removed. When the hold-down timer runs on RIP demand circuits, routes are advertised as unreachable on other interfaces. When the hold-down timer expires, the route is removed from the routing table if all destinations are aware that the route is unreachable or the remaining destinations are down.

Options

seconds—Estimated time to wait before making updates to the routing table.


878



•





Release Information


import [ policy-names ]; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Apply one or more policies to routes being imported by the local router from its neighbors. policy-names—Name of one or more policies.


export on page 874

•


•



879


max-retrans-time Syntax Hierarchy Level


max-retrans-time seconds; [edit logical-systems logical-system-name protocols rip group group-name], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip group group-name], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip group group-name], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced in Junos OS Release 11.1. RIP demand circuits send update messages every 5 seconds to an unresponsive peer. Configure the retransmission timer to limit the number of times the demand circuit resends update messages to an unresponsive peer. If the configured retransmission threshold is reached, routes from the next hop router are marked as unreachable and the hold-down timer starts. You must configure a pair of RIP demand circuits for this timer to take effect. To determine the number of times to resend the update message, use the following calculation: 5 seconds * number of retransmissions = retransmission seconds

Options

seconds—The total amount of time the demand circuit resends update messages to an

unresponsive peer. The seconds range corresponds to sending an update message a minimum of 1 time (5 seconds) and a maximum of 36 times (180 seconds). Range: 5 through 180 seconds Default: 5 seconds Required Privilege Level Related Documentation

880



•


•

demand-circuit on page 873



message-size Syntax Hierarchy Level

Release Information

Description

Options

message-size number; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify the number of route entries to be included in every RIP update message. To ensure interoperability with other vendors’ equipment, use the standard of 25 route entries per message. number—Number of route entries per update message.

Range: 25 through 255 entries Default: 25 entries Required Privilege Level Related Documentation




881


metric-in Syntax Hierarchy Level

Release Information

Description

Options

metric-in metric; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify the metric to add to incoming routes when advertising into RIP routes that were learned from other protocols. Use this statement to configure the routing device to prefer RIP routes learned through a specific neighbor. metric—Metric value.


882





metric-out Syntax Hierarchy Level

Release Information

Description

Options

metric-out metric; [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify the metric value to add to routes transmitted to the neighbor. Use this statement to control how other routing devices prefer RIP routes sent from this neighbor. metric—Metric value.



Configuring the Metric for Routes Exported by RIP on page 856


883


neighbor Syntax

Hierarchy Level

Release Information

neighbor neighbor-name { authentication-key password; authentication-type type; bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } multiplier number; version (0 | 1 | automatic); } (check-zero | no-check-zero); demand-circuit; import policy-name; max-retrans-time seconds; message-size number; metric-in metric; metric-out metric; receive receive-options; route-timeout seconds; send send-options; update-interval seconds; } [edit logical-systems logical-system-name protocols rip group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name], [edit protocols rip group group-name], [edit routing-instances routing-instance-name protocols rip group group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches.

Description

Configure neighbor-specific RIP parameters, thereby overriding the defaults set for the routing device.

Options

neighbor-name—Name of an interface over which a routing device communicates to its

neighbors. The remaining statements are explained separately.

884





Overview of RIP Neighbor Properties on page 842

no-check-zero See

check-zero


Release Information

Description

Options

preference preference; [edit logical-systems logical-system-name protocols rip group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name], [edit protocols rip group group-name], [edit routing-instances routing-instance-name protocols rip group group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify the preference of external routes learned by RIP as compared to those learned from other routing protocols. preference—Preference value. A lower value indicates a more preferred route. 32

Range: 0 through 4,294,967,295 (2

– 1)



Configuring the Default Preference Value for RIP on page 855


885


receive Syntax Hierarchy Level

Release Information

Description Options

receive receive-options; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure RIP receive options. receive-options—One of the following: •

both—Accept both RIP version 1 and version 2 packets.

•

none—Do not receive RIP packets.

•

version-1—Accept only RIP version 1 packets.

•

version-2—Accept only RIP version 2 packets.

Default: both Required Privilege Level Related Documentation

886


send on page 889

•





Release Information


rib-group group-name; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit protocols rip], [edit routing-instances routing-instance-name protocols rip]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Install RIP routes into multiple routing tables by configuring a routing table group. group-name—Name of the routing table group.



rip Syntax Hierarchy Level

Release Information


rip {...} [edit logical-systems logical-system-name protocols], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols], [edit protocols], [edit routing-instances routing-instance-name protocols]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Enable RIP routing on the routing device. RIP is disabled on the routing device. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Minimum RIP Configuration on page 841


887


route-timeout Syntax Hierarchy Level

Release Information

Description Options

route-timeout seconds; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit logical-systems logical-system-name protocols rip group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name], [edit protocols rip], [edit protocols rip group group-name], [edit routing-instances routing-instance-name protocols rip], [edit routing-instances routing-instance-name protocols rip group group-name]

Statement introduced in Junos OS Release 7.6. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure the route timeout interval for RIP. seconds—Estimated time to wait before making updates to the routing table.


888



•




send Syntax Hierarchy Level

Release Information

Description Options

send send-options; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name protocols rip group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name], [edit protocols rip], [edit protocols rip group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols rip], [edit routing-instances routing-instance-name protocols rip group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure RIP send options. send-options—One of the following: •

broadcast—Broadcast RIP version 2 packets (RIP version 1 compatible).

•

multicast—Multicast RIP version 2 packets. This is the default.

•

none—Do not send RIP updates.

•

version-1—Broadcast RIP version 1 packets.

Default: multicast Required Privilege Level Related Documentation


receive on page 886

•



889


traceoptions Syntax

Hierarchy Level

Release Information

Description

traceoptions { file filename ; flag flag ; } [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit protocols rip], [edit routing-instances routing-instance-name protocols rip]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Set RIP protocol-level tracing options.

Default

The default RIP protocol-level trace options are inherited from the global traceoptions statement.

Options

disable—(Optional) Disable the tracing operation. One use of this option is to disable a


name in quotation marks. We recommend that you place RIP tracing output in the file /var/log/rip-log. files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and

so on, until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum number of files, you must also specify a maximum file size with the size option. Range: 2 through 1000 files Default: 10 files flag—Tracing operation to perform. To specify more than one tracing operation, include

multiple flag statements. RIP Tracing Options

890

•

auth—RIP authentication

•

error—RIP error packets

•

expiration—RIP route expiration processing

•

holddown—RIP hold-down processing

•




•

packets—All RIP packets

•

request—RIP information packets such as request, poll, and poll entry packets

•

trigger—RIP triggered updates

•

update—RIP update packets

Global Tracing Options •


•


•




•


•


•


•




detail—Provide detailed trace information

•


•

receive-detail—Provide detailed trace information for packets being received

•


•

send-detail—Provide detailed trace information for packets being transmitted

no-world-readable—(Optional) Prevent any user from reading the log file. size size—(Optional) Maximum size of each trace file, in kilobytes (KB) or megabytes

(MB). When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum file size, you must also specify a maximum number of trace files with the files option. Syntax: xk to specify KB, xm to specify MB, or xg to specify GB Range: 10 KB through the maximum file size supported on your system Default: 128 KB world-readable—(Optional) Allow any user to read the log file.


891




Tracing RIP Protocol Traffic on page 863

update-interval Syntax Hierarchy Level

Release Information

Description

Options

update-interval seconds; [edit logical-systems logical-system-name protocols rip], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip], [edit protocols rip], [edit routing-instances routing-instance-name protocols rip]

Statement introduced in Junos OS Release 7.6. Statement introduced in Junos OS Release 9.0 for EX Series switches. Configure an update time interval to periodically send out routes learned by RIP to neighbors. seconds—Estimated time to wait before making updates to the routing table.


892




CHAPTER 22

Introduction to RIPng This chapter discusses the following topics that provide background information about RIP next generation (RIPng): •

RIPng Overview on page 893

•

RIPng Standards on page 894

RIPng Overview RIP next generation (RIPng) is an interior gateway protocol (IGP) that uses a distance-vector algorithm to determine the best route to a destination, using the hop count as the metric. RIPng is a routing protocol that exchanges routing information used to compute routes and is intended for IP version 6 (IPv6)-based networks. This section discusses the following topics: •

RIPng Protocol Overview on page 893

•

RIPng Packets on page 894

RIPng Protocol Overview The RIPng IGP uses the Bellman-Ford distance-vector algorithm to determine the best route to a destination. RIPng uses the hop count as the metric. RIPng allows hosts and routers to exchange information for computing routes through an IP-based network. RIPng is intended to act as an IGP for moderately-sized autonomous systems (ASs). The Junos OS implementation of RIPng is similar to RIPv2. However, RIPng is a distinct routing protocol from RIPv2 and has the following differences: •

RIPng does not need to implement authentication on packets.

•

There is no support for multiple instances of RIPng.

•

There is no support for RIPng routing table groups.

RIPng is a User Datagram Protocol (UDP)-based protocol and uses UDP port 521. RIPng has the following architectural limitations: •

The longest network path cannot exceed 15 hops (assuming that each network, or hop, has a cost of 1).


893


•

RIPng depends on counting to infinity to resolve certain unusual situations. When the network consists of several hundred routers, and when a routing loop has formed, the amount of time and network bandwidth required to resolve a next hop might be great.

•

RIPng uses only a fixed metric to select a route. Other IGPs use additional parameters, such as measured delay, reliability, and load.

RIPng Packets A RIPng packet header contains the following fields: •

Command—Indicates whether the packet is a request or response message. Request messages seek information for the router’s routing table. Response messages are sent periodically or when a request message is received. Periodic response messages are called update messages. Update messages contain the command and version fields and a set of destinations and metrics.

•

Version number—Specifies the version of RIPng that the originating router is running. This is currently set to Version 1.

The rest of the RIPng packet contains a list of routing table entries that contain the following fields: •

Destination prefix—128-bit IPv6 address prefix for the destination.

•

Prefix length—Number of significant bits in the prefix.

•

Metric—Value of the metric advertised for the address.

•

Route tag—A route attribute that must be advertised and redistributed with the route. Primarily, the route tag distinguishes external RIPng routes from internal RIPng routes in cases where routes must be redistributed across an exterior gateway protocol (EGP).

RIPng Standards RIPng is defined in the following documents: •

RFC 2080, RIPng for IPv6

•

RFC 2081, RIPng Protocol Applicability Statement

To access Internet Requests for Comments (RFCs) and drafts, go to the Internet Engineering Task Force (IETF) Web site at http://www.ietf.org.

894


CHAPTER 23

RIPng Configuration Guidelines This chapter discusses the following topics that provide information for configuring and monitoring RIPng: •

Configuring RIPng on page 895

•

Minimum RIPng Configuration on page 896

•

Overview of RIPng Global Properties on page 897

•

Overview of RIPng Neighbor Properties on page 897

•

Applying Policies to RIPng Routes Imported from Neighbors on page 897

•

Configuring the Metric Value Added to Imported RIPng Routes on page 898

•

Configuring RIPng Update Messages on page 898

•

Configuring RIPng Timers on page 898

•

Configuring Group-Specific RIPng Properties on page 899

•

Configuring Graceful Restart for RIPng on page 901

•

Tracing RIPng Protocol Traffic on page 901

•

Example: Configuring RIPng on page 902

Configuring RIPng To configure RIP next generation (RIPng), you include the following statements: protocols { ripng { graceful-restart { disable; restart-time seconds; } holddown seconds; import [ policy-names ]; metric-in metric; receive ; route-timeout seconds; send ; update-interval seconds; traceoptions { file filename ; flag flag ;


895


} group group-name { export [ policy-names ]; metric-out metric; preference number; route-timeout seconds; update-interval seconds; neighbor neighbor-name { import [ policy-names ]; metric-in metric; receive ; route-timeout seconds; send ; update-interval seconds; } } } }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. By default, RIPng is disabled.

NOTE: By default, RIPng routes are not redistributed. You must configure export policy needs to redistribute RIPng routes.

To have a router exchange routes with other routers, you must configure RIPng groups and neighbors. RIPng routes received from routers not configured as RIPng neighbors are ignored. Likewise, RIPng routes are advertised only to routers configured as RIPng neighbors.

Minimum RIPng Configuration For a routing device to accept RIPng routes, you must configure at least one RIPng group and the associated neighbor. Routes received from routing devices that are not configured as neighbors are ignored. All other RIPng configuration statements are optional. Include one neighbor statement for each interface on which you want to receive routes. The local routing device imports all routes by default from this neighbor and does not advertise routes. [edit] protocols { ripng { group group-name { neighbor interface-name; } } }

896


Chapter 23: RIPng Configuration Guidelines

NOTE: When you configure RIPng on an interface, you must also include the family inet statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level.

Overview of RIPng Global Properties To define RIPng global properties, which apply to all RIPng neighbors, include one or more of the following statements. import [ policy-names ]; metric-in metric; receive receive-options; send send-options;

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. For more information about configuring RIPng global properties, see the following topics: •


•


•


Overview of RIPng Neighbor Properties To define neighbor-specific properties, include one or more of the following statements. neighbor neighbor-name { import [ policy-names ]; metric-in metric; receive receive-options; send send-options; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. For more information about configuring RIPng neighbor properties, see the following topics: •


•


•


Applying Policies to RIPng Routes Imported from Neighbors To filter routes being imported by the local routing device from its neighbors, include the import statement and list the names of one or more policies to be evaluated. If you specify


897


more than one policy, they are evaluated in order (first to last) and the first matching policy is applied to the route. If no match is found, the local routing device does not import any routes. import [ policy-names ];


Configuring the Metric Value Added to Imported RIPng Routes By default, RIPng imports routes from the neighbors configured with the neighbor statement. These routes include those learned from RIPng as well as those learned from other protocols. By default, the current route metric of routes that RIPng imports from its neighbors is incremented by 1. To change the default metric to be added to incoming routes, include the metric-in statement: metric-in metric; metric can be a value from 1 through 15. A value of 16 indicates infinity, or unreachable.


Configuring RIPng Update Messages You can enable and disable the sending or receiving of update messages. By default, sending and receiving update messages is enabled. To disable the sending and receiving of update messages, include the receive none and send none statements: receive none; send none;

To enable the sending and receiving of update messages, include the receive and send statements: receive; send;


Configuring RIPng Timers You can configure various timers for RIPng. RIPng routes expire when either a route timeout limit is met or a route metric reaches infinity, and the route is no longer valid. However, the expired route is retained in the routing table for a time period so that neighbors can be notified that the route has been dropped. This time period is set by configuring the hold-down timer. Upon expiration of the hold-down timer, the route is removed from the routing table.

898



To configure the hold-down timer for RIPng, include the holddown statement: holddown seconds; seconds can be a value from 10 through 180. The default value is 120 seconds.

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. You can set a route timeout interval. If a route is not refreshed after being installed into the routing table by the specified time interval, the route is removed from the routing table. To configure the route timeout for RIPng, include the route-timeout statement: route-timeout seconds; seconds can be a value from 30 through 360. The default value is 180 seconds.

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. You can set an update time interval to periodically send out routes learned by RIPng to neighbors. To configure the update time interval, include the update-interval statement: update-interval seconds; seconds can be a value from 10 through 60. The default value is 30 seconds.


Configuring Group-Specific RIPng Properties You can group together neighbors that share the same export policy and export metric defaults. You configure group-specific RIPng properties by including the group statement: group group-name { export [ policy-names ]; metric-out metric; neighbor { ... neighbor-options ... } preference number; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Each group must contain at least one neighbor. You should create a group for each export policy that you have. For information about configuring neighbors, see “Overview of RIPng Neighbor Properties” on page 897.


899


This section discusses the following tasks: •

Applying Policies to Routes Exported by RIPng on page 900

•

Configuring the Default Preference Value for RIPng on page 900

•

Configuring the Metric for Routes Exported by RIPng on page 900

Applying Policies to Routes Exported by RIPng By default, RIPng does not export routes it has learned to its neighbors. To have RIPng export routes, apply one or more export policies. To apply export policies and to filter routes being exported from the local routing device to its neighbors, include the export statement and list the name of the policy to be evaluated: export [ policy--names ];

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. You can define one or more export policies. If no routes match the policies, the local routing device does not export any routes to its neighbors. Export policies override any metric values determined through calculations involving the values configured with the metric-in and metric-out statements (discussed in “Configuring the Metric Value Added to Imported RIPng Routes” on page 898 and“Configuring the Metric for Routes Exported by RIP” on page 856 respectively).

Configuring the Default Preference Value for RIPng By default, the Junos OS assigns a preference of 100 to routes that originate from RIPng. When the Junos OS determines that a route preference is to become the active route, the software selects the route with the lowest preference and installs this route into the forwarding table. To modify the default RIPng preference value, include the preference statement: preference preference;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement: 32

preference can be a value from 0 through 4,294,967,295 (2

– 1).

Configuring the Metric for Routes Exported by RIPng If you configure an export policy, RIPng exports routes it has learned to the neighbors configured with the neighbor statement. If a route being exported was learned from a member of the same RIPng group, the metric associated with that route (unless modified by an export policy) is the normal RIPng metric. For example, a RIPng route with a metric of 5 learned from a neighbor configured with a metric-in value of 2 is advertised with a combined metric of 7 when advertised to RIPng neighbors in the same group. However, if this route was learned from a RIPng neighbor in a different group or from a different protocol, the route is advertised with the

900



metric value configured for that group with the metric-out statement. The default value for metric-out is 1. To modify the metric for routes advertised outside a group, include the metric-out statement: metric-out metric;


Configuring Graceful Restart for RIPng Graceful restart is disabled by default. You can globally enable graceful restart for all routing protocols under the [edit routing-options] hierarchy level. You can configure graceful restart parameters specifically for RIPng. To do this, include the graceful-restart statement: graceful-restart { restart-time seconds; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To disable graceful restart for RIPng, specify the disable statement. To configure a time period for the restart to finish, specify the restart-time statement.

Tracing RIPng Protocol Traffic You can trace various RIPng protocol traffic to help debug RIP protocol issues. To trace RIP protocol traffic include the traceoptions statement at the [edit protocols ripng] hierarchy level: traceoptions { file filename ; flag flag ; }

You can specify the following RIPng protocol-specific trace options using the flag statement: •

error—RIPng error packets

•

expiration—RIPng route expiration processing

•

holddown—RIPng hold-down processing

•


•

packets—All RIPng packets

•

request—RIPng information packets


901


•

trigger—RIPng triggered updates

•

update—RIPng update packets



•


•


NOTE: Use the detail flag modifier with caution as this may cause the CPU to become very busy.

Global tracing options are inherited from the configuration set by the traceoptions statement at the [edit routing-options] hierarchy level. You can override the following global trace options for the RIPng protocol using the traceoptions flag statement included at the [edit protocols ripng] hierarchy level: •


•




•


•


•


•


•




•


•

For general information about tracing and global tracing options, see Tracing Global Routing Protocol Operations on page 138.

Example: Configuring RIPng Configure RIPng: [edit policy-options] policy-statement redist-direct { from protocol direct;

902



then accept; } [edit protocols ripng] metric-in 3; group wan { metric-out 2; export redist-direct; neighbor so-0/0/0.0; neighbor at-1/1/0.0; neighbor at-1/1/0.42; neighbor at-1/1/1.42 { receive version-2; } } group local { neighbor ge-2/3/0.0 { metric-in 1; send broadcast; } }


903


904


CHAPTER 24

Summary of RIPng Configuration Statements The following sections explain each of the RIP next generation (RIPng) statements in the [edit protocols ripng] hierarchy. The statements are organized alphabetically.


Release Information


export [ policy-names ]; [edit logical-systems logical-system-name protocols ripng group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng group group-name], [edit protocols ripng group group-name], [edit routing-instances routing-instance-name protocols ripng group group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Apply a policy or list of policies to routes being exported to the neighbors. policy-names—Name of one or more policies.


import on page 909

•

Applying Policies to Routes Exported by RIPng on page 900


905



Hierarchy Level

Release Information

Description Options

graceful-restart { disable; restart-time seconds; } [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng], [edit protocols ripng], [edit routing-instances routing-instance-name protocols ripng]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Configure graceful restart for RIPng. disable—Disables graceful restart for RIPng. seconds—Estimated time period for the restart to finish.


906



•

Configuring Graceful Restart for RIPng on page 901


Chapter 24: Summary of RIPng Configuration Statements

group Syntax

Hierarchy Level

Release Information

Description

Options

group group-name { export [ policy-names ]; metric-out metric; preference number; route-timeout seconds; update-interval seconds; neighbor neighbor-name { import policy-name; metric-in metric; receive ; route-timeout seconds; send ; update-interval seconds; } } [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng], [edit protocols ripng], [edit routing-instances routing-instance-name protocols ripng]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Configure a set of RIPng neighbors that share an export policy and metric. The export policy and metric govern what routes to advertise to neighbors in a given group. group-name—Name of a group, up to 16 characters long.



Configuring Group-Specific RIPng Properties on page 899


907


holddown Syntax Hierarchy Level

Release Information

Description

Options

holddown seconds; [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng], [edit protocols ripng], [edit routing-instances routing-instance-name protocols ripng]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Configure the time period the expired route is retained in the routing table before being removed. seconds—Estimated time to wait before making updates to the routing table.

Default: 180 seconds Range: 10 through 180 seconds Required Privilege Level Related Documentation

908






Release Information

Description


import [ policy-names ]; [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name protocols ripng group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name], [edit protocols ripng], [edit protocols ripng group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols ripng], [edit routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Apply one or more policies to routes being imported into the local routing device from the neighbors. policy-names—Name of one or more policies.


export on page 905

•



909


metric-in Syntax Hierarchy Level

Release Information

Description

Options

metric-in metric; [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name protocols ripng group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name], [edit protocols ripng], [edit protocols ripng group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols ripng], [edit routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Specify the metric to add to incoming routes when advertising into RIPng routes that were learned from other protocols. Use this statement to configure the routing device to prefer RIPng routes learned through a specific neighbor. metric—Metric value.


910






Release Information

Description

Options

metric-out metric; [edit logical-systems logical-system-name protocols ripng group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name], [edit protocols ripng group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Specify the metric value to add to routes transmitted to the neighbor. Use this statement to control how other routing devices prefer RIPng routes sent from this neighbor. metric—Metric value.



Configuring the Metric for Routes Exported by RIPng on page 900


911


neighbor Syntax

Hierarchy Level

Release Information

Description

Options

neighbor neighbor-name { import [ policy-names ]; metric-in metric; receive ; route-timeout seconds; send ; update-interval seconds; } [edit logical-systems logical-system-name protocols ripng group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng group group-name], [edit protocols ripng group group-name], [edit routing-instances routing-instance-name protocols ripng group group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Configure neighbor-specific RIPng parameters, thereby overriding the defaults set for the routing device. neighbor-name—Name of an interface over which a routing device communicates to its

neighbors. The remaining statements are explained separately. Required Privilege Level Related Documentation

912


Overview of RIPng Neighbor Properties on page 897




Release Information

Description

Options

preference preference; [edit logical-systems logical-system-name protocols ripng group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng group group-name], [edit protocols ripng group group-name], [edit routing-instances routing-instance-name protocols ripng group group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Specify the preference of external routes learned by RIPng as compared to those learned from other routing protocols. preference—Preference value. A lower value indicates a more preferred route. 32

Range: 0 through 4,294,967,295 (2

– 1)



Configuring the Default Preference Value for RIPng on page 900


913



Release Information

Description Options

receive ; [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name protocols ripng group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name], [edit protocols ripng], [edit protocols ripng group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols ripng], [edit routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Enable or disable receiving of update messages. none—(Optional) Disable receiving update messages.

Default: Enabled Required Privilege Level Related Documentation

914


send on page 916

•




ripng Syntax Hierarchy Level

Release Information


ripng {...} [edit logical-systems logical-system-name protocols], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols], [edit protocols], [edit routing-instances routing-instance-name protocols]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Enable RIPng routing on the routing device. RIPng is disabled on the routing device. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Minimum RIPng Configuration on page 896

route-timeout Syntax Hierarchy Level

Release Information

Description Options

route-timeout seconds; [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng], [edit protocols ripng], [edit routing-instances routing-instance-name protocols ripng]

Statement introduced in Junos OS Release 7.6. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Configure the route timeout interval for RIPng. seconds—Estimated time to wait before making updates to the routing table.





915


send Syntax Hierarchy Level

Release Information

Description Options

send ; [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name protocols ripng group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instances-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name], [edit protocols ripng], [edit protocols ripng group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols ripng], [edit routing-instances routing-instance-name protocols ripng group group-name neighbor neighbor-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Enable or disable sending of update messages. none—(Optional) Disable sending of update messages.

Default: Enabled Required Privilege Level Related Documentation

916


receive on page 914

•




traceoptions Syntax

Hierarchy Level

Release Information

Description

traceoptions { file filename ; flag flag ; } [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng], [edit protocols ripng], [edit routing-instances routing-instance-name protocols ripng]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Set RIPng protocol-level tracing options.

Default

The default RIPng protocol-level trace options are inherited from the global traceoptions statement.

Options



name in quotation marks. We recommend that you place RIPng tracing output in the file /var/log/ripng-log. files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and

so on, until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum number of files, you must also specify a maximum file size with the size option. Range: 2 through 1000 files Default: 10 files flag flag—Tracing operation to perform. To specify more than one tracing operation,

include multiple flag statements. RIPng Tracing Options •

error—RIPng error packets

•

expiration—RIPng route expiration processing

•

holddown—RIPng hold-down processing

•



917


•

packets—All RIPng packets

•

request—RIPng information packets such as request, poll, and poll entry packets

•

trigger—RIPng triggered updates

•

update—RIPng update packets



•


•




•


•


•


•





•


•

receive-detail—Provide detailed trace information for packets being received

•


•

send-detail—Provide detailed trace information for packets being transmitted

no-world-readable—(Optional) Do not allow any user to read the log file. size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB),

or gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum file size, you must also specify a maximum number of trace files with the files option. Syntax: xk to specify KB, xm to specify MB, or xg to specify GB Range: 10 KB through the maximum file size supported on your system Default: 128 KB world-readable—(Optional) Allow any user to read the log file.

918





Tracing RIPng Protocol Traffic on page 901

update-interval Syntax Hierarchy Level

Release Information

Description

Options

update-interval seconds; [edit logical-systems logical-system-name protocols ripng], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ripng], [edit protocols ripng], [edit routing-instances routing-instance-name protocols ripng]

Statement introduced in Junos OS Release 7.6. Statement introduced in Junos OS Release 9.0 for EX Series switches. Support for routing instances introduced in Junos OS Release 9.0. Configure an update time interval to periodically send out routes learned by RIP to neighbors. seconds—Estimated time to wait before making updates to the routing table.





919


920


CHAPTER 25

Introduction to ICMP Router Discovery This chapter discusses the following topics that provide background information about ICMP router discovery: •

ICMP Router Discovery Overview on page 921

•

ICMP Router Discovery Standards on page 922

ICMP Router Discovery Overview Router discovery uses Internet Control Message Protocol (ICMP) router advertisements and router solicitation messages to allow a host to discover the addresses of operational routers on the subnet. Hosts must discover routers before they can send IP datagrams outside their subnet. Router discovery allows a host to discover the addresses of operational routers on the subnet. The Junos OS implementation of router discovery supports server mode only. Each router periodically multicasts a router advertisement from each of its multicast interfaces, announcing the IP address of that interface. Hosts listen for advertisements to discover the addresses of their neighboring routers. When a host starts, it can send a multicast router solicitation to ask for immediate advertisements. The router discovery messages do not constitute a routing protocol. They enable hosts to discover the existence of neighboring routers, but do not determine which router is best to reach a particular destination. This section discusses the following topics: •

Operation of a Router Discovery Server on page 921

•

Router Advertisement Messages on page 922

Operation of a Router Discovery Server The router discovery server distributes information about the addresses of all routers on directly connected networks and about their preferences for becoming the default router. (A host sends a packet to the default router if the host does not have a route to a destination in its routing table.) The server does this by periodically sending router advertisement packets out each interface on which router discovery is enabled. In addition


921


to containing the router addresses, these packets also announce the existence of the server itself. The server can either transmit broadcast or multicast router advertisement packets. Multicast packets are sent to 224.0.0.1, which is the all-hosts multicast address. When packets are sent to the all-hosts multicast address, or when an interface is configured for the limited-broadcast address 255.255.255.255, all IP addresses configured on the physical interface are included in the router advertisement. When the packets are being sent to a network or subnet broadcast address, only the address associated with that network or subnet is included in the router advertisement. When the routing protocol process first starts on the server router, the server sends router advertisement packets every few seconds. Then, the server sends these packets less frequently, commonly every 10 minutes. The server responds to route solicitation packets it receives from a client. The response is sent unicast unless a router advertisement packet is due to be sent out momentarily.

NOTE: The Junos OS does not support the ICMP router solicitation message with the source address as 0.0.0.0.

Router Advertisement Messages Router advertisement messages include a preference level and a lifetime field for each advertised router address. The preference level specifies the router’s preference to become the default router. When a host chooses a default router address, it chooses the address with the highest preference. You can configure the preference level by including the priority statement as described in “Configuring the Addresses Included in ICMP Router Advertisements” on page 924. The lifetime field indicates the maximum length of time that the advertised addresses are to be considered valid by hosts in the absence of further advertisements. You can configure the advertising rate by including the max-advertisement-interval and min-advertisement-interval statements, and you can configure the lifetime by including the lifetime statement. For configuration instructions, see “Configuring the Frequency of ICMP Router Advertisements” on page 925 and “Modifying the Lifetime in ICMP Router Advertisements” on page 925.

ICMP Router Discovery Standards Router discovery is defined in RFC 1256, ICMP Router Discovery Messages. To access Internet Requests for Comments (RFCs) and drafts, go to the Internet Engineering Task Force (IETF) Web site at http://www.ietf.org.

922


CHAPTER 26

ICMP Router Discovery Configuration Guidelines This chapter describes the following tasks for configuring ICMP router discovery: •

Configuring ICMP Router Discovery on page 923

•

Minimum ICMP Router Discovery Configuration on page 924

•

Configuring the Addresses Included in ICMP Router Advertisements on page 924

•

Configuring the Frequency of ICMP Router Advertisements on page 925

•

Modifying the Lifetime in ICMP Router Advertisements on page 925

•

Tracing ICMP Protocol Traffic on page 925

Configuring ICMP Router Discovery To configure a router as a server for Internet Control Message Protocol (ICMP) router discovery, you can include the following statements in the configuration: protocols { router-discovery { disable; traceoptions { file filename ; flag flag ; } interface interface-name { min-advertisement-interval seconds; max-advertisement-interval seconds; lifetime seconds; } address address { (advertise | ignore); (broadcast | multicast); (priority number | ineligible); } }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. By default, router discovery is disabled.


923


Minimum ICMP Router Discovery Configuration To configure the router to be a router discovery server, you must include at least the following statement in the configuration. All other router discovery configuration statements are optional. protocols { router-discovery; }


NOTE: When you configure ICMP on an interface, you must also include the family inet statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level.

Configuring the Addresses Included in ICMP Router Advertisements To specify which addresses the router should include in its router advertisements, include the address statement: address address { (advertise | ignore); (broadcast | multicast); (priority number | ineligible); }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. Specify the IP address of the router, and optionally specify the following information about the router:

924

•

Whether the server should include this address in its router advertisements—By default, the address is advertised. To disable this function, include the ignore statement.

•

Whether the server should broadcast or multicast router advertisements—By default, advertisements are multicast if the router supports IP multicast; otherwise, they are broadcast. To modify the default functionality, include the broadcast or multicast statement.

•

Preference of the address to become the default router—In the priority statement, a higher value for number indicates that the address has a greater preference for becoming the default router. The default value is 0, which means that the address has the least chance of becoming the default router. If the router at this address should never become the default router, include the ineligible statement. To modify the preference, include the preference statement. number can be a value in the range from 0 through 0x80000000. The default is 0.


Chapter 26: ICMP Router Discovery Configuration Guidelines

Configuring the Frequency of ICMP Router Advertisements The router discovery server sends router advertisement messages, which include route information and indicate to network hosts that the router is still operational. The server sends these messages periodically, with a time range defined by minimum and maximum values. By default, the server sends router advertisements every 400 to 600 seconds. To modify these times, include the min-advertisement-interval and max-advertisement-interval statements: min-advertisement-interval seconds; max-advertisement-interval seconds;


Modifying the Lifetime in ICMP Router Advertisements The lifetime field in router advertisement messages indicates how long a host should consider the advertised address to be valid. If this amount of time passes and the host has not received a router advertisement from the server, the route marks the advertised addresses as invalid. By default, addresses are considered to be valid for 1800 seconds (30 minutes). To modify the router lifetime timer, include the lifetime statement: lifetime seconds;


Tracing ICMP Protocol Traffic To trace ICMP protocol traffic, you can specify options in the global traceoptions statement included at the [edit routing-options] hierarchy level, and you can specify ICMP-specific options by including the traceoptions statement: traceoptions { file filename ; flag flag ; }

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. You can specify the following ICMP-specific options in the ICMP flag statement: •

error—Trace error packets.

•

info—Trace information packets.

•

router-discovery—Trace all ICMP packets.

•

redirect—Trace redirect packets.


925


You can specify the following global flag options: •

all—Trace everything.

•

general—Trace general events.

•

normal—Trace normal events.

•

policy—Trace policy processing.

•

route—Trace routing information.

•


•

task—Trace routing protocol task processing.

•

timer—Trace routing protocol timer processing.

NOTE: Use the trace flags detail and all with caution. These flags may cause the CPU to become very busy.

For general information about tracing and global tracing options, see “Tracing Global Routing Protocol Operations” on page 138.

Example: Tracing ICMP Protocol Traffic Trace only unusual or abnormal operations to a file called routing-log, and trace router discovery state transitions to a file called icmp-log: [edit] routing-options { traceoptions { file routing-log; } } protocols { router-discovery { traceoptions { file icmp-log; flag state; } } }

926


CHAPTER 27

Summary of ICMP Router Discovery Configuration Statements The following sections explain each of the Internet Control Message Protocol (ICMP) router discovery configuration statements. The statements are organized alphabetically.

address Syntax

Hierarchy Level


address address { (advertise | ignore); (broadcast | multicast); (priority number | ineligible); } [edit logical-systems logical-system-name protocols router-discovery], [edit protocols router-discovery]

Statement introduced before Junos OS Release 7.4. IP addresses to include in router advertisement packets. address—IP address. To specify more than one address, specify multiple addresses or

include multiple address statements. The remaining statements are explained separately. Required Privilege Level Related Documentation




927


advertise Syntax Hierarchy Level



(advertise | ignore); [edit logical-systems logical-system-name protocols router-discovery address address], [edit protocols router-discovery address address]

Statement introduced before Junos OS Release 7.4. Specify whether the server should advertise the IP address in its router advertisement packets: •

advertise—Advertise the IP address in its router advertisement packets.

•

ignore—Do not advertise the IP addresses in router advertisement packets.

advertise



broadcast Syntax Hierarchy Level


(broadcast | multicast); [edit logical-systems logical-system-name protocols router-discovery address address], [edit protocols router-discovery address address]

Statement introduced before Junos OS Release 7.4. Specify when the server should include the IP addresses in router advertisement packets. On the same physical interfaces, some addresses might be included only in multicast packets, while others might be included only in broadcast packets. If you specify broadcast, the server includes the addresses in router advertisement packets only if the packets are broadcast.

Default

multicast if the router supports IP multicast; broadcast if the router does not support IP

multicast. Required Privilege Level Related Documentation

928



•



Chapter 27: Summary of ICMP Router Discovery Configuration Statements


Release Information Description Default Required Privilege Level Related Documentation

disable; [edit logical-systems logical-system-name protocols router-discovery], [edit protocols router-discovery]

Statement introduced before Junos OS Release 7.4. Disable router discovery. The configured object is enabled (operational) unless explicitly disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


ignore See

advertise

See

priority

ineligible


929


interface Syntax

Hierarchy Level


Options

interface interface-name { min-advertisement-interval seconds; max-advertisement-interval seconds; lifetime seconds; } [edit logical-systems logical-system-name protocols router-discovery], [edit protocols router-discovery]

Statement introduced before Junos OS Release 7.4. Specify physical interfaces on which to configure timers for router advertisement messages. interface-name—Name of an interface. Specify the full interface name, including the

physical and logical address components. To configure all interfaces, specify all. The remaining statements are explained separately. Required Privilege Level Related Documentation

930

routing—To view this statement in the configuration. “Configuring the Frequency of ICMP Router Advertisements” on page 925 •




lifetime Syntax Hierarchy Level

Release Information

lifetime seconds; [edit logical-systems logical-system-name protocols router-discovery interface interface-name], [edit protocols router-discovery interface interface-name]


Description

How long the addresses sent by the server in its router advertisement packets are valid. This time must be long enough so that another router advertisement packet is sent before the lifetime has expired. The lifetime value is placed in the advertisement lifetime field of the router advertisement packet.

Options

seconds—Lifetime value. A value of 0 indicates that one or more addresses are no longer

valid. Range: Three times the value set by the max-advertisement-interval statement through 2 hours, 30 minutes (9000 seconds) Default: 1800 seconds (30 minutes, which is three times the default value for the max-advertisement-interval statement) Required Privilege Level Related Documentation


max-advertisement-interval on page 932

•



931


max-advertisement-interval Syntax Hierarchy Level


Options

max-advertisement-interval seconds; [edit logical-systems logical-system-name protocols router-discovery interface interface-name], [edit protocols router-discovery interface interface-name]

Statement introduced before Junos OS Release 7.4. Maximum time the router waits before sending periodic router advertisement packets out the interface. These packets are broadcast or multicast, depending on how the address corresponding to this physical interface is configured. seconds—Maximum time between router advertisement packets.

Range: 4 through 1800 seconds Default: 600 seconds (10 minutes) Required Privilege Level Related Documentation

932


broadcast on page 928

•

lifetime on page 931

•

min-advertisement-interval on page 933

•


•




min-advertisement-interval Syntax Hierarchy Level


Options

min-advertisement-interval seconds; [edit logical-systems logical-system-name protocols router-discovery interface interface-name], [edit protocols router-discovery interface interface-name]

Statement introduced before Junos OS Release 7.4. Minimum time the router waits before sending router advertisement packets out the interface in response to route solicitation packets it receives from a client. These packets are broadcast or multicast, depending on how the address corresponding to this physical interface is configured. seconds—Minimum time between router advertisement packets.

Range: 3 seconds through 1800 seconds Default: 400 seconds (0.75 times the default value for the max-advertisement-interval statement) Required Privilege Level Related Documentation



•


•


•



933


multicast Syntax Hierarchy Level


(multicast | broadcast); [edit logical-systems logical-system-name protocols router-discovery address address], [edit protocols router-discovery address address]

Statement introduced before Junos OS Release 7.4. Specify when the server should include the IP addresses in router advertisement packets. On the same physical interfaces, some addresses might be included only in multicast packets, while others might be included only in broadcast packets. If you specify multicast, the server includes the addresses in router advertisement packets only if the packets are multicast. If the router supports IP multicast, and if the interface supports IP multicast, multicast is the default. Otherwise, the addresses are included in broadcast router advertisement packets. If the router does not support IP multicast, the addresses are not included.

Default

multicast if the router supports IP multicast; broadcast if the router does not support IP

multicast. Required Privilege Level Related Documentation

934



•






Options

priority (number | ineligible); [edit logical-systems logical-system-name protocols router-discovery address address], [edit protocols router-discovery address address]

Statement introduced before Junos OS Release 7.4. Preference of the address to become a default router. This preference is set relative to the preferences of other router addresses on the same subnet. ineligible—Address can never become the default router. priority number—Preference of the addresses for becoming the default router. A higher

value indicates that the address has a greater preference for becoming the default router. Range: 0 through 0x80000000 Default: 0 (This address has the least chance of becoming the default router.) Required Privilege Level Related Documentation



router-discovery Syntax Hierarchy Level

Release Information Description Default Required Privilege Level Related Documentation

router-discovery { ... } [edit logical-systems logical-system-name protocols], [edit protocols]

Statement introduced before Junos OS Release 7.4. Enable ICMP router discovery (server mode) on the router. Router discovery is disabled on the router. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



935


traceoptions Syntax

Hierarchy Level


traceoptions { file filename ; flag flag ; } [edit logical-systems logical-system-name protocols router-discovery], [edit protocols router-discovery]

Statement introduced before JUNOS Release 7.4. Configure ICMP protocol-level tracing options. To specify more than one tracing operation, include multiple flag statements.

Default

The default ICMP protocol-level tracing options are inherited from the routing protocols traceoptions statement included at the [edit routing-options] hierarchy level.

Options



name within quotation marks. All files are placed in the directory /var/log. We recommend that you place ICMP tracing output in the file icmp-log. files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and

so on, until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum number of files, you also must specify a maximum file size with the size option. Range: 2 through 1000 files Default: 2 files flag flag—Tracing operation to perform. To specify more than one tracing operation,

include multiple flag statements. These are the ICMP-specific tracing options: •

error—Errored ICMP packets

•

info—ICMP information packets

•

packets—All packets

•

router-discovery—All ICMP packets

•

redirect—ICMP redirect packets

These are the global tracing options:

936



•


•


•




•


•


•


•

timer—Timer usage




•


•



or gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum file size, you also must specify a maximum number of trace files with the files option. Syntax: xk to specify KB, xm to specify MB, or xg to specify GB Range: 10 KB through the maximum file size supported on your system Default: 1 MB world-readable—(Optional) Allow any user to read the log file.



Tracing ICMP Protocol Traffic on page 925


937


938


CHAPTER 28

Introduction to Neighbor Discovery This chapter discusses the following topics that provide background information about neighbor discovery: •

Neighbor Discovery Overview on page 939

•

Neighbor Discovery Standards on page 940

Neighbor Discovery Overview Neighbor discovery is a protocol that allows different nodes on the same link to advertise their existence to their neighbors, and to learn about the existence of their neighbors. A router periodically multicasts a router advertisement from each of its multicast interfaces, announcing its availability. Hosts listen for these advertisements for address autoconfiguration and discovery of link-local addresses of the neighboring routers. When a host starts, it multicasts a router solicitation to ask for immediate advertisements. The router discovery messages do not constitute a routing protocol. They enable hosts to discover the existence of neighboring routers, but are not used to determine which router is best to reach a particular destination. Neighbor discovery uses the following Internet Control Message Protocol version 6 (ICMPv6) messages: router solicitation, router advertisement, neighbor solicitation, neighbor advertisement, and redirect. Neighbor discovery for IPv6 replaces the following IPv4 protocols: router discovery (RDISC), Address Resolution Protocol (ARP), and ICMPv4 redirect. Junos OS Release 9.3 and later supports Secure Neighbor Discovery (SEND). SEND enables you to secure Neighbor Discovery protocol (NDP) messages. It is applicable in environments where physical security on a link is not assured and attacks on NDP messages are a concern. The Junos OS secures NDP messages through cryptographically generated addresses (CGAs). This section discusses the following topics: •

Router Discovery on page 940

•

Address Resolution on page 940

•

Redirect on page 940


939


Router Discovery Router advertisements can contain a list of prefixes. These prefixes are used for address autoconfiguration, to maintain a database of onlink (on the same data link) prefixes, and for duplication address detection. If a node is onlink, the router forwards packets to that node. If the node is not onlink, the packets are sent to the next router for consideration. For IPv6, each prefix in the prefix list can contain a prefix length, a valid lifetime for the prefix, a preferred lifetime for the prefix, an onlink flag, and an autoconfiguration flag. This information enables address autoconfiguration and the setting of link parameters such as maximum transmission unit (MTU) size and hop limit.

Address Resolution For IPv6, ICMPv6 neighbor discovery replaces Address Resolution Protocol (ARP) for resolving network addresses to link-level addresses. Neighbor discovery also handles changes in link-layer addresses, inbound load balancing, anycast addresses, and proxy advertisements. Nodes requesting the link-layer address of a target node multicast a neighbor solicitation message with the target address. The target sends back a neighbor advertisement message containing its link-layer address. Neighbor solicitation and advertisement messages are used for detecting duplicate unicast addresses on the same link. Autoconfiguration of an IP address depends on whether there is a duplicate address on that link. Duplicate address detection is a requirement for autoconfiguration. Neighbor solicitation and advertisement messages are also used for neighbor unreachability detection. Neighbor unreachability detection involves detecting the presence of a target node on a given link.

Redirect Redirect messages are sent to inform a host of a better next-hop router to a particular destination or an onlink neighbor. This is similar to ICMPv4 redirect.

Neighbor Discovery Standards The Junos OS substantially supports the following RFCs, which define standards for neighbor discovery: •

RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 Specification

•

RFC 4861, Neighbor Discovery for IP Version 6

•

RFC 4862, IPv6 Stateless Address Autoconfiguration

To access Internet RFCs and drafts, go to the Internet Engineering Task Force (IETF) website at http://www.ietf.org.

940


CHAPTER 29

Neighbor Discovery Configuration Guidelines This chapter describes the following tasks for configuring and monitoring neighbor discovery router advertisement messages: •

Configuring Neighbor Discovery on page 941

•

Minimum Neighbor Discovery Configuration on page 942

•

Configuring an Interface to Send Neighbor Discovery Advertisements on page 942

•

Configuring the Hop Count in Outgoing Neighbor Discovery Packets on page 943

•

Configuring the Lifetime for the Default Neighbor Discovery Router on page 943

•

Configuring the MTU Option for Neighbor Discovery Advertisements on page 943

•

Enabling Stateful Autoconfiguration with Neighbor Discovery on page 944

•

Configuring the Frequency of Neighbor Discovery Advertisements on page 945

•

Configuring the Delay Before Neighbor-Discovery Neighbors Mark the Router as Down on page 945

•

Configuring the Frequency of Neighbor Solicitation Messages on page 945

•

Configuring the Prefix Information Included in Neighbor Discovery Advertisements on page 946

•

Tracing Neighbor Discovery Protocol Traffic on page 947

Configuring Neighbor Discovery To configure neighbor discovery, include the following statements. You configure router advertisement on a per-interface basis. protocols { router-advertisement { interface interface-name { current-hop-limit number; default-lifetime seconds; (link-mtu | no-link-mtu); (managed-configuration |no-managed-configuration); max-advertisement-interval seconds; min-advertisement-interval seconds; (other-stateful-configuration | no-other-stateful-configuration);


941


prefix prefix { (autonomous | no-autonomous); (on-link | no-on-link); preferred-lifetime seconds; valid-lifetime seconds; } reachable-time milliseconds; retransmit-timer milliseconds; traceoptions { file filename ; flag flag ; } } }


Minimum Neighbor Discovery Configuration To configure the router to send router advertisement messages, you must include at least the following statements in the configuration. All other router advertisement configuration statements are optional. protocols { router-advertisement { interface interface-name { prefix prefix; } } }


NOTE: When you configure neighbor discovery router advertisement on an interface, you must also include the family inet6 statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level.

Configuring an Interface to Send Neighbor Discovery Advertisements To configure an interface to send router advertisement messages, include the interface statement: interface interface-name;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. Specify the interface name in the following format: physical.logical

942


Chapter 29: Neighbor Discovery Configuration Guidelines

NOTE: The Junos OS enters the Neighbor Discovery Protocol (NDP) packets into the routing platform cache even if there is no known route to the source.

NOTE: If you are using Virtual Router Redundancy Protocol (VRRP) for IPv6, you must include the virtual-router-only statement on both the master and backup VRRP on the IPv6 router.


•


Configuring the Hop Count in Outgoing Neighbor Discovery Packets The current hop limit field in the router advertisement messages indicates the default value placed in the hop count field of the IP header for outgoing packets. To configure the hop limit, include the current-hop-limit statement: current-hop-limit number;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. The default hop limit is 64.

Configuring the Lifetime for the Default Neighbor Discovery Router The default lifetime in router advertisement messages indicates the lifetime associated with the default router. To modify the default lifetime timer, include the default-lifetime statement: default-lifetime seconds;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. By default, the default router lifetime is three times the maximum advertisement interval. For more information about the maximum advertisement interval, see “Configuring the Frequency of Neighbor Discovery Advertisements” on page 945.

Configuring the MTU Option for Neighbor Discovery Advertisements In Junos OS Release 10.3 and later, you can configure the link-mtu statement to include the maximum transmission unit (MTU) option in router advertisement messages. The MTU option included in router advertisement messages ensures that all nodes on a link use the same MTU value in situations where the link MTU is not well known. By default, the MTU option field is not included in router advertisement messages.


943


To include the MTU option in router advertisement messages, include the link-mtu statement: link-mtu;

To stop including the MTU option in router advertisement messages, include the no-link-mtu statement: no link-mtu;

To configure the MTU option for neighbor discovery advertisements: 1.

Assign a 128-bit IPv6 address to the interface. [edit] user@host# set interfaces ge-2/0/0 unit 0 family inet6 address 2001:DB8::/32

2. Configure the interface to send router advertisement messages that include the MTU

option. [edit] user@host# set protocols router-advertisement interface ge-2/0/0 link-mtu


•

Neighbor Discovery Overview on page 939

•

Configuring Protocol Family and Interface Address Properties in the Junos OS Network Interfaces Configuration Guide

Enabling Stateful Autoconfiguration with Neighbor Discovery You can set two fields in the router advertisement message to enable stateful autoconfiguration on a host: the managed configuration field and the other stateful configuration field. Setting the managed configuration field enables the host to use a stateful autoconfiguration protocol for address autoconfiguration, along with any stateless autoconfiguration already configured. Setting the other stateful configuration field enables autoconfiguration of other nonaddress-related information. By default, stateful autoconfiguration is disabled. To set the managed configuration field and enable address autoconfiguration, include the managed-configuration statement: managed-configuration;

To disable managed configuration field, include the no-managed-configuration statement: nomanaged-configuration;

To set the other stateful configuration field and enable autoconfiguration of other types of information, include the other-stateful-configuration statement: other-stateful-configuration;

To disable other stateful configuration, include the no-other-stateful-configuration statement:

944



no-other-stateful-configuration;


Configuring the Frequency of Neighbor Discovery Advertisements The router sends router advertisements on each interface configured to transmit messages. The advertisements include route information and indicate to network hosts that the router is operational. The router sends these messages periodically, with a time range defined by minimum and maximum values. To modify the router advertisement interval, include the min-advertisement-interval and max-advertisement-interval statements: min-advertisement-interval seconds; max-advertisement-interval seconds;

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. By default, the maximum advertisement interval is 600 seconds and the minimum advertisement interval is one-third the maximum interval, or 200 seconds.

Configuring the Delay Before Neighbor-Discovery Neighbors Mark the Router as Down After receiving a reachability confirmation from a neighbor, a node considers that neighbor reachable for a certain amount of time without receiving another confirmation. This mechanism is used for neighbor unreachability detection, a mechanism for finding link failures to a target node. To modify the reachable time limit, include the reachable-time statement: reachable-time milliseconds;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. By default, the reachable time period is 0 milliseconds.

Configuring the Frequency of Neighbor Solicitation Messages The retransmit timer determines the retransmission frequency of neighbor solicitation messages. This timer is used to detect when a neighbor has become unreachable and to resolve addresses. To modify the retransmit timer, include the retransmit-timer statement: retransmit-timer milliseconds;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. By default, the retransmit timer is 0 milliseconds.


945


Configuring the Prefix Information Included in Neighbor Discovery Advertisements Router advertisement messages carry prefixes and information about them. A prefix is onlink when it is assigned to an interface on a specified link. The prefixes specify whether they are onlink or not onlink. A node considers a prefix to be onlink if it is represented by one of the link’s prefixes, a neighboring router specifies the address as the target of a redirect message, a neighbor advertisement message is received for the (target) address, or any neighbor discovery message is received from the address. These prefixes are also used for address autoconfiguration. The information about the prefixes specifies the lifetime of the prefixes, whether the prefix is autonomous, and whether the prefix is onlink. You can perform the following tasks when configuring the prefix information: •

Setting the Prefix for Onlink Determination on page 946

•

Setting the Prefix for Stateless Address Autoconfiguration on page 946

•

Configuring the Preferred Lifetime on page 947

•

Configuring the Valid Lifetime on page 947

Setting the Prefix for Onlink Determination You can specify prefixes in the router advertisement messages as onlink. When set as onlink, the prefixes are used for onlink determination. By default, prefixes are onlink. To explicitly set prefixes as onlink, include the on-link statement: on-link;

To set prefixes as not onlink, include the no-on-link statement: no-on-link;


Setting the Prefix for Stateless Address Autoconfiguration You can specify prefixes in the router advertisement messages as autonomous. When set as autonomous, the prefixes are used for stateless address autoconfiguration. By default, prefixes are autonomous. To explicitly specify prefixes as autonomous, include the autonomous statement: autonomous;

To specify prefixes as not autonomous, include the no-autonomous statement: no-autonomous;


946



Configuring the Preferred Lifetime The preferred lifetime for the prefixes in the router advertisement messages specifies how long the prefix generated by stateless autoconfiguration remains preferred. By default, the preferred lifetime is set to 604,800 seconds. To configure the preferred lifetime, include the preferred-lifetime statement: preferred-lifetime seconds;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. If you set the preferred lifetime to 0xffffffff, the lifetime is infinite. The preferred lifetime value must never exceed the valid lifetime value.

Configuring the Valid Lifetime The valid lifetime for the prefixes in the router advertisement messages specifies how long the prefix remains valid for onlink determination. By default, the valid lifetime is set to 2,592,000 seconds. To configure the valid lifetime, include the valid-lifetime statement: valid-lifetime seconds;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. If you set the valid lifetime to 0xffffffff, the lifetime is infinite. The valid lifetime value must never be smaller than the preferred lifetime value.

Tracing Neighbor Discovery Protocol Traffic You can trace various Neighbor Discovery protocol traffic to help debug Neighbor Discovery protocol issues. To trace Neighbor Discovery protocol traffic include the traceoptions statement at the [edit protocols router-advertisement] hierarchy level: traceoptions { file filename ; flag flag ; }

Global tracing options are inherited from the configuration set by the traceoptions statement at the [edit routing-options] hierarchy level. You can override the following global trace options for the Neighbor Discovery protocol using the traceoptions flag statement included at the [edit protocols router-advertisement] hierarchy level: •


•


and route trace operations)


947


•


•


•


•


•


•




948

•


•

For more information about tracing and global tracing options, see Tracing Global Routing Protocol Operations on page 138.


CHAPTER 30

Summary of Neighbor Discovery Router Advertisement Configuration Statements The following sections explain each of the neighbor discovery router advertisement configuration statements. The statements are organized alphabetically.

autonomous Syntax Hierarchy Level



(autonomous | no-autonomous); [edit logical-systems logical-system-name protocols router-advertisement interface interface-name prefix prefix], [edit protocols router-advertisement interface interface-name prefix prefix]

Statement introduced before Junos OS Release 7.4. Specify whether prefixes in the router advertisement messages are used for stateless address autoconfiguration: •

autonomous—Use prefixes for address autoconfiguration.

•

no-autonomous—Do not use prefixes for address autoconfiguration.

autonomous


Setting the Prefix for Stateless Address Autoconfiguration on page 946


949


current-hop-limit Syntax Hierarchy Level


current-hop-limit number; [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced before Junos OS Release 7.4. Default value placed in the hop count field of the IP header for outgoing packets. number—Hop limit. A value of 0 means the limit is unspecified by this router.



Configuring the Hop Count in Outgoing Neighbor Discovery Packets on page 943

default-lifetime Syntax Hierarchy Level


default-lifetime seconds; [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced before Junos OS Release 7.4. Lifetime associated with a default router. seconds—Default lifetime. A value of 0 means this router is not the default router.

Range: Maximum advertisement interval value through 9000 seconds Default: Three times the maximum advertisement interval value Required Privilege Level Related Documentation

950



•

Configuring the Lifetime for the Default Neighbor Discovery Router on page 943


Chapter 30: Summary of Neighbor Discovery Router Advertisement Configuration Statements

interface Syntax

Hierarchy Level


Options

interface interface-name { current-hop-limit number; default-lifetime seconds; (link-mtu | no-link-mtu); (managed-configuration | no-managed-configuration); max-advertisement-interval seconds; min-advertisement-interval seconds; (other-stateful-configuration | no-other-stateful-configuration); prefix prefix { (autonomous | no-autonomous); (on-link | no-on-link); preferred-lifetime seconds; valid-lifetime seconds; } reachable-time milliseconds; retransmit-timer milliseconds; } [edit logical-systems logical-system-name protocols router-advertisement], [edit protocols router-advertisement]

Statement introduced before Junos OS Release 7.4. Configure router advertisement properties on an interface. To configure more than one interface, include the interface statement multiple times. interface-name—Name of an interface. Specify the full interface name, including the

physical and logical address components. The remaining statements are explained separately. Required Privilege Level Related Documentation




951


link-mtu Syntax Hierarchy Level



(link-mtu | no-link-mtu); [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced in Junos OS 10.3. Specify whether to include the maximum transmission unit (MTU) option in router advertisement messages: •

link-mtu–Includes the MTU option in router advertisements.

•

no-link-mtu–Does not include the MTU option in router advertisements.

Router advertisement messages do not include the MTU option. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Configuring the MTU Option for Neighbor Discovery Advertisements on page 943

managed-configuration Syntax Hierarchy Level



952

(managed-configuration | no-managed-configuration); [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced before Junos OS Release 7.4. Specify whether to enable the host to use a stateful autoconfiguration protocol for address autoconfiguration, along with any stateless autoconfiguration already configured: •

managed-configuration—Enable host to use stateful autoconfiguration.

•

no-managed-configuration—Disable host from using stateful autoconfiguration.

The configured object is disabled unless explicitly enabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




max-advertisement-interval Syntax Hierarchy Level


max-advertisement-interval seconds; [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced before Junos OS Release 7.4. Maximum interval between each router advertisement message. seconds—Maximum interval.



min-advertisement-interval on page 953

•


min-advertisement-interval Syntax Hierarchy Level


min-advertisement-interval seconds; [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced before Junos OS Release 7.4. Minimum interval between each router advertisement message. seconds—Minimum interval.

Range: 3 seconds through three-quarter times the maximum advertisement interval value Default: One-third the maximum advertisement interval value Required Privilege Level Related Documentation



•



953


no-autonomous See

autonomous

no-managed-configuration See

managed-configuration

See

on-link

no-on-link

no-other-stateful-configuration See

other-stateful-configuration

on-link Syntax Hierarchy Level



954

(on-link | no-on-link); [edit logical-systems logical-system-name protocols router-advertisement interface interface-name prefix prefix], [edit protocols router-advertisement interface interface-name prefix prefix]

Statement introduced before Junos OS Release 7.4. Specify whether to enable prefixes to be used for onlink determination: •

no-on-link—Disable prefixes from being used for onlink determination.

•

on-link—Enable prefixes to be used for onlink determination.

The configured object is enabled unless explicitly disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




other-stateful-configuration Syntax Hierarchy Level


(other-stateful-configuration | no-other-stateful-configuration); [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced before Junos OS Release 7.4. Specify whether to enable autoconfiguration of other nonaddress-related information: •

no-other-stateful-configuration—Disable autoconfiguration of other nonaddress-related

information. •

other-stateful-configuration—Enable autoconfiguration of other nonaddress-related

information. Default Required Privilege Level Related Documentation

The configured object is disabled unless explicitly enabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


preferred-lifetime Syntax Hierarchy Level

Release Information

preferred-lifetime seconds; [edit logical-systems logical-system-name protocols router-advertisement interface interface-name prefix prefix], [edit protocols router-advertisement interface interface-name prefix prefix]


Description

Specify how long the prefix generated by stateless autoconfiguration remains preferred.

Options

seconds—Preferred lifetime, in seconds. If you set the preferred lifetime to 0xffffffff, the

lifetime is infinite. The preferred lifetime is never greater than the valid lifetime. Default: 604,800 seconds Required Privilege Level Related Documentation


valid-lifetime on page 959

•

Configuring the Preferred Lifetime on page 947


955


prefix Syntax

Hierarchy Level


prefix prefix { (autonomous | no-autonomous); (on-link | no-on-link); preferred-lifetime seconds; valid-lifetime seconds; } [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced before Junos OS Release 7.4. Configure prefix properties in router advertisement messages. prefix—Prefix name.




reachable-time Syntax Hierarchy Level


Options

reachable-time milliseconds; [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced before Junos OS Release 7.4. Set the length of time that a node considers a neighbor reachable until another reachability confirmation is received from that neighbor. milliseconds—Reachability time limit.

Range: 0 through 3,600,000 milliseconds Default: 0 milliseconds Required Privilege Level Related Documentation

956


Configuring the Delay Before Neighbor-Discovery Neighbors Mark the Router as Down on page 945



retransmit-timer Syntax Hierarchy Level


retransmit-timer milliseconds; [edit logical-systems logical-system-name protocols router-advertisement interface interface-name], [edit protocols router-advertisement interface interface-name]

Statement introduced before Junos OS Release 7.4. Set the retransmission frequency of neighbor solicitation messages. milliseconds—Retransmission frequency.

Default: 0 milliseconds Required Privilege Level Related Documentation


Configuring the Frequency of Neighbor Solicitation Messages on page 945

router-advertisement Syntax Hierarchy Level


router-advertisement {...} [edit logical-systems logical-system-name protocols], [edit protocols]

Statement introduced before Junos OS Release 7.4. Enable router advertisement. The remaining statements are explained separately.





957


traceoptions Syntax

Hierarchy Level

Release Information Description Default Options

traceoptions { file filename ; flag flag ; } [edit logical-systems logical-system-name protocols router-advertisement], [edit protocols router-advertisement]

Statement introduced before Junos OS Release 7.4. Specify router advertisement protocol-level tracing options. The default trace options are inherited from the global traceoptions statement. disable—(Optional) Disable the tracing operation. One use of this option is to disable a


name in quotation marks. We recommend that you place router advertisement tracing output in the file /var/log/router-advertisement-log. files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and

so on, until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum number of files, you must also specify a maximum file size with the size option. Range: 2 through 1000 files Default: 10 files flag flag—Tracing operation to perform. To specify more than one tracing operation,

include multiple flag statements. •


•


•

normal—All normal operations.

Default: If you do not specify this option, only unusual or abnormal operations are traced.

958

•


•


•


•


•

timer—Timer usage



no-world-readable—(Optional) Prevent any user from reading the log file. size size—(Optional) Maximum size of each trace file, in kilobytes (KB) or megabytes

(MB). When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum file size, you must also specify a maximum number of trace files with the files option. Syntax: xk to specify KB, xm to specify MB, or xg to specify GB Range: 10 KB through the maximum file size supported on your system Default: 128 KB world-readable—(Optional) Allow any user to read the log file.



Tracing Neighbor Discovery Protocol Traffic on page 947

valid-lifetime Syntax Hierarchy Level


valid-lifetime seconds; [edit logical-systems logical-system-name protocols router-advertisement interface interface-name prefix prefix], [edit protocols router-advertisement interface interface-name prefix prefix]

Statement introduced before Junos OS Release 7.4. Specify how long the prefix remains valid for onlink determination. seconds—Valid lifetime, in seconds. If you set the valid lifetime to 0xffffffff, the lifetime

is infinite. Default: 2,592,000 seconds Required Privilege Level Related Documentation


preferred-lifetime on page 955

•

Configuring the Valid Lifetime on page 947


959


960


CHAPTER 31

Secure Neighbor Discovery Configuration Guidelines This chapter discusses the following topics that describe how to configure Secure Neighbor Discovery: •

Secure Neighbor Discovery Configuration Overview on page 961

•

Configuring Secure Neighbor Discovery on page 961

•

Enabling Secure Neighbor Discovery on page 962

•

Configuring Cryptographically Generated Addresses for Secure Neighbor Discovery on page 962

•

Configuring Timestamps for Secure Neighbor Discovery on page 963

•

Tracing Secure Neighbor Discovery Protocol Traffic on page 964

Secure Neighbor Discovery Configuration Overview The Secure Neighbor Discovery (SEND) Protocol provides support for protecting Neighbor Discovery Protocol (NDP) messages. SEND is applicable in environments where physical security on a link is not ensured and attacks on NDP messages are a concern. The Junos OS implementation secures NDP messages through cryptographically generated addresses (CGAs). You must also enable IPv6 on at least one interface. Because SEND relies on dynamically generated CGAs, it does not support static IPv6 addresses.

Configuring Secure Neighbor Discovery To configure Secure Neighbor Discovery (SEND), include the following statements: protocols { neighbor-discovery { secure { security-level { (default | secure-messages-only); } cryptographic-address { key-length number; key-pair pathname;


961


} timestamp { clock-drift number; known-peer-window seconds; new-peer-window seconds; } traceoptions { file ; flag flag; no-remote-trace; } } } }

Enabling Secure Neighbor Discovery To enable Secure Neighbor Discovery (SEND), include the following statements: protocols { neighbor-discovery { secure { security-level { (default | secure-messages-only); } } } }

Specify default to send and receive both secure and unsecured Neighbor Discovery Protocol (NDP) packets. To configure SEND to accept secured NDP messages only and to drop unsecured ones. specify secure-messages-only.

Configuring Cryptographically Generated Addresses for Secure Neighbor Discovery The Secure Neighbor Discovery (SEND) Protocol uses cryptographically generated addresses (CGAs), as defined in RFC 3972, Cryptographically Generated Addresses, to ensure that the sender of a Neighbor Discovery Protocol (NDP) message is the “owner” of the claimed address. Each node must generate a public-private key pair before it can claim an address. The CGA is included in all outgoing neighbor solicitation and neighbor advertisement messages. To configure parameters for CGAs, include the following statements: protocols { neighbor-discovery { secure { cryptographic-address { key-length number; key-pair pathname; } } }

962


Chapter 31: Secure Neighbor Discovery Configuration Guidelines

}

For information about how to configure parameters for cryptographic addresses, see the following sections: •

Specifying the Pathname for the Key File on page 963

•

Specifying the RSA Key Length on page 963

Specifying the Pathname for the Key File A cryptographic address is dynamically generated based on a public key and a subnet prefix. The private-public key file that is generated is placed by default in the /var/etc/rsa_key directory. You can a specify a pathname for that file. Include the key-pair pathname statement: key-pair pathname;

For a complete list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement.

Specifying the RSA Key Length You can specify the length of the RSA key used to generate the CGA public-private pair. The default is 1024 bits, and you can specify a value from 1024 through 2048. Include the key-length number statement: key-length number;


Configuring Timestamps for Secure Neighbor Discovery The Secure Neighbor Discovery (SEND) Protocol supports several timestamp options, which are used to ensure that unsolicited solicitation and redirect messages are not being replayed. To configure timestamp parameters, include the following statements: protocols { neighbor-discovery { secure { timestamp { new-peer-window seconds; known-peer-window seconds; clock-drift value; } } } }

Use the new-peer-window seconds statement to specify the maximum allowable difference in the amount of time between the timestamp of a SEND message from a new peer and when it can be accepted. The default is 300 seconds.


963


Use the known-peer-window seconds statement to specify the expected interval between subsequent incoming SEND messages. The default is 1 second. A message from a known peer that arrives after the specified interval is discarded. Use the clock drift value statement to specify a fractional value of 100 for the allowable drift in time between the synchronization of peers. The default is 0.01, or 1 percent.

Tracing Secure Neighbor Discovery Protocol Traffic You can trace Secure Neighbor Discovery protocol traffic to help debug Secure Neighbor Discovery protocols issues. To trace Secure Neighbor Discovery protocol traffic include the traceoptions statement at the [edit protocols neighbor-discovery secure] hierarchy level: traceoptions { file ; flag flag; no-remote-trace; }

You can specify the following Secure Neighbor Discovery protocol-specific trace options using the flag statement: •

configuration—All configuration events

•

cryptographic-address—Cryptographically generated address events

•

protocol—Protocol processing events

•

rsa—RSA events

Global tracing options are inherited from the configuration set by the traceoptions statement at the [edit routing-options] hierarchy level. You can override the following global trace options for the IS-IS protocol using the traceoptions flag statement included at the [edit protocols neighbor-discovery secure] hierarchy level: •


NOTE: Use the trace flag all with caution since this may cause the CPU to become very busy.


964

•

traceoptions on page 971

•

Tracing Global Routing Protocol Operations on page 138.


CHAPTER 32

Summary of Secure Neighbor Discovery Configuration Statements The following sections explain each of the Secure Neighbor Discovery configuration statements. The statements are organized alphabetically.

cryptographic-address Syntax

Hierarchy Level Release Information Description

cryptographic-address { key-length number; key-pair pathname; } [edit protocols neighbor-discovery secure]

Statement introduced in Junos OS Release 9.3. Configure parameters for cryptographically generated addresses for Secure Neighbor Discovery. The remaining statements are explained separately.


routing level—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



965


key-length Syntax Hierarchy Level Release Information Description

Default Options

key-length number { [edit protocols neighbor-discovery secure cryptographic-address]

Statement introduced in Junos OS Release 9.3. Specify the length of the RSA key used to generate the public-private key pair for the cryptographic address. 1024 number—RSA key length.



Specifying the RSA Key Length on page 963

key-pair Syntax Hierarchy Level Release Information Description

Options

key-pair pathname; [edit protocols neighbor-discovery secure cryptographic-address]

Statement introduced in Junos OS Release 9.3. Specify the directory path of the public-private key file generated for the cryptographic address. pathname—Directory path of the public-private key file. The default location of the file

is /var/etc/rsa_key directory. Required Privilege Level Related Documentation

966


Specifying the Pathname for the Key File on page 963


Chapter 32: Summary of Secure Neighbor Discovery Configuration Statements

neighbor-discovery Syntax


neighbor-discovery { secure { security-level { (default | secure-messages-only); } cryptographic-address { key-length number; key-pair pathname; } timestamp { clock-drift number; known-peer-window number; new-peer-window number; } traceoptions { file ; flag flag; no-remote-trace; } } } [edit protocols]

Statement introduced in Junos OS Release 9.3. Enable Secure Neighbor Discovery. The remaining statements are explained separately.


Disabled routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



967


secure Syntax


secure { security-level { (default | secure-messages-only); } cryptographic-address { key-length number; key-pair pathname; } timestamp { clock-drift number; known-peer-window seconds; new-peer-window seconds; } traceoptions { file ; flag flag; no-remote-trace; } } [edit protocols neighbor-discovery]

Statement introduced in Junos OS Release 9.3. Configure parameters for Secure Neighbor Discovery. The remaining statements are explained separately.


968



•


•




security-level Syntax


security-level { (default | secure-messages-only); } [edit protocols neighbor-discovery secure]

Statement introduced in Junos OS Release 9.3. Configure the type of security mode for Secure Neighbor Discovery. default—Accept and transmit both secure and unsecured messages. secure-messages-only—Accept secure messages only. Discard unsecured messages.





969


timestamp Syntax


Options

timestamp { clock-drift value; known-peer-window seconds; new-peer-window seconds; } [edit protocols neighbor-discovery secure]

Statement introduced in Junos OS Release 9.3. Configure timestamp options, which are used to ensure that solicitation and redirect messages are not being replayed. clock-drift value—Specify the allowable drift in time between the synchronization of

peers. For value, specify a fractional value of 100. Default: 0.01 known-peer-window seconds—Specify the expected interval in seconds between Secure

Neighbor Discovery messages from an established peer. Default: 1 second new-peer-window seconds—Specify the maximum allowable time in seconds between

the timestamp of a Secure Neighbor Discovery message from a new peer and when it can be accepted. Default: 300 seconds Required Privilege Level Related Documentation

970





traceoptions Syntax


traceoptions { file ; flag flag; no-remote-trace; } [edit protocols neighbor-discovery secure]


Description

Configure tracing operations for Secure Neighbor Discovery events. To specify more than one tracing operation, include multiple flag statements.

Options

file filename—Name of the file to receive the tracing operation. Enclose the name within

quotation marks. All files are placed in the directory /var/log. files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1 and so

on, until the maximum number of trace files is reached. Then the oldest trace file is overwritten. If you specify a maximum number of files, you must also specify a maximum file size with the size option. Range: 2 through 1000 files Default: 10 files flag—Tracing operation to perform. To specify more than one tracing operation, include

multiple flag statements. Secure Neighbor Discovery Tracing Options •

configuration—All configuration events.

•

cryptographic-address—Cryptographically generated address events.

•

protocol—All protocol processing events.

•

rsa—RSA events.


all—All tracing operations.

You can specify one or more of following flag modifiers: •


•


•



971


match—(Optional) Specify a regular expression to match the output of the trace file you

want to log. no-remote-trace—Disable remote tracing globally or for a specific tracing operation. no-world-readable—(Optional) Prevent any user from reading this log file. size size—(Optional) Maximum size of each trace file, in kilobytes (KB) or megabytes

(MB). When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1, and trace-file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace files is reached. Then the oldest trace file is overwritten. Syntax: xk to specify KB, xm to specify MB, or xg to specify GB Range: 10 KB through the maximum file size supported on your system Default: 128 KB world-readable—(Optional) Allow any user to read this log file.


972




PART 6

BGP •

Introduction to BGP on page 975

•

BGP Configuration Guidelines on page 981

•

Summary of BGP Configuration Statements on page 1293


973


974


CHAPTER 33

Introduction to BGP This chapter discusses the following topics that provide background information about BGP: •

Understanding BGP on page 976

•

BGP Routes Overview on page 977

•

BGP Messages Overview on page 978


975


Understanding BGP BGP is an exterior gateway protocol (EGP) that is used to exchange routing information among routers in different autonomous systems (ASs). BGP routing information includes the complete route to each destination. BGP uses the routing information to maintain a database of network reachability information, which it exchanges with other BGP systems. BGP uses the network reachability information to construct a graph of AS connectivity, which enables BGP to remove routing loops and enforce policy decisions at the AS level. Multiprotocol BGP (MBGP) extensions enable BGP to support IP version 6 (IPv6). MBGP defines the attributes MP_REACH_NLRI and MP_UNREACH_NLRI, which are used to carry IPv6 reachability information. Network layer reachability information (NLRI) update messages carry IPv6 address prefixes of feasible routes. BGP allows for policy-based routing. You can use routing policies to choose among multiple paths to a destination and to control the redistribution of routing information. BGP uses TCP as its transport protocol, using port 179 for establishing connections. Running over a reliable transport protocol eliminates the need for BGP to implement update fragmentation, retransmission, acknowledgment, and sequencing. The Junos OS routing protocol software supports BGP version 4. This version of BGP adds support for Classless Interdomain Routing (CIDR), which eliminates the concept of network classes. Instead of assuming which bits of an address represent the network by looking at the first octet, CIDR allows you to explicitly specify the number of bits in the network address, thus providing a means to decrease the size of the routing tables. BGP version 4 also supports aggregation of routes, including the aggregation of AS paths. This section discusses the following topics: •

Autonomous Systems on page 976

•

AS Paths and Attributes on page 976

•

External and Internal BGP on page 977

Autonomous Systems An autonomous system (AS) is a set of routers that are under a single technical administration and normally use a single interior gateway protocol and a common set of metrics to propagate routing information within the set of routers. To other ASs, an AS appears to have a single, coherent interior routing plan and presents a consistent picture of what destinations are reachable through it.

AS Paths and Attributes The routing information that BGP systems exchange includes the complete route to each destination, as well as additional information about the route. The route to each destination is called the AS path, and the additional route information is included in path attributes. BGP uses the AS path and the path attributes to completely determine the network topology. Once BGP understands the topology, it can detect and eliminate

976


Chapter 33: Introduction to BGP

routing loops and select among groups of routes to enforce administrative preferences and routing policy decisions.

External and Internal BGP BGP supports two types of exchanges of routing information: exchanges among different ASs and exchanges within a single AS. When used among ASs, BGP is called external BGP (EBGP) and BGP sessions perform inter-AS routing. When used within an AS, BGP is called internal BGP (IBGP) and BGP sessions perform intra-AS routing. Figure 37 on page 977 illustrates ASs, IBGP, and EBGP.

Figure 37: ASs, EBGP, and IBGP

A BGP system shares network reachability information with adjacent BGP systems, which are referred to as neighbors or peers. BGP systems are arranged into groups. In an IBGP group, all peers in the group—called internal peers—are in the same AS. Internal peers can be anywhere in the local AS and do not have to be directly connected to one another. Internal groups use routes from an IGP to resolve forwarding addresses. They also propagate external routes among all other internal routers running IBGP, computing the next hop by taking the BGP next hop received with the route and resolving it using information from one of the interior gateway protocols. In an EBGP group, the peers in the group—called external peers—are in different ASs and normally share a subnet. In an external group, the next hop is computed with respect to the interface that is shared between the external peer and the local router. Related Documentation

•


•

BGP Messages Overview on page 978

BGP Routes Overview A BGP route is a destination, described as an IP address prefix, and information that describes the path to the destination.


977


The following information describes the path: •

AS path, which is a list of numbers of the ASs that a route passes through to reach the local router. The first number in the path is that of the last AS in the path—the AS closest to the local router. The last number in the path is the AS farthest from the local router, which is generally the origin of the path.

•

Path attributes, which contain additional information about the AS path that is used in routing policy.

BGP peers advertise routes to each other in update messages. BGP stores its routes in the Junos OS routing table (inet.0). The routing table stores the following information about BGP routes: •

Routing information learned from update messages received from peers

•

Local routing information that BGP applies to routes because of local policies

•

Information that BGP advertises to BGP peers in update messages

For each prefix in the routing table, the routing protocol process selects a single best path, called the active path. Unless you configure BGP to advertise multiple paths to the same destination, BGP advertises only the active path. The BGP router that first advertises a route assigns it one of the following values to identify its origin. During route selection, the lowest origin value is preferred.


•

0—The router originally learned the route through an IGP (OSPF, IS-IS, or a static route).

•

1—The router originally learned the route through an EGP (most likely BGP).

•

2—The route's origin is unknown.

•


•

Example: Advertising Multiple Paths in BGP on page 1258

BGP Messages Overview All BGP messages have the same fixed-size header, which contains a marker field that is used for both synchronization and authentication, a length field that indicates the length of the packet, and a type field that indicates the message type (for example, open, update, notification, keepalive, and so on). This section discusses the following topics:

978

•

Open Messages on page 979

•

Update Messages on page 979

•

Keepalive Messages on page 980

•

Notification Messages on page 980


Chapter 33: Introduction to BGP

Open Messages After a TCP connection is established between two BGP systems, they exchange BGP open messages to create a BGP connection between them. Once the connection is established, the two systems can exchange BGP messages and data traffic. Open messages consist of the BGP header plus the following fields: •

Version—The current BGP version number is 4.

•

Local AS number—You configure this by including the autonomous-system statement at the [edit routing-options] or [edit logical-systems logical-system-name routing-options] hierarchy level, as described in Specifying the Local Routing Device’s AS Number.

•

Hold time—Proposed hold-time value. You configure the local hold time with the BGP hold-time statement, as described in Configuring the Delay Before BGP Peers Mark the Routing Device as Down.

•

BGP identifier—IP address of the BGP system. This address is determined when the system starts and is the same for every local interface and every BGP peer. You can configure the BGP identifier by including the router-id statement at the [edit routing-options] or [edit logical-systems logical-system-name routing-options] hierarchy level, as described in Assigning a BGP Identifier. By default, BGP uses the IP address of the first interface it finds in the router.

•

Parameter field length and the parameter itself—These are optional fields.

Update Messages BGP systems send update messages to exchange network reachability information. BGP systems use this information to construct a graph that describes the relationships among all known ASs. Update messages consist of the BGP header plus the following optional fields: •

Unfeasible routes length—Length of the withdrawn routes field

•

Withdrawn routes—IP address prefixes for the routes being withdrawn from service because they are no longer deemed reachable

•

Total path attribute length—Length of the path attributes field; it lists the path attributes for a feasible route to a destination

•

Path attributes—Properties of the routes, including the path origin, the multiple exit discriminator (MED), the originating system’s preference for the route, and information about aggregation, communities, confederations, and route reflection

•

Network layer reachability information (NLRI)—IP address prefixes of feasible routes being advertised in the update message


979


Keepalive Messages BGP systems exchange keepalive messages to determine whether a link or host has failed or is no longer available. Keepalive messages are exchanged often enough so that the hold timer does not expire. These messages consist only of the BGP header.

Notification Messages BGP systems send notification messages when an error condition is detected. After the message is sent, the BGP session and the TCP connection between the BGP systems are closed. Notification messages consist of the BGP header plus the error code and subcode, and data that describes the error. Related Documentation

980

•


•



CHAPTER 34

BGP Configuration Guidelines This chapter includes the following topics: •

Examples: Configuring External BGP Peering on page 982

•

Examples: Configuring Internal BGP Peering on page 999

•

Example: Preventing BGP Session Resets on page 1022

•

Example: Configuring BGP Interactions with IGPs on page 1029

•

Example: Configuring BGP Route Reflectors on page 1033

•


•

Example: Configuring BGP Route Authentication on page 1056

•

Example: Configuring IPsec Protection for BGP on page 1063

•

Examples: Configuring BGP MED on page 1067

•

Example: Configuring EBGP Multihop on page 1105

•

Examples: Configuring BGP Multipath on page 1114

•

Example: Configuring BGP Local Preference on page 1130

•

Example: Configuring BGP Route Preference (Administrative Distance) on page 1143

•

Example: Configuring BGP Path Selection on page 1150

•

Examples: Configuring BGP Local AS on page 1160

•

Example: Removing Private AS Numbers on page 1180

•

Example: Configuring BGP Flap Damping on page 1186

•

Examples: Configuring Multiprotocol BGP on page 1190

•

Example: Configuring BGP and CLNS on page 1216

•

Examples: Configuring TCP and BGP Security on page 1223

•

Example: Configuring BGP Route Advertisement on page 1236

•

Example: Configuring BFD for BGP on page 1243

•

Example: Configuring BFD Authentication for BGP on page 1252

•

Example: Advertising Multiple BGP Paths to a Destination on page 1257

•

Example: Configuring BGP Monitoring Protocol on page 1282

•

Example: Configuring BGP Trace Operations on page 1285


981


Examples: Configuring External BGP Peering •

Understanding External BGP Peering Sessions on page 982

•

Example: Configuring External BGP Point-to-Point Peer Sessions on page 983

•

Example: Configuring External BGP on Logical Systems with IPv6 Interfaces on page 990

Understanding External BGP Peering Sessions To establish point-to-point connections between peer autonomous systems (ASs), you configure a BGP session on each interface of a point-to-point link. Generally, such sessions are made at network exit points with neighboring hosts outside the AS. Figure 38 on page 982 shows an example of a BGP peering session.

Figure 38: BGP Peering Session

AS 10 OSPF

RIP

AS 3 BGP

B g015013

A

In Figure 38 on page 982, Router A is a gateway router for AS 3, and Router B is a gateway router for AS 10. For traffic internal to either AS, an interior gateway protocol (IGP) is used (OSPF, for instance). To route traffic between peer ASs, a BGP session is used. You arrange BGP routing devices into groups of peers. Different peer groups must have different group types, AS numbers, or route reflector cluster identifiers. To define a BGP group that recognizes only the specified BGP systems as peers, statically configure all the system’s peers by including one or more neighbor statements. The peer neighbor’s address can be either an IPv6 or IPv4 address. As the number of external BGP (EBGP) groups increases, the ability to support a large number of BGP sessions might become a scaling issue. The preferred way to configure a large number of BGP neighbors is to configure a few groups consisting of multiple neighbors per group. Supporting fewer EBGP groups generally scales better than supporting a large number of EBGP groups. This becomes more evident in the case of hundreds of EBGP groups when compared with a few EBGP groups with multiple peers in each group. After the BGP peers are established, BGP routes are not automatically advertised by the BGP peers. At each BGP-enabled device, policy configuration is required to export the local, static, or IGP-learned routes into the BGP RIB and then advertise them as BGP routes to the other peers. BGP's advertisement policy, by default, does not advertise any non-BGP routes (such as local routes) to peers.

982


Chapter 34: BGP Configuration Guidelines

Example: Configuring External BGP Point-to-Point Peer Sessions This example shows how to configure BGP point-to-point peer sessions. •


•


•


•


Requirements Before you begin, if the default BGP policy is not adequate for your network, configure routing policies to filter incoming BGP routes and to advertise BGP routes.

Overview Figure 39 on page 983 shows a network with BGP peer sessions. In the sample network, Device E in AS 17 has BGP peer sessions to a group of peers called external-peers. Peers A, B, and C reside in AS 22 and have IP addresses 10.10.10.2, 10.10.10.6, and 10.10.10.10. Peer D resides in AS 79, at IP address 10.21.7.2. This example shows the configuration on Device E.

Figure 39: Typical Network with BGP Peer Sessions

10.2

A AS 22

AS 17

E

10.1 10.5 10.9 7.1

10.6

B

10.10

C

7.2 D

g040727

AS 79


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.


983


set interfaces ge-1/2/0 unit 0 description to-A set interfaces ge-1/2/0 unit 0 family inet address 10.10.10.1/30 set interfaces ge-0/0/1 unit 5 description to-B set interfaces ge-0/0/1 unit 5 family inet address 10.10.10.5/30 set interfaces ge-0/1/0 unit 9 description to-C set interfaces ge-0/1/0 unit 9 family inet address 10.10.10.9/30 set interfaces ge-1/2/1 unit 21 description to-D set interfaces ge-1/2/1 unit 21 family inet address 10.21.7.1/30 set protocols bgp group external-peers type external set protocols bgp group external-peers peer-as 22 set protocols bgp group external-peers neighbor 10.10.10.2 set protocols bgp group external-peers neighbor 10.10.10.6 set protocols bgp group external-peers neighbor 10.10.10.10 set protocols bgp group external-peers neighbor 10.21.7.2 peer-as 79 set routing-options autonomous-system 17


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure the BGP peer sessions: 1.

Configure the interfaces to Peers A, B, C, and D. [edit interfaces] user@E# set ge-1/2/0 unit 0 description to-A user@E# set ge-1/2/0 unit 0 family inet address 10.10.10.1/30 user@E# set ge-0/0/1 unit 5 description to-B user@E# set ge-0/0/1 unit 5 family inet address 10.10.10.5/30 user@E# set ge-0/1/0 unit 9 description to-C user@E# set ge-0/1/0 unit 9 family inet address 10.10.10.9/30 user@E# set ge-1/2/1 unit 21 description to-D user@E# set ge-1/2/1 unit 21 family inet address 10.21.7.1/30

2.

Set the autonomous system (AS) number. [edit routing-options] user@E# set autonomous-system 17

3.

Create the BGP group, and add the external neighbor addresses. [edit protocols bgp group external-peers] user@E# set neighbor 10.10.10.2 user@E# set neighbor 10.10.10.6 user@E# set neighbor 10.10.10.10

4.

Specify the autonomous system (AS) number of the external AS. [edit protocols bgp group external-peers] user@E# set peer-as 22

5.

Add Peer D, and set the AS number at the individual neighbor level. [edit protocols bgp group external-peers] user@E# set neighbor 10.21.7.2 peer-as 79

6.

Set the peer type to external BGP (EBGP). [edit protocols bgp group external-peers]

984



user@E# set type external

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. [edit] user@E# show interfaces ge-1/2/0 { unit 0 { description to-A; family inet { address 10.10.10.1/30; } } } ge-0/0/1 { unit 5 { description to-B; family inet { address 10.10.10.5/30; } } } ge-0/1/0 { unit 9 { description to-C; family inet { address 10.10.10.9/30; } } } ge-1/2/1 { unit 21 { description to-D; family inet { address 10.21.7.1/30; } } } [edit] user@E# show protocols bgp { group external-peers { type external; peer-as 22; neighbor 10.10.10.2; neighbor 10.10.10.6; neighbor 10.10.10.10; neighbor 10.21.7.2 { peer-as 79; } } }


985


[edit] user@E# show routing-options autonomous-system 17;



Verifying BGP Neighbors on page 986

•

Verifying BGP Groups on page 988

•

Verifying BGP Summary Information on page 989

•

Verifying Reachability of All Peers in a BGP Network on page 989

Verifying BGP Neighbors Purpose

Action

Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address. From operational mode, run the show bgp neighbor command. user@E> show bgp neighbor Peer: 10.10.10.2+179 AS 22 Local: 10.10.10.1+65406 AS 17 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.10.2 Local ID: 10.10.10.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down Local Interface: ge-1/2/0.0 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 22) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 10 Sent 6 Checked 1 Input messages: Total 8522 Updates 1 Refreshes 0 Octets 161922 Output messages: Total 8433 Updates 0 Refreshes 0 Octets 160290

986



Output Queue[0]: 0 Peer: 10.10.10.6+54781 AS 22 Local: 10.10.10.5+179 AS 17 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.10.6 Local ID: 10.10.10.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down Local Interface: ge-0/0/1.5 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 22) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 12 Sent 6 Checked 33 Input messages: Total 8527 Updates 1 Refreshes 0 Octets 162057 Output messages: Total 8430 Updates 0 Refreshes 0 Octets 160233 Output Queue[0]: 0 Peer: 10.10.10.10+55012 AS 22 Local: 10.10.10.9+179 AS 17 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.10.10 Local ID: 10.10.10.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 2 BFD: disabled, down Local Interface: fe-0/1/0.9 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast


987


Peer supports 4 byte AS extension (peer-as 22) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 15 Sent 6 Checked 37 Input messages: Total 8527 Updates 1 Refreshes 0 Output messages: Total 8429 Updates 0 Refreshes 0 Output Queue[0]: 0

Octets 162057 Octets 160214

Peer: 10.21.7.2+61867 AS 79 Local: 10.21.7.1+179 AS 17 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.21.7.2 Local ID: 10.10.10.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 3 BFD: disabled, down Local Interface: ge-1/2/1.21 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 79) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 28 Sent 24 Checked 47 Input messages: Total 8521 Updates 1 Refreshes 0 Octets 161943 Output messages: Total 8427 Updates 0 Refreshes 0 Octets 160176 Output Queue[0]: 0

Verifying BGP Groups Purpose Action

Verify that the BGP groups are configured correctly. From operational mode, run the show bgp group command. user@E> show bgp group Group Type: External Name: external-peers

988

Index: 0

Local AS: 17 Flags:



Holdtime: 0 Total peers: 4 10.10.10.2+179 10.10.10.6+54781 10.10.10.10+55012 10.21.7.2+61867 inet.0: 0/0/0/0 Groups: 1 Table inet.0

Established: 4

Peers: 4 External: 4 Internal: 0 Down peers: 0 Flaps: 0 Tot Paths Act Paths Suppressed History Damp State Pending 0 0 0 0 0 0

Verifying BGP Summary Information Purpose Action

Verify that the BGP configuration is correct. From operational mode, run the show bgp summary command. user@E> show bgp summary Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.10.10.2 22 8559 8470 0 0 2d 16:12:56 0/0/0/0 0/0/0/0 10.10.10.6 22 8566 8468 0 0 2d 16:12:12 0/0/0/0 0/0/0/0 10.10.10.10 22 8565 8466 0 0 2d 16:11:31 0/0/0/0 0/0/0/0 10.21.7.2 79 8560 8465 0 0 2d 16:10:58 0/0/0/0 0/0/0/0

Verifying Reachability of All Peers in a BGP Network Purpose

Action

By using the ping tool on each peer address in the network, verify that all peers in the network are reachable from each device. For each device in the BGP network: 1.

In the J-Web interface, select Troubleshoot>Ping Host.

2. In the Remote Host box, type the name of a host for which you want to verify

reachability from the device. 3. Click Start. Output appears on a separate page.

Sample Output PING 10.10.10.10 : 56 data bytes 64 bytes from 10.10.10.10: icmp_seq=0 ttl=255 time=0.382 ms 64 bytes from 10.10.10.10: icmp_seq=1 ttl=255 time=0.266 ms

Meaning

If a host is active, it generates an ICMP response. If this response is received, the round-trip time is listed in the time field.


989


Example: Configuring External BGP on Logical Systems with IPv6 Interfaces This example shows how to configure external BGP (EBGP) point-to-point peer sessions on logical systems with IPv6 interfaces. •


•


•


•


Requirements In this example, no special configuration beyond device initialization is required.

Overview Junos OS supports EBGP peer sessions by means of IPv6 link-local addresses. An IPv6 peer session can be configured when a 128-bit IPv6 address is specified in the neighbor statement. The peer address is identified as link-local by means of the local-interface statement. The local-interface statement is valid only for 128-bit IPv6 link-local addresses and is mandatory for configuring an IPv6 EBGP link-local peer session. Configuring EBGP peering using link-local addresses is only applicable for directly connected interfaces. There is no support for multihop peering. This example uses Frame Relay interface encapsulation on logical tunnel (lt) interfaces. This is a requirement because only Frame Relay encapsulation is supported when IPv6 addresses are configured on the lt interfaces. Figure 40 on page 991 shows a network with BGP peer sessions. In the sample network, Router R1 has five logical systems configured. Device E in autonomous system (AS) 17 has BGP peer sessions to a group of peers called external-peers. Peers A, B, and C reside in AS 22 and have IPv6 addresses fe80::a0a:a02, fe80::a0a:a06, and fe80::a0a:a0a. Peer D resides in AS 79, at IP address fe80::a15:702. This example shows the configuration on Device E.

990



Figure 40: Typical Network with BGP Peer Sessions R1

A 2001:db8:0:1::/64 AS 17

E

2001:db8:0:2::/64

AS 22 B

2001:db8:0:3::/64 C 2001:db8:0:4::/64

D

g040726

AS 79


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems A interfaces lt-1/2/0 unit 1 description to-E set logical-systems A interfaces lt-1/2/0 unit 1 encapsulation frame-relay set logical-systems A interfaces lt-1/2/0 unit 1 dlci 1 set logical-systems A interfaces lt-1/2/0 unit 1 peer-unit 25 set logical-systems A interfaces lt-1/2/0 unit 1 family inet6 address fe80::a0a:a02/126 set logical-systems A protocols bgp group external-peers type external set logical-systems A protocols bgp group external-peers peer-as 17 set logical-systems A protocols bgp group external-peers neighbor fe80::a0a:a01 local-interface lt-1/2/0.1 set logical-systems A routing-options autonomous-system 22 set logical-systems B interfaces lt-1/2/0 unit 6 description to-E set logical-systems B interfaces lt-1/2/0 unit 6 encapsulation frame-relay set logical-systems B interfaces lt-1/2/0 unit 6 dlci 6 set logical-systems B interfaces lt-1/2/0 unit 6 peer-unit 5 set logical-systems B interfaces lt-1/2/0 unit 6 family inet6 address fe80::a0a:a06/126 set logical-systems B protocols bgp group external-peers type external


991


set logical-systems B protocols bgp group external-peers peer-as 17 set logical-systems B protocols bgp group external-peers neighbor fe80::a0a:a05 local-interface lt-1/2/0.6 set logical-systems B routing-options autonomous-system 22 set logical-systems C interfaces lt-1/2/0 unit 10 description to-E set logical-systems C interfaces lt-1/2/0 unit 10 encapsulation frame-relay set logical-systems C interfaces lt-1/2/0 unit 10 dlci 10 set logical-systems C interfaces lt-1/2/0 unit 10 peer-unit 9 set logical-systems C interfaces lt-1/2/0 unit 10 family inet6 address fe80::a0a:a0a/126 set logical-systems C protocols bgp group external-peers type external set logical-systems C protocols bgp group external-peers peer-as 17 set logical-systems C protocols bgp group external-peers neighbor fe80::a0a:a09 local-interface lt-1/2/0.10 set logical-systems C routing-options autonomous-system 22 set logical-systems D interfaces lt-1/2/0 unit 7 description to-E set logical-systems D interfaces lt-1/2/0 unit 7 encapsulation frame-relay set logical-systems D interfaces lt-1/2/0 unit 7 dlci 7 set logical-systems D interfaces lt-1/2/0 unit 7 peer-unit 21 set logical-systems D interfaces lt-1/2/0 unit 7 family inet6 address fe80::a15:702/126 set logical-systems D protocols bgp group external-peers type external set logical-systems D protocols bgp group external-peers peer-as 17 set logical-systems D protocols bgp group external-peers neighbor fe80::a15:701 local-interface lt-1/2/0.7 set logical-systems D routing-options autonomous-system 79 set logical-systems E interfaces lt-1/2/0 unit 5 description to-B set logical-systems E interfaces lt-1/2/0 unit 5 encapsulation frame-relay set logical-systems E interfaces lt-1/2/0 unit 5 dlci 6 set logical-systems E interfaces lt-1/2/0 unit 5 peer-unit 6 set logical-systems E interfaces lt-1/2/0 unit 5 family inet6 address fe80::a0a:a05/126 set logical-systems E interfaces lt-1/2/0 unit 9 description to-C set logical-systems E interfaces lt-1/2/0 unit 9 encapsulation frame-relay set logical-systems E interfaces lt-1/2/0 unit 9 dlci 10 set logical-systems E interfaces lt-1/2/0 unit 9 peer-unit 10 set logical-systems E interfaces lt-1/2/0 unit 9 family inet6 address fe80::a0a:a09/126 set logical-systems E interfaces lt-1/2/0 unit 21 description to-D set logical-systems E interfaces lt-1/2/0 unit 21 encapsulation frame-relay set logical-systems E interfaces lt-1/2/0 unit 21 dlci 7 set logical-systems E interfaces lt-1/2/0 unit 21 peer-unit 7 set logical-systems E interfaces lt-1/2/0 unit 21 family inet6 address fe80::a15:701/126 set logical-systems E interfaces lt-1/2/0 unit 25 description to-A set logical-systems E interfaces lt-1/2/0 unit 25 encapsulation frame-relay set logical-systems E interfaces lt-1/2/0 unit 25 dlci 1 set logical-systems E interfaces lt-1/2/0 unit 25 peer-unit 1 set logical-systems E interfaces lt-1/2/0 unit 25 family inet6 address fe80::a0a:a01/126 set logical-systems E protocols bgp group external-peers type external set logical-systems E protocols bgp group external-peers peer-as 22 set logical-systems E protocols bgp group external-peers neighbor fe80::a0a:a02 local-interface lt-1/2/0.25 set logical-systems E protocols bgp group external-peers neighbor fe80::a0a:a06 local-interface lt-1/2/0.5 set logical-systems E protocols bgp group external-peers neighbor fe80::a0a:a0a local-interface lt-1/2/0.9 set logical-systems E protocols bgp group external-peers neighbor fe80::a15:702 local-interface lt-1/2/0.21

992



set logical-systems E protocols bgp group external-peers neighbor fe80::a15:702 peer-as 79 set logical-systems E routing-options autonomous-system 17


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure the BGP peer sessions: 1.

Run the show interfaces terse command to verify that the physical router has a logical tunnel (lt) interface. user@R1> show interfaces terse Interface ... lt-1/2/0 ...

2.

Admin Link Proto up

Local

Remote

up

On Logical System E, configure the interfaces to Peers A, B, C, and D. user@R1> set cli logical-system E Logical system: E [edit] user@R1:E> edit Entering configuration mode [edit] user@R1:E# edit interfaces [edit interfaces] user@R1:E# set lt-1/2/0 unit 5 description to-B user@R1:E# set lt-1/2/0 unit 5 encapsulation frame-relay user@R1:E# set lt-1/2/0 unit 5 dlci 6 user@R1:E# set lt-1/2/0 unit 5 peer-unit 6 user@R1:E# set lt-1/2/0 unit 5 family inet6 address fe80::a0a:a05/126 user@R1:E# set lt-1/2/0 unit 9 description to-C user@R1:E# set lt-1/2/0 unit 9 encapsulation frame-relay user@R1:E# set lt-1/2/0 unit 9 dlci 10 user@R1:E# set lt-1/2/0 unit 9 peer-unit 10 user@R1:E# set lt-1/2/0 unit 9 family inet6 address fe80::a0a:a09/126 user@R1:E# set lt-1/2/0 unit 21 description to-D user@R1:E# set lt-1/2/0 unit 21 encapsulation frame-relay user@R1:E# set lt-1/2/0 unit 21 dlci 7 user@R1:E# set lt-1/2/0 unit 21 peer-unit 7 user@R1:E# set lt-1/2/0 unit 21 family inet6 address fe80::a15:701/126 user@R1:E# set lt-1/2/0 unit 25 description to-A user@R1:E# set lt-1/2/0 unit 25 encapsulation frame-relay user@R1:E# set lt-1/2/0 unit 25 dlci 1 user@R1:E# set lt-1/2/0 unit 25 peer-unit 1 user@R1:E# set lt-1/2/0 unit 25 family inet6 address fe80::a0a:a01/126

3.

Set the autonomous system (AS) number. [edit routing-options] user@R1:E# set autonomous-system 17

4.

Create the BGP group, and add the external neighbor addresses.


993


When you configure IPv6 external BGP neighbor addresses, you must include the local-interface statement and specify the name of the local interface that connects to the neighbor. [edit protocols bgp group external-peers] user@R1:E# set neighbor fe80::a0a:a02 local-interface lt-1/2/0.25 user@R1:E# set neighbor fe80::a0a:a06 local-interface lt-1/2/0.5 user@R1:E# set neighbor fe80::a0a:a0a local-interface lt-1/2/0.9 user@R1:E# set neighbor fe80::a15:702 local-interface lt-1/2/0.21 5.

Specify the autonomous system (AS) number of the external AS. [edit protocols bgp group external-peers] user@R1:E# set peer-as 22

6.

Add Peer D, and set the AS number at the individual neighbor level. [edit protocols bgp group external-peers] user@R1:E# set neighbor fe80::a15:702 peer-as 79

7.

Set the peer type to EBGP. [edit protocols bgp group external-peers] user@R1:E# set type external

8.

Results

Repeat these steps for Peers A, B, C, and D.

From configuration mode, confirm your configuration by entering the show logical-systems command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. [edit] user@R1# show logical-systems A{ interfaces { lt-1/2/0 { unit 1 { description to-E; encapsulation frame-relay; dlci 1; peer-unit 25; family inet6 { address fe80::a0a:a02/126; } } } } protocols { bgp { group external-peers { type external; peer-as 17; neighbor fe80::a0a:a01 { local-interface lt-1/2/0.1; } } } }

994



routing-options { autonomous-system 22; } } B{ interfaces { lt-1/2/0 { unit 6 { description to-E; encapsulation frame-relay; dlci 6; peer-unit 5; family inet6 { address fe80::a0a:a06/126; } } } } protocols { bgp { group external-peers { type external; peer-as 17; neighbor fe80::a0a:a05 { local-interface lt-1/2/0.6; } } } } routing-options { autonomous-system 22; } } C{ interfaces { lt-1/2/0 { unit 10 { description to-E; encapsulation frame-relay; dlci 10; peer-unit 9; family inet6 { address fe80::a0a:a0a/126; } } } } protocols { bgp { group external-peers { type external; peer-as 17; neighbor fe80::a0a:a09 { local-interface lt-1/2/0.10; } }


995


} } routing-options { autonomous-system 22; } } D{ interfaces { lt-1/2/0 { unit 7 { description to-E; encapsulation frame-relay; dlci 7; peer-unit 21; family inet6 { address fe80::a15:702/126; } } } } protocols { bgp { group external-peers { type external; peer-as 17; neighbor fe80::a15:701 { local-interface lt-1/2/0.7; } } } } routing-options { autonomous-system 79; } } E{ interfaces { lt-1/2/0 { unit 5 { description to-B; encapsulation frame-relay; dlci 6; peer-unit 6; family inet6 { address fe80::a0a:a05/126; } } unit 9 { description to-C; encapsulation frame-relay; dlci 10; peer-unit 10; family inet6 { address fe80::a0a:a09/126; } }

996



unit 21 { description to-D; encapsulation frame-relay; dlci 7; peer-unit 7; family inet6 { address fe80::a15:701/126; } } unit 25 { description to-A; encapsulation frame-relay; dlci 1; peer-unit 1; family inet6 { address fe80::a0a:a01/126; } } } } protocols { bgp { group external-peers { type external; peer-as 22; neighbor fe80::a0a:a02 { local-interface lt-1/2/0.25; } neighbor fe80::a0a:a06 { local-interface lt-1/2/0.5; } neighbor fe80::a0a:a0a { local-interface lt-1/2/0.9; } neighbor fe80::a15:702 { local-interface lt-1/2/0.21; peer-as 79; } } } } routing-options { autonomous-system 17; } }



997




•


•



Action

Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address. From operational mode, run the show bgp neighbor command. user@R1:E> show bgp neighbor Peer: fe80::a0a:a02 AS 22 Local: fe80::a0a:a01 AS 17 Type: External State: Active Flags: Last State: Idle Last Event: Start Last Error: Open Message Error Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Error: 'Open Message Error' Sent: 48 Recv: 0 Local Interface: lt-1/2/0.25 Peer: fe80::a0a:a06 AS 22 Local: fe80::a0a:a05 AS 17 Type: External State: Active Flags: Last State: Idle Last Event: Start Last Error: Open Message Error Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Error: 'Open Message Error' Sent: 48 Recv: 0 Local Interface: lt-1/2/0.5 Peer: fe80::a0a:a0a AS 22 Local: fe80::a0a:a09 AS 17 Type: External State: Active Flags: Last State: Idle Last Event: Start Last Error: Open Message Error Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Error: 'Open Message Error' Sent: 48 Recv: 0 Local Interface: lt-1/2/0.9 Peer: fe80::a15:702 AS 79 Local: fe80::a15:701 AS 17 Type: External State: Active Flags: Last State: Idle Last Event: Start Last Error: Open Message Error Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Error: 'Open Message Error' Sent: 48 Recv: 0 Local Interface: lt-1/2/0.21

998




Verify that the BGP groups are configured correctly. From operational mode, run the show bgp group command. user@R1:E> show bgp group Group Type: External Name: external-peers Index: 0 Holdtime: 0 Total peers: 4 Established: 0 fe80::a0a:a02 fe80::a0a:a06 fe80::a0a:a0a fe80::a15:702 Groups: 1 Table inet6.0

Local AS: 17 Flags:



Verify that the BGP configuration is correct. From operational mode, run the show bgp summary command. user@R1:E> show bgp summary Groups: 1 Peers: 4 Down peers: 4 Table Tot Paths Act Paths Suppressed History Damp State Pending inet6.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... fe80::a0a:a02 22 0 98 0 0 1:52:40 Active fe80::a0a:a06 22 0 98 0 0 1:52:40 Active fe80::a0a:a0a 22 0 98 0 0 1:52:40 Active fe80::a15:702 79 0 98 0 0 1:52:40 Active


•

Examples: Configuring External BGP Peering on page 982

•

BGP Configuration Overview

Examples: Configuring Internal BGP Peering •


•

Example: Configuring Internal BGP Peer Sessions on page 1001

•

Example: Configuring Internal BGP Peering Sessions on Logical Systems on page 1012


999


Understanding BGP BGP is an exterior gateway protocol (EGP) that is used to exchange routing information among routers in different autonomous systems (ASs). BGP routing information includes the complete route to each destination. BGP uses the routing information to maintain a database of network reachability information, which it exchanges with other BGP systems. BGP uses the network reachability information to construct a graph of AS connectivity, which enables BGP to remove routing loops and enforce policy decisions at the AS level. Multiprotocol BGP (MBGP) extensions enable BGP to support IP version 6 (IPv6). MBGP defines the attributes MP_REACH_NLRI and MP_UNREACH_NLRI, which are used to carry IPv6 reachability information. Network layer reachability information (NLRI) update messages carry IPv6 address prefixes of feasible routes. BGP allows for policy-based routing. You can use routing policies to choose among multiple paths to a destination and to control the redistribution of routing information. BGP uses TCP as its transport protocol, using port 179 for establishing connections. Running over a reliable transport protocol eliminates the need for BGP to implement update fragmentation, retransmission, acknowledgment, and sequencing. The Junos OS routing protocol software supports BGP version 4. This version of BGP adds support for Classless Interdomain Routing (CIDR), which eliminates the concept of network classes. Instead of assuming which bits of an address represent the network by looking at the first octet, CIDR allows you to explicitly specify the number of bits in the network address, thus providing a means to decrease the size of the routing tables. BGP version 4 also supports aggregation of routes, including the aggregation of AS paths. This section discusses the following topics: •

Autonomous Systems on page 1000

•

AS Paths and Attributes on page 1000

•

External and Internal BGP on page 1001

Autonomous Systems An autonomous system (AS) is a set of routers that are under a single technical administration and normally use a single interior gateway protocol and a common set of metrics to propagate routing information within the set of routers. To other ASs, an AS appears to have a single, coherent interior routing plan and presents a consistent picture of what destinations are reachable through it.

AS Paths and Attributes The routing information that BGP systems exchange includes the complete route to each destination, as well as additional information about the route. The route to each destination is called the AS path, and the additional route information is included in path attributes. BGP uses the AS path and the path attributes to completely determine the network topology. Once BGP understands the topology, it can detect and eliminate routing loops and select among groups of routes to enforce administrative preferences and routing policy decisions.

1000



External and Internal BGP BGP supports two types of exchanges of routing information: exchanges among different ASs and exchanges within a single AS. When used among ASs, BGP is called external BGP (EBGP) and BGP sessions perform inter-AS routing. When used within an AS, BGP is called internal BGP (IBGP) and BGP sessions perform intra-AS routing. Figure 37 on page 977 illustrates ASs, IBGP, and EBGP.

Figure 41: ASs, EBGP, and IBGP

A BGP system shares network reachability information with adjacent BGP systems, which are referred to as neighbors or peers. BGP systems are arranged into groups. In an IBGP group, all peers in the group—called internal peers—are in the same AS. Internal peers can be anywhere in the local AS and do not have to be directly connected to one another. Internal groups use routes from an IGP to resolve forwarding addresses. They also propagate external routes among all other internal routers running IBGP, computing the next hop by taking the BGP next hop received with the route and resolving it using information from one of the interior gateway protocols. In an EBGP group, the peers in the group—called external peers—are in different ASs and normally share a subnet. In an external group, the next hop is computed with respect to the interface that is shared between the external peer and the local router.

Example: Configuring Internal BGP Peer Sessions This example shows how to configure internal BGP peer sessions. •


•


•


•



1001


Requirements No special configuration beyond device initialization is required before you configure this example.

Overview In this example, you configure internal BGP (IBGP) peer sessions. The loopback interface (lo0) is used to establish connections between IBGP peers. The loopback interface is always up as long as the device is operating. If there is a route to the loopback address, the IBGP peer session stays up. If a physical interface address is used instead and that interface goes up and down, the IBGP peer session also goes up and down. Thus, if the device has link redundancy, the loopback interface provides fault tolerance in case the physical interface or one of the links goes down. When a device peers with a remote device’s loopback interface address, the local device expects BGP update messages to come from (be sourced by) the remote device’s loopback interface address. The local-address statement enables you to specify the source information in BGP update messages. If you omit the local-address statement, the expected source of BGP update messages is based on the device’s source address selection rules, which normally results in the egress interface address being the expected source of update messages. When this happens, the peer session is not established because a mismatch exists between the expected source address (the egress interface of the peer) and the actual source (the loopback interface of the peer). To make sure that the expected source address matches the actual source address, specify the loopback interface address in the local-address statement. Because IBGP supports multihop connections, IBGP neighbors can be located anywhere within the autonomous system (AS) and often do not share a link. A recursive route lookup resolves the loopback peer address to an IP forwarding next hop. In this example, this service is provided by OSPF. Although interior gateway protocol (IGP) neighbors do not need to be directly connected, they do need to be fully meshed. In this case, fully meshed means that each device is logically connected to every other device through neighbor peer relationships. The neighbor statement creates the mesh.

NOTE: The requirement for a full mesh is waived if you configure a confederation or route reflection.

After the BGP peers are established, BGP routes are not automatically advertised by the BGP peers. At each BGP-enabled device, policy configuration is required to export the local, static, or IGP-learned routes into the BGP routing information base (RIB) and then advertise them as BGP routes to the other peers. BGP's advertisement policy, by default, does not advertise any non-BGP routes (such as local routes) to peers. In the sample network, the devices in AS 17 are fully meshed in the group internal-peers. The devices have loopback addresses 192.168.6.5, 192.163.6.4, and 192.168.40.4. Figure 42 on page 1003 shows a typical network with internal peer sessions.

1002



Figure 42: Typical Network with IBGP Sessions

192.168.6.5 AS 17

A

192.163.6.4 C

B

g040732

192.168.40.4

Configuration


•

Configuring Device A on page 1004

•

Configuring Device B on page 1006

•

Configuring Device C on page 1008


Device A

set interfaces ge-0/1/0 unit 1 description to-B set interfaces ge-0/1/0 unit 1 family inet address 10.10.10.1/30 set interfaces lo0 unit 1 family inet address 192.168.6.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers description “connections to B and C” set protocols bgp group internal-peers local-address 192.168.6.5 set protocols bgp group internal-peers export send-direct set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.40.4 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface ge-0/1/0.1 set policy-options policy-statement send-direct term 2 from protocol direct set policy-options policy-statement send-direct term 2 then accept set routing-options router-id 192.168.6.5 set routing-options autonomous-system 17

Device B

set interfaces ge-0/1/0 unit 2 description to-A set interfaces ge-0/1/0 unit 2 family inet address 10.10.10.2/30 set interfaces ge-0/1/1 unit 5 description to-C set interfaces ge-0/1/1 unit 5 family inet address 10.10.10.5/30 set interfaces lo0 unit 2 family inet address 192.163.6.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers description “connections to A and C” set protocols bgp group internal-peers local-address 192.163.6.4 set protocols bgp group internal-peers export send-direct set protocols bgp group internal-peers neighbor 192.168.40.4 set protocols bgp group internal-peers neighbor 192.168.6.5


1003


set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface ge-0/1/0.2 set protocols ospf area 0.0.0.0 interface ge-0/1/1.5 set policy-options policy-statement send-direct term 2 from protocol direct set policy-options policy-statement send-direct term 2 then accept set routing-options router-id 192.163.6.4 set routing-options autonomous-system 17

Device C

set interfaces ge-0/1/0 unit 6 description to-B set interfaces ge-0/1/0 unit 6 family inet address 10.10.10.6/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers description “connections to A and B” set protocols bgp group internal-peers local-address 192.168.40.4 set protocols bgp group internal-peers export send-direct set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface ge-0/1/0.6 set policy-options policy-statement send-direct term 2 from protocol direct set policy-options policy-statement send-direct term 2 then accept set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17

Configuring Device A Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure internal BGP peer sessions on Device A: 1.

Configure the interfaces. [edit interfaces ge-0/1/0 unit 1] user@A# set description to-B user@A# set family inet address 10.10.10.1/30 [edit interfaces] user@A# set lo0 unit 1 family inet address 192.168.6.5/32

2.

Configure BGP. The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C. [edit protocols bgp group internal-peers] user@A# set type internal user@A# set description “connections to B and C” user@A# set local-address 192.168.6.5 user@A# set export send-direct user@A# set neighbor 192.163.6.4 user@A# set neighbor 192.168.40.4

3.

Configure OSPF. [edit protocols ospf area 0.0.0.0]

1004



user@A# set interface lo0.1 passive user@A# set interface ge-0/1/0.1 4.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit policy-options policy-statement send-direct term 2] user@A# set from protocol direct user@A# set then accept

5.

Configure the router ID and the AS number. [edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@A# show interfaces ge-0/1/0 { unit 1 { description to-B; family inet { address 10.10.10.1/30; } } } lo0 { unit 1 { family inet { address 192.168.6.5/32; } } } user@A# show policy-options policy-statement send-direct { term 2 { from protocol direct; then accept; } } user@A# show protocols bgp { group internal-peers { type internal; description “connections to B and C”; local-address 192.168.6.5; export send-direct; neighbor 192.163.6.4; neighbor 192.168.40.4;


1005


} } ospf { area 0.0.0.0 { interface lo0.1 { passive; } interface ge-0/1/0.1; } } user@A# show routing-options router-id 192.168.6.5; autonomous-system 17;

If you are done configuring the device, enter commit from configuration mode. Configuring Device B Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode. To configure internal BGP peer sessions on Device B: 1.

Configure the interfaces. [edit interfaces ge-0/1/0 unit 2] user@B# set description to-A user@B# set family inet address 10.10.10.2/30 [edit interfaces ge-0/1/1] user@B# set unit 5 description to-C user@B# set unit 5 family inet address 10.10.10.5/30 [edit interfaces] user@B# set lo0 unit 2 family inet address 192.163.6.4/32

2.

Configure BGP. The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C. [edit protocols bgp group internal-peers] user@B# set type internal user@B# set description “connections to A and C” user@B# set local-address 192.163.6.4 user@B# set export send-direct user@B# set neighbor 192.168.40.4 user@B# set neighbor 192.168.6.5

3.

Configure OSPF. [edit protocols ospf area 0.0.0.0] user@B# set interface lo0.2 passive user@B# set interface ge-0/1/0.2 user@B# set interface ge-0/1/1.5

1006



4.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit policy-options policy-statement send-direct term 2] user@B# set from protocol direct user@B# set then accept

5.

Configure the router ID and the AS number. [edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@B# show interfaces ge-0/1/0 { unit 2 { description to-A; family inet { address 10.10.10.2/30; } } } ge-0/1/1 { unit 5 { description to-C; family inet { address 10.10.10.5/30; } } } lo0 { unit 2 { family inet { address 192.163.6.4/32; } } } user@B# show policy-options policy-statement send-direct { term 2 { from protocol direct; then accept; } } user@B# show protocols bgp { group internal-peers { type internal;


1007


description “connections to A and C”; local-address 192.163.6.4; export send-direct; neighbor 192.168.40.4; neighbor 192.168.6.5; } } ospf { area 0.0.0.0 { interface lo0.2 { passive; } interface ge-0/1/0.2; interface ge-0/1/1.5; } } user@B# show routing-options router-id 192.163.6.4; autonomous-system 17;

If you are done configuring the device, enter commit from configuration mode. Configuring Device C Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure internal BGP peer sessions on Device C: 1.

Configure the interfaces. [edit interfaces ge-0/1/0 unit 6] user@C# set description to-B user@C# set family inet address 10.10.10.6/30 [edit interfaces] user@C# set lo0 unit 3 family inet address 192.168.40.4/32

2.

Configure BGP. The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C. [edit protocols bgp group internal-peers] user@C# set type internal user@C# set description “connections to A and B” user@C# set local-address 192.168.40.4 user@C# set export send-direct user@C# set neighbor 192.163.6.4 user@C# set neighbor 192.168.6.5

3.

Configure OSPF. [edit protocols ospf area 0.0.0.0] user@C# set interface lo0.3 passive user@C# set interface ge-0/1/0.6

1008



4.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit policy-options policy-statement send-direct term 2] user@C# set from protocol direct user@C# set then accept

5.

Configure the router ID and the AS number. [edit routing-options] user@C# set router-id 192.168.40.4 user@C# set autonomous-system 17

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@C# show interfaces ge-0/1/0 { unit 6 { description to-B; family inet { address 10.10.10.6/30; } } } lo0 { unit 3 { family inet { address 192.168.40.4/32; } } } user@C# show policy-options policy-statement send-direct { term 2 { from protocol direct; then accept; } } user@C# show protocols bgp { group internal-peers { type internal; description “connections to A and B”; local-address 192.168.40.4; export send-direct; neighbor 192.163.6.4; neighbor 192.168.6.5; } } ospf {


1009


area 0.0.0.0 { interface lo0.3 { passive; } interface ge-0/1/0.6; } } user@C# show routing-options router-id 192.168.40.4; autonomous-system 17;




•


•


•

Verifying That BGP Routes Are Installed in the Routing Table on page 1012


Action

Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address. From operational mode, enter the show bgp neighbor command. user@A> show bgp neighbor Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+58852 AS 17 Type: Internal State: Established Flags: Sync Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct ] Options: Preference LocalAddress Refresh Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete

1010



Send state: in sync Active prefixes: 0 Received prefixes: 3 Accepted prefixes: 3 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 25 Sent 19 Checked 67 Input messages: Total 2420 Updates 4 Refreshes 0 Output messages: Total 2411 Updates 2 Refreshes 0 Output Queue[0]: 0


Peer: 192.168.40.4+179 AS 17 Local: 192.168.6.5+56466 AS 17 Type: Internal State: Established Flags: Sync Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct ] Options: Preference LocalAddress Refresh Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 2 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 7 Sent 21 Checked 24 Input messages: Total 2412 Updates 2 Refreshes 0 Octets 45867 Output messages: Total 2409 Updates 2 Refreshes 0 Octets 45883 Output Queue[0]: 0


Verify that the BGP groups are configured correctly. From operational mode, enter the show bgp group command. user@A> show bgp group Group Type: Internal Name: internal-peers Export: [ send-direct Holdtime: 0 Total peers: 2 192.163.6.4+179


AS: 17 Index: 0 ]

Local AS: 17 Flags:

Established: 2

1011


192.168.40.4+179 inet.0: 0/5/5/0 Groups: 1 Table inet.0



Verify that the BGP configuration is correct. From operational mode, enter the show bgp summary command. user@A> show bgp summary Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 5 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2441 2432 0 0 18:18:52 0/3/3/0 0/0/0/0 192.168.40.4 17 2432 2430 0 0 18:18:48 0/2/2/0 0/0/0/0

Verifying That BGP Routes Are Installed in the Routing Table Purpose

Action

Verify that the export policy configuration is causing the BGP routes to be installed in the routing tables of the peers. From operational mode, enter the show route protocol bgp command. user@A> show route protocol bgp inet.0: 7 destinations, 12 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/30

10.10.10.4/30

192.163.6.4/32

192.168.40.4/32

[BGP/170] 07:09:57, AS path: I > to 10.10.10.2 via [BGP/170] 07:09:57, AS path: I > to 10.10.10.2 via [BGP/170] 07:07:12, AS path: I > to 10.10.10.2 via [BGP/170] 07:09:57, AS path: I > to 10.10.10.2 via [BGP/170] 07:07:12, AS path: I > to 10.10.10.2 via

localpref 100, from 192.163.6.4 ge-0/1/0.1 localpref 100, from 192.163.6.4 ge-0/1/0.1 localpref 100, from 192.168.40.4 ge-0/1/0.1 localpref 100, from 192.163.6.4 ge-0/1/0.1 localpref 100, from 192.168.40.4 ge-0/1/0.1

Example: Configuring Internal BGP Peering Sessions on Logical Systems This example shows how to configure internal BGP peer sessions on logical systems.

1012

•


•




•


•


Requirements In this example, no special configuration beyond device initialization is required.

Overview In this example, you configure internal BGP (IBGP) peering sessions. In the sample network, the devices in AS 17 are fully meshed in the group internal-peers. The devices have loopback addresses 192.168.6.5, 192.163.6.4, and 192.168.40.4. Figure 42 on page 1003 shows a typical network with internal peer sessions.


192.168.6.5 AS 17

A

192.163.6.4 C

B

g040731

192.168.40.4


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems A interfaces lt-0/1/0 unit 1 description to-B set logical-systems A interfaces lt-0/1/0 unit 1 encapsulation ethernet set logical-systems A interfaces lt-0/1/0 unit 1 peer-unit 2 set logical-systems A interfaces lt-0/1/0 unit 1 family inet address 10.10.10.1/30 set logical-systems A interfaces lo0 unit 1 family inet address 192.168.6.5/32 set logical-systems A protocols bgp group internal-peers type internal set logical-systems A protocols bgp group internal-peers local-address 192.168.6.5 set logical-systems A protocols bgp group internal-peers export send-direct set logical-systems A protocols bgp group internal-peers neighbor 192.163.6.4 set logical-systems A protocols bgp group internal-peers neighbor 192.168.40.4 set logical-systems A protocols ospf area 0.0.0.0 interface lo0.1 passive set logical-systems A protocols ospf area 0.0.0.0 interface lt-0/1/0.1 set logical-systems A policy-options policy-statement send-direct term 2 from protocol direct set logical-systems A policy-options policy-statement send-direct term 2 then accept


1013


set logical-systems A routing-options router-id 192.168.6.5 set logical-systems A routing-options autonomous-system 17 set logical-systems B interfaces lt-0/1/0 unit 2 description to-A set logical-systems B interfaces lt-0/1/0 unit 2 encapsulation ethernet set logical-systems B interfaces lt-0/1/0 unit 2 peer-unit 1 set logical-systems B interfaces lt-0/1/0 unit 2 family inet address 10.10.10.2/30 set logical-systems B interfaces lt-0/1/0 unit 5 description to-C set logical-systems B interfaces lt-0/1/0 unit 5 encapsulation ethernet set logical-systems B interfaces lt-0/1/0 unit 5 peer-unit 6 set logical-systems B interfaces lt-0/1/0 unit 5 family inet address 10.10.10.5/30 set logical-systems B interfaces lo0 unit 2 family inet address 192.163.6.4/32 set logical-systems B protocols bgp group internal-peers type internal set logical-systems B protocols bgp group internal-peers local-address 192.163.6.4 set logical-systems B protocols bgp group internal-peers export send-direct set logical-systems B protocols bgp group internal-peers neighbor 192.168.40.4 set logical-systems B protocols bgp group internal-peers neighbor 192.168.6.5 set logical-systems B protocols ospf area 0.0.0.0 interface lo0.2 passive set logical-systems B protocols ospf area 0.0.0.0 interface lt-0/1/0.2 set logical-systems B protocols ospf area 0.0.0.0 interface lt-0/1/0.5 set logical-systems B policy-options policy-statement send-direct term 2 from protocol direct set logical-systems B policy-options policy-statement send-direct term 2 then accept set logical-systems B routing-options router-id 192.163.6.4 set logical-systems B routing-options autonomous-system 17 set logical-systems C interfaces lt-0/1/0 unit 6 description to-B set logical-systems C interfaces lt-0/1/0 unit 6 encapsulation ethernet set logical-systems C interfaces lt-0/1/0 unit 6 peer-unit 5 set logical-systems C interfaces lt-0/1/0 unit 6 family inet address 10.10.10.6/30 set logical-systems C interfaces lo0 unit 3 family inet address 192.168.40.4/32 set logical-systems C protocols bgp group internal-peers type internal set logical-systems C protocols bgp group internal-peers local-address 192.168.40.4 set logical-systems C protocols bgp group internal-peers export send-direct set logical-systems C protocols bgp group internal-peers neighbor 192.163.6.4 set logical-systems C protocols bgp group internal-peers neighbor 192.168.6.5 set logical-systems C protocols ospf area 0.0.0.0 interface lo0.3 passive set logical-systems C protocols ospf area 0.0.0.0 interface lt-0/1/0.6 set logical-systems C policy-options policy-statement send-direct term 2 from protocol direct set logical-systems C policy-options policy-statement send-direct term 2 then accept set logical-systems C routing-options router-id 192.168.40.4 set logical-systems C routing-options autonomous-system 17

Device A Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure internal BGP peer sessions on Device A: 1.

Configure the interfaces. [edit logical-systems A interfaces lt-0/1/0 unit 1] user@R1# set description to-B user@R1# set encapsulation ethernet user@R1# set peer-unit 2

1014



user@R1# set family inet address 10.10.10.1/30 user@R1# set family inet address 192.168.6.5/32 user@R1# up user@R1# up [edit logical-systems A interfaces] user@R1# set lo0 unit 1 family inet address 192.168.6.5/32 user@R1# exit [edit] user@R1# edit logical-systems B interfaces lt-0/1/0 [edit logical-systems B interfaces lt-0/1/0] user@R1# set unit 2 description to-A user@R1# set unit 2 encapsulation ethernet user@R1# set unit 2 peer-unit 1 user@R1# set unit 2 family inet address 10.10.10.2/30 user@R1# set unit 5 description to-C user@R1# set unit 5 encapsulation ethernet user@R1# set unit 5 peer-unit 6 user@R1# set family inet address 10.10.10.5/30 user@R1# up [edit logical-systems B interfaces] user@R1# set lo0 unit 2 family inet address 192.163.6.4/32 user@R1# exit [edit] user@R1# edit logical-systems C interfaces lt-0/1/0 unit 6 [edit logical-systems C interfaces lt-0/1/0 unit 6] set description to-B set encapsulation ethernet set peer-unit 5 set family inet address 10.10.10.6/30 user@R1# up user@R1# up [edit logical-systems C interfaces] set lo0 unit 3 family inet address 192.168.40.4/32 2.

Configure BGP. On Logical System A, the neighbor statements are included for both Device B and Device C, even though Logical System A is not directly connected to Device C. [edit logical-systems A protocols bgp group internal-peers] user@R1# set type internal user@R1# set local-address 192.168.6.5 user@R1# set export send-direct user@R1# set neighbor 192.163.6.4 user@R1# set neighbor 192.168.40.4 [edit logical-systems B protocols bgp group internal-peers] user@R1# set type internal user@R1# set local-address 192.163.6.4 user@R1# set export send-direct user@R1# set neighbor 192.168.40.4 user@R1# set neighbor 192.168.6.5 [edit logical-systems C protocols bgp group internal-peers] user@R1# set type internal user@R1# set local-address 192.168.40.4


1015


user@R1# set export send-direct user@R1# set neighbor 192.163.6.4 user@R1# set neighbor 192.168.6.5 3.

Configure OSPF. [edit logical-systems A protocols ospf area 0.0.0.0] user@R1# set interface lo0.1 passive user@R1# set interface lt-0/1/0.1 [edit logical-systems A protocols ospf area 0.0.0.0] user@R1# set interface lo0.2 passive user@R1# set interface lt-0/1/0.2 user@R1# set interface lt-0/1/0.5 [edit logical-systems A protocols ospf area 0.0.0.0] user@R1# set interface lo0.3 passive user@R1# set interface lt-0/1/0.6

4.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit logical-systems A policy-options policy-statement send-direct term 2] user@R1# set from protocol direct user@R1# set then accept [edit logical-systems B policy-options policy-statement send-direct term 2] user@R1# set from protocol direct user@R1# set then accept [edit logical-systems C policy-options policy-statement send-direct term 2] user@R1# set from protocol direct user@R1# set then accept

5.

Configure the router ID and the autonomous system (AS) number. [edit logical-systems A routing-options] user@R1# set router-id 192.168.6.5 user@R1# set autonomous-system 17 [edit logical-systems B routing-options] user@R1# set router-id 192.163.6.4 user@R1# set autonomous-system 17 [edit logical-systems C routing-options] user@R1# set router-id 192.168.40.4 user@R1# set autonomous-system 17

Results

From configuration mode, confirm your configuration by entering the show logical-systems command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it. user@R1# show logical-systems

1016



A{ interfaces { lt-0/1/0 { unit 1 { description to-B; encapsulation ethernet; peer-unit 2; family inet { address 10.10.10.1/30; } } } lo0 { unit 1 { family inet { address 192.168.6.5/32; } } } } protocols { bgp { group internal-peers { type internal; local-address 192.168.6.5; export send-direct; neighbor 192.163.6.4; neighbor 192.168.40.4; } } ospf { area 0.0.0.0 { interface lo0.1 { passive; } interface lt-0/1/0.1; } } } policy-options { policy-statement send-direct { term 2 { from protocol direct; then accept; } } } routing-options { router-id 192.168.6.5; autonomous-system 17; } } B{ interfaces { lt-0/1/0 { unit 2 {


1017


description to-A; encapsulation ethernet; peer-unit 1; family inet { address 10.10.10.2/30; } } unit 5 { description to-C; encapsulation ethernet; peer-unit 6; family inet { address 10.10.10.5/30; } } } lo0 { unit 2 { family inet { address 192.163.6.4/32; } } } } protocols { bgp { group internal-peers { type internal; local-address 192.163.6.4; export send-direct; neighbor 192.168.40.4; neighbor 192.168.6.5; } } ospf { area 0.0.0.0 { interface lo0.2 { passive; } interface lt-0/1/0.2; interface lt-0/1/0.5; } } } policy-options { policy-statement send-direct { term 2 { from protocol direct; then accept; } } } routing-options { router-id 192.163.6.4; autonomous-system 17; }

1018



} C{ interfaces { lt-0/1/0 { unit 6 { description to-B; encapsulation ethernet; peer-unit 5; family inet { address 10.10.10.6/30; } } } lo0 { unit 3 { family inet { address 192.168.40.4/32; } } } } protocols { bgp { group internal-peers { type internal; local-address 192.168.40.4; export send-direct; neighbor 192.163.6.4; neighbor 192.168.6.5; } } ospf { area 0.0.0.0 { interface lo0.3 { passive; } interface lt-0/1/0.6; } } } policy-options { policy-statement send-direct { term 2 { from protocol direct; then accept; } } } routing-options { router-id 192.168.40.4; autonomous-system 17; } }



1019




•


•


•

Verifying That BGP Routes Are Installed in the Routing Table on page 1022


Action

Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address. From the operational mode, enter the show bgp neighbor command. user@R1> show bgp neighbor logical-system A Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+58852 AS 17 Type: Internal State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct ] Options: Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 3 Accepted prefixes: 3 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 16 Sent 1 Checked 63 Input messages: Total 15713 Updates 4 Refreshes 0 Octets 298622 Output messages: Total 15690 Updates 2 Refreshes 0 Octets 298222 Output Queue[0]: 0 Peer: 192.168.40.4+179 AS 17 Local: 192.168.6.5+56466 AS 17 Type: Internal State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None

1020



Export: [ send-direct ] Options: Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 2 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 15 Sent 22 Checked 68 Input messages: Total 15688 Updates 2 Refreshes 0 Octets 298111 Output messages: Total 15688 Updates 2 Refreshes 0 Octets 298184 Output Queue[0]: 0


Verify that the BGP groups are configured correctly. From the operational mode, enter the show bgp group command. user@A> show bgp group logical-system A Group Type: Internal AS: 17 Name: internal-peers Index: 0 Export: [ send-direct ] Holdtime: 0 Total peers: 2 Established: 2 192.163.6.4+179 192.168.40.4+179 inet.0: 0/5/5/0 Groups: 1 Table inet.0

Local AS: 17 Flags:



Verify that the BGP configuration is correct. From the operational mode, enter the show bgp summary command. user@A> show bgp summary logical-system A


1021


Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 5 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 15723 15700 0 0 4d 22:13:15 0/3/3/0 0/0/0/0 192.168.40.4 17 15698 15699 0 0 4d 22:13:11 0/2/2/0 0/0/0/0

Verifying That BGP Routes Are Installed in the Routing Table Purpose Action

Verify that the export policy configuration is working. From the operational mode, enter the show route protocol bgp command. user@A> show route protocol bgp logical-system A inet.0: 7 destinations, 12 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/30

10.10.10.4/30

192.163.6.4/32

192.168.40.4/32

[BGP/170] 4d 11:05:55, localpref AS path: I > to 10.10.10.2 via lt-0/1/0.1 [BGP/170] 4d 11:05:55, localpref AS path: I > to 10.10.10.2 via lt-0/1/0.1 [BGP/170] 4d 11:03:10, localpref AS path: I > to 10.10.10.2 via lt-0/1/0.1 [BGP/170] 4d 11:05:55, localpref AS path: I > to 10.10.10.2 via lt-0/1/0.1 [BGP/170] 4d 11:03:10, localpref AS path: I > to 10.10.10.2 via lt-0/1/0.1

100, from 192.163.6.4

100, from 192.163.6.4

100, from 192.168.40.4

100, from 192.163.6.4

100, from 192.168.40.4

Example: Preventing BGP Session Resets •

Understanding BGP Session Resets on page 1022

•

Example: Preventing BGP Session Flaps When VPN Families Are Configured on page 1023

Understanding BGP Session Resets Certain configuration actions and events cause BGP sessions to be reset (dropped and then reestablished).

1022



If you configure both route reflection and VPNs on the same routing device, the following modifications to the route reflection configuration cause current BGP sessions to be reset: •

Adding a cluster ID—If a BGP session shares the same autonomous system (AS) number with the group where you add the cluster ID, all BGP sessions are reset regardless of whether the BGP sessions are contained in the same group.

•

Creating a new route reflector—If you have an internal BGP (IBGP) group with an AS number and create a new route reflector group with the same AS number, all BGP sessions in the IBGP group and the new route reflector group are reset.

•

Changing configuration statements that affect BGP peers, such as renaming a BGP group, resets the BGP sessions.

•

If you change the address family specified in the [edit protocols bgp family] hierarchy level, all current BGP sessions on the routing device are dropped and then reestablished.

Example: Preventing BGP Session Flaps When VPN Families Are Configured This example shows a workaround for a known issue in which BGP sessions sometimes go down and then come back up (in other words, flap) when virtual private network (VPN) families are configured. If any VPN family (for example, inet-vpn, inet6-vpn, inet-mpvn, inet-mdt, inet6-mpvn, l2vpn, iso-vpn, and so on) is configured on a BGP master instance, a flap of either a route reflector (RR) internal BGP (IBGP) session or an external BGP (EBGP) session causes flaps of other BGP sessions configured with the same VPN family. •


•


•


•



Configure router interfaces.

•

Configure an interior gateway protocol (IGP).

•

Configure BGP.

•

Configure VPNs.


1023


Overview When a router or switch is configured as either a route reflector (RR) or an AS boundary router (an external BGP peer) and a VPN family (for example, the family inet-vpn unicast statement) is configured, a flap of either the RR IBGP session or the EBGP session causes flaps of all other BGP sessions that are configured with the family inet-vpn unicast statement. This example shows how to prevent these unnecessary session flaps. The reason for the flapping behavior is related to BGP operation in Junos OS when originating VPN routes. BGP has the following two modes of operation with respect to originating VPN routes: •

If BGP does not need to propagate VPN routes because the session has no EBGP peer and no RR clients, BGP exports VPN routes directly from the instance.inet.0 routing table to other PE routers. This behavior is efficient in that it avoids the creation of two copies of many routes (one in the instance.inet.0 table and one in the bgp.l3vpn.0 table).

•

If BGP does need to propagate VPN routes because the session has an EBGP peer or RR clients, BGP first exports the VPN routes from the instance.inet.0 table to the bgp.l3vpn.0 table. Then BGP exports the routes to other PE routers. In this scenario, two copies of the route are needed to enable best-route selection. A PE router might receive the same VPN route from a CE device and also from an RR client or EBGP peer.

When, because of a configuration change, BGP transitions from needing two copies of a route to not needing two copies of a route (or the reverse), all sessions over which VPN routes are exchanged go down and then come back up. Although this example focuses on the family inet-vpn unicast statement, the concept applies to all VPN network layer reachability information (NLRI) families. This issue impacts logical systems as well. All BGP sessions in the master instance related to the VPN NLRI family are brought down to implement the table advertisement change for the VPN NLRI family. Changing an RR to a non-RR or the reverse (by adding or removing the cluster statement) causes the table advertisement change. Also, configuring the first EBGP session or removing the EBGP session from the configuration in the master instance for a VPN NLRI family causes the table advertisement change. The way to prevent these unnecessary session flaps is to configure an extra RR client or EBGP session as a passive session with a neighbor address that does not exist. This example focuses on the EBGP case, but the same workaround works for the RR case. When a session is passive, the routing device does not send Open requests to a peer. Once you configure the routing device to be passive, the routing device does not originate the TCP connection. However, when the routing device receives a connection from the peer and an Open message, it replies with another BGP Open message. Each routing device declares its own capabilities. Figure 44 on page 1025 shows the topology for the EBGP case. Router R1 has an IBGP session with Routers R2 and R3 and an EBGP session with Router R4. All sessions have the family inet-vpn unicast statement configured. If the R1-R4 EBGP session flaps, the R1-R2 and R1-R3 BGP sessions flap also.

1024



Figure 44: Topology for the EBGP Case

IBGP

R1

EBGP

R3

R2

g040893

IBGP

R4

Figure 45 on page 1025 shows the topology for the RR case. Router R1 is the RR, and Router R3 is the client. Router R1 has IBGP sessions with Routers R2 and R3. All sessions have the family inet-vpn unicast statement configured. If the R1-R3 session flaps, the R1-R2 and R1-R4 sessions flap also.

Figure 45: Topology for the RR Case R3 Route Reflector Client

R1

IBGP

R2

IBGP

R4

g040894

Route Reflector


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set protocols bgp family inet-vpn unicast set protocols bgp family l2vpn signaling set protocols bgp group R1-R4 type external set protocols bgp group R1-R4 local-address 4.4.4.2 set protocols bgp group R1-R4 neighbor 4.4.4.1 peer-as 200 set protocols bgp group R1-R2-R3 type internal set protocols bgp group R1-R2-R3 log-updown set protocols bgp group R1-R2-R3 local-address 15.15.15.15 set protocols bgp group R1-R2-R3 neighbor 12.12.12.12 set protocols bgp group R1-R2-R3 neighbor 13.13.13.13


1025


set protocols bgp group Fake type external set protocols bgp group Fake passive set protocols bgp group Fake neighbor 100.100.100.100 peer-as 500


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure the EBGP scenario: 1.

Configure one or more VPN families. [edit protocols bgp] user@R1# set family inet-vpn unicast user@R1# set family l2vpn signaling

2.

Configure the EBGP session. [edit protocols bgp] user@R1# set group R1-R4 type external user@R1# set group R1-R4 local-address 4.4.4.2 user@R1# set group R1-R4 neighbor 4.4.4.1 peer-as 200

3.

Configure the IBGP sessions. [edit protocols bgp] user@R1# set group R1-R2-R3 type internal user@R1# set group R1-R2-R3 local-address 15.15.15.15 user@R1# set group R1-R2-R3 neighbor 12.12.12.12 user@R1# set group R1-R2-R3 neighbor 13.13.13.13

4.

(Optional) Configure BGP so that it generates a syslog message whenever a BGP peer makes a state transition. [edit protocols bgp] user@R1# set group R1-R2-R3 log-updown

Enabling the log-updown statement causes BGP state transitions to be logged at warning level. Step-by-Step Procedure

To verify that unnecessary session flaps are occurring: 1.

Run the show bgp summary command to verify that the sessions have been established. user@R1> show bgp summary Groups: 2 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 4.4.4.1 200 6 5 0 0 1:08 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 12.12.12.12 100 3 7 0 0 1:18 Establ bgp.l3vpn.0: 0/0/0/0

1026



bgp.l2vpn.0: 0/0/0/0 13.13.13.13 100 3 bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 2.

6

0

0

1:14 Establ

Deactivate the EBGP session. user@R1# deactivate group R1-R4 user@R1# commit

Mar 10 18:27:40 R1: rpd[1464]: bgp_peer_delete:6589: NOTIFICATION sent to 4.4.4.1 (External AS 200): code 6 (Cease) subcode 3 (Peer Unconfigured), Reason: Peer Deletion Mar 10 18:27:40 R1: rpd[1464]: bgp_adv_main_update:7253: NOTIFICATION sent to 12.12.12.12 (Internal AS 100): code 6 (Cease) subcode 6 (Other Configuration Change), Reason: Configuration change - VPN table advertise Mar 10 18:27:40 R1: rpd[1464]: bgp_adv_main_update:7253: NOTIFICATION sent to 13.13.13.13 (Internal AS 100): code 6 (Cease) subcode 6 (Other Configuration Change), Reason: Configuration change - VPN table advertise 3.

Run the show bgp summary command to view the session flaps. user@R1> show bgp summary Groups: 1 Peers: 2 Down peers: 2 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 12.12.12.12 100 4 9 0 1 19 Active 13.13.13.13 100 4 8 0 1 19 Active user@R1> show bgp summary Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 12.12.12.12 100 2 3 0 1 0 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 13.13.13.13 100 2 3 0 1 0 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To prevent unnecessary BGP session flaps: 1.

Add a passive EBGP session with a neighbor address that does not exist in the peer autonomous system (AS). [edit protocols bgp] user@R1# set group Fake type external


1027


user@R1# set group Fake passive user@R1# set neighbor 100.100.100.100 peer-as 500 2.

Run the show bgp summary command to verify that the real sessions have been established and the passive session is idle. user@R1> show bgp summary Groups: 3 Peers: 4 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 4.4.4.1 200 9500 9439 0 0 2d 23:14:23 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 12.12.12.12 100 10309 10239 0 0 3d 5:17:49 Establ bgp.l3vpn.0: 0/0/0/0 13.13.13.13 100 10306 10241 0 0 3d 5:18:25 Establ bgp.l3vpn.0: 0/0/0/0 100.100.100.100 500 0 0 0 0 2d 23:38:52 Idle


Bringing Down the EBGP Session on page 1028

•

Verifying That the IBGP Sessions Remain Up on page 1028

Bringing Down the EBGP Session Purpose Action

Try to cause the flap issue after the workaround is configured. user@R1# deactivate group R1-R4 user@R1# commit

Verifying That the IBGP Sessions Remain Up Purpose Action

Make sure that the IBGP sessions do not flap after the EBGP session is deactivated. user@R1> show bgp summary Groups: 2 Peers: 3 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 12.12.12.12 100 10312 10242 0 0 3d 5:19:01 Establ bgp.l3vpn.0: 0/0/0/0 13.13.13.13 100 10309 10244 0 0 3d 5:19:37 Establ bgp.l3vpn.0: 0/0/0/0 100.100.100.100 500 0 0 0 0 2d 23:40:04 Idle user@R1> show bgp summary Groups: 3 Peers: 4 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0

1028



bgp.l2vpn.0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 4.4.4.1 200 5 4 0 0 28 bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 12.12.12.12 100 10314 10244 0 0 3d 5:19:55 bgp.l3vpn.0: 0/0/0/0 13.13.13.13 100 10311 10246 0 0 3d 5:20:31 bgp.l3vpn.0: 0/0/0/0 100.100.100.100 500 0 0 0 0 2d 23:40:58


•


•


0

Establ

Establ Establ Idle

Example: Configuring BGP Interactions with IGPs •

Understanding Routing Policies on page 1029

•

Example: Injecting OSPF Routes into the BGP Routing Table on page 1029

Understanding Routing Policies Each routing policy is identified by a policy name. The name can contain letters, numbers, and hyphens (-) and can be up to 255 characters long. To include spaces in the name, enclose the entire name in double quotation marks. Each routing policy name must be unique within a configuration. Once a policy is created and named, it must be applied before it is active. You apply routing policies using the import and export statements at the protocols>protocol-name level in the configuration hierarchy. In the import statement, you list the name of the routing policy to be evaluated when routes are imported into the routing table from the routing protocol. In the export statement, you list the name of the routing policy to be evaluated when routes are being exported from the routing table into a dynamic routing protocol. Only active routes are exported from the routing table. To specify more than one policy and create a policy chain, you list the policies using a space as a separator. If multiple policies are specified, the policies are evaluated in the order in which they are specified. As soon as an accept or reject action is executed, the policy chain evaluation ends.

Example: Injecting OSPF Routes into the BGP Routing Table This example shows how to create a policy that injects OSPF routes into the BGP routing table. •


•


•



1029


•


•

Troubleshooting on page 1032



•


•


Overview In this example, you create a routing policy called injectpolicy1 and a routing term called injectterm1. The policy injects OSPF routes into the BGP routing table.

Configuration •

Configuring the Routing Policy on page 1030

•

Configuring Tracing for the Routing Policy on page 1031

Configuring the Routing Policy CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set policy-options policy-statement injectpolicy1 term injectterm1 from protocol ospf set policy-options policy-statement injectpolicy1 term injectterm1 from area 0.0.0.1 set policy-options policy-statement injectpolicy1 term injectterm1 then accept set protocols bgp export injectpolicy1


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To inject OSPF routes into a BGP routing table: 1.

Create the policy term. [edit policy-options policy-statement injectpolicy1] user@host# set term injectterm1

2.

Specify OSPF as a match condition. [edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from protocol ospf

3.

Specify the routes from an OSPF area as a match condition. [edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from area 0.0.0.1

1030



4.

Specify that the route is to be accepted if the previous conditions are matched. [edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set then accept

5.

Apply the routing policy to BGP. [edit] user@host# set protocols bgp export injectpolicy1

Results

Confirm your configuration by entering the show policy-options and show protocols bgp commands from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show policy-options policy-statement injectpolicy1 { term injectterm1 { from { protocol ospf; area 0.0.0.1; } then accept; } } user@host# show protocols bgp export injectpolicy1;

If you are done configuring the device, enter commit from configuration mode. Configuring Tracing for the Routing Policy CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set policy-options policy-statement injectpolicy1 term injectterm1 then trace set routing-options traceoptions file ospf-bgp-policy-log set routing-options traceoptions file size 5m set routing-options traceoptions file files 5 set routing-options traceoptions flag policy


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. 1.

Include a trace action in the policy. [edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# then trace

2.

Configure the tracing file for the output. [edit routing-options traceoptions] user@host# set file ospf-bgp-policy-log


1031


user@host# set file size 5m user@host# set file files 5 user@host# set flag policy

Results

Confirm your configuration by entering the show policy-options and show routing-options commands from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show policy-options policy-statement injectpolicy1 { term injectterm1 { then { trace; } } } user@host# show routing-options traceoptions { file ospf-bgp-policy-log size 5m files 5; flag policy; }


Verification Confirm that the configuration is working properly. Verifying That the Expected BGP Routes Are Present Purpose Action

Verify the effect of the export policy. From operational mode, enter the show route command.

Troubleshooting Using the show log Command to Examine the Actions of the Routing Policy Problem

The routing table contains unexpected routes, or routes are missing from the routing table.

Solution

If you configure policy tracing as shown in this example, you can run the show log ospf-bgp-policy-log command to diagnose problems with the routing policy. The show log ospf-bgp-policy-log command displays information about the routes that the injectpolicy1 policy term analyzes and acts upon.


1032

•


•




Example: Configuring BGP Route Reflectors •

Understanding BGP Route Reflectors on page 1033

•

Example: Configuring a Route Reflector on page 1035

Understanding BGP Route Reflectors Because of the internal BGP (IBGP) full-mesh requirement, most networks use route reflectors to simplify configuration. The formula to compute the number of sessions required for a full mesh is v * (v - 1)/2, where v is the number of BGP-enabled devices. The full-mesh model does not scale well. Using a route reflector, you group routers into clusters, which are identified by numeric identifiers unique to the autonomous system (AS). Within the cluster, you must configure a BGP session from a single router (the route reflector) to each internal peer. With this configuration, the IBGP full-mesh requirement is met. To use route reflection in an AS, you designate one or more routers as a route reflector—typically, one per point of presence (POP). Route reflectors have the special BGP ability to readvertise routes learned from an internal peer to other internal peers. So rather than requiring all internal peers to be fully meshed with each other, route reflection requires only that the route reflector be fully meshed with all internal peers. The route reflector and all its internal peers form a cluster, as shown in Figure 46 on page 1033.

NOTE: For some Juniper Networks devices, you must have an Advanced BGP Feature license installed on each device that uses a route reflector. For license details, see the Junos OS Initial Configuration Guide for Security Devices.

Figure 46: Simple Route Reflector Topology (One Cluster)

Figure 46 on page 1033 shows Router RR configured as the route reflector for Cluster 127. The other routers are designated internal peers within the cluster. BGP routes are advertised to Router RR by any of the internal peers. RR then readvertises those routes to all other peers within the cluster.


1033


You can configure multiple clusters and link them by configuring a full mesh of route reflectors (see Figure 47 on page 1034).

Figure 47: Basic Route Reflection (Multiple Clusters)

Figure 47 on page 1034 shows Route Reflectors RR1, RR2, RR3, and RR4 as fully meshed internal peers. When a router advertises a route to RR1, RR1 readvertises the route to the other route reflectors, which, in turn, readvertise the route to the remaining routers within the AS. Route reflection allows the route to be propagated throughout the AS without the scaling problems created by the full mesh requirement. However, as clusters become large, a full mesh with a route reflector becomes difficult to scale, as does a full mesh between route reflectors. To help offset this problem, you can group clusters of routers together into clusters of clusters for hierarchical route reflection (see Figure 48 on page 1034).

Figure 48: Hierarchical Route Reflection (Clusters of Clusters)

1034



Figure 48 on page 1034 shows RR2, RR3, and RR4 as the route reflectors for Clusters 127, 19, and 45, respectively. Rather than fully mesh those route reflectors, the network administrator has configured them as part of another cluster (Cluster 6) for which RR1 is the route reflector. When a router advertises a route to RR2, RR2 readvertises the route to all the routers within its own cluster, and then readvertises the route to RR1. RR1 readvertises the route to the routers in its cluster, and those routers propagate the route down through their clusters.

Example: Configuring a Route Reflector This example shows how to configure a route reflector (RR). •


•


•


•



Overview Generally, internal BGP (IBGP)-enabled devices need to be fully meshed, because IBGP does not readvertise updates to other IBGP-enabled devices. The full mesh is a logical mesh achieved through configuration of multiple neighbor statements on each IBGP-enabled device. The full mesh is not necessarily a physical full mesh. Maintaining a full mesh (logical or physical) does not scale well in large deployments. Figure 49 on page 1036 shows an IBGP network with Device A acting as an RR. Device B and Device C are clients of the RR. Device D and Device E are outside the cluster, so they are nonclients of the RR. On Device A, the RR, you must form peer relationships with all of the IBGP-enabled devices by including the neighbor statement for the clients (Device B and Device C) and the nonclients (Device D and Device E). You must also include the cluster statement and a cluster identifier. The cluster identifier can be any 32-bit value. This example uses the loopback interface IP address of the RR. On Device B and Device C, the RR clients, you only need one neighbor statement that forms a peer relationship with the RR, Device A. On Device D and Device E, the nonclients, you need a neighbor statement for each nonclient device (D-to-E and E-to-D). You also need a neighbor statement for the RR (D-to-A and E-to-A). Device D and Device E do not need neighbor statements for the client devices (Device B and Device C).

TIP: Device D and Device E are considered to be nonclients because they have explicitly configured peer relationships with each other. To make them


1035


RR clients, remove the neighbor 192.168.5.5 statement from the configuration on Device D, and remove the neighbor 192.168.0.1 statement from the configuration on Device E.

Figure 49: IBGP Network Using a Route Reflector AS 17 192.168.5.5 E

192.168.0.1 D

192.168.6.5 A Route Reflector 192.163.6.4 C

B

g040867

192.168.40.4


Device A

1036

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set interfaces fe-0/0/0 unit 1 description to-B set interfaces fe-0/0/0 unit 1 family inet address 10.10.10.1/30 set interfaces fe-0/0/1 unit 3 description to-D set interfaces fe-0/0/1 unit 3 family inet address 10.10.10.9/30 set interfaces lo0 unit 1 family inet address 192.168.6.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.6.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers cluster 192.168.6.5 set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.40.4



set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.1 set protocols ospf area 0.0.0.0 interface fe-0/0/1.3 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.6.5 set routing-options autonomous-system 17

Device B

set interfaces fe-0/0/0 unit 2 description to-A set interfaces fe-0/0/0 unit 2 family inet address 10.10.10.2/30 set interfaces fe-0/0/1 unit 5 description to-C set interfaces fe-0/0/1 unit 5 family inet address 10.10.10.5/30 set interfaces lo0 unit 2 family inet address 192.163.6.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.163.6.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.2 set protocols ospf area 0.0.0.0 interface fe-0/0/1.5 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.163.6.4 set routing-options autonomous-system 17

Device C

set interfaces fe-0/0/0 unit 6 description to-B set interfaces fe-0/0/0 unit 6 family inet address 10.10.10.6/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.40.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.6 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17

Device D

set interfaces fe-0/0/0 unit 4 description to-A set interfaces fe-0/0/0 unit 4 family inet address 10.10.10.10/30 set interfaces fe-0/0/1 unit 7 description to-E set interfaces fe-0/0/1 unit 7 family inet address 10.10.10.13/30 set interfaces lo0 unit 4 family inet address 192.168.0.1/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.0.1 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.4 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.4 set protocols ospf area 0.0.0.0 interface fe-0/0/1.7 set policy-options policy-statement send-ospf term 2 from protocol ospf


1037


set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.0.1 set routing-options autonomous-system 17

Device E

set interfaces fe-0/0/0 unit 8 description to-D set interfaces fe-0/0/0 unit 8 family inet address 10.10.10.14/30 set interfaces lo0 unit 5 family inet address 192.168.5.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.5.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.8 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.5.5 set routing-options autonomous-system 17

Configuring the Route Reflector Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure IBGP in the network using Juniper Networks Device A as a route reflector: 1.

Configure the interfaces. [edit interfaces] user@A# set fe-0/0/0 unit 1 description to-B user@A# set fe-0/0/0 unit 1 family inet address 10.10.10.1/30 user@A# set fe-0/0/1 unit 3 description to-D user@A# set fe-0/0/1 unit 3 family inet address 10.10.10.9/30 user@A# set lo0 unit 1 family inet address 192.168.6.5/32

2.

Configure BGP, including the cluster identifier and neighbor relationships with all IBGP-enabled devices in the autonomous system (AS). Also apply the policy that redistributes OSPF routes into BGP. [edit protocols bgp group internal-peers] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set export send-ospf user@A# set cluster 192.168.6.5 user@A# set neighbor192.163.6.4 user@A# set neighbor 192.168.40.4 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5

3.

Configure static routing or an interior gateway protocol (IGP). This example uses OSPF. [edit protocols ospf area 0.0.0.0] user@A# set interface lo0.1 passive user@A# set interface fe-0/0/0.1

1038



user@A# set interface fe-0/0/1.3 4.

Configure the policy that redistributes OSPF routes into BGP. [edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept

5.

Configure the router ID and the autonomous system (AS) number. [edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@A# show interfaces fe-0/0/0 { unit 1 { description to-B; family inet { address 10.10.10.1/30; } } } fe-0/0/1 { unit 3 { description to-D; family inet { address 10.10.10.9/30; } } } lo0 { unit 1 { family inet { address 192.168.6.5/32; } } } user@A# show protocols bgp { group internal-peers { type internal; local-address 192.168.6.5; export send-ospf; cluster 192.168.6.5; neighbor 192.163.6.4; neighbor 192.168.40.4; neighbor 192.168.0.1; neighbor 192.168.5.5; } }


1039


ospf { area 0.0.0.0 { interface lo0.1 { passive; } interface fe-0/0/0.1; interface fe-0/0/1.3; } } user@A# show policy-options policy-statement send-ospf { term 2 { from protocol ospf; then accept; } } user@A# show routing-options router-id 192.168.6.5; autonomous-system 17;


NOTE: Repeat these steps for each nonclient BGP peer within the cluster that you are configuring if the other nonclient devices are from Juniper Networks. Otherwise, consult the device’s documentation for instructions.

Configuring Client Peers Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure client peers: 1.

Configure the interfaces. [edit interfaces] user@B# set fe-0/0/0 unit 2 description to-A user@B# set fe-0/0/0 unit 2 family inet address 10.10.10.2/30 user@B# set fe-0/0/1 unit 5 description to-C user@B# set fe-0/0/1 unit 5 family inet address 10.10.10.5/30 user@B# set lo0 unit 2 family inet address 192.163.6.4/32

2.

Configure the BGP neighbor relationship with the RR. Also apply the policy that redistributes OSPF routes into BGP. [edit protocols bgp group internal-peers] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set export send-ospf user@B# set neighbor 192.168.6.5

1040



3.

Configure OSPF. [edit protocols ospf area 0.0.0.0] user@B# set interface lo0.2 passive user@B# set interface fe-0/0/0.2 user@B# set interface fe-0/0/1.5

4.

Configure the policy that redistributes OSPF routes into BGP. [edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept

5.

Configure the router ID and the AS number. [edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@B# show interfaces fe-0/0/0 { unit 2 { description to-A; family inet { address 10.10.10.2/30; } } } fe-0/0/1 { unit 5 { description to-C; family inet { address 10.10.10.5/30; } } } lo0 { unit 2 { family inet { address 192.163.6.4/32; } } } user@B# show protocols bgp { group internal-peers { type internal; local-address 192.163.6.4; export send-ospf; neighbor 192.168.6.5; }


1041


} ospf { area 0.0.0.0 { interface lo0.2 { passive; } interface fe-0/0/0.2; interface fe-0/0/1.5; } } user@B# show policy-options policy-statement send-ospf { term 2 { from protocol ospf; then accept; } } user@B# show routing-options router-id 192.163.6.4; autonomous-system 17;


NOTE: Repeat these steps for each client BGP peer within the cluster that you are configuring if the other client devices are from Juniper Networks. Otherwise, consult the device’s documentation for instructions.

Configuring Nonclient Peers Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure nonclient peers: 1.

Configure the interfaces. [edit interfaces] user@D# set fe-0/0/0 unit 4 description to-A user@D# set fe-0/0/0 unit 4 family inet address 10.10.10.10/30 user@D# set fe-0/0/1 unit 7 description to-E user@D# set fe-0/0/1 unit 7 family inet address 10.10.10.13/30 user@D# set lo0 unit 4 family inet address 192.168.0.1/32

2.

Configure the BGP neighbor relationships with the RR and with the other nonclient peers. Also apply the policy that redistributes OSPF routes into BGP. [edit protocols bgp group internal-peers] user@D# set type internal user@D# set local-address 192.168.0.1 user@D# set export send-ospf

1042



user@D# set neighbor 192.168.6.5 user@D# set neighbor 192.168.5.5 3.

Configure OSPF. [edit protocols ospf area 0.0.0.0] user@D# set interface lo0.4 passive user@D# set interface fe-0/0/0.4 user@D# set interface fe-0/0/1.7

4.

Configure the policy that redistributes OSPF routes into BGP. [edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept

5.

Configure the router ID and the AS number. [edit routing-options] user@D# set router-id 192.168.0.1 user@D# set autonomous-system 17

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@D# show interfaces fe-0/0/0 { unit 4 { description to-A; family inet { address 10.10.10.10/30; } } } fe-0/0/1 { unit 7 { description to-E; family inet { address 10.10.10.13/30; } } } lo0 { unit 4 { family inet { address 192.168.0.1/32; } } } user@D# show protocols bgp { group internal-peers { type internal; local-address 192.168.0.1; export send-ospf;


1043


neighbor 192.168.6.5; neighbor 192.168.5.5; } } ospf { area 0.0.0.0 { interface lo0.4 { passive; } interface fe-0/0/0.4; interface fe-0/0/1.7; } } user@D# show policy-options policy-statement send-ospf { term 2 { from protocol ospf; then accept; } } user@D# show routing-options router-id 192.168.0.1; autonomous-system 17;


NOTE: Repeat these steps for each nonclient BGP peer within the cluster that you are configuring if the other nonclient devices are from Juniper Networks. Otherwise, consult the device’s documentation for instructions.



•


•


•

Verifying Routing Table Information on page 1048


Action

Verify that BGP is running on configured interfaces and that the BGP session is established for each neighbor address. From operational mode, enter the show bgp neighbor command. user@A> show bgp neighbor Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+62857 AS 17 Type: Internal State: Established (route reflector client)Flags: Last State: OpenConfirm Last Event: RecvKeepAlive

1044



Last Error: None Export: [ send-ospf ] Options: Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 6 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 5 Sent 3 Checked 19 Input messages: Total 2961 Updates 7 Refreshes 0 Octets 56480 Output messages: Total 2945 Updates 6 Refreshes 0 Octets 56235 Output Queue[0]: 0 Peer: 192.168.0.1+179 AS 17 Local: 192.168.6.5+60068 AS 17 Type: Internal State: Established (route reflector client)Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-ospf ] Options: Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.0.1 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 3 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync


1045


Active prefixes: 0 Received prefixes: 6 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 18 Sent 20 Checked 12 Input messages: Total 15 Updates 5 Refreshes 0 Output messages: Total 554 Updates 4 Refreshes 0 Output Queue[0]: 0


Peer: 192.168.5.5+57458 AS 17 Local: 192.168.6.5+179 AS 17 Type: Internal State: Established (route reflector client)Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-ospf ] Options: Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.5.5 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 2 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 7 Accepted prefixes: 7 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 17 Sent 3 Checked 9 Input messages: Total 2967 Updates 7 Refreshes 0 Octets 56629 Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197 Output Queue[0]: 0 Peer: 192.168.40.4+53990 AS 17 Local: 192.168.6.5+179 AS 17 Type: Internal State: Established (route reflector client)Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-ospf ] Options: Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast

1046



Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 7 Accepted prefixes: 7 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 5 Sent 23 Checked 52 Input messages: Total 2960 Updates 7 Refreshes 0 Output messages: Total 2943 Updates 6 Refreshes 0 Output Queue[0]: 0



Verify that the BGP groups are configured correctly. From operational mode, enter the show bgp group command. user@A> show bgp group Group Type: Internal AS: 17 Name: internal-peers Index: 0 Export: [ send-ospf ] Options: Holdtime: 0 Total peers: 4 Established: 4 192.163.6.4+179 192.168.40.4+53990 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 1 Table inet.0

Local AS: 17 Flags:



Verify that the BGP configuration is correct. From operational mode, enter the show bgp summary command.

user@A> show bgp summary Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2981 2965 0 0 22:19:15 0/6/1/0


0/0/0/0

1047


192.168.0.1 192.168.5.5 192.168.40.4

17 17 17

36 2988 2980

575 2964 2964

0 0 0

0 0 0

13:43 0/6/1/0 22:19:10 0/7/7/0 22:19:14 0/7/7/0

0/0/0/0 0/0/0/0 0/0/0/0

Verifying Routing Table Information Purpose Action

Verify that the routing table contains the IBGP routes. From operational mode, enter the show route command. user@A> show route inet.0: 12 destinations, 38 routes (12 active, 0 holddown, 10 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/30

10.10.10.1/32 10.10.10.4/30

10.10.10.8/30

10.10.10.9/32 10.10.10.12/30

192.163.6.4/32

192.168.0.1/32

1048

*[Direct/0] 22:22:03 > via fe-0/0/0.1 [BGP/170] 22:20:55, MED 2, localpref AS path: I > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:51, MED 3, localpref AS path: I > to 10.10.10.10 via fe-0/0/1.3 *[Local/0] 22:22:03 Local via fe-0/0/0.1 *[OSPF/10] 22:21:13, metric 2 > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:51, MED 4, localpref AS path: I > to 10.10.10.10 via fe-0/0/1.3 *[Direct/0] 22:22:03 > via fe-0/0/1.3 [BGP/170] 22:20:51, MED 2, localpref AS path: I > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 3, localpref AS path: I > to 10.10.10.2 via fe-0/0/0.1 *[Local/0] 22:22:03 Local via fe-0/0/1.3 *[OSPF/10] 22:21:08, metric 2 > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 4, localpref AS path: I > to 10.10.10.2 via fe-0/0/0.1 *[OSPF/10] 22:21:13, metric 1 > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:55, MED 1, localpref AS path: I > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:51, MED 3, localpref AS path: I > to 10.10.10.10 via fe-0/0/1.3 *[OSPF/10] 22:21:08, metric 1 > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:51, MED 1, localpref AS path: I > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 3, localpref AS path: I > to 10.10.10.2 via fe-0/0/0.1

100, from 192.168.40.4

100, from 192.168.5.5

100, from 192.168.5.5

100, from 192.168.5.5

100, from 192.168.40.4

100, from 192.168.40.4

100, from 192.168.40.4

100, from 192.168.5.5

100, from 192.168.5.5

100, from 192.168.40.4



192.168.5.5/32

192.168.6.5/32

192.168.40.4/32

224.0.0.5/32


*[OSPF/10] 22:21:08, metric 2 > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 00:15:24, MED 1, localpref AS path: I > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 4, localpref AS path: I > to 10.10.10.2 via fe-0/0/0.1 *[Direct/0] 22:22:04 > via lo0.1 [BGP/170] 22:20:51, MED 2, localpref AS path: I > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 2, localpref AS path: I > to 10.10.10.2 via fe-0/0/0.1 *[OSPF/10] 22:21:13, metric 2 > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:55, MED 1, localpref AS path: I > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:51, MED 4, localpref AS path: I > to 10.10.10.10 via fe-0/0/1.3 *[OSPF/10] 22:22:07, metric 1 MultiRecv

•


•


100, from 192.168.0.1

100, from 192.168.40.4

100, from 192.168.5.5

100, from 192.168.40.4

100, from 192.163.6.4

100, from 192.168.5.5

Example: Configuring BGP Confederations •

Understanding BGP Confederations on page 1049

•


Understanding BGP Confederations BGP confederations are another way to solve the scaling problems created by the BGP full mesh requirement. BGP confederations effectively break up a large autonomous system (AS) into subautonomous systems (sub-ASs). Each sub-AS must be uniquely identified within the confederation AS by a sub-AS number. Typically, sub-AS numbers are taken from the private AS numbers between 64,512 and 65,535. Within a sub-AS, the same internal BGP (IBGP) full mesh requirement exists. Connections to other confederations are made with standard external BGP (EBGP), and peers outside the sub-AS are treated as external. To avoid routing loops, a sub-AS uses a confederation sequence, which operates like an AS path but uses only the privately assigned sub-AS numbers. The confederation AS appears whole to other confederation ASs. The AS path received by other ASs shows only the globally assigned AS number. It does not include the confederation sequence or the privately assigned sub-AS numbers. The sub-AS numbers


1049


are removed when the route is advertised out of the confederation AS. Figure 50 on page 1050 shows an AS divided into four confederations.

Figure 50: BGP Confederations

AS 3 Sub-AS 64517

Sub-AS 64550

IBGP

IBGP

EBGP

IBGP

Sub-AS 65410

IBGP

g015021

Sub-AS 65300

Figure 50 on page 1050 shows AS 3 divided into four sub-ASs, 64517, 64550, 65300, and 65410, which are linked through EBGP sessions. Because the confederations are connected by EBGP, they do not need to be fully meshed. EBGP routes are readvertised to other sub-ASs.

1050



Example: Configuring BGP Confederations This example shows how to configure BGP confederations. •


•


•


•


Requirements •


•


•


•

Configure a routing policy to advertise the BGP routes.

Overview Within a confederation, the links between the confederation member autonomous systems (ASs) must be external BGP (EBGP) links, not internal BGP (IBGP) links. Like route reflectors, BGP confederations reduce the number of peer sessions and TCP sessions to maintain connections between IBGP routing devices. BGP confederation is another way to solve the scaling problems created by the IBGP full mesh requirement. BGP confederations effectively break up a large AS into subautonomous systems. Each sub-AS must be uniquely identified within the confederation AS by a sub-AS number. Typically, sub-AS numbers are taken from the private AS numbers between 64512 and 65535. Within a sub-AS, the same IBGP full mesh requirement exists. Connections to other confederations are made with standard EBGP, and peers outside the sub-AS are treated as external. To avoid routing loops, a sub-AS uses a confederation sequence, which operates like an AS path but uses only the privately assigned sub-AS numbers. Figure 51 on page 1052 shows a sample network in which AS 17 has two separate confederations: sub-AS 64512 and sub-AS 64513, each of which has multiple routers. Within a sub-AS, an IGP is used to establish network connectivity with internal peers. Between sub-ASs, an EBGP peer session is established.


1051


Figure 51: Typical Network Using BGP Confederations


All Devices in Sub-AS 64512

Border Device in Sub-AS 64512

All Devices in Sub-AS 64513

Border Device in Sub-AS 64513

1052

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set routing-options autonomous-system 64512 set routing-options confederation 17 members 64512 set routing-options confederation 17 members 64513 set protocols bgp group sub-AS-64512 type internal set protocols bgp group sub-AS-64512 local-address 192.168.5.1 set protocols bgp group sub-AS-64512 neighbor 192.168.8.1 set protocols bgp group sub-AS-64512 neighbor 192.168.15.1 set protocols bgp group to-sub-AS-64513 type external set protocols bgp group to-sub-AS-64513 peer-as 64513 set protocols bgp group to-sub-AS-64513 neighbor 192.168.5.2 set routing-options autonomous-system 64513 set routing-options confederation 17 members 64512 set routing-options confederation 17 members 64513 set protocols bgp group sub-AS-64513 type internal set protocols bgp group sub-AS-64513 local-address 192.168.5.2 set protocols bgp group sub-AS-64513 neighbor 192.168.9.1 set protocols bgp group sub-AS-64513 neighbor 192.168.16.1 set protocols bgp group to-sub-AS-64512 type external set protocols bgp group to-sub-AS-64512 peer-as 64512 set protocols bgp group to-sub-AS-64512 neighbor 192.168.5.1




This procedure shows the steps for the devices that are in sub-AS 64512. The autonomous-system statement sets the sub-AS number of the device. The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure BGP confederations: 1.

Set the sub-AS number for the device. [edit routing-options] user@host# set autonomous-system 64512

2.

In the confederation, include all sub-ASs in the main AS. The number 17 represents the main AS. The members statement lists all the sub-ASs in the main AS. [edit routing-options confederation] user@host# set 17 members 64512 user@host# set 17 members 64513

3.

On the border device in sub-AS 64512, configure an EBGP connection to the border device in AS 64513. [edit protocols bgp group to-sub-AS-64513] user@host# set type external user@host# set neighbor 192.168.5.2 user@host# set peer-as 64513

4.

Configure an IBGP group for peering with the devices within sub-AS 64512. [edit protocols bgp group sub-AS-64512] user@host# set type internal user@host# set local-address 192.168.5.1 user@host# neighbor 192.168.8.1 user@host# neighbor 192.168.15.1

Results

From configuration mode, confirm your configuration by entering the show routing-options and show protocols commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show routing-options autonomous-system 64512; confederation 17 members [ 64512 64513 ]; user@host# show protocols bgp { group to-sub-AS-64513 { # On the border devices only type external; peer-as 64513; neighbor 192.168.5.2; } group sub-AS-64512 { type internal; local-address 192.168.5.1;


1053


neighbor 192.168.8.1; neighbor 192.168.15.1; } }

If you are done configuring the device, enter commit from configuration mode. Repeat these steps for Sub-AS 64513.



•


•



Action

Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address. From the CLI, enter the show bgp neighbor command.

Sample Output user@host> show bgp neighbor Peer: 10.255.245.12+179 AS 35 Local: 10.255.245.13+2884 AS 35 Type: Internal State: Established (route reflector client)Flags: Sync Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: Preference LocalAddress HoldTime Cluster AddressFamily Rib-group Refresh Address families configured: inet-vpn-unicast inet-labeled-unicast Local Address: 10.255.245.13 Holdtime: 90 Preference: 170 Flags for NLRI inet-vpn-unicast: AggregateLabel Flags for NLRI inet-labeled-unicast: AggregateLabel Number of flaps: 0 Peer ID: 10.255.245.12 Local ID: 10.255.245.13 Active Holdtime: 90 Keepalive Interval: 30 NLRI advertised by peer: inet-vpn-unicast inet-labeled-unicast NLRI for this session: inet-vpn-unicast inet-labeled-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 300 Stale routes from peer are kept for: 60 Restart time requested by this peer: 300 NLRI that peer supports restart for: inet-unicast inet6-unicast NLRI that restart is negotiated for: inet-unicast inet6-unicast NLRI of received end-of-rib markers: inet-unicast inet6-unicast NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast Table inet.0 Bit: 10000 RIB State: restart is complete Send state: in sync Active prefixes: 4 Received prefixes: 6 Suppressed due to damping: 0 Table inet6.0 Bit: 20000 RIB State: restart is complete Send state: in sync

1054



Active prefixes: 0 Received prefixes: 2 Suppressed due to damping: 0 Last traffic (seconds): Received 3 Sent 3 Checked 3 Input messages: Total 9 Updates 6 Refreshes 0 Output messages: Total 7 Updates 3 Refreshes 0 Output Queue[0]: 0 Output Queue[1]: 0 Trace options: detail packets Trace file: /var/log/bgpgr size 131072 files 10

Meaning


The output shows a list of the BGP neighbors with detailed session information. Verify the following information: •

Each configured peering neighbor is listed.

•

For State, each BGP session is Established.

•

For Type, each peer is configured as the correct type (either internal or external).

•

For AS, the AS number of the BGP neighbor is correct.


Verify that the BGP groups are configured correctly. From the CLI, enter the show bgp group command.

Sample Output user@host> show bgp group Group Type: Internal AS: 10045 Name: pe-to-asbr2 Export: [ match-all ] Total peers: 1 Established: 1 10.0.0.4+179 bgp.l3vpn.0: 1/1/0 vpn-green.inet.0: 1/1/0

Local AS: 10045 Flags: Export Eval

Groups: 1 Peers: 1 External: 0 Internal: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State bgp.l3vpn.0 1 1 0 0 0

Meaning

Flaps: 0 Pending 0

The output shows a list of the BGP groups with detailed group information. Verify the following information: •

Each configured group is listed.

•

For AS, each group's remote AS is configured correctly.

•

For Local AS, each group's local AS is configured correctly.

•

For Group Type, each group has the correct type (either internal or external).

•

For Total peers, the expected number of peers within the group is shown.


1055


•

For Established, the expected number of peers within the group have BGP sessions in the Established state.

•

The IP addresses of all the peers within the group are present.


Verify that the BGP configuration is correct. From the CLI, enter the show bgp summary command.

Sample Output user@host> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State inet.0 6 4 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 10.0.0.2 65002 88675 88652 0 2 42:38 0/0/0 10.0.0.3 65002 54528 54532 0 1 2w4d22h 0/0/0 10.0.0.4 65002 51597 51584 0 0 2w3d22h 0/0/0

Meaning


Pending 0

2/4/0 0/0/0 2/2/0

The output shows a summary of BGP session information. Verify the following information: •

For Groups, the total number of configured groups is shown.

•

For Peers, the total number of BGP peers is shown.

•

For Down Peers, the total number of unestablished peers is 0. If this value is not zero, one or more peering sessions are not yet established.

•

Under Peer, the IP address for each configured peer is shown.

•

Under AS, the peer AS for each configured peer is correct.

•

Under Up/Dwn State, the BGP state reflects the number of paths received from the neighbor, the number of these paths that have been accepted, and the number of routes being damped (such as 0/0/0). If the field is Active, it indicates a problem in the establishment of the BGP session.

•


•


Example: Configuring BGP Route Authentication

1056

•

Understanding Route Authentication on page 1057

•

Example: Configuring Route Authentication for BGP on page 1058



Understanding Route Authentication Router and route authentication and route integrity greatly mitigate the risk of an attacker who configures a machine or router to share incorrect routing information with another router. In an attack, the attacked router can be tricked into creating a routing loop, the attacked router’s routing table can be greatly increased thus impacting performance, or routing information can be redirected to a place in the network for the attacker to analyze it. Bogus route advertisements can be sent out on a segment. These updates are accepted into the routing tables of neighbor routers unless an authentication mechanism is in place to verify the source of the routes. Router and route authentication enables routers to share information only if they can verify, based on a password (key), that they are talking to a trusted source. The hashed key is sent along with the route being sent to another router. The receiving router compares this key to its own configured key. If they are the same, it accepts the route. By using a hashing algorithm, the key is not sent over the wire in plain text. Instead, a keyed hash is calculated using the configured key. The routing update is used as the input text along with the key into the hashing function. This hash is sent along with the route update to the receiving router. The receiving router compares the received hash with a hash it generates on the route update using the preshared key configured on it. If the two hashes are the same, the route is assumed to be from a trusted source. The key is known only to the sending and receiving routers. To further strengthen security, you can configure a series of authentication keys (a keychain). Each key has a unique start time within the keychain. Keychain authentication allows you to change the password information periodically without bringing down peering sessions. This keychain authentication method is referred to as hitless because the keys roll over from one to the next without resetting any peering sessions or interrupting the routing protocol. The sending peer uses the following rules to identify the active authentication key: •

The start-time is less than or equal to the current time (in other words, not in the future).

•

The start time is greater than that of all other keys in the chain whose start time is less than the current time (in other words, closest to the current time).

The receiving peer determines the key with which it authenticates based upon the incoming key identifier. The sending peer identifies the current authentication key based on a configured start time and then generates a hash value using the current key. The sending peer then Inserts a TCP enhanced authentication option object into the BGP update message. The object contains an object ID (assigned by IANA), and the object length, the current key, and a hash value. The receiving peer examines the incoming TCP enhanced authentication option, looks up the received authentication key, and determines whether the key is acceptable based on the start time, the system time, and the tolerance parameter. If the key is accepted, the receiving peer calculates a hash and authenticates the update message.


1057


Initial application of a keychain to a TCP session causes the session to reset. However, once the keychain is applied, the addition or removal of a password from the keychain does not cause the TCP session to reset. Also, the TCP session does not reset when the keychain changes from one authentication algorithm to another.

Example: Configuring Route Authentication for BGP All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in autonomous system (AS) routing. By default, authentication is disabled. •


•


•


•



Configure the router interfaces.

•


Overview Authentication guarantees that only trusted routers participate in routing updates. When you configure authentication, the algorithm creates an encoded checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet’s checksum. This example includes the following statements for configuring and applying the keychain: •

key—A keychain can have multiple keys. Each key within a keychain must be identified

by a unique integer value. The range of valid identifier values is from 0 through 63. The key can be up to 126 characters long. Characters can include any ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”). •

tolerance—(Optional) For each keychain, you can configure a clock-skew tolerance

value in seconds. The clock-skew tolerance is applicable to the receiver accepting keys for BGP updates. The configurable range is 0 through 999,999,999 seconds. During the tolerance period, either the current or previous password is acceptable. •

key-chain—For each keychain, you must specify a name. This example defines one

keychain: bgp-auth. You can have multiple keychains on a routing device. For example, you can have a keychain for BGP, a keychain for OSPF, and a keychain for LDP. •

secret—For each key in the keychain, you must set a secret password. This password

can be entered in either encrypted or plain text format in the secret statement. It is always displayed in encrypted format.

1058



•

start-time—Each key must specify a start time in UTC format. Control gets passed

from one key to the next. When a configured start time arrives (based on the routing device’s clock), the key with that start time becomes active. Start times are specified in the local time zone for a routing device and must be unique within the key chain. •

authentication-key-chain—Enables you to apply a keychain at the global BGP level for

all peers, for a group, or for a neighbor. This example applies the keychain to the peers defined in the external BGP (EBGP) group called ext. •

authentication-algorithm—For each keychain, you can specify a hashing algorithm. The

algorithm can be AES-128, MD5, or SHA-1. You associate keychain and an authentication algorithm with a BGP neighboring session. This example configures a keychain named bgp-auth. Key 0 will be sent and accepted starting at 2011-6-23.20:19:33 -0700, and will stop being sent and accepted when the next key in the keychain (key 1) becomes active. Key 1 becomes active one year later at 2012-6-23.20:19:33 -0700, and will not stop being sent and accepted unless another key is configured with a start time that is later than the start time of key 1. A clock-skew tolerance of 30 seconds applies to the receiver accepting the keys. During the tolerance period, either the current or previous key is acceptable. The keys are shared-secret passwords. This means that the neighbors receiving the authenticated routing updates must have the same authentication keychain configuration, including the same keys (passwords). So Router R0 and Router R1 must have the same authentication-key-chain configuration if they are configured as peers. This example shows the configuration on only one of the routing devices. Topology Diagram Figure 52 on page 1059 shows the topology used in this example.

Figure 52: Authentication for BGP

R1 g041117

R0


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set protocols bgp group ext type external set protocols bgp group ext peer-as 65530 set protocols bgp group ext neighbor 172.16.2.1 set routing-options autonomous-system 65533 set protocols bgp group ext authentication-key-chain bgp-auth set protocols bgp group ext authentication-algorithm md5 set security authentication-key-chains key-chain bgp-auth tolerance 30


1059


set security authentication-key-chains key-chain bgp-auth key 0 secret this-is-the-secret-password set security authentication-key-chains key-chain bgp-auth key 0 start-time 2011-6-23.20:19:33-0700 set security authentication-key-chains key-chain bgp-auth key 1 secret this-is-another-secret-password set security authentication-key-chains key-chain bgp-auth key 1 start-time 2012-6-23.20:19:33-0700


The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Router R1 to accept route filters from Device CE1 and perform outbound route filtering using the received filters: 1.

Configure the local autonomous system. [edit routing-options] user@R1# set autonomous-system 65533

2.

Configure one or more BGP groups. [edit protocols bgp group ext] user@R1# set type external user@R1# set peer-as 65530 user@R1# set neighbor 172.16.2.1

3.

Configure authentication with multiple keys. [edit security authentication-key-chains key-chain bgp-auth] user@R1# set key 0 secret this-is-the-secret-password user@R1# set key 0 start-time 2011-6-23.20:19:33-0700 user@R1# set key 1 secret this-is-another-secret-password user@R1# set key 1 start-time 2012-6-23.20:19:33-0700

The start time of each key must be unique within the keychain. 4.

Apply the authentication keychain to BGP and set the hashing algorithm. [edit protocols bgp group ext] user@R1# set authentication-key-chain bgp-auth user@R1# set authentication-algorithm md5

5.

(Optional) Apply a clock-skew tolerance value in seconds. [edit security authentication-key-chains key-chain bgp-auth] user@R1# set tolerance 30

Results

From configuration mode, confirm your configuration by entering the show protocols, show routing-options, and show security commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show protocols bgp { group ext { type external; peer-as 65530;

1060



neighbor 172.16.2.1; authentication-key-chain bgp-auth; authentication-algorithm md5; } } user@R1# show routing-options autonomous-system 65533; user@R1# show security authentication-key-chains { key-chain bgp-auth { tolerance 30; key 0 { secret "$9$5T6AREylK8RhxNdwaJn/CtO1cyKvWx9AylMWdVgoJDjqP5FCA0z3IEhcMWLxNbgJDi.F6A"; ## SECRET-DATA start-time “2011-6-23.20:19:33 -0700”; } key 1 { secret "$9$UyD.59CuO1h9AylKW-dqmfT369CuRhSP5hrvMN-JGDiqfu0IleWpuh."; ## SECRET-DATA start-time “2012-6-23.20:19:33 -0700”; } } }

If you are done configuring the device, enter commit from configuration mode. Repeat the procedure for every BGP-enabled device in the network, using the appropriate interface names and addresses for each BGP-enabled device.


Verifying Authentication for the Neighbor on page 1061

•

Verifying That Authorization Messages Are Sent on page 1062

•

Checking Authenication Errors on page 1063

•

Verifying the Operation of the Keychain on page 1063

Verifying Authentication for the Neighbor Purpose

Action

Make sure that the AutheKeyChain option appears in the output of the show bgp neighbor command. From operational mode, enter the show bgp neighbor command. user@R1> show bgp neighbor Peer: 172.16.2.1+179 AS 65530 Local: 172.16.2.2+1222 AS 65533 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ direct-lo0 ] Options: Options:


1061


Authentication key is configured Authentication key chain: jni Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 172.16.2.1 Local ID: 10.255.124.35 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 Local Interface: fe-0/0/1.0 NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 2 Received prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 1 Last traffic (seconds): Received 2 Sent 2 Checked 2 Input messages: Total 21 Updates 2 Refreshes 0 Octets 477 Output messages: Total 22 Updates 1 Refreshes 0 Octets 471 Output Queue[0]: 0

Verifying That Authorization Messages Are Sent Purpose Action

Confirm that BGP has the enhanced authorization option. From operational mode, enter the monitor traffic interface fe-0/0/1 command. user@R1> monitor traffic interface fe-0/0/1 verbose output suppressed, use or for full protocol decode Listening on fe-0/0/1, capture size 96 bytes 13:08:00.618402 In arp who-has 172.16.2.66 tell 172.16.2.69 13:08:02.408249 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 1889289217:1889289235(18) ack 2215740969 win 58486 : 13:08:02.418396 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 1:19(18) ack 18 win 57100 : 13:08:02.518146 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 19 win 58468 13:08:28.199557 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: P 286842489:286842508(19) ack 931203976 win 57200 : BGP, length: 19 13:08:28.209661 In IP 172.16.2.1.bgp > 172.16.2.2.nerv: P 1:20(19) ack 19 win 56835 : BGP, length: 19 13:08:28.309525 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: . ack 20 win 57181 13:08:32.439708 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 54:72(18) ack 55 win 58432 : 13:08:32.449795 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 55:73(18) ack 72 win 57046 : 13:08:32.549726 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 73 win 58414 13:08:33.719880 In arp who-has 172.16.2.66 tell 172.16.2.69 ^C

1062



35 packets received by filter 0 packets dropped by kernel

Checking Authenication Errors Purpose Action

Check the number of packets dropped by TCP because of authentication errors. From operational mode, enter the show system statistics tcp | match auth command. user@R1> show system statistics tcp | match auth 0 send packets dropped by TCP due to auth errors 58 rcv packets dropped by TCP due to auth errors

Verifying the Operation of the Keychain Purpose Action

Check the number of packets dropped by TCP because of authentication errors. From operational mode, enter the show security keychain detail command. user@R1> show security keychain detail keychain Active-ID Next-ID Transition Send Receive Send Receive bgp-auth 3 3 1 1 1d 23:58 Id 3, Algorithm hmac-md5, State send-receive, Option basic Start-time Wed Aug 11 16:28:00 2010, Mode send-receive Id 1, Algorithm hmac-md5, State inactive, Option basic Start-time Fri Aug 20 11:30:57 2010, Mode send-receive


•


•


Tolerance 30

Example: Configuring IPsec Protection for BGP •

Understanding IPsec for BGP on page 1063

•

Example: Using IPsec to Protect BGP Traffic on page 1064

Understanding IPsec for BGP You can apply the IP security (IPsec) to BGP traffic. IPsec is a protocol suite used for protecting IP traffic at the packet level. IPsec is based on security associations (SAs). An SA is a simplex connection that provides security services to the packets carried by the SA. After configuring the SA, you can apply it to BGP peers. The Junos OS implementation of IPsec supports two types of security: host to host and gateway to gateway. Host-to-host security protects BGP sessions with other routers. An SA to be used with BGP must be configured manually and use transport mode. Static values must be configured on both ends of the security association. To apply host protection, you configure manual SAs in transport mode and then reference the SA by name in the BGP configuration to protect a session with a given peer. Manual SAs require no negotiation between the peers. All values, including the keys, are static and specified in the configuration. Manual SAs statically define the security parameter index values, algorithms, and keys to be used and require matching


1063


configurations on both end points of the tunnel (on both peers). As a result, each peer must have the same configured options for communication to take place. In transport mode, IPsec headers are inserted after the original IP header and before the transport header. The security parameter index is an arbitrary value used in combination with a destination address and a security protocol to uniquely identify the SA.

Example: Using IPsec to Protect BGP Traffic IPsec is a suite of protocols used to provide secure network connections at the IP layer. It is used to provide data source authentication, data integrity, confidentiality and packet replay protection. This example shows how to configure IPsec functionality to protect Routing Engine-to-Routing Engine BGP sessions. Junos OS supports IPsec Authentication Header (AH) and Encapsulating Security Payload (ESP) in transport and tunnel mode, as well as a utility for creating policies and manually configuring keys. •


•


•


•




•


•

Configure BGP.

For transport mode, no PIC is necessary.

Overview The SA is configured at the [edit security ipsec security-association name] hierarchy level with the mode statement set to transport. In transport mode, Junos OS does not support authentication header (AH) or encapsulating security payload (ESP) header bundles. Junos OS supports only the BGP protocol in transport mode. This example specifies bidirectional IPsec to decrypt and authenticate the incoming and outgoing traffic using the same algorithm, keys, and SPI in both directions, unlike inbound and outbound SAs that use different attributes in both directions. A more specific SA overrides a more general SA. For example, if a specific SA is applied to a specific peer, that SA overrides the SA applied to the whole peer group. Topology Diagram Figure 53 on page 1065 shows the topology used in this example.

1064



Figure 53: IPsec for BGP

R0

g041117

R1

Configuration •



To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. [edit] set security ipsec security-association test-sa mode transport set security ipsec security-association test-sa manual direction bidirectional protocol esp set security ipsec security-association test-sa manual direction bidirectional spi 1000 set security ipsec security-association test-sa manual direction bidirectional encryption algorithm 3des-cbc set security ipsec security-association test-sa manual direction bidirectional encryption key ascii-text "$9$kPT3AtO1hr6/u1IhvM8X7Vb2JGimfz.PtuB1hcs2goGDkqf5Qndb.5QzCA0BIRrvx7VsgJ" set protocols bgp group 1 neighbor 1.1.1.1 ipsec-sa test-sa


The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Router R1: 1.

Configure the SA mode. [edit security ipsec security-association test-sa] user@R1# set mode transport

2.

Configure the IPsec protocol to be used. [edit security ipsec security-association test-sa] user@R1# set manual direction bidirectional protocol esp

3.

Configure to security parameter index to uniquely identify the SA. [edit security ipsec security-association test-sa] user@R1# set manual direction bidirectional spi 1000

4.

Configure the encryption algorithm. [edit security ipsec security-association test-sa] user@R1# set manual direction bidirectional encryption algorithm 3des-cbc

5.

Configure the encryption key. [edit security ipsec security-association test-sa] user@R1# set manual direction bidirectional encryption key ascii-text "$9$kPT3AtO1hr6/u1IhvM8X7Vb2JGimfz.PtuB1hcs2goGDkqf5Qndb.5QzCA0BIRrvx7VsgJ"


1065


When you use an ASCII text key, the key must contain exactly 24 characters. 6.

Apply the SA to the BGP peer. [edit protocols bgp group 1 neighbor 1.1.1.1] user@R1# set ipsec-sa test-sa

Results

From configuration mode, confirm your configuration by entering the show protocols and show security commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show protocols bgp { group 1 { neighbor 1.1.1.1 { ipsec-sa test-sa; } } } user@R1# show security ipsec { security-association test-sa { mode transport; manual { direction bidirectional { protocol esp; spi 1000; encryption { algorithm 3des-cbc; key ascii-text "$9$kPT3AtO1hr6/u1IhvM8X7Vb2JGimfz.PtuB1hcs2goGDkqf5Qndb.5QzCA0BIRrvx7VsgJ"; ## SECRET-DATA } } } } }

If you are done configuring the device, enter commit from configuration mode. Repeat the configuration on Router R0, changing only the neighbor address.


Verifying the Security Associaton on page 1066

Verifying the Security Associaton Purpose

Action

Make sure that the correct settings appear in the output of the show ipsec security-associations command. From operational mode, enter the show ipsec security-associations command. user@R1> show ipsec security-associations

1066



Security association: test-sa Direction SPI AUX-SPI inbound 1000 0 outbound 1000 0

Meaning


Mode transport transport

Type manual manual

Protocol ESP ESP

The output is straighforward for most fields except the AUX-SPI field. The AUX-SPI is the value of the auxiliary security parameter index. When the value is AH or ESP, AUX-SPI is always 0. When the value is AH+ESP, AUX-SPI is always a positive integer.

•

Configuring Manual IPsec Security Associations for an ES PIC

Examples: Configuring BGP MED •

Understanding the MED Attribute on page 1067

•

Example: Configuring the MED Attribute Directly on page 1069

•

Example: Configuring the MED Using Route Filters on page 1082

•

Example: Configuring the MED Using Communities on page 1095

•

Example: Associating the MED Path Attribute with the IGP Metric and Delaying MED Updates on page 1095

Understanding the MED Attribute The BGP multiple exit discriminator (MED, or MULTI_EXIT_DISC) is a non-transitive attribute, meaning that it is not propagated throughout the Internet, but only to adjacent autonomous systems (ASs). The MED attribute is optional, meaning that it is not always sent with the BGP updates. The purpose of MED is to influence how other ASs enter your AS to reach a certain prefix. The MED attribute has a value that is referred to as a metric. If all other factors in determining an exit point are equal, the exit point with the lowest metric is preferred. If a MED is received over an external BGP link, it is propagated over internal links to other BGP-enabled devices within the AS. BGP update messages include a MED metric if the route was learned from BGP and already had a MED metric associated with it, or if you configure the MED metric in the configuration file. A MED metric is advertised with a route according to the following general rules: •

A more specific metric overrides a less specific metric. That is, a group-specific metric overrides a global BGP metric, and a peer-specific metric overrides a global BGP or group-specific metric.

•

A metric defined with a routing policy overrides a metric defined with the metric-out statement.


1067


•

If any metric is defined, it overrides a metric received in a route.

•

If the received route does not have an associated MED metric, and if you do not explicitly configure a metric value, no metric is advertised. When you do not explicitly configure a metric value, the MED value is equivalent to zero (0) when advertising an active route.

Because the AS path rather than the number of hops between hosts is the primary criterion for BGP route selection, an AS with multiple connections to a peer AS can have multiple equivalent AS paths. When the routing table contains two routes to the same host in a neighboring AS, an MED metric assigned to each route can determine which to include in the forwarding table. The MED metric you assign can force traffic through a particular exit point in an AS. Figure 54 on page 1068 illustrates how MED metrics are used to determine route selection.

Figure 54: Default MED Example

Figure 54 on page 1068 shows AS 1 and AS 2 connected by two separate BGP links to Routers C and D. Host E in AS 1 is located nearer to Router C. Host F, also in AS 1, is located nearer to Router D. Because the AS paths are equivalent, two routes exist for each host, one through Router C and one through Router D. To force all traffic destined for Host E through Router C, the network administrator for AS 2 assigns an MED metric for each router to Host E at its exit point. An MED metric of 10 is assigned to the route to Host E through Router C, and an MED metric of 20 is assigned to the route to Host E through Router D. BGP routers in AS 2 then select the route with the lower MED metric for the forwarding table. By default, only the MEDs of routes that have the same peer ASs are compared. However, you can configure the routing table path selection options listed in Table 12 on page 1069 to compare MEDs in different ways. The MED options are not mutually exclusive and can be configured in combination or independently. For the MED options to take effect, you must configure them uniformly all through your network. The MED option or options you configure determine the route selected. Thus we recommend that you carefully evaluate your network for preferred routes before configuring the MED options.

1068



Table 12: MED Options for Routing Table Path Selection Option (Name)

Function

Use

Always comparing MEDs (always-compare-med)

Ensures that the MEDs for paths from peers in different ASs are always compared in the route selection process.

Useful when all enterprises participating in a network agree on a uniform policy for setting MEDs. For example, in a network shared by two ISPs, both must agree that a certain path is the better path to configure the MED values correctly.

Adding IGP cost to MED (med-plus-igp)

Before comparing MED values for path selection, adds to the MED the cost of the IGP route to the BGP next-hop destination.

Useful when the downstream AS requires the complete cost of a certain route that is received across multiple ASs.

This option replaces the MED value for the router, but does not affect the IGP metric comparison. As a result, when multiple routes have the same value after the MED-plus-IPG comparison, and route selection continues, the IGP route metric is also compared, even though it was added to the MED value and compared earlier in the selection process. Applying Cisco IOS nondeterministic behavior (cisco-non-deterministic)

Specifies the nondeterministic behavior of the Cisco IOS software: •

The active path is always first. All nonactive but eligible paths follow the active path and are maintained in the order in which they were received. Ineligible paths remain at the end of the list.

•

When a new path is added to the routing table, path comparisons are made among all routes, including those paths that must never be selected because they lose the MED tie-breaking rule.

We recommend that you do not configure this option, because the nondeterministic behavior sometimes prevents the system from properly comparing the MEDs between paths.

Example: Configuring the MED Attribute Directly This example shows how to configure a multiple exit discriminator (MED) metric to advertise in BGP update messages. •


•


•


•



1069



Overview To directly configure a MED metric to advertise in BGP update messages, include the metric-out statement: metric-out (metric | minimum-igp offset | igp delay-med-update | offset); metric is the primary metric on all routes sent to peers. It can be a value in the range 32

from 0 through 4,294,967,295 (2

– 1).

The following optional settings are also supported: •

minimum-igp—Sets the metric to the minimum metric value calculated in the interior

gateway protocol (IGP) to get to the BGP next hop. If a newly calculated metric is greater than the minimum metric value, the metric value remains unchanged. If a newly calculated metric is lower, the metric value is lowered to that value. •

igp—Sets the metric to the most recent metric value calculated in the IGP to get to the

BGP next hop. •

delay-med-update—Delays sending MED updates when the MED value increases.

Include the delay-med-update statement when you configure the igp statement. The default interval to delay sending updates, unless the MED is lower or another attribute associated with the route has changed is 10 minutes. Include the med-igp-update-interval minutes statement at the [edit routing-options] hierarchy level to modify the default interval. •

offset—Specifies a value for offset to increase or decrease the metric that is used from

the metric value calculated in the IGP. The metric value is offset by the value specified. The metric calculated in the IGP (by specifying either igp or igp-minimum) is increased if the offset value is positive. The metric calculated in the IGP (by specifying either igp or igp-minimum) is decreased if the offset value is negative. 31

31

offset can be a value in the range from –2 through 2 – 1. Note that the adjusted metric

can never go below 0 or above 2

32

– 1.

Figure 55 on page 1071 shows a typical network with internal peer sessions and multiple exit points to a neighboring autonomous system (AS).

1070



Figure 55: Typical Network with IBGP Sessions and Multiple Exit Points R2 AS123 12.12.12.0/24

24.24.24.0/24

R1

R4

AS123

AS4 34.34.34.0/24

R3 AS123

g041151

13.13.13.0/24

Device R4 has multiple loopback interfaces configured to simulate advertised prefixes. The extra loopback interface addresses are 44.44.44.44/32 and 144.144.144.144/32. This example shows how to configure Device R4 to advertise a MED value of 30 to Device R3 and a MED value of 20 to Device R2. This causes all of the devices in AS 123 to prefer the path through Device R2 to reach AS 4.

Configuration


Device R1

•

Configuring Device R1 on page 1073

•


•


•


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set interfaces fe-1/2/0 unit 1 family inet address 12.12.12.1/24 set interfaces fe-1/2/1 unit 2 family inet address 13.13.13.1/24 set interfaces lo0 unit 1 family inet address 192.168.1.1/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.1.1 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.2.1 set protocols bgp group internal neighbor 192.168.3.1 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.1 set protocols ospf area 0.0.0.0 interface fe-1/2/1.2 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 123 set routing-options router-id 192.168.1.1


1071


1072

Device R2

set interfaces fe-1/2/0 unit 3 family inet address 12.12.12.2/24 set interfaces fe-1/2/1 unit 4 family inet address 24.24.24.2/24 set interfaces lo0 unit 2 family inet address 192.168.2.1/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.2.1 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.1.1 set protocols bgp group internal neighbor 192.168.3.1 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external peer-as 4 set protocols bgp group external neighbor 24.24.24.4 set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.3 set protocols ospf area 0.0.0.0 interface fe-1/2/1.4 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 123 set routing-options router-id 192.168.2.1

Device R3


Device R4

set interfaces fe-1/2/0 unit 7 family inet address 24.24.24.4/24 set interfaces fe-1/2/1 unit 8 family inet address 34.34.34.4/24 set interfaces lo0 unit 4 family inet address 192.168.4.1/32 set interfaces lo0 unit 4 family inet address 44.44.44.44/32 set interfaces lo0 unit 4 family inet address 144.144.144.144/32 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external peer-as 123 set protocols bgp group external neighbor 34.34.34.3 metric-out 30 set protocols bgp group external neighbor 24.24.24.2 metric-out 20 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 4 set routing-options router-id 192.168.4.1



Configuring Device R1 Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Device R1: 1.

Configure the interfaces. [edit interfaces fe-1/2/0 unit 1] user@R1# set family inet address 12.12.12.1/24 [edit interfaces fe-1/2/1 unit 2] user@R1# set family inet address 13.13.13.1/24 [edit interfaces lo0 unit 1] user@R1# set family inet address 192.168.1.1/32

2.

Configure BGP. [edit protocols bgp group internal] user@R1# set type internal user@R1# set local-address 192.168.1.1 user@R1# set export send-direct user@R1# set neighbor 192.168.2.1 user@R1# set neighbor 192.168.3.1

3.

Configure OSPF. [edit protocols ospf area 0.0.0.0] user@R1# set interface lo0.1 passive user@R1# set interface fe-1/2/0.1 user@R1# set interface fe-1/2/1.2

4.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit policy-options policy-statement send-direct term 1] user@R1# set from protocol direct user@R1# set then accept

5.

Configure the router ID and autonomous system (AS) number. [edit routing-options] user@R1# set autonomous-system 123 user@R1# set router-id 192.168.1.1

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show interfaces fe-1/2/0 {


1073


unit 1 { family inet { address 12.12.12.1/24; } } } fe-1/2/1 { unit 2 { family inet { address 13.13.13.1/24; } } } lo0 { unit 1 { family inet { address 192.168.1.1/32; } } } user@R1# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R1# show protocols bgp { group internal { type internal; local-address 192.168.1.1; export send-direct; neighbor 192.168.2.1; neighbor 192.168.3.1; } } ospf { area 0.0.0.0 { interface lo0.1 { passive; } interface fe-1/2/0.1; interface fe-1/2/1.2; } } user@R1# show routing-options autonomous-system 123; router-id 192.168.1.1;


1074






2.

Configure BGP. [edit protocols bgp group internal] user@R2# set type internal user@R2# set local-address 192.168.2.1 user@R2# set export send-direct user@R2# set neighbor 192.168.1.1 user@R2# set neighbor 192.168.3.1 [edit protocols bgp group external] user@R2# set type external user@R2# set export send-direct user@R2# set peer-as 4 user@R2# set neighbor 24.24.24.4

3.


4.


5.



1075


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R2# show interfaces fe-1/2/0 { unit 3 { family inet { address 12.12.12.2/24; } } } fe-1/2/1 { unit 4 { family inet { address 24.24.24.2/24; } } } lo0 { unit 2 { family inet { address 192.168.2.1/32; } } } user@R2# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R2# show protocols bgp { group internal { type internal; local-address 192.168.2.1; export send-direct; neighbor 192.168.1.1; neighbor 192.168.3.1; } group external { type external; export send-direct; peer-as 4; neighbor 24.24.24.4; } } ospf { area 0.0.0.0 { interface lo0.2 { passive;

1076



} interface fe-1/2/0.3; interface fe-1/2/1.4; } } user@R2# show routing-options autonomous-system 123; router-id 192.168.2.1;

If you are done configuring the device, enter commit from configuration mode. Configuring Device R3 Step-by-Step Procedure



2.


3.


4.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes.


1077


[edit policy-options policy-statement send-direct term 1] user@R3# set from protocol direct user@R3# set then accept 5.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R3# show interfaces fe-1/2/0 { unit 5 { family inet { address 13.13.13.3/24; } } } fe-1/2/1 { unit 6 { family inet { address 34.34.34.3/24; } } } lo0 { unit 3 { family inet { address 192.168.3.1/32; } } } user@R3# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R3# show protocols bgp { group internal { type internal; local-address 192.168.3.1; export send-direct; neighbor 192.168.1.1; neighbor 192.168.2.1; } group external {

1078



type external; export send-direct; peer-as 4; neighbor 34.34.34.4; } } ospf { area 0.0.0.0 { interface lo0.3 { passive; } interface fe-1/2/0.5; interface fe-1/2/1.6; } } user@R3# show routing-options autonomous-system 123; router-id 192.168.3.1;



Configure the interfaces. [edit interfaces fe-1/2/0 unit 7] user@R4# set family inet address 24.24.24.4/24 [edit interfaces fe-1/2/1 unit 8] user@R4# set family inet address 34.34.34.4/24 [edit interfaces lo0 unit 4] user@R4# set family inet address 192.168.4.1/32 user@R4# set family inet address 44.44.44.44/32 user@R4# set family inet address 144.144.144.144/32

Device R4 has multiple loopback interface addresses to simulate advertised prefixes. 2.


3.

Configure BGP. [edit protocols bgp group external] user@R4# set type external


1079


user@R4# set export send-direct user@R4# set peer-as 123 4.

Configure a MED value of 30 for neighbor Device R3, and a MED value of 20 for neighbor Device R2. [edit protocols bgp group external] user@R4# set neighbor 34.34.34.3 metric-out 30 user@R4# set neighbor 24.24.24.2 metric-out 20

This configuration causes autonomous system (AS) 123 (of which Device R1, Device R2, and Device R3 are members) to prefer the path through Device R2 to reach AS 4. 5.

Configure the router ID and AS number. [edit routing-options] user@R4# set autonomous-system 4 user@R4# set router-id 192.168.4.1

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R4# show interfaces fe-1/2/0 { unit 7 { family inet { address 24.24.24.4/24; } } } fe-1/2/1 { unit 8 { family inet { address 34.34.34.4/24; } } } lo0 { unit 4 { family inet { address 192.168.4.1/32; address 44.44.44.44/32; address 144.144.144.144/32; } } } user@R4# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } }

1080



user@R4# show protocols bgp { group external { type external; export send-direct; peer-as 123; neighbor 34.34.34.3 { metric-out 30; } neighbor 24.24.24.2 { metric-out 20; } } } user@R4# show routing-options autonomous-system 4; router-id 192.168.4.1;



Checking the Active Path From Device R1 to Device R4 on page 1081

•

Verifying That Device R4 Is Sending Its Routes Correctly on page 1082

Checking the Active Path From Device R1 to Device R4 Purpose Action

Verify that the active path goes through Device R2. From operational mode, enter the show route protocol bgp command. user@R1> show route protocol bgp inet.0: 13 destinations, 19 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 12.12.12.0/24

[BGP/170] 3d 22:52:38, localpref 100, AS path: I > to 12.12.12.2 via fe-1/2/0.1 13.13.13.0/24 [BGP/170] 3d 03:15:16, localpref 100, AS path: I > to 13.13.13.3 via fe-1/2/1.2 24.24.24.0/24 [BGP/170] 3d 22:52:38, localpref 100, AS path: I > to 12.12.12.2 via fe-1/2/0.1 34.34.34.0/24 [BGP/170] 3d 03:15:16, localpref 100, AS path: I > to 13.13.13.3 via fe-1/2/1.2 44.44.44.44/32 *[BGP/170] 01:41:11, MED 20, localpref AS path: 4 I > to 12.12.12.2 via fe-1/2/0.1 144.144.144.144/32 *[BGP/170] 00:08:13, MED 20, localpref AS path: 4 I > to 12.12.12.2 via fe-1/2/0.1 192.168.2.1/32 [BGP/170] 3d 22:52:38, localpref 100, AS path: I


from 192.168.2.1

from 192.168.3.1

from 192.168.2.1

from 192.168.3.1

100, from 192.168.2.1

100, from 192.168.2.1

from 192.168.2.1

1081


192.168.3.1/32

192.168.4.1/32

Meaning

> to 12.12.12.2 via fe-1/2/0.1 [BGP/170] 3d 03:15:16, localpref 100, from 192.168.3.1 AS path: I > to 13.13.13.3 via fe-1/2/1.2 *[BGP/170] 01:41:11, MED 20, localpref 100, from 192.168.2.1 AS path: 4 I > to 12.12.12.2 via fe-1/2/0.1

The asterisk (*) shows that the preferred path is through Device R2. The reason for the path selection is listed as MED 20. Verifying That Device R4 Is Sending Its Routes Correctly

Purpose

Action

Make sure that Device R4 is sending update messages with a value of 20 to Device R2 and a value of 30 to Device R3. From operational mode, enter the show route advertising-protocol bgp 24.24.24.2 command. user@R4> show route advertising-protocol bgp 24.24.24.2 inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 24.24.24.0/24 Self 20 I * 34.34.34.0/24 Self 20 I * 44.44.44.44/32 Self 20 I * 144.144.144.144/32 Self 20 I * 192.168.4.1/32 Self 20 I user@R4> show route advertising-protocol bgp 34.34.34.3 inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 24.24.24.0/24 Self 30 I * 34.34.34.0/24 Self 30 I * 44.44.44.44/32 Self 30 I * 144.144.144.144/32 Self 30 I * 192.168.4.1/32 Self 30 I

Meaning

The MED column shows that Device R4 is sending the correct MED values to its two external BGP (EBGP) neighbors.

Example: Configuring the MED Using Route Filters This example shows how to configure a policy that uses route filters to modify the multiple exit discriminator (MED) metric to advertise in BGP update messages. •


•


•


•



1082



Overview To configure a route-filter policy that modifies the advertised MED metric in BGP update messages, include the metric statement in the policy action. Figure 56 on page 1083 shows a typical network with internal peer sessions and multiple exit points to a neighboring autonomous system (AS).


24.24.24.0/24

R1

R4

AS123

AS4 34.34.34.0/24

R3 AS123

g041151

13.13.13.0/24

Device R4 has multiple loopback interfaces configured to simulate advertised prefixes. The extra loopback interface addresses are 44.44.44.44/32 and 144.144.144.144/32. This example shows how to configure Device R4 to advertise a MED value of 30 to Device R3 for all routes except 144.144.144.144. For 144.144.144.144, a MED value of 10 is advertised to Device 3. A MED value of 20 is advertised to Device R2, regardless of the route prefix.


Device R1

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set interfaces fe-1/2/0 unit 1 family inet address 12.12.12.1/24 set interfaces fe-1/2/1 unit 2 family inet address 13.13.13.1/24 set interfaces lo0 unit 1 family inet address 192.168.1.1/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.1.1 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.2.1 set protocols bgp group internal neighbor 192.168.3.1 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.1 set protocols ospf area 0.0.0.0 interface fe-1/2/1.2 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 123


1083


set routing-options router-id 192.168.1.1

1084

Device R2


Device R3


Device R4

set interfaces fe-1/2/0 unit 7 family inet address 24.24.24.4/24 set interfaces fe-1/2/1 unit 8 family inet address 34.34.34.4/24 set interfaces lo0 unit 4 family inet address 192.168.4.1/32 set interfaces lo0 unit 4 family inet address 44.44.44.44/32 set interfaces lo0 unit 4 family inet address 144.144.144.144/32 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external peer-as 123 set protocols bgp group external neighbor 34.34.34.3 export med-10 set protocols bgp group external neighbor 34.34.34.3 export med-30 set protocols bgp group external neighbor 24.24.24.2 metric-out 20 set policy-options policy-statement med-10 from route-filter 144.144.144.144/32 exact set policy-options policy-statement med-10 then metric 10



set policy-options policy-statement med-10 then accept set policy-options policy-statement med-30 from route-filter 0.0.0.0/0 longer set policy-options policy-statement med-30 then metric 30 set policy-options policy-statement med-30 then accept set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 4 set routing-options router-id 192.168.4.1




2.


3.


4.


5.



1085


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show interfaces fe-1/2/0 { unit 1 { family inet { address 12.12.12.1/24; } } } fe-1/2/1 { unit 2 { family inet { address 13.13.13.1/24; } } } lo0 { unit 1 { family inet { address 192.168.1.1/32; } } } user@R1# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R1# show protocols bgp { group internal { type internal; local-address 192.168.1.1; export send-direct; neighbor 192.168.2.1; neighbor 192.168.3.1; } } ospf { area 0.0.0.0 { interface lo0.1 { passive; } interface fe-1/2/0.1; interface fe-1/2/1.2; } } user@R1# show routing-options

1086



autonomous-system 123; router-id 192.168.1.1;




2.


3.


4.


5.

Configure the router ID and autonomous system (AS) number. [edit routing-options]


1087


user@R2# set autonomous-system 123 user@R2# set router-id 192.168.2.1

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R2# show interfaces fe-1/2/0 { unit 3 { family inet { address 12.12.12.2/24; } } } fe-1/2/1 { unit 4 { family inet { address 24.24.24.2/24; } } } lo0 { unit 2 { family inet { address 192.168.2.1/32; } } } user@R2# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R2# show protocols bgp { group internal { type internal; local-address 192.168.2.1; export send-direct; neighbor 192.168.1.1; neighbor 192.168.3.1; } group external { type external; export send-direct; peer-as 4; neighbor 24.24.24.4; } } ospf {

1088



area 0.0.0.0 { interface lo0.2 { passive; } interface fe-1/2/0.3; interface fe-1/2/1.4; } } user@R2# show routing-options autonomous-system 123; router-id 192.168.2.1;




2.


3.


4.

Configure a policy that accepts direct routes.


1089


Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit policy-options policy-statement send-direct term 1] user@R3# set from protocol direct user@R3# set then accept 5.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R3# show interfaces fe-1/2/0 { unit 5 { family inet { address 13.13.13.3/24; } } } fe-1/2/1 { unit 6 { family inet { address 34.34.34.3/24; } } } lo0 { unit 3 { family inet { address 192.168.3.1/32; } } } user@R3# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R3# show protocols bgp { group internal { type internal; local-address 192.168.3.1; export send-direct; neighbor 192.168.1.1; neighbor 192.168.2.1;

1090



} group external { type external; export send-direct; peer-as 4; neighbor 34.34.34.4; } } ospf { area 0.0.0.0 { interface lo0.3 { passive; } interface fe-1/2/0.5; interface fe-1/2/1.6; } } user@R3# show routing-options autonomous-system 123; router-id 192.168.3.1;



Configure the interfaces. [edit interfaces fe-1/2/0 unit 7] user@R4# set family inet address 24.24.24.4/24 [edit interfaces fe-1/2/1 unit 8] user@R4# set family inet address 34.34.34.4/24 [edit interfaces lo0 unit 4] user@R4# set family inet address 192.168.4.1/32 user@R4# set family inet address 44.44.44.44/32 user@R4# set family inet address 144.144.144.144/32

Device R4 has multiple loopback interface addresses to simulate advertised prefixes. 2.


3.

Configure BGP.


1091


[edit protocols bgp group external] user@R4# set type external user@R4# set export send-direct user@R4# set peer-as 123 4.

Configure the two MED policies. [edit policy-options] set policy-statement med-10 from route-filter 144.144.144.144/32 exact set policy-statement med-10 then metric 10 set policy-statement med-10 then accept set policy-statement med-30 from route-filter 0.0.0.0/0 longer set policy-statement med-30 then metric 30 set policy-statement med-30 then accept

5.

Configure the two EBGP neighbors, applying the two MED policies to Device R3, and a MED value of 20 to Device R2. [edit protocols bgp group external] user@R4# set neighbor 34.34.34.3 export med-10 user@R4# set neighbor 34.34.34.3 export med-30 user@R4# set neighbor 24.24.24.2 metric-out 20

6.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R4# show interfaces fe-1/2/0 { unit 7 { family inet { address 24.24.24.4/24; } } } fe-1/2/1 { unit 8 { family inet { address 34.34.34.4/24; } } } lo0 { unit 4 { family inet { address 192.168.4.1/32; address 44.44.44.44/32; address 144.144.144.144/32; } }

1092



} user@R4# show policy-options policy-statement med-10 { from { route-filter 144.144.144.144/32 exact; } then { metric 10; accept; } } policy-statement med-30 { from { route-filter 0.0.0.0/0 longer; } then { metric 30; accept; } } policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R4# show protocols bgp { group external { type external; export send-direct; peer-as 123; neighbor 24.24.24.2 { metric-out 20; } neighbor 34.34.34.3 { export [ med-10 med-30 ]; } } } user@R4# show routing-options autonomous-system 4; router-id 192.168.4.1;




•

Verifying That Device R4 Is Sending Its Routes Correctly on page 1094


1093




[BGP/170] 4d 01:13:32, localpref 100, AS path: I > to 12.12.12.2 via fe-1/2/0.1 13.13.13.0/24 [BGP/170] 3d 05:36:10, localpref 100, AS path: I > to 13.13.13.3 via fe-1/2/1.2 24.24.24.0/24 [BGP/170] 4d 01:13:32, localpref 100, AS path: I > to 12.12.12.2 via fe-1/2/0.1 34.34.34.0/24 [BGP/170] 3d 05:36:10, localpref 100, AS path: I > to 13.13.13.3 via fe-1/2/1.2 44.44.44.44/32 *[BGP/170] 00:06:03, MED 20, localpref AS path: 4 I > to 12.12.12.2 via fe-1/2/0.1 144.144.144.144/32 *[BGP/170] 00:06:03, MED 10, localpref AS path: 4 I > to 13.13.13.3 via fe-1/2/1.2 192.168.2.1/32 [BGP/170] 4d 01:13:32, localpref 100, AS path: I > to 12.12.12.2 via fe-1/2/0.1 192.168.3.1/32 [BGP/170] 3d 05:36:10, localpref 100, AS path: I > to 13.13.13.3 via fe-1/2/1.2 192.168.4.1/32 *[BGP/170] 00:06:03, MED 20, localpref AS path: 4 I > to 12.12.12.2 via fe-1/2/0.1

Meaning

from 192.168.2.1

from 192.168.3.1

from 192.168.2.1

from 192.168.3.1

100, from 192.168.2.1

100, from 192.168.3.1

from 192.168.2.1

from 192.168.3.1

100, from 192.168.2.1

The output shows that the preferred path to the routes advertised by Device R4 is through Device R2 for all routes except 144.144.144.144/32. For 144.144.144.144/32, the preferred path is through Device R3. Verifying That Device R4 Is Sending Its Routes Correctly

Purpose

Action

Make sure that Device R4 is sending update messages with a value of 20 to Device R2 and a value of 30 to Device R3. From operational mode, enter the show route advertising-protocol bgp 24.24.24.2 command. user@R4> show route advertising-protocol bgp 24.24.24.2 inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 24.24.24.0/24 Self 20 I * 34.34.34.0/24 Self 20 I * 44.44.44.44/32 Self 20 I * 144.144.144.144/32 Self 20 I * 192.168.4.1/32 Self 20 I

1094



user@R4> show route advertising-protocol bgp 34.34.34.3 inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 24.24.24.0/24 Self 30 I * 34.34.34.0/24 Self 30 I * 44.44.44.44/32 Self 30 I * 144.144.144.144/32 Self 10 I * 192.168.4.1/32 Self 30 I

Meaning

The MED column shows that Device R4 is sending the correct MED values to its two EBGP neighbors.

Example: Configuring the MED Using Communities Set the multiple exit discriminator (MED) metric to 20 for all routes from a particular community. [edit] routing-options { router-id 10.0.0.1; autonomous-system 23; } policy-options { policy-statement from-otago { from community otago; then metric 20; } community otago members [56:2379 23:46944]; } protocols { bgp { import from-otago; group 23 { type external; peer-as 56; neighbor 192.168.0.1 { traceoptions { file bgp-log-peer; flag packets; } log-updown; } } } }

Example: Associating the MED Path Attribute with the IGP Metric and Delaying MED Updates This example shows how to associate the multiple exit discriminator (MED) path attribute with the interior gateway protocol (IGP) metric, and configure a timer to delay update of the MED attribute. •


•



1095


•


•



Overview BGP can be configured to advertise the MED attribute for a route based on the IGP distance of its internal BGP (IBGP) route next-hop. The IGP metric enables internal routing to follow the shortest path according to the administrative setup. In some deployments, it might be ideal to communicate IGP shortest-path knowledge to external BGP (EBGP) peers in a neighboring autonomous system (AS). This allows those EBGP peers to forward traffic into your AS using the shortest paths possible. Routes learned from an EBGP peer usually have a next hop on a directly connected interface, and thus the IGP value is equal to zero. Zero is the value advertised. The IGP metric is a nonzero value when a BGP peer sends third-party next hops that require the local system to perform next-hop resolution—IBGP configurations, configurations within confederation peers, or EBGP configurations that include the multihop command. In these scenarios, it might make sense to associate the MED value with the IGP metric by including the metric-out minimum-igp or metric-out igp option. The drawback of associating the MED with the IGP metric is the risk of excessive route advertisements when there are IGP instabilities in the network. Configuring a delay for the MED update provides a mechanism to reduce route advertisements in such scenarios. The delay works by slowing down MED updates when the IGP metric for the next hop changes. The approach uses a timer to periodically advertise MED updates. When the timer expires, the MED attribute for routes with metric-out igp delay-updates configured is updated to the current IGP metric of the next hop. The BGP-enabled device sends out advertisements for routes for which the MED attribute has changed. The delay-updates option identifies the BGP groups (or peers) for which the MED updates must be suppressed. The time for advertising MED updates is set to 10 minutes by default. You can increase the interval up to 600 minutes by including the med-igp-update-interval statement in the routing-options configuration.

NOTE: If you have nonstop active routing (NSR) enabled and a switchover occurs, the delayed MED updates might be advertised as soon as the switchover occurs.

When you configure the metric-out igp option, the IGP metric directly tracks the IGP cost to the IBGP peer. When the IGP cost goes down, so does the advertised MED value. Conversely, when the IGP cost goes up, the MED value goes up as well. When you configure the metric-out minimum-igp option, the advertised MED value changes only when the IGP cost to the IBGP peer goes down. An increase in the IGP cost does not affect the MED value. The router monitors and remembers the lowest IGP cost until the

1096



routing process (rpd) is restarted. The BGP peer sends an update only if the MED is lower than the previously advertised value or another attribute associated with the route has changed, or if the BGP peer is responding to a refresh route request. This example uses the metric statement in the OSPF configuration to demonstrate that when the IGP metric changes, the MED also changes after the configured delay interval. The OSPF metric can range from 1 through 65,535. Figure 57 on page 1097 shows the sample topology.

Figure 57: Topology for Delaying the MED Update AS 1

R2

R1

R3

AS 2 R4

R5

R6

R8

AS 3

g041155

R7

In this example, the MED value advertised by Device R1 is associated with the IGP running in AS 1. The MED value advertised by Device R1 impacts the decisions of the neighboring AS (AS 2) when AS 2 is forwarding traffic into AS 1.

Configuration •



1097



1098


Device R1

set interfaces fe-1/2/0 unit 2 description R1->R2 set interfaces fe-1/2/0 unit 2 family inet address 10.0.0.1/30 set interfaces fe-1/2/1 unit 7 description R1->R4 set interfaces fe-1/2/1 unit 7 family inet address 172.16.0.1/30 set interfaces lo0 unit 1 family inet address 192.168.0.1/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.0.1 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.0.2 set protocols bgp group internal neighbor 192.168.0.3 set protocols bgp group external type external set protocols bgp group external metric-out igp delay-med-update set protocols bgp group external export send-direct set protocols bgp group external peer-as 2 set protocols bgp group external neighbor 172.16.0.2 set protocols ospf area 0.0.0.0 interface fe-1/2/0.2 metric 600 set protocols ospf area 0.0.0.0 interface lo0.1 passive set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options med-igp-update-interval 12 set routing-options router-id 192.168.0.1 set routing-options autonomous-system 1

Device R2

set interfaces fe-1/2/0 unit 1 description R2->R1 set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 4 description R2->R3 set interfaces fe-1/2/1 unit 4 family inet address 10.0.2.2/30 set interfaces lo0 unit 2 family inet address 192.168.0.2/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.0.2 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.0.1 set protocols bgp group internal neighbor 192.168.0.3 set protocols ospf area 0.0.0.0 interface fe-1/2/0.1 set protocols ospf area 0.0.0.0 interface fe-1/2/1.4 set protocols ospf area 0.0.0.0 interface lo0.2 passive set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options router-id 192.168.0.2 set routing-options autonomous-system 1

Device R3

set interfaces fe-1/2/0 unit 3 description R3->R2 set interfaces fe-1/2/0 unit 3 family inet address 10.0.2.1/30 set interfaces fe-1/2/1 unit 5 description R3->R5 set interfaces fe-1/2/1 unit 5 family inet address 172.16.0.5/30 set interfaces lo0 unit 3 family inet address 192.168.0.3/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.0.3 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.0.1



set protocols bgp group internal neighbor 192.168.0.2 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external peer-as 2 set protocols bgp group external neighbor 172.16.0.6 set protocols ospf area 0.0.0.0 interface fe-1/2/0.3 set protocols ospf area 0.0.0.0 interface lo0.3 passive set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options router-id 192.168.0.3 set routing-options autonomous-system 1

Device R4

set interfaces fe-1/2/0 unit 8 description R4->R1 set interfaces fe-1/2/0 unit 8 family inet address 172.16.0.2/30 set interfaces fe-1/2/1 unit 9 description R4->R5 set interfaces fe-1/2/1 unit 9 family inet address 10.0.4.1/30 set interfaces fe-1/2/2 unit 13 description R4->R6 set interfaces fe-1/2/2 unit 13 family inet address 172.16.0.9/30 set interfaces lo0 unit 4 family inet address 192.168.0.4/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.0.4 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.0.5 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external neighbor 172.16.0.10 peer-as 3 set protocols bgp group external neighbor 172.16.0.1 peer-as 1 set protocols ospf area 0.0.0.0 interface fe-1/2/1.9 set protocols ospf area 0.0.0.0 interface lo0.4 passive set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options router-id 192.168.0.4 set routing-options autonomous-system 2

Device R5

set interfaces fe-1/2/0 unit 6 description R5->R3 set interfaces fe-1/2/0 unit 6 family inet address 172.16.0.6/30 set interfaces fe-1/2/1 unit 10 description R5->R4 set interfaces fe-1/2/1 unit 10 family inet address 10.0.4.2/30 set interfaces fe-1/2/2 unit 11 description R5->R8 set interfaces fe-1/2/2 unit 11 family inet address 172.16.0.13/30 set interfaces lo0 unit 5 family inet address 192.168.0.5/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.0.5 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.0.4 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external neighbor 172.16.0.5 peer-as 1 set protocols bgp group external neighbor 172.16.0.14 peer-as 3 set protocols ospf area 0.0.0.0 interface fe-1/2/1.10 set protocols ospf area 0.0.0.0 interface lo0.5 passive set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options router-id 192.168.0.5 set routing-options autonomous-system 2


1099


1100

Device R6

set interfaces fe-1/2/0 unit 14 description R6->R4 set interfaces fe-1/2/0 unit 14 family inet address 172.16.0.10/30 set interfaces fe-1/2/1 unit 15 description R6->R7 set interfaces fe-1/2/1 unit 15 family inet address 10.0.6.1/30 set interfaces lo0 unit 6 family inet address 192.168.0.6/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.0.6 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.0.7 set protocols bgp group internal neighbor 192.168.0.8 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external peer-as 2 set protocols bgp group external neighbor 172.16.0.9 peer-as 2 set protocols ospf area 0.0.0.0 interface fe-1/2/1.15 set protocols ospf area 0.0.0.0 interface lo0.6 passive set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options router-id 192.168.0.6 set routing-options autonomous-system 3

Device R7

set interfaces fe-1/2/0 unit 16 description R7->R6 set interfaces fe-1/2/0 unit 16 family inet address 10.0.6.2/30 set interfaces fe-1/2/1 unit 17 description R7->R8 set interfaces fe-1/2/1 unit 17 family inet address 10.0.7.2/30 set interfaces lo0 unit 7 family inet address 192.168.0.7/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.0.7 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.0.6 set protocols bgp group internal neighbor 192.168.0.8 set protocols ospf area 0.0.0.0 interface fe-1/2/0.16 set protocols ospf area 0.0.0.0 interface fe-1/2/1.17 set protocols ospf area 0.0.0.0 interface lo0.7 passive set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options router-id 192.168.0.7 set routing-options autonomous-system 3

Device R8

set interfaces fe-1/2/0 unit 12 description R8->R5 set interfaces fe-1/2/0 unit 12 family inet address 172.16.0.14/30 set interfaces fe-1/2/1 unit 18 description R8->R7 set interfaces fe-1/2/1 unit 18 family inet address 10.0.7.1/30 set interfaces lo0 unit 8 family inet address 192.168.0.8/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.0.8 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.0.6 set protocols bgp group internal neighbor 192.168.0.7 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external peer-as 2 set protocols bgp group external neighbor 172.16.0.13 peer-as 2 set protocols ospf area 0.0.0.0 interface fe-1/2/1.18 set protocols ospf area 0.0.0.0 interface lo0.8 passive



set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options router-id 192.168.0.8 set routing-options autonomous-system 3



Configure the interfaces. [edit interfaces fe-1/2/0 unit 2] user@R1# set description R1->R2 user@R1# set family inet address 10.0.0.1/30 [edit interfaces fe-1/2/1 unit 7] user@R1# set description R1->R4 user@R1# set family inet address 172.16.0.1/30 [edit interfaces lo0 unit 1] user@R1# set family inet address 192.168.0.1/32

2.

Configure IBGP. [edit protocols bgp group internal] user@R1# set type internal user@R1# set local-address 192.168.0.1 user@R1# set export send-direct user@R1# set neighbor 192.168.0.2 user@R1# set neighbor 192.168.0.3

3.

Configure EBGP. [edit protocols bgp group external] user@R1# set type external user@R1# set export send-direct user@R1# set peer-as 2 user@R1# set neighbor 172.16.0.2

4.

Associate the MED value with the IGP metric. [edit protocols bgp group external] user@R1# set metric-out igp delay-med-update

The default for the MED update is 10 minutes when you include the delay-med-update option. When you exclude the delay-med-update option, the MED update occurs immediately after the IGP metric changes. 5.

(Optional) Configure the update interval for the MED update. [edit routing-options] user@R1# set med-igp-update-interval 12

You can configure the interval from 10 minutes through 600 minutes.


1101


6.

Configure OSPF. [edit protocols ospf area 0.0.0.0] user@R1# set interface fe-1/2/0.2 metric 600 user@R1# set interface lo0.1 passive

The metric statement is used here to demonstrate what happens when the IGP metric changes. 7.


8.

Configure the router ID and autonomous system (AS) number. [edit routing-options] user@R1# set router-id 192.168.0.1 user@R1# set autonomous-system 1

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show interfaces fe-1/2/0 { unit 2 { description R1->R2; family inet { address 10.0.0.1/30; } } } fe-1/2/1 { unit 7 { description R1->R4; family inet { address 172.16.0.1/30; } } } lo0 { unit 1 { family inet { address 192.168.0.1/32; } } } user@R1# show policy-options policy-statement send-direct { term 1 {

1102



from protocol direct; then accept; } } user@R1# show protocols bgp { group internal { type internal; local-address 192.168.0.1; export send-direct; neighbor 192.168.0.2; neighbor 192.168.0.3; } group external { type external; metric-out igp delay-med-update; export send-direct; peer-as 2; neighbor 172.16.0.2; } } ospf { area 0.0.0.0 { interface fe-1/2/0.2 { metric 600; } interface lo0.1 { passive; } } } user@R1# show routing-options med-igp-update-interval 12; router-id 192.168.0.1; autonomous-system 1;

If you are done configuring the device, enter commit from configuration mode. Repeat the configuration steps on the other devices in the topology, as needed for your network.


Checking the BGP Advertisements on page 1103

•

Verifying That the MED Value Changes When the OSPF Metric Changes on page 1104

•

Testing the minimum-igp Setting on page 1104

Checking the BGP Advertisements Purpose

Action

Verify that Device R1 is advertising to Device R4 a BGP MED value that reflects the IGP metric. From operational mode, enter the show route advertising-protocol bgp command.


1103


user@R1> show route advertising-protocol bgp 172.16.0.2 inet.0: 19 destinations, 33 routes (19 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.0/30 Self 0 I * 172.16.0.0/30 Self 0 I * 172.16.0.4/30 Self 601 I * 192.168.0.1/32 Self 0 I

Meaning

The 601 value in the MED column shows that the MED value has been updated to reflect the configured OSPF metric. Verifying That the MED Value Changes When the OSPF Metric Changes

Purpose

Action

Make sure that when you raise the OSPF metric to 700, the MED value is updated to reflect this change. From configuration mode, enter the set protocols ospf area 0 interface fe-1/2/0.2 metric 700 command. user@R1# set protocols ospf area 0 interface fe-1/2/0.2 metric 700 user@R1# commit

After waiting 12 minutes (the configured delay period), enter the show route advertising-protocol bgp command from operational mode. user@R1> show route advertising-protocol bgp 172.16.0.2 inet.0: 19 destinations, 33 routes (19 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.0/30 Self 0 I * 172.16.0.0/30 Self 0 I * 172.16.0.4/30 Self 701 I * 192.168.0.1/32 Self 0 I

Meaning

The 701 value in the MED column shows that the MED value has been updated to reflect the configured OSPF metric. Testing the minimum-igp Setting

Purpose

Action

Change the configuration to use the minimum-igp statement instead of the igp statement. When you increase the OSPF metric, the MED value remains unchanged, but when you decrease the OSPF metric, the MED value reflects the new OSPF metric. From configuration mode, delete the igp statement, add the minimum-igp statement, and increase the OSPF metric. user@R1# user@R1# user@R1# user@R1#

delete protocols bgp group external metric-out igp set protocols bgp group external metric-out minimum-igp set protocols ospf area 0 interface fe-1/2/0.2 metric 800 commit

From operational mode, enter the show route advertising-protocol bgp command to make sure that the MED value does not change. user@R1> show route advertising-protocol bgp 172.16.0.2 inet.0: 19 destinations, 33 routes (19 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.0/30 Self 0 I * 172.16.0.0/30 Self 0 I

1104



* 172.16.0.4/30 * 192.168.0.1/32

Self Self

701 0

I I

From configuration mode, decrease the OSPF metric. user@R1# set protocols ospf area 0 interface fe-1/2/0.2 metric 20 user@R1# commit

From operational mode, enter the show route advertising-protocol bgp command to make sure that the MED value does change. user@R1> show route advertising-protocol bgp 172.16.0.2 inet.0: 19 destinations, 33 routes (19 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.0/30 Self 0 I * 172.16.0.0/30 Self 0 I * 172.16.0.4/30 Self 21 I * 192.168.0.1/32 Self 0 I

Meaning


When the minimum-igp statement is configured, the MED value changes only when a shorter path is available.

•


•


Example: Configuring EBGP Multihop •

Understanding BGP Multihop on page 1105

•

Example: Configuring EBGP Multihop Sessions on page 1105

Understanding BGP Multihop When external BGP (EBGP) peers are not directly connected to each other, they must cross one or more non-BGP routers to reach each other. Configuring multihop EBGP enables the peers to pass through the other routers to form peer relationships and exchange update messages. This type of configuration is typically used when a Juniper Networks routing device needs to run EBGP with a third-party router that does not allow direct connection of the two EBGP peers. EBGP multihop enables a neighbor connection between two EBGP peers that do not have a direct connection.

Example: Configuring EBGP Multihop Sessions This example shows how to configure an external BGP (EBGP) peer that is more than one hop away from the local router. This type of session is called a multihop BGP session. •


•


•


•



1105



Overview The configuration to enable multihop EBGP sessions requires connectivity between the two EBGP peers. This example uses static routes to provide connectivity between the devices. Unlike directly connected EBGP sessions in which physical address are typically used in the neighbor statements, you must use loopback interface addresses for multihop EBGP by specifying the loopback interface address of the indirectly connected peer. In this way, EBGP multihop is similar to internal BGP (IBGP). Finally, you must add the multihop statement. Optionally, you can set a maximum time-to-live (TTL) value with the ttl statement. The TTL is carried in the IP header of BGP packets. If you do not specify a TTL value, the system’s default maximum TTL value is used. The default TTL value is 64 for multihop EBGP sessions. Another option is to retain the BGP next-hop value for route advertisements by including the no-nexthop-change statement. Figure 58 on page 1106 shows a typical EBGP multihop network. Device C and Device E have an established EBGP session. Device D is not a BGP-enabled device. All of the devices have connectivity via static routes.

Figure 58: Typical Network with EBGP Multihop Sessions AS 18

AS 17

D

E

g041150

C


Device C

1106

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set interfaces fe-1/2/0 unit 9 description to-D set interfaces fe-1/2/0 unit 9 family inet address 10.10.10.9/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group external-peers type external set protocols bgp group external-peers multihop ttl 2



set protocols bgp group external-peers local-address 192.168.40.4 set protocols bgp group external-peers export send-static set protocols bgp group external-peers peer-as 18 set protocols bgp group external-peers neighbor 192.168.6.7 set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 10.10.10.14/32 next-hop 10.10.10.10 set routing-options static route 192.168.6.7/32 next-hop 10.10.10.10 set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17

Device D

set interfaces fe-1/2/0 unit 10 description to-C set interfaces fe-1/2/0 unit 10 family inet address 10.10.10.10/30 set interfaces fe-1/2/1 unit 13 description to-E set interfaces fe-1/2/1 unit 13 family inet address 10.10.10.13/30 set interfaces lo0 unit 4 family inet address 192.168.6.6/32 set routing-options static route 192.168.40.4/32 next-hop 10.10.10.9 set routing-options static route 192.168.6.7/32 next-hop 10.10.10.14 set routing-options router-id 192.168.6.6

Device E

set interfaces fe-1/2/0 unit 14 description to-D set interfaces fe-1/2/0 unit 14 family inet address 10.10.10.14/30 set interfaces lo0 unit 5 family inet address 192.168.6.7/32 set protocols bgp group external-peers multihop ttl 2 set protocols bgp group external-peers local-address 192.168.6.7 set protocols bgp group external-peers export send-static set protocols bgp group external-peers peer-as 17 set protocols bgp group external-peers neighbor 192.168.40.4 set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 10.10.10.8/30 next-hop 10.10.10.13 set routing-options static route 192.168.40.4/32 next-hop 10.10.10.13 set routing-options router-id 192.168.6.7 set routing-options autonomous-system 18

Device C Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Device C: 1.

Configure the interface to the directly connected device (to-D), and configure the loopback interface. [edit interfaces fe-1/2/0 unit 9] user@C# set description to-D user@C# set family inet address 10.10.10.9/30 [edit interfaces lo0 unit 3] user@C# set family inet address 192.168.40.4/32

2.

Configure an EBGP session with Device E. The neighbor statement points to the loopback interface on Device E.


1107


[edit protocols bgp group external-peers] user@C# set type external user@C# set local-address 192.168.40.4 user@C# set export send-static user@C# set peer-as 18 user@C# set neighbor 192.168.6.7 3.

Configure the multihop statement to enable Device C and Device E to become EBGP peers. Because the peers are two hops away from each other, the example uses the ttl 2 statement. [edit protocols bgp group external-peers] user@C# set multihop ttl 2

4.

Configure connectivity to Device E, using static routes. You must configure a route to both the loopback interface address and to the address on the physical interface. [edit routing-options] user@C# set static route 10.10.10.14/32 next-hop 10.10.10.10 user@C# set static route 192.168.6.7/32 next-hop 10.10.10.10

5.

Configure the local router ID and the autonomous system (AS) number. [edit routing-options] user@C# set router-id 192.168.40.4 user@C# set autonomous-system 17

6.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit policy-options policy-statement send-static term 1] user@C# set from protocol static user@C# set then accept

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@C# show interfaces fe-1/2/0 { unit 9 { description to-D; family inet { address 10.10.10.9/30; } } } lo0 { unit 3 { family inet { address 192.168.40.4/32;

1108



} } } user@C# show protocols bgp { group external-peers { type external; multihop { ttl 2; } local-address 192.168.40.4; export send-static; peer-as 18; neighbor 192.168.6.7; } } user@C# show policy-options policy-statement send-static { term 1 { from protocol static; then accept; } } user@C# show routing-options static { route 10.10.10.14/32 next-hop 10.10.10.10; route 192.168.6.7/32 next-hop 10.10.10.10; } router-id 192.168.40.4; autonomous-system 17;

If you are done configuring the device, enter commit from configuration mode. Repeat these steps for all BFD sessions in the topology. Configuring Device D Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Device D: 1.

Set the CLI to Device D. user@host> set cli logical-system D

2.

Configure the interfaces to the directly connected devices, and configure a loopback interface. [edit interfaces fe-1/2/0 unit 10] user@D# set description to-C user@D# set family inet address 10.10.10.10/30 [edit interfaces fe-1/2/1 unit 13]


1109


user@D# set description to-E user@D# set family inet address 10.10.10.13/30 [edit interfaces lo0 unit 4] user@D# set family inet address 192.168.6.6/32 3.

Configure connectivity to the other devices using static routes to the loopback interface addresses. On Device D, you do not need static routes to the physical addresses because Device D is directly connected to Device C and Device E. [edit routing-options] user@D# set static route 192.168.40.4/32 next-hop 10.10.10.9 user@D# set static route 192.168.6.7/32 next-hop 10.10.10.14

4.

Configure the local router ID. [edit routing-options] user@D# set router-id 192.168.6.6

Results

From configuration mode, confirm your configuration by entering the show interfaces and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@D# show interfaces fe-1/2/0 { unit 10 { description to-C; family inet { address 10.10.10.10/30; } } } fe-1/2/1 { unit 13 { description to-E; family inet { address 10.10.10.13/30; } } } lo0 { unit 4 { family inet { address 192.168.6.6/32; } } } user@D# show protocols user@D# show routing-options static { route 192.168.40.4/32 next-hop 10.10.10.9; route 192.168.6.7/32 next-hop 10.10.10.14; }

1110



router-id 192.168.6.6;

If you are done configuring the device, enter commit from configuration mode. Repeat these steps for all BFD sessions in the topology. Configuring Device E Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Device E: 1.

Set the CLI to Device E. user@host> set cli logical-system E

2.

Configure the interface to the directly connected device (to-D), and configure the loopback interface. [edit interfaces fe-1/2/0 unit 14] user@E# set description to-D user@E# set family inet address 10.10.10.14/30 [edit interfaces lo0 unit 5] user@E# set family inet address 192.168.6.7/32

3.

Configure an EBGP session with Device E. The neighbor statement points to the loopback interface on Device C. [edit protocols bgp group external-peers] user@E# set local-address 192.168.6.7 user@E# set export send-static user@E# set peer-as 17 user@E# set neighbor 192.168.40.4

4.

Configure the multihop statement to enable Device C and Device E to become EBGP peers. Because the peers are two hops away from each other, the example uses the ttl 2 statement. [edit protocols bgp group external-peers] user@E# set multihop ttl 2

5.

Configure connectivity to Device E, using static routes. You must configure a route to both the loopback interface address and to the address on the physical interface. [edit routing-options] user@E# set static route 10.10.10.8/30 next-hop 10.10.10.13 user@E# set static route 192.168.40.4/32 next-hop 10.10.10.13

6.

Configure the local router ID and the autonomous system (AS) number. [edit routing-options] user@E# set router-id 192.168.6.7 user@E# set autonomous-system 18


1111


7.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit policy-options policy-statement send-static term 1] user@E# set from protocol static user@E# set then accept

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@E# show interfaces fe-1/2/0 { unit 14 { description to-D; family inet { address 10.10.10.14/30; } } } lo0 { unit 5 { family inet { address 192.168.6.7/32; } } } user@E# show protocols bgp { group external-peers { multihop { ttl 2; } local-address 192.168.6.7; export send-static; peer-as 17; neighbor 192.168.40.4; } } user@E# show policy-options policy-statement send-static { term 1 { from protocol static; then accept; } } user@E# show routing-options static { route 10.10.10.8/30 next-hop 10.10.10.13; route 192.168.40.4/32 next-hop 10.10.10.13; }

1112



router-id 192.168.6.7; autonomous-system 18;



Verifying Connectivity on page 1113

•

Verifying That BGP Sessions Are Established on page 1113

•

Viewing Advertised Routes on page 1114

Verifying Connectivity Purpose

Make sure that Device C can ping Device E, specifying the loopback interface address as the source of the ping request. The loopback interface address is the source address that BGP will use.

Action

From operational mode, enter the ping 10.10.10.14 source 192.168.40.4 command from Device C, and enter the ping 10.10.10.9 source 192.168.6.7 command from Device E. user@C> ping 10.10.10.14 source 192.168.40.4 PING 10.10.10.14 (10.10.10.14): 56 data bytes 64 bytes from 10.10.10.14: icmp_seq=0 ttl=63 time=1.262 ms 64 bytes from 10.10.10.14: icmp_seq=1 ttl=63 time=1.202 ms ^C --- 10.10.10.14 ping statistics --2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.202/1.232/1.262/0.030 ms user@E> ping 10.10.10.9 source 192.168.6.7 PING 10.10.10.9 (10.10.10.9): 56 data bytes 64 bytes from 10.10.10.9: icmp_seq=0 ttl=63 time=1.255 ms 64 bytes from 10.10.10.9: icmp_seq=1 ttl=63 time=1.158 ms ^C --- 10.10.10.9 ping statistics --2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.158/1.206/1.255/0.049 ms

Meaning

The static routes are working if the pings work. Verifying That BGP Sessions Are Established

Purpose Action

Verify that the BGP sessions are up. From operational mode, enter the show bgp summary command. user@C> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed inet.0 2 0 0


History Damp State 0 0

Pending 0

1113


Peer AS InPkt State|#Active/Received/Accepted/Damped... 192.168.6.7 18 147 0/2/2/0 0/0/0/0

OutPkt

OutQ

147

0

Flaps Last Up/Dwn 1

1:04:27

user@E> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 2 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.168.40.4 17 202 202 0 1 1:02:18 0/2/2/0 0/0/0/0

Meaning

The output shows that both devices have one peer each. No peers are down. Viewing Advertised Routes

Purpose Action

Check to make sure that routes are being advertised by BGP. From operational mode, enter the show route advertising-protocol bgp neighbor command. user@C> show route advertising-protocol bgp 192.168.6.7 inet.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.10.10.14/32 Self I * 192.168.6.7/32 Self I user@E> show route advertising-protocol bgp 192.168.40.4 inet.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.10.10.8/30 Self I * 192.168.40.4/32 Self I

Meaning


The send-static routing policy is exporting the static routes from the routing table into BGP. BGP is advertising these routes between the peers because the BGP peer session is established.

•


•


Examples: Configuring BGP Multipath

1114

•

Understanding BGP Multipath on page 1115

•

Example: Load-Balancing BGP Traffic on page 1115

•

Example: Configuring Single-Hop EBGP Peers to Accept Remote Next Hops on page 1119



Understanding BGP Multipath The Junos OS BGP multipath feature supports the following applications: •

Load balancing across multiple links between two routing devices belonging to different autonomous systems (ASs)

•

Load balancing across a common subnet or multiple subnets to different routing devices belonging to the same peer AS

•

Load balancing across multiple links between two routing devices belonging to different external confederation peers

•

Load balancing across a common subnet or multiple subnets to different routing devices belonging to external confederation peers

In a common scenario for load balancing, a customer is multihomed to multiple routers in a point of presence (POP). The default behavior is to send all traffic across only one of the available links. Load balancing causes traffic to use two or more of the links. BGP multipath does not apply to paths that share the same MED-plus-IGP cost, yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.

Example: Load-Balancing BGP Traffic This example shows how to configure BGP to select multiple equal-cost external BGP (EBGP) or internal BGP (IBGP) paths as active paths. •


•


•


•




•


•

Configure BGP.

•

Configure a routing policy that exports routes (such as direct routes or IGP routes) from the routing table into BGP.

Overview In this example, Device R1 is in AS 65000 and is connected to both Device R2 and Device R3, which are in AS 65001. This example shows the configuration on Device R1.


1115


Topology Figure 59 on page 1116 shows the topology used in this example.

Figure 59: BGP Load Balancing AS 65001

AS 65000 10.0.1.1

10.0.2.2

10.0.1.2 R1

R2

10.0.0.1

10.0.2.1 R3 g040875

10.0.0.2


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set protocols bgp group external type external set protocols bgp group external peer-as 65001 set protocols bgp group external multipath set protocols bgp group external neighbor 10.0.1.1 set protocols bgp group external neighbor 10.0.0.2 set policy-options policy-statement loadbal from route-filter 10.0.0.0/16 orlonger set policy-options policy-statement loadbal then load-balance per-packet set routing-options forwarding-table export loadbal set routing-options autonomous-system 65000


The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure the BGP peer sessions: 1.

Configure the BGP group. [edit protocols bgp group external] user@R1# set type external user@R1# set peer-as 65001 user@R1# set neighbor 10.0.1.1 user@R1# set neighbor 10.0.0.2

2.

Enable the BGP group to use multiple paths.

NOTE: To disable the default check requiring that paths accepted by BGP multipath must have the same neighboring autonomous system (AS), include the multiple-as option.

1116



[edit protocols bgp group external] user@R1# set multipath 3.

Configure the load-balancing policy. [edit policy-options policy-statement loadbal] user@R1# set from route-filter 10.0.0.0/16 orlonger user@R1# set then load-balance per-packet

4.

Apply the load-balancing policy. [edit routing-options] user@R1# set forwarding-table export loadbal

5.

Configure the local autonomous system (AS) number. [edit routing-options] user@R1# set autonomous-system 65000

Results

From configuration mode, confirm your configuration by entering the show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. [edit] user@R1# show protocols bgp { group external { type external; peer-as 65001; multipath; neighbor 10.0.1.1; neighbor 10.0.0.2; } } [edit] user@R1# show policy-options policy-statement loadbal { from { route-filter 10.0.0.0/16 orlonger; } then { load-balance per-packet; } } [edit] user@R1# show routing-options autonomous-system 65000; forwarding-table { export loadbal; }



1117


Verification Confirm that the configuration is working properly: •

Verifying Routes on page 1118

•

Verifying Forwarding on page 1119

Verifying Routes Purpose Action

Verify that routes are learned from both routers in the neighboring AS. From operational mode, run the show route command. user@R1> show route 10.0.2.0 inet.0: 12 destinations, 15 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.2.0/30

*[BGP/170] 03:12:32, localpref 100 AS path: 65001 I to 10.0.1.1 via ge-1/2/0.0 > to 10.0.0.2 via ge-1/2/1.0 [BGP/170] 03:12:32, localpref 100 AS path: 65001 I > to 10.0.1.1 via ge-1/2/0.0

user@R1> show route 10.0.2.0 detail inet.0: 12 destinations, 15 routes (12 active, 0 holddown, 0 hidden) 10.0.2.0/30 (2 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Router, Next hop index: 262142 Next-hop reference count: 3 Source: 10.0.0.2 Next hop: 10.0.1.1 via ge-1/2/0.0 Next hop: 10.0.0.2 via ge-1/2/1.0, selected State: Local AS: 65000 Peer AS: 65001 Age: 3:18:30 Task: BGP_65001.10.0.0.2+55402 Announcement bits (1): 2-KRT AS path: 65001 I Accepted Multipath Localpref: 100 Router ID: 192.168.2.1 BGP Preference: 170/-101 Next hop type: Router, Next hop index: 602 Next-hop reference count: 5 Source: 10.0.1.1 Next hop: 10.0.1.1 via ge-1/2/0.0, selected State: Inactive reason: Not Best in its group - Active preferred Local AS: 65000 Peer AS: 65001 Age: 3:18:30 Task: BGP_65001.10.0.1.1+53135 AS path: 65001 I Accepted Localpref: 100 Router ID: 192.168.3.1

1118



Meaning

The active path, denoted with an asterisk (*), has two next hops: 10.0.1.1 and 10.0.0.2 to the 10.0.2.0 destination. The 10.0.1.1 next hop is copied from the inactive path to the active path. Verifying Forwarding

Purpose Action

Verify that both next hops are installed in the forwarding table. From operational mode, run the show route forwarding-table command. user@R1> show route forwarding-table destination 10.0.2.0 Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif 10.0.2.0/30 user 0 ulst 262142 2 10.0.1.1 ucst 602 5 ge-1/2/0.0 10.0.0.2 ucst 522 6 ge-1/2/1.0

Example: Configuring Single-Hop EBGP Peers to Accept Remote Next Hops This example shows how to configure a single-hop external BGP (EBGP) peer to accept a remote next hop with which it does not share a common subnet. •


•


•


•



Overview In some situations, it is necessary to configure a single-hop EBGP peer to accept a remote next hop with which it does not share a common subnet. The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded. The ability to have a single-hop EBGP peer accept a remote next hop to which it is not directly connected also prevents you from having to configure the single-hop EBGP neighbor as a multihop session. When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses. Configuring the accept-remote-nexthop statement allows a single-hop EBGP peer to accept a remote next hop, which restores multipath functionality for routes that are resolved over these next-hop addresses. You can configure this statement at the global, group, and neighbor hierarchy levels for BGP. The statement is also supported on logical systems and the VPN routing and forwarding (VRF) routing instance type. Both the remote next-hop and the EBGP peer must support BGP route refresh as defined in RFC 2918, Route Refresh Capability in BGP-4. If the remote peer does not support BGP route refresh, the session is reset.


1119


NOTE: You cannot configure both the multihop and accept-remote-nexthop statements for the same EBGP peer.

When you enable a single-hop EBGP peer to accept a remote next hop, you must also configure an import routing policy on the EBGP peer that specifies the remote next-hop address. This example includes an import routing policy, agg_route, that enables a single-hop external BGP peer (Device R1) to accept the remote next-hop 1.1.10.10 for the route to the 1.1.230.0/23 network. At the [edit protocols bgp] hierarchy level, the example includes the import agg_route statement to apply the policy to the external BGP peer and includes the accept-remote-nexthop statement to enable the single-hop EBGP peer to accept the remote next hop. Figure 60 on page 1120 shows the sample topology.

Figure 60: Topology for Accepting a Remote Next Hop AS 65500

AS 65000

R0

R1

lo0: 10.255.14.179

lo0:10.255.71.24

lo0:10.255.14.177

AS 65000

g041156

R2

Configuration


1120

•

Device R0 on page 1122

•


•


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network



configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. Device R0

set interfaces fe-1/2/0 unit 1 family inet address 1.1.0.1/30 set interfaces fe-1/2/1 unit 2 family inet address 1.1.1.1/30 set interfaces lo0 unit 1 family inet address 10.255.14.179/32 set protocols bgp group ext type external set protocols bgp group ext export test_route set protocols bgp group ext export agg_route set protocols bgp group ext peer-as 65000 set protocols bgp group ext multipath set protocols bgp group ext neighbor 1.1.0.2 set protocols bgp group ext neighbor 1.1.1.2 set policy-options policy-statement agg_route term 1 from protocol static set policy-options policy-statement agg_route term 1 from route-filter 1.1.230.0/23 exact set policy-options policy-statement agg_route term 1 then accept set policy-options policy-statement test_route term 1 from protocol static set policy-options policy-statement test_route term 1 from route-filter 1.1.10.10/32 exact set policy-options policy-statement test_route term 1 then accept set routing-options static route 1.1.10.10/32 reject set routing-options static route 1.1.230.0/23 reject set routing-options autonomous-system 65500

Device R1

set interfaces fe-1/2/0 unit 3 family inet address 1.1.0.2/30 set interfaces fe-1/2/1 unit 4 family inet address 1.12.0.1/30 set interfaces fe-1/2/2 unit 5 family inet address 1.1.1.2/30 set interfaces lo0 unit 2 family inet address 10.255.71.24/32 set protocols bgp accept-remote-nexthop set protocols bgp group ext type external set protocols bgp group ext import agg_route set protocols bgp group ext peer-as 65500 set protocols bgp group ext multipath set protocols bgp group ext neighbor 1.1.0.1 set protocols bgp group ext neighbor 1.1.1.1 set protocols bgp group int type internal set protocols bgp group int local-address 10.255.71.24 set protocols bgp group int neighbor 10.255.14.177 set protocols ospf area 0.0.0.0 interface fe-1/2/1.4 set protocols ospf area 0.0.0.0 interface 10.255.71.24 set policy-options policy-statement agg_route term 1 from protocol bgp set policy-options policy-statement agg_route term 1 from route-filter 1.1.230.0/23 exact set policy-options policy-statement agg_route term 1 then next-hop 1.1.10.10 set policy-options policy-statement agg_route term 1 then accept set routing-options autonomous-system 65000

Device R2

set interfaces fe-1/2/0 unit 6 family inet address 1.12.0.2/30 set interfaces lo0 unit 3 family inet address 10.255.14.177/32 set protocols bgp group int type internal set protocols bgp group int local-address 10.255.14.177 set protocols bgp group int neighbor 10.255.71.24 set protocols ospf area 0.0.0.0 interface fe-1/2/0.6 set protocols ospf area 0.0.0.0 interface 10.255.14.177 set routing-options autonomous-system 65000


1121


Device R0 Step-by-Step Procedure



2.

Configure EBGP. [edit protocols bgp group ext] user@R0# set type external user@R0# set peer-as 65000 user@R0# set neighbor 1.1.0.2 user@R0# set neighbor 1.1.1.2

3.

Enable multipath BGP between Device R0 and Device R1. [edit protocols bgp group ext] user@R0# set multipath

4.

Configure static routes to remote networks. These routes are not part of the topology. The purpose of these routes is to demonstrate the functionality in this example. [edit routing-options] user@R0# set static route 1.1.10.10/32 reject user@R0# set static route 1.1.230.0/23 reject

5.

Configure routing policies that accept the static routes. [edit policy-options policy-statement agg_route term 1] user@R0# set from protocol static user@R0# set from route-filter 1.1.230.0/23 exact user@R0# set then accept [edit policy-options policy-statement test_route term 1] user@R0# set from protocol static user@R0# set from route-filter 1.1.10.10/32 exact user@R0# set then accept

6.

Export the agg_route and test_route policies from the routing table into BGP. [edit protocols bgp group ext] user@R0# set export test_route user@R0# set export agg_route

1122



7.

Configure the autonomous system (AS) number. [edit routing-options] user@R0# set autonomous-system 65500

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R0# show interfaces fe-1/2/0 { unit 1 { family inet { address 1.1.0.1/30; } } } fe-1/2/1 { unit 2 { family inet { address 1.1.1.1/30; } } } lo0 { unit 1 { family inet { address 10.255.14.179/32; } } } user@R0# show policy-options policy-statement agg_route { term 1 { from { protocol static; route-filter 1.1.230.0/23 exact; } then accept; } } policy-statement test_route { term 1 { from { protocol static; route-filter 1.1.10.10/32 exact; } then accept; } } user@R0# show protocols bgp { group ext {


1123


type external; export [ test_route agg_route ]; peer-as 65000; multipath; neighbor 1.1.0.2; neighbor 1.1.1.2; } } user@R0# show routing-options static { route 1.1.10.10/32 reject; route 1.1.230.0/23 reject; } autonomous-system 65500;



Configure the interfaces. [edit interfaces fe-1/2/0 unit 3] user@R1# set family inet address 1.1.0.2/30 [edit interfaces fe-1/2/1 unit 4] user@R1# set family inet address 1.12.0.1/30 [edit interfaces fe-1/2/2 unit 5] user@R1# set family inet address 1.1.1.2/30 [edit interfaces lo0 unit 2] user@R1# set family inet address 10.255.71.24/32

2.

Configure OSPF. [edit protocols ospf area 0.0.0.0] user@R1# set interface fe-1/2/1.4 user@R1# set interface 10.255.71.24

3.

Enable Device R1 to accept the remote next hop. [edit protocols bgp] user@R1# set accept-remote-nexthop

4.

Configure IBGP. [edit protocols bgp group int] user@R1# set type internal user@R1# set local-address 10.255.71.24 user@R1# set neighbor 10.255.14.177

1124



5.

Configure EBGP. [edit protocols bgp group ext] user@R1# set type external user@R1# set peer-as 65500 user@R1# set neighbor 1.1.0.1 user@R1# set neighbor 1.1.1.1

6.

Enable multipath BGP between Device R0 and Device R1. [edit protocols bgp group ext] user@R1# set multipath

7.

Configure a routing policy that enables a single-hop external BGP peer (Device R1) to accept the remote next-hop 1.1.10.10 for the route to the 1.1.230.0/23 network. [edit policy-options policy-statement agg_route term 1] user@R1# set from protocol bgp user@R1# set from route-filter 1.1.230.0/23 exact user@R1# set then next-hop 1.1.10.10 user@R1# set then accept

8.

Import the agg_route policy into the routing table on Device R1. [edit protocols bgp group ext] user@R1# set import agg_route

9.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show interfaces fe-1/2/0 { unit 3 { family inet { address 1.1.0.2/30; } } } fe-1/2/1 { unit 4 { family inet { address 1.12.0.1/30; } } } fe-1/2/2 { unit 5 { family inet { address 1.1.1.2/30; } }


1125


} lo0 { unit 2 { family inet { address 10.255.71.24/32; } } } user@R1# show policy-options policy-statement agg_route { term 1 { from { protocol bgp; route-filter 1.1.230.0/23 exact; } then { next-hop 1.1.10.10; accept; } } } user@R1# show protocols bgp { accept-remote-nexthop; group ext { type external; import agg_route; peer-as 65500; multipath; neighbor 1.1.0.1; neighbor 1.1.1.1; } group int { type internal; local-address 10.255.71.24; neighbor 10.255.14.177; } } ospf { area 0.0.0.0 { interface fe-1/2/1.4; interface 10.255.71.24; } } user@R1# show routing-options autonomous-system 65000;


1126





Configure the interfaces. [edit interfaces fe-1/2/0 unit 6] user@R2# set family inet address 1.12.0.2/30 [edit interfaces lo0 unit 3] user@R2# set family inet address 10.255.14.177/32

2.


3.

Configure IBGP. [edit protocols bgp group int] user@R2# set type internal user@R2# set local-address 10.255.14.177 user@R2# set neighbor 10.255.71.24

4.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R2# show interfaces fe-1/2/0 { unit 6 { family inet { address 1.12.0.2/30; } } } lo0 { unit 3 { family inet { address 10.255.14.177/32; } } } user@R2# show protocols bgp { group int {


1127


type internal; local-address 10.255.14.177; neighbor 10.255.71.24; } } ospf { area 0.0.0.0 { interface fe-1/2/0.6; interface 10.255.14.177; } } user@R2# show routing-options autonomous-system 65000;



Verifying That the Multipath Route with the Indirect Next Hop Is in the Routing Table on page 1128

•

Deactivating and Reactivating the accept-remote-nexthop Statement on page 1129

Verifying That the Multipath Route with the Indirect Next Hop Is in the Routing Table Purpose Action

Verify that Device R1 has a route to the 1.1.230.0/23 network. From operational mode, enter the show route 1.1.230.0 extensive command. user@R1> show route 1.1.230.0 extensive inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden) Restart Complete 1.1.230.0/23 (2 entries, 1 announced) TSI: KRT in-kernel 1.1.230.0/23 -> {indirect(262142)} Page 0 idx 1 Type 1 val 9168f6c Nexthop: 1.1.10.10 Localpref: 100 AS path: [65000] 65500 I Communities: Path 1.1.230.0 from 1.1.0.1 Vector len 4. Val: 1 *BGP Preference: 170/-101 Next hop type: Indirect Address: 0x90c44d8 Next-hop reference count: 4 Source: 1.1.0.1 Next hop type: Router, Next hop index: 262143 Next hop: 1.1.0.1 via fe-1/2/0.3, selected Next hop: 1.1.1.1 via fe-1/2/2.5 Protocol next hop: 1.1.10.10 Indirect next hop: 91c0000 262142 State: Local AS: 65000 Peer AS: 65500 Age: 2:55:31 Metric2: 0 Task: BGP_65500.1.1.0.1+64631 Announcement bits (3): 2-KRT 3-BGP_RT_Background 4-Resolve tree

1128



1

BGP

Meaning

AS path: 65500 I Accepted Multipath Localpref: 100 Router ID: 10.255.14.179 Indirect next hops: 1 Protocol next hop: 1.1.10.10 Indirect next hop: 91c0000 262142 Indirect path forwarding next hops: 2 Next hop type: Router Next hop: 1.1.0.1 via fe-1/2/0.3 Next hop: 1.1.1.1 via fe-1/2/2.5 1.1.10.10/32 Originating RIB: inet.0 Node path count: 1 Forwarding nexthops: 2 Nexthop: 1.1.0.1 via fe-1/2/0.3 Nexthop: 1.1.1.1 via fe-1/2/2.5 Preference: 170/-101 Next hop type: Indirect Address: 0x90c44d8 Next-hop reference count: 4 Source: 1.1.1.1 Next hop type: Router, Next hop index: 262143 Next hop: 1.1.0.1 via fe-1/2/0.3, selected Next hop: 1.1.1.1 via fe-1/2/2.5 Protocol next hop: 1.1.10.10 Indirect next hop: 91c0000 262142 State: Inactive reason: Not Best in its group - Update source Local AS: 65000 Peer AS: 65500 Age: 2:55:27 Metric2: 0 Task: BGP_65500.1.1.1.1+53260 AS path: 65500 I Accepted Localpref: 100 Router ID: 10.255.14.179 Indirect next hops: 1 Protocol next hop: 1.1.10.10 Indirect next hop: 91c0000 262142 Indirect path forwarding next hops: 2 Next hop type: Router Next hop: 1.1.0.1 via fe-1/2/0.3 Next hop: 1.1.1.1 via fe-1/2/2.5 1.1.10.10/32 Originating RIB: inet.0 Node path count: 1 Forwarding nexthops: 2 Nexthop: 1.1.0.1 via fe-1/2/0.3 Nexthop: 1.1.1.1 via fe-1/2/2.5

The output shows that Device R1 has a route to the 1.1.230.0 network with the multipath feature enabled (Accepted Multipath). The output also shows that the route has an indirect next hop of 1.1.10.10. Deactivating and Reactivating the accept-remote-nexthop Statement

Purpose

Make sure that the multipath route with the indirect next hop is removed from the routing table when you deactivate the accept-remote-nexthop statement.


1129


Action

1.

From configuration mode, enter the deactivate protocols bgp accept-remote-nexthop command. user@R1# deactivate protocols bgp accept-remote-nexthop user@R1# commit

2. From operational mode, enter the show route 1.1.230.0 command. user@R1> show route 1.1.230.0 3. From configuration mode, reactivate the statement by entering the activate protocols

bgp accept-remote-nexthop command. user@R1# activate protocols bgp accept-remote-nexthop user@R1# commit 4. From operational mode, reenter the show route 1.1.230.0 command. user@R1> show route 1.1.230.0

inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 1.1.230.0/23

Meaning


*[BGP/170] 03:13:19, localpref 100 AS path: 65500 I > to 1.1.0.1 via fe-1/2/0.3 to 1.1.1.1 via fe-1/2/2.5 [BGP/170] 03:13:15, localpref 100, from 1.1.1.1 AS path: 65500 I > to 1.1.0.1 via fe-1/2/0.3 to 1.1.1.1 via fe-1/2/2.5

When the accept-remote-nexthop statement is deactivated, the multipath route to the 1.1.230.0 network is removed from the routing table .

•


•


Example: Configuring BGP Local Preference •

Understanding the BGP Local Preference on page 1130

•

Example: Configuring the Local Preference Value for BGP Routes on page 1131

Understanding the BGP Local Preference Internal BGP (IBGP) sessions use a metric called the local preference, which is carried in IBGP update packets in the path attribute LOCAL_PREF. When an autonomous system (AS) has multiple routes to another AS, the local preference indicates the degree of preference for one route over the other routes. The route with the highest local preference value is preferred.

1130



The LOCAL_PREF path attribute is always advertised to IBGP peers and to neighboring confederations. It is never advertised to external BGP (EBGP) peers. The default behavior is to not modify the LOCAL_PREF path attribute if it is present. The LOCAL_PREF path attribute applies at export time only, when the routes are exported from the routing table into BGP. If a BGP route is received without a LOCAL_PREF attribute, the route is stored in the routing table and advertised by BGP as if it were received with a LOCAL_PREF value of 100. A non-BGP route that is advertised by BGP is advertised with a LOCAL_PREF value of 100 by default.

Example: Configuring the Local Preference Value for BGP Routes This example shows how to configure local preference in internal BGP (IBGP) peer sessions. •


•


•


•



Overview To change the local preference metric advertised in the path attribute, you must include 32 the local-preference statement, specifying a value from 0 through 4,294,967,295 (2 – 1). There are several reasons you might want to prefer one path over another. For example, compared to other paths, perhaps one path is less expensive to use, has higher bandwidth, or is more stable. Figure 61 on page 1132 shows a typical network with internal peer sessions and multiple exit points to a neighboring AS.


1131



24.24.24.0/24

R1

R4

AS123

AS4 34.34.34.0/24

R3 AS123

g041151

13.13.13.0/24

To reach Device R4, Device R1 can go through either Device R2 or Device R3. By default, the local preference is 100 for both routes. When the local preferences are equal, Junos OS has rules for breaking the tie and choosing a path. (See “Understanding BGP Path Selection” on page 7.) In this example, the active route is through Device R2 because Device R2’s router ID is lower than Device R3’s router ID. After showing the default behavior without an explicit setting for the local preference, this example shows how to configure a local preference of 300 on Device R3, thereby making Device R3 the preferred path to reach Device R4.

Configuration


Device R1

1132

•


•


•


•


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set interfaces fe-1/2/0 unit 1 family inet address 12.12.12.1/24 set interfaces fe-1/2/1 unit 2 family inet address 13.13.13.1/24 set interfaces lo0 unit 1 family inet address 192.168.1.1/32 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.1.1 set protocols bgp group internal export send-direct set protocols bgp group internal neighbor 192.168.2.1 set protocols bgp group internal neighbor 192.168.3.1 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.1 set protocols ospf area 0.0.0.0 interface fe-1/2/1.2 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept



set routing-options autonomous-system 123 set routing-options router-id 192.168.1.1

Device R2


Device R3


Device R4

set interfaces fe-1/2/0 unit 7 family inet address 24.24.24.4/24 set interfaces fe-1/2/1 unit 8 family inet address 34.34.34.4/24 set interfaces lo0 unit 4 family inet address 192.168.4.1/32 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external peer-as 123 set protocols bgp group external neighbor 34.34.34.3 set protocols bgp group external neighbor 24.24.24.2 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 4 set routing-options router-id 192.168.4.1


1133





2.


3.


4.


5.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show interfaces fe-1/2/0 {

1134



unit 1 { family inet { address 12.12.12.1/24; } } } fe-1/2/1 { unit 2 { family inet { address 13.13.13.1/24; } } } lo0 { unit 1 { family inet { address 192.168.1.1/32; } } } user@R1# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R1# show protocols bgp { group internal { type internal; local-address 192.168.1.1; export send-direct; neighbor 192.168.2.1; neighbor 192.168.3.1; } } ospf { area 0.0.0.0 { interface lo0.1 { passive; } interface fe-1/2/0.1; interface fe-1/2/1.2; } } user@R1# show routing-options autonomous-system 123; router-id 192.168.1.1;



1135





2.


3.


4.


5.


1136



Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R2# show interfaces fe-1/2/0 { unit 3 { family inet { address 12.12.12.2/24; } } } fe-1/2/1 { unit 4 { family inet { address 24.24.24.2/24; } } } lo0 { unit 2 { family inet { address 192.168.2.1/32; } } } user@R2# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R2# show protocols bgp { group internal { type internal; local-address 192.168.2.1; export send-direct; neighbor 192.168.1.1; neighbor 192.168.3.1; } group external { type external; export send-direct; peer-as 4; neighbor 24.24.24.4; } } ospf { area 0.0.0.0 { interface lo0.2 { passive;


1137


} interface fe-1/2/0.3; interface fe-1/2/1.4; } } user@R2# show routing-options autonomous-system 123; router-id 192.168.2.1;




2.


3.


4.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes.

1138



[edit policy-options policy-statement send-direct term 1] user@R3# set from protocol direct user@R3# set then accept 5.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R3# show interfaces fe-1/2/0 { unit 5 { family inet { address 13.13.13.3/24; } } } fe-1/2/1 { unit 6 { family inet { address 34.34.34.3/24; } } } lo0 { unit 3 { family inet { address 192.168.3.1/32; } } } user@R3# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R3# show protocols bgp { group internal { type internal; local-address 192.168.3.1; export send-direct; neighbor 192.168.1.1; neighbor 192.168.2.1; } group external {


1139


type external; export send-direct; peer-as 4; neighbor 34.34.34.4; } } ospf { area 0.0.0.0 { interface lo0.3 { passive; } interface fe-1/2/0.5; interface fe-1/2/1.6; } } user@R3# show routing-options autonomous-system 123; router-id 192.168.3.1;




2.

Configure BGP. [edit protocols bgp group external] set type external set export send-direct set peer-as 123 set neighbor 34.34.34.3 set neighbor 24.24.24.2

3.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit policy-options policy-statement send-direct term 1] user@R4# set from protocol direct

1140



user@R4# set then accept 4.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R4# show interfaces fe-1/2/0 { unit 7 { family inet { address 24.24.24.4/24; } } } fe-1/2/1 { unit 8 { family inet { address 34.34.34.4/24; } } } lo0 { unit 4 { family inet { address 192.168.4.1/32; } } } user@R4# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R4# show protocols bgp { group external { type external; export send-direct; peer-as 123; neighbor 34.34.34.3; neighbor 24.24.24.2; } } user@R4# show routing-options autonomous-system 4;


1141


router-id 192.168.4.1;




•

Altering the Local Preference to Change the Path Selection on page 1142

•

Rechecking the Active Path From Device R1 to Device R4 on page 1143



13.13.13.0/24

24.24.24.0/24

34.34.34.0/24

192.168.2.1/32

192.168.3.1/32

192.168.4.1/32

Meaning

[BGP/170] 00:11:48, AS path: I > to 12.12.12.2 via [BGP/170] 00:11:48, AS path: I > to 13.13.13.3 via [BGP/170] 00:11:48, AS path: I > to 12.12.12.2 via [BGP/170] 00:11:48, AS path: I > to 13.13.13.3 via [BGP/170] 00:11:48, AS path: I > to 12.12.12.2 via [BGP/170] 00:11:48, AS path: I > to 13.13.13.3 via *[BGP/170] 00:05:14, AS path: 4 I > to 12.12.12.2 via [BGP/170] 00:05:14, AS path: 4 I > to 13.13.13.3 via

localpref 100, from 192.168.2.1 fe-1/2/0.1 localpref 100, from 192.168.3.1 fe-1/2/1.2 localpref 100, from 192.168.2.1 fe-1/2/0.1 localpref 100, from 192.168.3.1 fe-1/2/1.2 localpref 100, from 192.168.2.1 fe-1/2/0.1 localpref 100, from 192.168.3.1 fe-1/2/1.2 localpref 100, from 192.168.2.1 fe-1/2/0.1 localpref 100, from 192.168.3.1 fe-1/2/1.2

The asterisk (*) shows that the preferred path is through Device R2. In the default configuration, Device R2 has a lower router ID than Device R3. The router ID is controlling the path selection. Altering the Local Preference to Change the Path Selection

Purpose Action

1142

Change the path so that it goes through Device R3. From configuration mode, enter the set local-preference 300 command.



[edit protocols bgp group internal] user@R1# set local-preference 300 user@R1# commit

Rechecking the Active Path From Device R1 to Device R4 Purpose Action


13.13.13.0/24

24.24.24.0/24

34.34.34.0/24

192.168.2.1/32

192.168.3.1/32

192.168.4.1/32

Meaning


[BGP/170] 00:16:48, AS path: I > to 12.12.12.2 via [BGP/170] 00:00:22, AS path: I > to 13.13.13.3 via [BGP/170] 00:16:48, AS path: I > to 12.12.12.2 via [BGP/170] 00:00:22, AS path: I > to 13.13.13.3 via [BGP/170] 00:16:48, AS path: I > to 12.12.12.2 via [BGP/170] 00:00:22, AS path: I > to 13.13.13.3 via *[BGP/170] 00:00:21, AS path: 4 I > to 13.13.13.3 via

localpref 100, from 192.168.2.1 fe-1/2/0.1 localpref 300, from 192.168.3.1 fe-1/2/1.2 localpref 100, from 192.168.2.1 fe-1/2/0.1 localpref 300, from 192.168.3.1 fe-1/2/1.2 localpref 100, from 192.168.2.1 fe-1/2/0.1 localpref 300, from 192.168.3.1 fe-1/2/1.2 localpref 300, from 192.168.3.1 fe-1/2/1.2

The asterisk (*) shows that the preferred path is through Device R3. In the altered configuration, Device R3 has a higher local preference than Device R2. The local preference is controlling the path selection.

•


•


Example: Configuring BGP Route Preference (Administrative Distance) •

Understanding Route Preference Values on page 1143

•

Example: Configuring the Preference Value for BGP Routes on page 1145

Understanding Route Preference Values The Junos OS routing protocol process assigns a default preference value (also known as an administrative distance) to each route that the routing table receives. The default value depends on the source of the route. The preference value is a value from 0


1143


32

through 4,294,967,295 (2

– 1), with a lower value indicating a more preferred route.

Table 3 on page 10 lists the default preference values.

Table 13: Default Route Preference Values How Route Is Learned

Default Preference


Directly connected network

0

–

System routes

4

–

Static and Static LSPs

5

static

RSVP-signaled LSPs

7

RSVP preference as described in the Junos OS MPLS

Applications Configuration Guide LDP-signaled LSPs

9

LDP preference, as described in the Junos OS MPLS

Applications Configuration Guide

1144

OSPF internal route

10

OSPF preference


15

IS-IS preference


18

IS-IS preference

Redirects

30

–

Kernel

40

–

SNMP

50

–

Router discovery

55

–

RIP

100

RIP preference

RIPng

100

RIPng preference

PIM

105


DVMRP

110


Aggregate

130

aggregate


150



160



165


BGP

170

BGP preference, export, import



Table 13: Default Route Preference Values (continued) How Route Is Learned

Default Preference


MSDP

175


In general, the narrower the scope of the statement, the higher precedence its preference value is given, but the smaller the set of routes it affects. To modify the default preference value for routes learned by routing protocols, you generally apply routing policy when configuring the individual routing protocols. You also can modify some preferences with other configuration statements, which are indicated in the table.

Example: Configuring the Preference Value for BGP Routes This example shows how to specify the preference for routes learned from BGP. Routing information can be learned from multiple sources. To break ties among equally specific routes learned from multiple sources, each source has a preference value. Routes that are learned through explicit administrative action, such as static routes, are preferred over routes learned from a routing protocol, such as BGP or OSPF. This concept is called administrative distance by some vendors. •


•


•


•



Overview Routing information can be learned from multiple sources, such as through static configuration, BGP, or an interior gateway protocol (IGP). When Junos OS determines a route’s preference to become the active route, it selects the route with the lowest preference as the active route and installs this route into the forwarding table. By default, the routing software assigns a preference of 170 to routes that originated from BGP. Of all the routing protocols, BGP has the highest default preference value, which means that routes learned by BGP are the least likely to become the active route. Some vendors have a preference (distance) of 20 for external BGP (EBGP) and a distance of 200 for internal BGP (IGBP). Junos OS uses the same value (170) for both EBGP and IBGP. However, this difference between vendors has no operational impact because Junos OS always prefers EBGP routes over IBGP routes. Another area in which vendors differ is in regard to IGP distance compared to BGP distance. For example, some vendors assign a distance of 110 to OSPF routes. This is higher than the EBGP distance of 20 , and results in the selection of an EBGP route over an equivalent OSPF route. In the same scenario, Junos OS chooses the OSPF route,


1145


because of the default preference 10 for an internal OSPF route and 150 for an external OSPF route, which are both lower than the 170 preference assigned to all BGP routes. In a multivendor environment, you might want to change the preference value for BGP routes so that Junos OS chooses an EBGP route instead of an OSPF route. To accomplish this goal, one option is to include the preference statement in the EBGP configuration. To modify the default BGP preference value, include the preferece statement, specifying 32 a value from 0 through 4,294,967,295 (2 – 1).

TIP: Another way to achieve multivendor compatibility is to include the advertise-inactive statement in the EBGP configuration. This causes the routing table to export to BGP the best route learned by BGP even if Junos OS did not select it to be an active route. By default, BGP stores the route information it receives from update messages in the Junos OS routing table, and the routing table exports only active routes into BGP, which BGP then advertises to its peers. The advertise-inactive statement causes Junos OS to advertise the best BGP route that is inactive because of IGP preference. When you use the advertise-inactive statement, the Junos OS device uses the OSPF route for forwarding, and the other vendor’s device uses the EBGP route for forwarding. However, from the perspective of an EBGP peer in a neighboring AS, both vendors’ devices appear to behave the same way.

Topology In the sample network, Device R1 and Device R2 have EBGP routes to each other and also OSPF routes to each other. This example shows the routing tables in the following cases: •

Accept the default preference values of 170 for BGP and 10 for OSPF.

•

Change the BGP preference to 8.

Figure 62 on page 1147 shows the sample network.

1146



Figure 62: BGP Preference Value Topology AS 65500

R1

R2

AS 65000

g041157

lo0: 10.255.14.177



Device R1

set interfaces fe-1/2/0 unit 4 family inet address 1.12.0.1/30 set interfaces lo0 unit 2 family inet address 10.255.71.24/32 set protocols bgp export send-direct set protocols bgp group ext type external set protocols bgp group ext preference 8 set protocols bgp group ext peer-as 65000 set protocols bgp group ext neighbor 1.12.0.2 set protocols ospf area 0.0.0.0 interface fe-1/2/0.4 set protocols ospf area 0.0.0.0 interface 10.255.71.24 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 65500

Device R2

set interfaces fe-1/2/0 unit 6 family inet address 1.12.0.2/30 set interfaces lo0 unit 3 family inet address 10.255.14.177/32 set protocols bgp export send-direct set protocols bgp group ext type external set protocols bgp group ext peer-as 65500 set protocols bgp group ext neighbor 1.12.0.1 set protocols ospf area 0.0.0.0 interface fe-1/2/0.6 set protocols ospf area 0.0.0.0 interface 10.255.14.177 set policy-options policy-statement send-direct term 1 from protocol direct


1147


set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 65000


The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Device R1: 1.

Configure the interfaces. [edit interfaces] user@R1# set fe-1/2/0 unit 4 family inet address 1.12.0.1/30 user@R1# set lo0 unit 2 family inet address 10.255.71.24/32

2.

Configure the local autonomous system. [edit routing-options] user@R1# set autonomous-system 65500

3.

Configure the external peering with Device R2. [edit protocols bgp] user@R1# set export send-direct user@R1# set group ext type external user@R1# set group ext preference 8 user@R1# set group ext peer-as 65000 user@R1# set group ext neighbor 1.12.0.2

4.


5.

Configure the routing policy. [edit policy-options policy-statement send-direct term 1] user@R1# set from protocol direct user@R1# set then accept

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show interfaces fe-1/2/0 { unit 4 { family inet { address 1.12.0.1/30; } } } lo0 { unit 2 { family inet { address 10.255.71.24/32;

1148



} } } user@R1# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R1# show protocols protocols { bgp { export send-direct; group ext { type external; preference 8; peer-as 65000; neighbor 1.12.0.2; } } ospf { area 0.0.0.0 { interface fe-1/2/0.4; interface 10.255.71.24; } } } user@R1# show routing-options autonomous-system 65500;

If you are done configuring the device, enter commit from configuration mode. Repeat these steps on Device R2.

Verification Confirm that the configuration is working properly. Verifying the Preference Purpose

Action

Make sure that the routing tables on Device R1 and Device R2 reflect the fact that Device R1 is using the configured EBGP preference of 8, and Device R2 is using the default EBGP preference of 170. From operational mode, enter the show route command. user@R1> show route inet.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1.12.0.0/30


*[Direct/0] 3d 07:03:01 > via fe-1/2/0.4 [BGP/8] 01:04:49, localpref 100 AS path: 65000 I > to 1.12.0.2 via fe-1/2/0.4

1149


1.12.0.1/32 10.255.14.177/32

10.255.71.24/32 224.0.0.5/32

*[Local/0] 3d 07:03:01 Local via fe-1/2/0.4 *[BGP/8] 01:04:49, localpref 100 AS path: 65000 I > to 1.12.0.2 via fe-1/2/0.4 [OSPF/10] 3d 07:02:16, metric 1 > to 1.12.0.2 via fe-1/2/0.4 *[Direct/0] 3d 07:03:01 > via lo0.2 *[OSPF/10] 5d 03:42:16, metric 1 MultiRecv

user@R2> show route inet.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1.12.0.0/30

1.12.0.2/32 10.255.14.177/32 10.255.71.24/32

224.0.0.5/32

Meaning


*[Direct/0] 3d 07:03:30 > via fe-1/2/0.6 [BGP/170] 00:45:36, localpref AS path: 65500 I > to 1.12.0.1 via fe-1/2/0.6 *[Local/0] 3d 07:03:30 Local via fe-1/2/0.6 *[Direct/0] 3d 07:03:30 > via lo0.3 *[OSPF/10] 3d 07:02:45, metric > to 1.12.0.1 via fe-1/2/0.6 [BGP/170] 00:45:36, localpref AS path: 65500 I > to 1.12.0.1 via fe-1/2/0.6 *[OSPF/10] 5d 03:42:45, metric MultiRecv

100

1 100

1

The output shows that on Device R1, the active path to Device R2’s loopback interface (10.255.14.177/32) is a BGP route. The output also shows that on Device R2, the active path to Device R1’s loopback interface (10.255.71.24/32) is an OSPF route.

•

Route Preferences Overview on page 6

•


•


Example: Configuring BGP Path Selection •


•


Understanding BGP Path Selection For each prefix in the routing table, the routing protocol process selects a single best path. After the best path is selected, the route is installed in the routing table. The best path becomes the active route if the same prefix is not learned by a protocol with a lower (more preferred) global preference value. The algorithm for determining the active route is as follows:

1150



1.

Verify that the next hop can be resolved.

2. Choose the path with the lowest preference value (routing protocol process

preference). Routes that are not eligible to be used for forwarding (for example, because they were rejected by routing policy or because a next hop is inaccessible) have a preference of –1 and are never chosen. 3. For BGP, prefer the path with higher local preference.

For non-BGP paths, choose the path with the lowest preference2 value. 4. For BGP, prefer the path with the shortest autonomous system (AS) path value

(skipped if the as-path-ignore statement is configured). A confederation segment (sequence or set) has a path length of 0. An AS set has a path length of 1. 5. For BGP, prefer the route with the lower origin code.

Routes learned from an interior gateway protocol (IGP) have a lower origin code than those learned from an exterior gateway protocol (EGP), and both have lower origin codes than incomplete routes (routes whose origin is unknown). 6. For BGP, prefer the path with the lowest multiple exit discriminator (MED) metric.

Depending on whether nondeterministic routing table path selection behavior is configured, there are two possible cases: •

If nondeterministic routing table path selection behavior is not configured (that is, if the path-selection cisco-nondeterministic statement is not included in the BGP configuration), for paths with the same neighboring AS numbers at the front of the AS path, prefer the path with the lowest MED metric. To always compare MEDs whether or not the peer ASs of the compared routes are the same, include the path-selection always-compare-med statement.

•

If nondeterministic routing table path selection behavior is configured (that is, the path-selection cisco-nondeterministic statement is included in the BGP configuration), prefer the path with the lowest MED metric.

Confederations are not considered when determining neighboring ASs. A missing MED metric is treated as if a MED were present but zero.

NOTE: MED comparison works for single path selection within an AS (when the route does not include an AS path), though this usage Is uncommon.

7. Prefer strictly internal paths, which include IGP routes and locally generated routes

(static, direct, local, and so forth). 8. Prefer strictly external BGP (EBGP) paths over external paths learned through internal

BGP (IBGP) sessions.


1151


9. For BGP, prefer the path whose next hop is resolved through the IGP route with the

lowest metric.

NOTE: A path is considered a BGP equal-cost path (and will be used for forwarding) if a tie-break is performed after the previous step. All paths with the same neighboring AS, learned by a multipath-enabled BGP neighbor, are considered. BGP multipath does not apply to paths that share the same MED-plus-IGP cost yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.

10. For BGP, if both paths are external, prefer the currently active path to minimize

route-flapping. This rule is not used if: •

path-selection external-router-id is configured.

•

Both peers have the same router ID.

•

Either peer is a confederation peer.

•

Neither path is the current active path.

11. For BGP, prefer the path from the peer with the lowest router ID. For any path with an

originator ID attribute, substitute the originator ID for the router ID during router ID comparison. 12. For BGP, prefer the path with the shortest cluster list length. The length is 0 for no list. 13. For BGP, prefer the path from the peer with the lowest peer IP address.

By default, only the multiple exit discriminators (MEDs) of routes that have the same peer autonomous systems (ASs) are compared. You can configure routing table path selection options to obtain different behaviors. The third step of the algorithm, by default, evaluates the length of the AS path and determines the active path. You can configure an option that enables Junos OS to skip this third step of the algorithm by including the as-path-ignore option.

NOTE: The as-path-ignore option is not supported for routing instances.

To configure routing table path selection behavior, include the path-selection statement: path-selection { (always-compare-med | cisco-non-deterministic | external-router-id); as-path-ignore; med-plus-igp { igp-multiplier number; med-multiplier number; } }

1152



For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. Routing table path selection can be configured in one of the following ways: •

Using the same nondeterministic behavior as does the Cisco IOS software (cisco-non-deterministic). This behavior has two effects: •

The active path is always first. All nonactive but eligible paths follow the active path and are maintained in the order in which they were received, with the most recent path first. Ineligible paths remain at the end of the list.

•

When a new path is added to the routing table, path comparisons are made without removing from consideration those paths that should never be selected because those paths lose the MED tie-breaking rule.

NOTE: The result of these two effects is that the system only sometimes compares the MED values between paths that it should otherwise compare. Because of this, we recommend that you not configure nondeterministic behavior.

•

Always comparing MEDs whether or not the peer ASs of the compared routes are the same (always-compare-med).

•

Comparing the router ID between external BGP paths to determine the active path (external-router-id). By default, router ID comparison is not performed if one of the external paths is active. You can force the router ID comparison by restarting the routing process with the restart routing operational-mode command.

•

Adding the IGP cost to the next-hop destination to the MED value before comparing MED values for path selection. BGP multipath does not apply to paths that share the same MED-plus-IGP cost, yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.

Example: Ignoring the AS Path Attribute When Selecting the Best Path If multiple BGP routes to the same destination exist, BGP selects the best path based on the route attributes of the paths. One of the route attributes that affects the best-path decision is the length of the AS paths of each route. Routes with shorter AS paths are preferred over those with longer AS paths. Although not typically practical, some scenarios might require that the AS path length be ignored in the route selection process. This example shows how to configure a routing device to ignore the AS path attribute. •


•


•


•



1153



Overview On externally connected routing devices, the purpose of skipping the AS path comparison might be to force an external BGP (EBGP) versus internal BGP (IBGP) decision to remove traffic from your network as soon as possible. On internally connected routing devices, you might want your IBGP-only routers to default to the local externally connected gateway. The local IBGP-only (internal) routers skip the AS path comparison and move down the decision tree to use the closest interior gateway protocol (IGP) gateway (lowest IGP metric). Doing this might be an effective way to force these routers to use a LAN connection instead of their WAN connection.

CAUTION: When you include the as-path-ignore statement on a routing device in your network, you might need to include it on all other BGP-enabled devices in your network to prevent routing loops and convergence issues. This is especially true for IBGP path comparisons.

In this example, Device R2 is learning about the loopback interface address on Device R4 (4.4.4.4/32) from Device R1 and Device R3. Device R1 is advertising 4.4.4.4/32 with an AS-path of 1 5 4, and Device R3 is advertising 4.4.4.4/32 with an AS-path of 3 4. Device R2 selects the path for 4.4.4.4/32 from Device R3 as the best path because the AS path is shorter than the AS path from Device R1. This example modifies the BGP configuration on Device R2 so that the AS-path length is not used in the best-path selection. Device R1 has a lower router ID (1.1.1.1) than Device R3 (1.1.1.1). If all other path selection criteria are equal (or, as in this case, ignored), the route learned from Device R1 is used. Because the AS-path attribute is being ignored, the best path is toward Device R1 because of its lower router ID value. Figure 63 on page 1155 shows the sample topology.

1154



Figure 63: Topology for Ignoring the AS-Path Lengh AS 4

R4

AS 5

R5

R2

Router ID: 3.3.3.3

Router ID: 1.1.1.1

AS 1

R3

AS 2

AS 3

g041166

R1


Device R1

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set interfaces fe-1/2/0 unit 1 family inet address 192.168.10.1/24 set interfaces fe-1/2/1 unit 10 family inet address 192.168.50.2/24 set interfaces lo0 unit 1 family inet address 1.1.1.1/32 set protocols bgp group ext type external set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext export send-local set protocols bgp group ext neighbor 192.168.10.2 peer-as 2 set protocols bgp group ext neighbor 192.168.50.1 peer-as 5 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-local term 1 from protocol local


1155


set policy-options policy-statement send-local term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 192.168.20.0/24 next-hop 192.168.10.2 set routing-options static route 192.168.30.0/24 next-hop 192.168.10.2 set routing-options static route 192.168.40.0/24 next-hop 192.168.50.1 set routing-options router-id 1.1.1.1 set routing-options autonomous-system 1

1156

Device R2

set interfaces fe-1/2/0 unit 2 family inet address 192.168.10.2/24 set interfaces fe-1/2/1 unit 3 family inet address 192.168.20.2/24 set interfaces lo0 unit 2 family inet address 2.2.2.2/32 set protocols bgp path-selection as-path-ignore set protocols bgp group ext type external set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext export send-local set protocols bgp group ext neighbor 192.168.10.1 peer-as 1 set protocols bgp group ext neighbor 192.168.20.1 peer-as 3 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-local term 1 from protocol local set policy-options policy-statement send-local term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 192.168.50.0/24 next-hop 192.168.10.1 set routing-options static route 192.168.40.0/24 next-hop 192.168.10.1 set routing-options static route 192.168.30.0/24 next-hop 192.168.20.1 set routing-options router-id 2.2.2.2 set routing-options autonomous-system 2

Device R3

set interfaces fe-1/2/0 unit 4 family inet address 192.168.20.1/24 set interfaces fe-1/2/1 unit 5 family inet address 192.168.30.1/24 set interfaces lo0 unit 3 family inet address 1.1.1.1/32 set protocols bgp group ext type external set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext export send-local set protocols bgp group ext neighbor 192.168.20.2 peer-as 2 set protocols bgp group ext neighbor 192.168.30.2 peer-as 4 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-local term 1 from protocol local set policy-options policy-statement send-local term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 192.168.10.0/24 next-hop 192.168.20.2 set routing-options static route 192.168.50.0/24 next-hop 192.168.20.2 set routing-options static route 192.168.40.0/24 next-hop 192.168.30.2 set routing-options router-id 3.3.3.3 set routing-options autonomous-system 3

Device R4

set interfaces fe-1/2/0 unit 6 family inet address 192.168.30.2/24 set interfaces fe-1/2/1 unit 7 family inet address 192.168.40.1/24 set interfaces lo0 unit 4 family inet address 4.4.4.4/32



set protocols bgp group ext type external set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext export send-local set protocols bgp group ext neighbor 192.168.30.1 peer-as 3 set protocols bgp group ext neighbor 192.168.40.2 peer-as 5 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-local term 1 from protocol local set policy-options policy-statement send-local term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 192.168.10.0/24 next-hop 192.168.40.2 set routing-options static route 192.168.50.0/24 next-hop 192.168.40.2 set routing-options static route 192.168.40.0/24 next-hop 192.168.30.1 set routing-options router-id 4.4.4.4 set routing-options autonomous-system 4

Device R5

set interfaces fe-1/2/0 unit 8 family inet address 192.168.40.2/24 set interfaces fe-1/2/1 unit 9 family inet address 192.168.50.1/24 set interfaces lo0 unit 5 family inet address 5.5.5.5/32 set protocols bgp group ext type external set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext export send-local set protocols bgp group ext neighbor 192.168.40.1 peer-as 4 set protocols bgp group ext neighbor 192.168.50.2 peer-as 1 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-local term 1 from protocol local set policy-options policy-statement send-local term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 192.168.10.0/24 next-hop 192.168.50.2 set routing-options static route 192.168.20.0/24 next-hop 192.168.50.2 set routing-options static route 192.168.30.0/24 next-hop 192.168.40.1 set routing-options router-id 5.5.5.5 set routing-options autonomous-system 5



Configure the interfaces. [edit interfaces] user@R2# set fe-1/2/0 unit 2 family inet address 192.168.10.2/24 user@R2# set fe-1/2/1 unit 3 family inet address 192.168.20.2/24 user@R2# set lo0 unit 2 family inet address 2.2.2.2/32

2.

Configure EBGP. [edit protocols bgp group ext]


1157


user@R2# set type external user@R2# set export send-direct user@R2# set export send-static user@R2# set export send-local user@R2# set neighbor 192.168.10.1 peer-as 1 user@R2# set neighbor 192.168.20.1 peer-as 3 3.

Configure the autonomous system (AS) path attribute to be ignored in the Junos OS path selection algorithm. [edit protocols bgp] user@R2# set path-selection as-path-ignore

4.

Configure the routing policy. [edit policy-options] user@R2# set policy-statement send-direct term 1 from protocol direct user@R2# set policy-statement send-direct term 1 then accept user@R2# set policy-statement send-local term 1 from protocol local user@R2# set policy-statement send-local term 1 then accept user@R2# set policy-statement send-static term 1 from protocol static user@R2# set policy-statement send-static term 1 then accept

5.

Configure some static routes. [edit routing-options static] user@R2# set route 192.168.50.0/24 next-hop 192.168.10.1 user@R2# set route 192.168.40.0/24 next-hop 192.168.10.1 user@R2# set route 192.168.30.0/24 next-hop 192.168.20.1

6.

Configure the autonomous system (AS) number and the router ID. [edit routing-options] user@R2# set router-id 2.2.2.2 user@R2# set autonomous-system 2

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R2# show interfaces fe-1/2/0 { unit 2 { family inet { address 192.168.10.2/24; } } } fe-1/2/1 { unit 3 { family inet { address 192.168.20.2/24; } } } lo0 { unit 2 {

1158



family inet { address 2.2.2.2/32; } } } user@R2# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } policy-statement send-local { term 1 { from protocol local; then accept; } } policy-statement send-static { term 1 { from protocol static; then accept; } } user@R2# show protocols bgp { path-selection as-path-ignore; group ext { type external; export [ send-direct send-static send-local ]; neighbor 192.168.10.1 { peer-as 1; } neighbor 192.168.20.1 { peer-as 3; } } } user@R21# show routing-options static { route 192.168.50.0/24 next-hop 192.168.10.1; route 192.168.40.0/24 next-hop 192.168.10.1; route 192.168.30.0/24 next-hop 192.168.20.1; } router-id 2.2.2.2; autonomous-system 2;

If you are done configuring the device, enter commit from configuration mode. Repeat the configuration on the other devices in the network, changing the interface names and IP addresses, as needed.


1159



Checking the Neighbor Status on page 1160

Checking the Neighbor Status Purpose

Make sure that from Device R2, the active path to get to AS 4 is through AS 1 and AS 5, not through AS 3.

NOTE: To verify the functionality of the as-path-ignore statement, you might need to run the restart routing command to force reevaluation of the active path. This is because for BGP, if both paths are external, the Junos OS behavior is to prefer the currently active path. This behavior helps to minimize route-flapping. Use caution when restarting the routing protocol process in a production network.

Action

From operational mode, enter the restart routing command. user@R2> restart routing Routing protocols process started, pid 49396

From operational mode, enter the show route 4.4.4.4 protocol bgp command. user@R2> show route 4.4.4.4 protocol bgp inet.0: 12 destinations, 25 routes (12 active, 0 holddown, 4 hidden) + = Active Route, - = Last Active, * = Both 4.4.4.4/32

Meaning


*[BGP/170] 00:00:12, localpref 100 AS path: 1 5 4 I > to 192.168.10.1 via fe-1/2/0.2 [BGP/170] 00:00:08, localpref 100 AS path: 3 4 I > to 192.168.20.1 via fe-1/2/1.3

The asterisk (*) is next to the path learned from R1, meaning that this is the active path. The AS path for the active path is 1 5 4, which is longer than the AS path (3 4) for the nonactive path learned from Router R3.

•


•


Examples: Configuring BGP Local AS

1160

•

Understanding the BGP Local AS Attribute on page 1161

•

Example: Configuring a Local AS for EBGP Sessions on page 1164

•

Example: Configuring a Private Local AS for EBGP Sessions on page 1174



Understanding the BGP Local AS Attribute When an Internet service provider (ISP) acquires a network that belongs to a different autonomous system (AS), there is no seamless method for moving the BGP peers of the acquired network to the AS of the acquiring ISP. The process of configuring the BGP peers with the new AS number can be time-consuming and cumbersome. Sometimes customers do not want to or are not immediately able to modify their peer arrangements or configuration. During such a transition period, it can be useful to configure BGP-enabled devices in the new AS to use the former AS number in BGP updates. This former AS number is called a local AS. The use of a local AS number permits the routing devices in an acquired network to appear to belong to two ASs: the new AS (the global AS) to which it now physically belongs and the former AS. The local AS is prepended before the global AS in the AS path used by the BGP peer sent to internal BGP (IBGP) neighbors and external BGP (EBGP) peers. For example, ISP A, with an AS of 1000, acquires ISP B, with an AS of 100. ISP B’s customer, ISP C, does not want to change its configuration. After ISP B becomes part of ISP A, a local AS number of 100 is configured for use in EBGP peer sessions with ISP C. This means that the local AS value of 100 is prepended before the global AS value of 1000 in the AS path used to export routes to direct external peers in ISP C. The Junos OS implementation of the local AS attribute supports the following options:


1161


•

Local AS with private option—When you use the private option, the local AS is used during the establishment of the BGP session with an EBGP neighbor but is hidden in the AS path sent to other EBGP peers. Only the global AS is included in the AS path sent to external peers. The private option is useful for establishing local peering with routing devices that remain configured with their former AS or with a specific customer that has not yet modified its peer arrangements. The local AS is used to establish the BGP session with the EBGP neighbor but is hidden in the AS path sent to external peers in another AS. Include the private option so that the local AS is not prepended before the global AS in the AS path sent to external peers. When you specify the private option, the local AS is prepended only in the AS path sent to the EBGP neighbor. For example, in Figure 64 on page 1162, Router 1 and Router 2 are in AS 64496, Router 4 is in AS 64511, and Router 3 is in AS 64510. Router 2 used to belong to AS 64497, which has merged with another network and now belongs to AS 64496. Because Router 3 still peers with Router 2 using its former AS, 64497, Router 2 needs to be configured with a local AS of 64497 to maintain peering with Router 3. Configuring a local AS of 64497 permits Router 2 to add AS 64497 when advertising routes to Router 3. Router 3 sees an AS path of 64497 64496 for the prefix 10/8.

Figure 64: Local AS Configuration AS 64511

AS 64496 192.168.1 1

2 IBGP

.1

EBGP

4 .2

AS 64497 192.168.10 10.0.0.0/8 EBGP 10.222.0.0/16 .2

AS 64510

g017007

3

To prevent Router 2 from adding the local AS number in its announcements to other peers, use the local-as 64497 private statement. This statement configures Router 2 to not include local AS 64497 when announcing routes to Router 1 and to Router 4. In this case, Router 4 sees an AS path of 64496 64510 for the prefix 10.222/16. •

1162

Local AS with alias option—In Junos OS Release 9.5 and later, you can configure a local AS as an alias. During the establishment of the BGP open session, the AS used in the Open message alternates between the local AS and the global AS. If the local AS is used to connect with the EBGP neighbor, then only the local AS is prepended to the AS path when the BGP peer session is established. If the global AS is used to connect with the EBGP neighbor, then only the global AS is prepended to the AS path when the BGP peer session is established. The use of the alias option also means that



the local AS is not prepended to the AS path for any routes learned from that EBGP neighbor. Therefore, the local AS remains hidden from other external peers. Configuring a local AS with the alias option is especially useful when you are migrating the routing devices in an acquired network to the new AS. During the migration process, some routing devices might be configured with the new AS while others remain configured with the former AS. For example, it is good practice to start by migrating first to the new AS any routing devices that function as route reflectors. However, as you migrate the route reflector clients incrementally, the route reflector has to peer with routing devices configured with the former AS as well as routing devices configured with the new AS. To establish local peer sessions, it can be useful for the BGP peers in the network to be able to use both the local AS and the global AS. At the same time, you want to hide this local AS from external peers and use only the global AS in the AS path when exporting routes to another AS. In such situations, choose the alias option. Include the alias option to configure the local AS as an alias to the global AS configured at the [edit routing-options] hierarchy level. When you configure a local AS as an alias, during the establishment of the BGP open session, the AS used in the Open message alternates between the local AS and the global AS. The local AS is prepended to the AS path only when the peer session with an EBGP neighbor is established using that local AS. The local AS is hidden in the AS path sent to any other external peers. Only the global AS is prepended to the AS path when the BGP session is established using the global AS.

NOTE: The private and alias options are mutually exclusive. You cannot configure both options with the same local-as statement.

•

Local AS with option not to prepend the global AS—In Junos OS Release 9.6 and later, you can configure a local AS with the option not to prepend the global AS. Only the local AS is included in the AS path sent to external peers. Use the no-prepend-global-as option when you want to strip the global AS number from outbound BGP updates. This option is useful in a virtual private network (VPN) scenario where you want to hide the global AS from the VPN. Include the no-prepend-global-as option to have the global AS configured at the [edit routing-options] hierarchy level stripped from the AS path sent to external peers. When you use this option, only the local AS is included in the AS path.

•

Number of loops option—The local AS feature also supports the ability to specify the number of times detection of the AS number in the AS_PATH attribute causes the route to be discarded or hidden. For example, if you configure loops 1, the route is hidden if the AS number is detected in the path one or more times. This is the default behavior. If you configure loops 2, the route is hidden if the AS number is detected in the path two or more times. For the loops number statement, you can configure 1 through 10.


1163


NOTE: If you configure the local AS values for any BGP group, the detection of routing loops is performed using both the AS and the local AS values for all BGP groups. If the local AS for the EBGP or IBGP peer is the same as the current AS, do not use the local-as statement to specify the local AS number. When you configure the local AS within a VRF, this impacts the AS path loop-detection mechanism. All of the local-as statements configured on the device are part of a single AS domain. The AS path loop-detection mechanism is based on looking for a matching AS present in the domain.

Example: Configuring a Local AS for EBGP Sessions This example shows how to configure a local autonomous system (AS) for a BGP peer so that both the global AS and the local AS are used in BGP inbound and outbound updates. •


•


•


•



Overview Use the local-as statement when ISPs merge and want to preserve a customer’s configuration, particularly the AS with which the customer is configured to establish a peer relationship. The local-as statement simulates the AS number already in place in customer routers, even if the ISP’s router has moved to a different AS. This example shows how to use the local-as statement to configure a local AS. The local-as statement is supported for BGP at the global, group, and neighbor hierarchy levels. When you configure the local-as statement, you must specify an AS number. You can specify a number from 1 through 4,294,967,295 in plain-number format. In Junos OS Release 9.1 and later, the range for autonomous system (AS) numbers is extended to provide BGP support for 4-byte AS numbers as defined in RFC 4893, BGP Support for Four-octet AS Number Space. In Junos OS Release 9.3 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. You can specify a value from 0.0 through 65535.65535

1164



in AS-dot notation format. Junos OS continues to support 2-byte AS numbers. The 2-byte AS number range is 1 through 65,535 (this is a subset of the 4-byte range). Figure 65 on page 1165 shows the sample topology.

R1

R2

R3

AS 100

AS 200

AS 300

g041158

Figure 65: Topology for Configuring the Local AS

In this example, Device R2 used to belong to AS 250 and now is in AS 200. Device R1 and Device R3 are configured to peer with AS 250 instead of the new AS number (AS 200). Device R2 has the new AS number configured with the autonoumous-system 200 statement. What enables the peering sessions to work is the addition of the local-as 250 statement in the BGP configuration. Because local-as 250 is configured, Device R2 includes both the global AS (200) and the local AS (250) in BGP inbound and outbound updates.

Configuration


•


•


•



Device R1

set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.1/30 set interfaces lo0 unit 1 family inet address 192.168.0.1/32 set protocols bgp group ext type external set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext peer-as 250 set protocols bgp group ext neighbor 10.0.0.2 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 10.1.0.0/30 next-hop 10.0.0.2 set routing-options autonomous-system 100

Device R2

set interfaces fe-1/2/0 unit 2 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 3 family inet address 10.1.0.1/30 set interfaces lo0 unit 2 family inet address 192.168.0.2/32 set protocols bgp group ext type external set protocols bgp group ext export send-direct


1165


set protocols bgp group ext export send-static set protocols bgp group ext local-as 250 set protocols bgp group ext neighbor 10.0.0.1 peer-as 100 set protocols bgp group ext neighbor 10.1.0.2 peer-as 300 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options autonomous-system 200

Device R3





2.

Configure external BGP (EBGP). [edit protocols bgp group ext] user@R1# set type external user@R1# set export send-direct user@R1# set export send-static user@R1# set peer-as 250 user@R1# set neighbor 10.0.0.2

3.

Configure the routing policy. [edit policy-options] user@R1# set policy-statement send-direct term 1 from protocol direct user@R1# set policy-statement send-direct term 1 then accept user@R1# set policy-statement send-static term 1 from protocol static user@R1# set policy-statement send-static term 1 then accept

4.

Configure a static route to the remote network between Device R2 and Device R3. [edit routing-options]

1166



user@R1# set static route 10.1.0.0/30 next-hop 10.0.0.2 5.

Configure the global AS number. [edit routing-options] user@R1# set autonomous-system 100

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show interfaces fe-1/2/0 { unit 1 { family inet { address 10.0.0.1/30; } } } lo0 { unit 1 { family inet { address 192.168.0.1/32; } } } user@R1# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } policy-statement send-static { term 1 { from protocol static; then accept; } } user@R1# show protocols bgp { group ext { type external; export [ send-direct send-static ]; peer-as 250; neighbor 10.0.0.2; } } user@R1# show routing-options static { route 10.1.0.0/30 next-hop 10.0.0.2; } autonomous-system 100;


1167




Configure the interfaces. [edit interfaces] user@R2# set fe-1/2/0 unit 2 family inet address 10.0.0.2/30 user@R2# set fe-1/2/1 unit 3 family inet address 10.1.0.1/30 user@R2# set lo0 unit 2 family inet address 192.168.0.2/32

2.

Configure EBGP. [edit protocols bgp group ext] user@R2# set type external user@R2# set export send-direct user@R2# set export send-static user@R2# set neighbor 10.0.0.1 peer-as 100 user@R2# set neighbor 10.1.0.2 peer-as 300

3.

Configure the local autonomous system (AS) number. [edit protocols bgp group ext] user@R2# set local-as 250

4.

Configure the global AS number. [edit routing-options] user@R2# set autonomous-system 200

5.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R2# show interfaces fe-1/2/0 { unit 2 { family inet { address 10.0.0.2/30; }

1168



} } fe-1/2/1 { unit 3 { family inet { address 10.1.0.1/30; } } } lo0 { unit 2 { family inet { address 192.168.0.2/32; } } } user@R2# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } policy-statement send-static { term 1 { from protocol static; then accept; } } user@R2# show protocols bgp { group ext { type external; export [ send-direct send-static ]; local-as 250; neighbor 10.0.0.1 { peer-as 100; } neighbor 10.1.0.2 { peer-as 300; } } } user@R2# show routing-options autonomous-system 200;



1169





2.

Configure EBGP. [edit protocols bgp group ext] user@R3# set type external user@R3# set export send-direct user@R3# set export send-static user@R3# set peer-as 250 user@R3# set neighbor 10.1.0.1

3.

Configure the global autonomous system (AS) number. [edit routing-options] user@R3# set autonomous-system 300

4.

Configure a static route to the remote network between Device R1 and Device R2. [edit routing-options] user@R3# set static route 10.0.0.0/30 next-hop 10.1.0.1

5.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R3# show interfaces fe-1/2/0 { unit 4 { family inet { address 10.1.0.2/30; } } } lo0 { unit 3 { family inet { address 192.168.0.3/32;

1170



} } } user@R3# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } policy-statement send-static { term 1 { from protocol static; then accept; } } user@R3# show protocols bgp { group ext { type external; export [ send-direct send-static ]; peer-as 250; neighbor 10.1.0.1; } } user@R3# show routing-options static { route 10.0.0.0/30 next-hop 10.1.0.1; } autonomous-system 300;



Checking the Local and Global AS Settings on page 1171

•

Checking the BGP Peering Sessions on page 1173

•

Verifying the BGP AS Paths on page 1173

Checking the Local and Global AS Settings Purpose Action

Make sure that Device R2 has the local and global AS settings configured. From operational mode, enter the show bgp neighbors command. user@R2> show bgp neighbors Peer: 10.0.0.1+179 AS 100 Local: 10.0.0.2+61036 AS 250 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct send-static ] Options:


1171


Holdtime: 90 Preference: 170 Local AS: 250 Local System AS: 200 Number of flaps: 0 Peer ID: 192.168.0.1 Local ID: 192.168.0.2 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down Local Interface: fe-1/2/0.2 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 100) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 3 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 4 Last traffic (seconds): Received 6 Sent 14 Checked 47 Input messages: Total 258 Updates 3 Refreshes 0 Octets 4969 Output messages: Total 258 Updates 2 Refreshes 0 Octets 5037 Output Queue[0]: 0 Peer: 10.1.0.2+179 AS 300 Local: 10.1.0.1+52296 AS 250 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct send-static ] Options: Holdtime: 90 Preference: 170 Local AS: 250 Local System AS: 200 Number of flaps: 0 Peer ID: 192.168.0.3 Local ID: 192.168.0.2 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down Local Interface: fe-1/2/1.3 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 300) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 3 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 4

1172



Last traffic (seconds): Received 19 Sent 26 Checked 9 Input messages: Total 256 Updates 3 Refreshes 0 Output messages: Total 256 Updates 2 Refreshes 0 Output Queue[0]: 0

Meaning


The Local AS: 250 and Local System AS: 200 output shows that Device R2 has the expected settings. Also, the options list includes LocalAS. Checking the BGP Peering Sessions

Purpose Action

Make sure that the sessions are established and that the local AS number 250 is displayed. From operational mode, enter the show bgp summary command. user@R1> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 4 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.0.0.2 250 232 233 0 4 1:42:37 2/4/4/0 0/0/0/0 user@R3> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 4 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.1.0.1 250 235 236 0 4 1:44:25 2/4/4/0 0/0/0/0

Meaning

Device R1 and Device R3 appear to be peering with a device in AS 250, even though Device R2 is actually in AS 200. Verifying the BGP AS Paths

Purpose

Action

Make sure that the routes are in the routing tables and that the AS paths show the local AS number 250. From configuration mode, enter the set route protocol bgp command. user@R1> show route protocol bgp inet.0: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30

10.1.0.0/30

192.168.0.2/32

192.168.0.3/32


[BGP/170] 01:46:44, localpref AS path: 250 I > to 10.0.0.2 via fe-1/2/0.1 [BGP/170] 01:46:44, localpref AS path: 250 I > to 10.0.0.2 via fe-1/2/0.1 *[BGP/170] 01:46:44, localpref AS path: 250 I > to 10.0.0.2 via fe-1/2/0.1 *[BGP/170] 01:46:40, localpref

100

100

100

100

1173


AS path: 250 300 I > to 10.0.0.2 via fe-1/2/0.1 user@R3> show route protocol bgp inet.0: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30

10.1.0.0/30

192.168.0.1/32

192.168.0.2/32

Meaning

[BGP/170] 01:47:10, localpref AS path: 250 I > to 10.1.0.1 via fe-1/2/0.4 [BGP/170] 01:47:10, localpref AS path: 250 I > to 10.1.0.1 via fe-1/2/0.4 *[BGP/170] 01:47:10, localpref AS path: 250 100 I > to 10.1.0.1 via fe-1/2/0.4 *[BGP/170] 01:47:10, localpref AS path: 250 I > to 10.1.0.1 via fe-1/2/0.4

100

100

100

100

Device R1 and Device R3 appear to have routes with AS paths that include AS 250, even though Device R2 is actually in AS 200.

Example: Configuring a Private Local AS for EBGP Sessions This example shows how to configure a private local autonomous system (AS) number. The local AS is considered to be private because it is advertised to peers that use the local AS number for peering, but is hidden in the announcements to peers that can use the global AS number for peering. •


•


•


•



Overview Use the local-as statement when ISPs merge and want to preserve a customer’s configuration, particularly the AS with which the customer is configured to establish a peer relationship. The local-as statement simulates the AS number already in place in customer routers, even if the ISP’s router has moved to a different AS. When you use the private option, the local AS is used during the establishment of the BGP session with an external BGP (EBGP) neighbor but is hidden in the AS path sent to other EBGP peers. Only the global AS is included in the AS path sent to external peers. The private option is useful for establishing local peering with routing devices that remain configured with their former AS or with a specific customer that has not yet modified its

1174



peer arrangements. The local AS is used to establish the BGP session with the EBGP neighbor but is hidden in the AS path sent to external peers in another AS. Include the private option so that the local AS is not prepended before the global AS in the AS path sent to external peers. When you specify the private option, the local AS is prepended only in the AS path sent to the EBGP neighbor. Figure 66 on page 1175 shows the sample topology.

Figure 66: Topology for Configuring a Private Local AS AS 64496

Local AS 64497

R2

R3

R4

g041160

R1

Device R1 is in AS 64496. Device R2 is in AS 64510. Device R3 is in AS 64511. Device R4 is in AS 64512. Device R1 used to belong to AS 64497, which has merged with another network and now belongs to AS 64496. Because Device R3 still peers with Device R1 using its former AS, 64497, Device R1 needs to be configured with a local AS of 64497 to maintain peering with Device R3. Configuring a local AS of 64497 permits Device R1 to add AS 64497 when advertising routes to Device R3. Device R3 sees an AS path of 64497 64496 for the prefix 10.1.1.2/32, which is Device R2's loopback interface. Device R4, which is behind Device R3, sees an AS path of 64511 64497 64496 64510 to Device R2’s loopback interface. To prevent Device R1 from adding the local AS number in its announcements to other peers, this example includes the local-as 64497 private statement. The private option configures Device R1 to not include the local AS 64497 when announcing routes to Device R2. Device R2 sees an AS path of 64496 64511 to Device R3 and an AS path of 64496 64511 64512 to Device R4. The private option in Device R1's configuration causes the AS number 64497 to be missing from the AS paths that Device R1 readvertises to Device R2. Device R2 is hiding the private local AS from all the routers, except Device R3. The private option applies to the routes that Device R1 receives (learns) from Device R3 and that Device R1, in turn, readvertises to other routers. When these routes, learned from Device R3, are readavertised by Device R1 to Device R2, the private local AS is missing from the AS path advertised to Device R2.

Configuration •



1175



1176


Device R1

set interfaces fe-1/2/0 unit 3 family inet address 192.168.1.1/24 set interfaces fe-1/2/1 unit 5 family inet address 192.168.10.1/24 set interfaces lo0 unit 2 family inet address 10.1.1.1/32 set protocols bgp group external-AS64511 type external set protocols bgp group external-AS64511 peer-as 64511 set protocols bgp group external-AS64511 local-as 64497 set protocols bgp group external-AS64511 local-as private set protocols bgp group external-AS64511 neighbor 192.168.1.2 set protocols bgp group external-AS64510 type external set protocols bgp group external-AS64510 peer-as 64510 set protocols bgp group external-AS64510 neighbor 192.168.10.2 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 64496

Device R2

set interfaces fe-1/2/0 unit 6 family inet address 192.168.10.2/24 set interfaces lo0 unit 3 family inet address 10.1.1.2/32 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external peer-as 64496 set protocols bgp group external neighbor 192.168.10.1 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 64510

Device R3

set interfaces fe-1/2/0 unit 4 family inet address 192.168.1.2/24 set interfaces fe-1/2/1 unit 7 family inet address 192.168.5.1/24 set interfaces lo0 unit 4 family inet address 10.1.1.3/32 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external neighbor 192.168.1.1 peer-as 64497 set protocols bgp group external neighbor 192.168.5.2 peer-as 64512 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 64511

Device R4

set interfaces fe-1/2/0 unit 8 family inet address 192.168.5.2/24 set interfaces lo0 unit 5 family inet address 10.1.1.4/32 set protocols bgp group external type external set protocols bgp group external export send-direct set protocols bgp group external peer-as 64511 set protocols bgp group external neighbor 192.168.5.1 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set routing-options autonomous-system 64512






2.

Configure the EBGP peering session with Device R2. [edit protocols bgp group external-AS64510] user@R1# set type external user@R1# set peer-as 64510 user@R1# set neighbor 192.168.10.2

3.

Configure the EBGP peering session with Device R3. [edit protocols bgp group external-AS64511] user@R1# set type external user@R1# set peer-as 64511 user@R1# set local-as 64497 user@R1# set local-as private user@R1# set neighbor 192.168.1.2

4.

Configure the routing policy. [edit policy-options policy-statement send-direct term 1] user@R1# set from protocol direct user@R1# set then accept

5.

Configure the global autonomous system (AS) number. [edit routing-options] user@R1# set autonomous-system 64496

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show interfaces fe-1/2/0 { unit 3 { family inet { address 192.168.1.1/24; }


1177


} } fe-1/2/1 { unit 5 { family inet { address 192.168.10.1/24; } } } lo0 { unit 2 { family inet { address 10.1.1.1/32; } } } user@R1# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } user@R1# show protocols bgp { group external-AS64511 { type external; peer-as 64511; local-as 64497 private; neighbor 192.168.1.2; } group external-AS64510 { type external; peer-as 64510; neighbor 192.168.10.2; } } user@R1# show routing-options autonomous-system 64496;

If you are done configuring the device, enter commit from configuration mode. Repeat the configuration as needed for the other devices in the topology.


1178

•

Checking Device R2’s AS Paths on page 1179

•

Checking Device R3’s AS Paths on page 1179



Checking Device R2’s AS Paths Purpose

Action

Make sure that Device R2 does not have AS 64497 in its AS paths to Device R3 and Device R4. From operational mode, enter the show route protocol bgp command. user@R2> show route protocol bgp inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.1.3/32

10.1.1.4/32

192.168.5.0/24

Meaning

*[BGP/170] 01:33:11, localpref 100 AS path: 64496 64511 I > to 192.168.10.1 via fe-1/2/0.6 *[BGP/170] 01:33:11, localpref 100 AS path: 64496 64511 64512 I > to 192.168.10.1 via fe-1/2/0.6 *[BGP/170] 01:49:15, localpref 100 AS path: 64496 64511 I > to 192.168.10.1 via fe-1/2/0.6

Device R2’s AS paths do not include AS 64497. Checking Device R3’s AS Paths

Purpose

Action

Make sure that Device R2 does not have AS 64497 in its AS paths to Device R3 and Device R4. From operational mode, enter the show route protocol bgp command. user@R3> show route protocol bgp inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.1.2/32

10.1.1.4/32

192.168.5.0/24

Meaning


*[BGP/170] 01:35:11, localpref 100 AS path: 64497 64496 64510 I > to 192.168.1.1 via fe-1/2/0.4 *[BGP/170] 01:35:11, localpref 100 AS path: 64512 I > to 192.168.5.2 via fe-1/2/1.7 [BGP/170] 01:51:15, localpref 100 AS path: 64512 I > to 192.168.5.2 via fe-1/2/1.7

Device R3’s route to Device R2 (prefix 10.1.1.2) includes both the local and the global AS configured on Device R1 (64497 and 64496, respectively).

•


•



1179


Example: Removing Private AS Numbers •

Understanding Private AS Number Removal from AS Paths on page 1180

•

Example: Removing Private AS Numbers from AS Paths on page 1181

Understanding Private AS Number Removal from AS Paths By default, when BGP advertises AS paths to remote systems, it includes all AS numbers, including private AS numbers. You can configure the software so that it removes private AS numbers from AS paths. Doing this is useful when any of the following circumstances are true: •

A remote AS for which you provide connectivity is multihomed, but only to the local AS.

•

The remote AS does not have an officially allocated AS number.

•

It is not appropriate to make the remote AS a confederation member AS of the local AS.

Most companies acquire their own AS number. Some companies also use private AS numbers to connect to their public AS network. These companies might use a different private AS number for each region in which their company does business. In any implementation, announcing a private AS number to the Internet must be avoided. Service providers can use the remove-private statement to prevent advertising private AS numbers to the Internet. In an enterprise scenario, suppose that you have multiple AS numbers in your company, some of which are private AS numbers, and one with a public AS number. The one with a public AS number has a direct connection to the service provider. In the AS that connects directly to the service provider, you can use the remove-private statement to filter out any private AS numbers in the advertisements that are sent to the service provider.

CAUTION: Changing configuration statements that affect BGP peers, such as enabling or disabling remove-private or renaming a BGP group, resets the BGP sessions. Changes that affect BGP peers should only be made when resetting a BGP session is acceptable.

The AS numbers are stripped from the AS path starting at the left end of the AS path (the end where AS paths have been most recently added). The routing device stops searching for private ASs when it finds the first nonprivate AS or a peer’s private AS. If the AS path contains the AS number of the external BGP (EBGP) neighbor, BGP does not remove the private AS number.

NOTE: As of Junos OS 10.0R2 and later, if there is a need to send prefixes to an EBGP peer that has an AS number that matches an AS number in the AS path, consider using the as-override statement instead of the remove-private statement.

1180



The operation takes place after any confederation member ASs have already been removed from the AS path, if applicable. The software is preconfigured with knowledge of the set of AS numbers that is considered private, a range that is defined in the Internet Assigned Numbers Authority (IANA) assigned numbers document. The set of AS numbers reserved as private are in the range from 64,512 through 65,534, inclusive.

Example: Removing Private AS Numbers from AS Paths This example demonstrates the removal of a private AS number from the advertised AS path to avoid announcing the private AS number to the Internet. •


•


•


•



Overview Service providers and enterprise networks use the remove-private statement to prevent advertising private AS numbers to the Internet. The remove-private statement works in the outbound direction. You configure the remove-private statement on a device that has a public AS number and that is connected to one or more devices that have private AS numbers. Generally, you would not configure this statement on a device that has a private AS number. Figure 67 on page 1181 shows the sample topology.

R1

ISP

R2

AS 65535

AS 100

AS 200

g041165

Figure 67: Topology for Removing a Private AS from the Advertised AS Path

In this example, Device R1 is connected to its service provider using private AS number 65535. The example shows the remove-private statement configured on Device ISP to prevent Device R1’s private AS number from being announced to Device R2. Device R2 sees only the AS number of the service provider.


1181




Device R1


Device ISP

set interfaces fe-1/2/0 unit 2 family inet address 192.168.10.10/24 set interfaces fe-1/2/1 unit 3 family inet address 192.168.20.20/24 set interfaces lo0 unit 2 family inet address 10.10.0.1/32 set protocols bgp group ext type external set protocols bgp group ext neighbor 192.168.10.1 peer-as 65535 set protocols bgp group ext neighbor 192.168.20.1 remove-private set protocols bgp group ext neighbor 192.168.20.1 peer-as 200 set routing-options autonomous-system 100

Device R2


Device ISP Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Device ISP: 1.

Configure the interfaces. [edit interfaces]

1182



user@ISP# set fe-1/2/0 unit 2 family inet address 192.168.10.10/24 user@ISP# set fe-1/2/1 unit 3 family inet address 192.168.20.20/24 user@ISP# set lo0 unit 2 family inet address 10.10.0.1/32 2.

Configure EBGP. [edit protocols bgp group ext] user@ISP# set type external user@ISP# set neighbor 192.168.10.1 peer-as 65535 user@ISP# set neighbor 192.168.20.1 peer-as 200

3.

For the neighbor in autonomous system (AS) 200 (Device R2), remove private AS numbers from the advertised AS paths. [edit protocols bgp group ext] user@ISP# set neighbor 192.168.20.1 remove-private

4.

Configure the AS number. [edit routing-options] user@ISP# set autonomous-system 100

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@ISP# show interfaces fe-1/2/0 { unit 2 { family inet { address 192.168.10.10/24; } } } fe-1/2/1 { unit 3 { family inet { address 192.168.20.20/24; } } } lo0 { unit 2 { family inet { address 10.10.0.1/32; } } } user@ISP# show protocols bgp { group ext { type external; neighbor 192.168.10.1 { peer-as 65535; } neighbor 192.168.20.1 { remove-private;


1183


peer-as 200; } } } user@ISP# show routing-options autonomous-system 100;

If you are done configuring the device, enter commit from configuration mode. Repeat the configuration on Device R1 and Device R2, changing the interface names and IP address, as needed, and adding the routing policy configuration.


Checking the Neighbor Status on page 1184

•

Checking the Routing Tables on page 1185

•

Checking the AS Path When the remove-private Statement Is Deactivated on page 1185

Checking the Neighbor Status Purpose

Action

Make sure that Device ISP has the remove-private setting enabled in its neighbor session with Device R2. From operational mode, enter the show bgp neighbor 192.168.20.1 command. user@ISP> show bgp neighbor 192.168.20.1 Peer: 192.168.20.1+179 AS 200 Local: 192.168.20.20+60216 AS 100 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.20.1 Local ID: 10.10.0.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down Local Interface: fe-1/2/1.3 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 200) Peer does not support Addpath Table inet.0 Bit: 10001 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 3 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 1

1184



Last traffic (seconds): Received 10 Sent 16 Checked 55 Input messages: Total 54 Updates 3 Refreshes 0 Output messages: Total 54 Updates 1 Refreshes 0 Output Queue[0]: 0

Meaning


The RemovePrivateAS option shows that Device ISP has the expected setting. Checking the Routing Tables

Purpose Action

Make sure that the devices have the expected routes and AS paths. From operational mode, enter the show route protocol bgp command. user@R1> show route protocol bgp inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.20.1/32

*[BGP/170] 00:28:57, localpref 100 AS path: 100 200 I > to 192.168.10.10 via fe-1/2/0.1

user@ISP> show route protocol bgp inet.0: 7 destinations, 11 routes (7 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.1/32

10.10.20.1/32

192.168.10.0/24

192.168.20.0/24

*[BGP/170] 00:29:40, localpref 100 AS path: 65535 I > to 192.168.10.1 via fe-1/2/0.2 *[BGP/170] 00:29:36, localpref 100 AS path: 200 I > to 192.168.20.1 via fe-1/2/1.3 [BGP/170] 00:29:40, localpref 100 AS path: 65535 I > to 192.168.10.1 via fe-1/2/0.2 [BGP/170] 00:29:36, localpref 100 AS path: 200 I > to 192.168.20.1 via fe-1/2/1.3

user@R2> show route protocol bgp inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.1/32

Meaning

*[BGP/170] 00:29:53, localpref 100 AS path: 100 I > to 192.168.20.20 via fe-1/2/0.4

Device ISP has the private AS number 65535 in its AS path to Device R1. However, Device ISP does not advertise this private AS number to Device R2. This is shown in the routing table of Device R2. Device R2’s path to Device R1 contains only the AS number for Device ISP. Checking the AS Path When the remove-private Statement Is Deactivated

Purpose

Verify that without the remove-private statement, the private AS number appears in Device R2’s routing table.


1185


Action

From configuration mode on Device ISP, enter the deactivate remove-private command and then recheck the routing table on Device R2. [protocols bgp group ext neighbor 192.168.20.1] user@ISP# deactivate remove-private user@ISP# commit user@R2> show route protocol bgp inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.1/32

Meaning


*[BGP/170] 00:00:54, localpref 100 AS path: 100 65535 I > to 192.168.20.20 via fe-1/2/0.4

Private AS number 65535 appears in Device R2’s AS path to Device R1.

•


•


Example: Configuring BGP Flap Damping •

Understanding Damping Parameters on page 1186

•

Example: Configuring Damping Parameters on page 1187

Understanding Damping Parameters BGP route flapping describes the situation in which BGP systems send an excessive number of update messages to advertise network reachability information. BGP flap damping is a method of reducing the number of update messages sent between BGP peers, thereby reducing the load on these peers, without adversely affecting the route convergence time for stable routes. Flap damping reduces the number of update messages by marking routes as ineligible for selection as the active or preferable route. Marking routes in this way leads to some delay, or suppression, in the propagation of route information, but the result is increased network stability. You typically apply flap damping to external BGP (EBGP) routes (routes in different ASs). You can also apply flap damping within a confederation, between confederation member ASs. Because routing consistency within an AS is important, do not apply flap damping to internal BGP (IBGP) routes. (If you do, it is ignored.) By default, route flap damping is not enabled. Damping is applied to external peers and to peers at confederation boundaries. When you enable damping, default parameters are applied, as summarized in Table 14 on page 1187.

1186



Table 14: Damping Parameters Damping Parameter

Description

Default Value

Possible Values

half-life minutes

Decay half-life—Number of minutes after which an arbitrary value is halved if a route stays stable.

15 (minutes)

1 through 4

max-suppress minutes

Maximum hold-down time for a route, in minutes.

60 (minutes)

1 through 720

reuse

Reuse threshold—Arbitrary value below which a suppressed route can be used again.

750

1 through 20,000

suppress

Cutoff (suppression) threshold—Arbitrary value above which a route can no longer be used or included in advertisements.

3000

1 through 20,000

To change the default BGP flap damping values, you define actions by creating a named set of damping parameters and including it in a routing policy with the damping action. For the damping routing policy to work, you also must enable BGP route flap damping.

Example: Configuring Damping Parameters This example shows how to configure damping parameters. •


•


•


•


Requirements Before you begin, configure router interfaces and configure routing protocols, as explained in Routing Policies Configuration Overview.

Overview In this example, you configure a routing policy called policy1 and a corresponding routing term called term1. Within the term, you configure the route filter to include source routes greater than or equal to 10.210.0.0/16 and destination routes greater than or equal to 10.215.0.0/16. Then you group the source and destination prefixes into a forwarding class called forwarding-class1 and apply policy1 to the forwarding table. The routing policy is evaluated when routes are being exported from the routing table into the forwarding table. Only the active routes are exported from the routing table.


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set policy-options policy-statement dampenpolicy1 term dampenterm1 from route-filter 172.16.0.0/12 orlonger damping group1


1187


set policy-options policy-statement dampenpolicy1 term dampenterm1 from route-filter 192.168.0.0/16 orlonger set policy-options policy-statement dampenpolicy1 term dampenterm1 from route-filter 10.0.0.0/8 orlonger set policy-options policy-statement test term 1 from protocol direct set policy-options damping group1 half-life 30 set policy-options damping group1 reuse 750 set policy-options damping group1 suppress 3000 set policy-options damping group1 max-suppress 60 set policy-options damping group2 half-life 40 set policy-options damping group2 reuse 1000 set policy-options damping group2 suppress 400 set policy-options damping group2 max-suppress 45 set policy-options damping group3 disable set protocols bgp damping set protocols bgp group groupA neighbor 172.16.15.14 import dampenpolicy1


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure damping parameters: 1.

Specify the routes to dampen and associate each group of routes with a group name. [edit policy-options policy-statement dampenpolicy1 term dampenterm1] user@host# set from route-filter 172.16.0.0/12 orlonger damping group1 user@host# set from route-filter 192.168.0.0/16 orlonger user@host# set from route-filter 10.0.0.0/8 orlonger

2.

Create and configure the damping parameter groups. [edit policy-options damping] user@host# set group1 half-life 30 max-suppress 60 reuse 750 suppress 3000 user@host# set group2 half-life 40 max-suppress 45 reuse 1000 suppress 400 user@host# set group3 disable

3.

Enable damping for BGP. [edit] user@host# set protocols bgp damping

4.

Apply the policy as an import policy for the BGP neighbor. [edit ] user@host# set protocols bgp group groupA neighbor 172.16.15.14 import dampenpolicy1

NOTE: You can refer to the same routing policy one or more times in the same or different import statement.

1188



Results

Confirm your configuration by entering the show policy-options and show protocols bgp commands from configuration mode. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it. user@host# show policy-options policy-statement dampenpolicy1 { term dampenterm1 { from { route-filter 172.16.0.0/12 orlonger damping group1; route-filter 192.168.0.0/16 orlonger; route-filter 10.0.0.0/8 orlonger; } } } damping group1 { half-life 30; reuse 750; suppress 3000; max-suppress 60; } damping group2 { half-life 40; reuse 1000; suppress 400; max-suppress 45; } damping group3 { disable; } user@host# show protocols bgp damping; group groupA { neighbor 172.16.15.14 { import dampenpolicy1; } }



Verifying the Damping Parameters on page 1189

•

Verifying the Routing Policy on page 1190

Verifying the Damping Parameters Purpose

Action

Verify that the policy and term are configured on the device and that the appropriate damping parameters are specified within the term. From operational mode, enter the show policy-options command.


1189


Verifying the Routing Policy Purpose

Action


Verify that damping is enabled for BGP and that the routing policy is applied to the routing protocol. From operational mode, enter the show protocols bgp command.

•


•


Examples: Configuring Multiprotocol BGP •


•

Example: Configuring IPv6 BGP Routes over IPv4 Transport on page 1196

•


•

Enabling Layer 2 VPN and VPLS Signaling on page 1215

Understanding Multiprotocol BGP Multiprotocol BGP (MP-BGP) is an extension to BGP that enables BGP to carry routing information for multiple network layers and address families. MP-BGP can carry the unicast routes used for multicast routing separately from the routes used for unicast IP forwarding. To enable MP-BGP, you configure BGP to carry network layer reachability information (NLRI) for address families other than unicast IPv4 by including the family inet statement: family inet { (any | flow | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown ; } ; prefix-limit { maximum number; teardown ; } rib-group group-name; } }

To enable MP-BGP to carry NLRI for the IPv6 address family, include the family inet6 statement: family inet6 { (any | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown ;

1190



} ; prefix-limit { maximum number; teardown ; } rib-group group-name; } }

On routers only, to enable MP-BGP to carry Layer 3 virtual private network (VPN) NLRI for the IPv4 address family, include the family inet-vpn statement: family inet-vpn { (any | flow | multicast | unicast) { accepted-prefix-limit { maximum number; teardown ; } ; prefix-limit { maximum number; teardown ; } rib-group group-name; } }

On routers only, to enable MP-BGP to carry Layer 3 VPN NLRI for the IPv6 address family, include the family inet6-vpn statement: family inet6-vpn { (any | multicast | unicast) { accepted-prefix-limit { maximum number; teardown ; } ; prefix-limit { maximum number; teardown ; } rib-group group-name; } }

On routers only, to enable MP-BGP to carry multicast VPN NLRI for the IPv4 address family and to enable VPN signaling, include the family inet-mvpn statement: family inet-mvpn { signaling { accepted-prefix-limit { maximum number; teardown ; } ; prefix-limit {


1191


maximum number; teardown ; } } }

To enable MP-BGP to carry multicast VPN NLRI for the IPv6 address family and to enable VPN signaling, include the family inet6-mvpn statement: family inet6-mvpn { signaling { accepted-prefix-limit { maximum number; teardown ; } ; prefix-limit { maximum number; teardown show bgp neighbor Peer: 192.168.10.1+179 AS 100 Local: 192.168.10.10+54226 AS 200 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct send-static ] Options: Address families configured: inet-unicast inet6-unicast Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.10.1 Local ID: 10.10.0.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down Local Interface: fe-1/2/0.2 NLRI for restart configured on peer: inet-unicast inet6-unicast NLRI advertised by peer: inet-unicast inet6-unicast NLRI for this session: inet-unicast inet6-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast inet6-unicast NLRI of received end-of-rib markers: inet-unicast inet6-unicast NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast Peer supports 4 byte AS extension (peer-as 100) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 3 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 4

1200



Table inet6.0 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 1 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 24 Sent 12 Checked 60 Input messages: Total 132 Updates 6 Refreshes 0 Output messages: Total 133 Updates 3 Refreshes 0 Output Queue[0]: 0 Output Queue[1]: 0


Peer: 192.168.20.1+179 AS 300 Local: 192.168.20.21+54706 AS 200 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct send-static ] Options: Address families configured: inet-unicast inet6-unicast Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.20.1 Local ID: 10.10.0.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down Local Interface: fe-1/2/1.3 NLRI for restart configured on peer: inet-unicast inet6-unicast NLRI advertised by peer: inet-unicast inet6-unicast NLRI for this session: inet-unicast inet6-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast inet6-unicast NLRI of received end-of-rib markers: inet-unicast inet6-unicast NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast Peer supports 4 byte AS extension (peer-as 300) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 3 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 4 Table inet6.0 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 1 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 1 Sent 15 Checked 75 Input messages: Total 133 Updates 6 Refreshes 0 Octets 2719 Output messages: Total 131 Updates 3 Refreshes 0 Octets 2734 Output Queue[0]: 0 Output Queue[1]: 0


1201


Meaning

The various occurrences of inet6-unicast in the output shows that BGP is enabled to carry IPv6 unicast routes. Checking the Routing Table

Purpose Action

Make sure that Device R2 has BGP routes in its inet6.0 routing table. From operational mode, enter the show route protocol bgp inet6.0 command. user@R2> show route protocol bgp table inet6.0 inet6.0: 7 destinations, 10 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both ::192.168.10.0/120

::192.168.20.0/120

[BGP/170] 01:03:49, localpref 100, from 192.168.20.1 AS path: 300 I > to ::192.168.20.21 via fe-1/2/1.3 [BGP/170] 01:03:53, localpref 100, from 192.168.10.1 AS path: 100 I > to ::192.168.10.10 via fe-1/2/0.2

Example: Enabling BGP to Carry Flow-Specification Routes This example shows how to allow BGP to carry flow-specification network layer reachability information (NLRI) messages. •


•


•


•




•


•

Configure BGP.

•

Configure a routing policy that exports routes (such as direct routes or IGP routes) from the routing table into BGP.

Overview Propagating firewall filter information as part of BGP enables you to propagate firewall filters against denial-of-service (DOS) attacks dynamically across autonomous systems. Flow routes are encapsulated into the flow-specification NLRI and propagated through a network or virtual private networks (VPNs), sharing filter-like information. Flow routes are an aggregation of match conditions and resulting actions for packets. They provide you with traffic filtering and rate-limiting capabilities much like firewall filters. Unicast flow routes are supported for the default instance, VPN routing and forwarding (VRF) instances, and virtual-router instances.

1202



The flow route filters are first configured on a router statically, with a set of matching criteria followed by the actions to be taken. Then, in addition to family inet unicast, family inet flow (or family inet-vpn flow) is configured between this BGP-enabled device and its peers. By default, statically configured flow routes (firewall filters) are advertised to other BGP-enabled devices that support the family inet flow or family inet-vpn flow NLRI. The receiving BGP-enabled device performs a validation process before installing the firewall filter into the flow routing table instance-name.inetflow.0. The validation procedure is described in Internet draft draft-ietf-idr-flow-spec-09.txt, Dissemination of Flow Specification Rules. The receiving BGP-enabled device accepts a flow route if it passes the following criteria: •

The originator of a flow route matches the originator of the best match unicast route for the destination address that is embedded in the route.

•

There are no more specific unicast routes, when compared to the destination address of the flow route, for which the active route has been received from a different next-hop autonomous system.

The first criterion ensures that the filter is being advertised by the next-hop used by unicast forwarding for the destination address embedded in the flow route. For example, if a flow route is given as 10.1.1.1, proto=6, port=80, the receiving BGP-enabled device selects the more specific unicast route in the unicast routing table that matches the destination prefix 10.1.1.1/32. On a unicast routing table containing 10.1/16 and 10.1.1/24, the latter is chosen as the unicast route to compare against. Only the active unicast route entry is considered. This follows the concept that a flow route is valid if advertised by the originator of the best unicast route. The second criterion addresses situations in which a given address block is allocated to different entities. Flows that resolve to a best-match unicast route that is an aggregate route are only accepted if they do not cover more specific routes that are being routed to different next-hop autonomous systems. You can bypass the validation process and use your own specific import policy. To disable the validation procedure and use an import policy instead, include the no-validate statement at the [edit protocols bgp group group-name family inet flow] hierarchy level. After a flow route is installed in the inetflow.0 table, it is also added to the list of firewall filters in the kernel. On routers only, flow-specification NLRI messages are supported in VPNs. The VPN compares the route target extended community in the NLRI to the import policy. If there is a match, the VPN can start using the flow routes to filter and rate-limit packet traffic. Received flow routes are installed into the flow routing table instance-name.inetflow.0. Flow routes can also be propagated throughout a VPN network and shared among VPNs. To enable multiprotocol BGP (MP-BGP) to carry flow-specification NLRI for the inet-vpn address family, include the flow statement at the [edit protocols bgp group group-name family inet-vpn] hierarchy level. VPN flow routes are supported for the default instance only. Flow routes configured for VPNs with family inet-vpn are not automatically validated,


1203


so the no-validate statement is not supported at the [edit protocols bgp group group-name family inet-vpn] hierarchy level. No validation is needed if the flow routes are configured locally between devices in a single AS. Import and export policies can be applied to the family inet flow or family inet-vpn flow NLRI, affecting the flow routes accepted or advertised, similar to the way import and export policies are applied to other BGP families. The only difference is that the flow policy configuration must include the from rib inetflow.0 statement. This statement causes the policy to be applied to the flow routes. An exception to this rule occurs if the policy has only the then reject or the then accept statement and no from statement. Then, the policy affects all routes, including IP unicast and IP flow. This example shows how to configure the following export policies: •

A policy that allows the advertisement of flow routes specified by a route-filter. Only the flow routes covered by the 10.13/16 block are advertised. This policy does not affect unicast routes.

•

A policy that allows all unicast and flow routes to be advertised to the neighbor.

•

A policy that disallows all routes (unicast or flow) to be advertised to the neighbor.

Configuration •

Configuring a Static Flow Route on page 1204

•

Advertising Flow Routes Specified by a Route Filter on page 1205

•

Advertising All Unicast and Flow Routes on page 1207

•

Advertising No Unicast or Flow Routes on page 1208

•

Limiting the Number of Flow Routes Installed in a Routing Table on page 1210

•

Limiting the Number of Prefixes Received on a BGP Peering Session on page 1210

Configuring a Static Flow Route CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set routing-options flow route block-10.131.1.1 match destination 10.131.1.1/32 set routing-options flow route block-10.131.1.1 match protocol icmp set routing-options flow route block-10.131.1.1 match icmp-type echo-request set routing-options flow route block-10.131.1.1 then discard set routing-options flow term-order standard



1204

Configure the match conditions.



[edit routing-options flow route block-10.131.1.1] user@host# set match destination 10.131.1.1/32 user@host# set match protocol icmp user@host# set match icmp-type echo-request 2.

Configure the action. [edit routing-options flow route block-10.131.1.1] user@host# set then discard

3.

(Recommended) For the flow specification algorithm, configure the standard-based term order. [edit routing-options flow] user@host# set term-order standard

In the default term ordering algorithm, as specified in the flowspec RFC draft Version 6, a term with less specific matching conditions is always evaluated before a term with more specific matching conditions. This causes the term with more specific matching conditions to never be evaluated. Version 7 of RFC 5575 made a revision to the algorithm so that the more specific matching conditions are evaluated before the less specific matching conditions. For backward compatibility, the default behavior is not altered in Junos OS, even though the newer algorithm makes more sense. To use the newer algorithm, include the term-order standard statement in the configuration. This statement is supported in Junos OS Release 10.0 and later. Results

From configuration mode, confirm your configuration by entering the show routing-options command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. [edit] user@host# show routing-options flow { term-order standard; route block-10.131.1.1 { match { destination 10.131.1.1/32; protocol icmp; icmp-type echo-request; } then discard; } }

If you are done configuring the device, enter commit from configuration mode. Advertising Flow Routes Specified by a Route Filter CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set protocols bgp group core family inet unicast set protocols bgp group core family inet flow


1205


set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a from rib inetflow.0 set policy-options policy-statement p1 term a from route-filter 10.13.0.0/16 orlonger set policy-options policy-statement p1 term a then accept set policy-options policy-statement p1 term b then reject set routing-options autonomous-system 65001



Configure the BGP group. [edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5

2.

Configure the flow policy. [edit policy-options policy-statement p1] user@host# set term a from rib inetflow.0 user@host# set term a from route-filter 10.13.0.0/16 orlonger user@host# set term a then accept user@host# set term b then reject

3.

Configure the local autonomous system (AS) number. [edit routing-options] user@host# set autonomous-system 65001

Results

From configuration mode, confirm your configuration by entering the show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. [edit] user@host# show protocols bgp { group core { family inet { unicast; flow; } export p1; peer-as 65000; neighbor 10.12.99.5; } } [edit]

1206



user@host# show policy-options policy-statement p1 { term a { from { rib inetflow.0; route-filter 10.13.0.0/16 orlonger; } then accept; } term b { then reject; } } [edit] user@host# show routing-options autonomous-system 65001;

If you are done configuring the device, enter commit from configuration mode. Advertising All Unicast and Flow Routes CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a then accept set routing-options autonomous-system 65001




2.

Configure the flow policy. [edit policy-options policy-statement p1] user@host# set term a then accept

3.

Configure the local autonomous system (AS) number. [edit routing-options]


1207


user@host# set autonomous-system 65001

Results

From configuration mode, confirm your configuration by entering the show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. [edit] user@host# show protocols bgp { group core { family inet { unicast; flow; } export p1; peer-as 65000; neighbor 10.12.99.5; } } [edit] user@host# show policy-options policy-statement p1 { term a { then accept; } } [edit] user@host# show routing-options autonomous-system 65001;

If you are done configuring the device, enter commit from configuration mode. Advertising No Unicast or Flow Routes CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a then reject set routing-options autonomous-system 65001

1208






2.

Configure the flow policy. [edit policy-options policy-statement p1] user@host# set term a then reject

3.

Configure the local autonomous system (AS) number. [edit routing-options] user@host# set autonomous-system 65001

Results

From configuration mode, confirm your configuration by entering the show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. [edit] user@host# show protocols bgp { group core { family inet { unicast; flow; } export p1; peer-as 65000; neighbor 10.12.99.5; } } [edit] user@host# show policy-options policy-statement p1 { term a { then reject; } } [edit] user@host# show routing-options autonomous-system 65001;



1209


Limiting the Number of Flow Routes Installed in a Routing Table CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set routing-options rib inetflow.0 maximum-prefixes 1000 set routing-options rib inetflow.0 maximum-prefixes threshold 50


The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

NOTE: Application of a route limit might result in unpredictable dynamic route protocol behavior. For example, once the limit is reached and routes are being rejected, BGP does not necessarily attempt to reinstall the rejected routes after the number of routes drops below the limit. BGP sessions might need to be cleared to resolve this issue.

To limit the flow routes: 1.

Set an upper limit for the number of prefixes installed in inetflow.0 table. [edit routing-options rib inetflow.0] user@host# set maximum-prefixes 1000

2.

Set a threshold value of 50 percent, where when 500 routes are installed, a warning is logged in the system log. [edit routing-options rib inetflow.0] user@host# set maximum-prefixes threshold 50

Results

From configuration mode, confirm your configuration by entering the show routing-options command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. [edit] user@host# show routing-options rib inetflow.0 { maximum-prefixes 1000 threshold 50; }

If you are done configuring the device, enter commit from configuration mode. Limiting the Number of Prefixes Received on a BGP Peering Session CLI Quick Configuration

1210




set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit maximum 1000 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit teardown 50


The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. Configuring a prefix limit for a specific neighbor provides more predictable control over which peer can advertise how many flow routes. To limit the number of prefixes: 1.

Set a limit of 1000 BGP routes from neighbor 10.12.99.2. [edit protocols bgp group x1] user@host# set neighbor 10.12.99.2 family inet flow prefix-limit maximum 1000

2.

Configure the neighbor session to be brought down when the maximum number of prefixes is reached. [edit routing-options rib inetflow.0] user@host# set neighbor 10.12.99.2 family inet flow prefix-limit teardown 50

If you specify a percentage, as shown here, messages are logged when the number of prefixes reaches that percentage. After the session is brought down, the session reestablishes in a short time unless you include the idle-timeout statement. Results

From configuration mode, confirm your configuration by entering the show protocols command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. [edit] user@host# show protocols bgp { group x1 { neighbor 10.12.99.2 { flow { prefix-limit { maximum 1000; teardown 50; } } } } } }



1211



Verifying the NLRI on page 1212

•

Verifying Routes on page 1213

•

Verifying Flow Validation on page 1214

•

Verifying Firewall Filters on page 1214

•

Verifying System Logging When Exceeding the Number of Allowed Flow Routes on page 1215

•

Verifying System Logging When Exceeding the Number of Prefixes Received on a BGP Peering Session on page 1215

Verifying the NLRI Purpose Action

Look at the NLRI enabled for the neighbor. From operational mode, run the show bgp neighbor 10.12.99.5 command. Look for inet-flow in the output. user@host> show bgp neighbor 10.12.99.5 Peer: 10.12.99.5+3792 AS 65000 Local: 10.12.99.6+179 AS 65002 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ direct ] Options: Address families configured: inet-unicast inet-multicast inet-flow Holdtime: 90 Preference: 170 Number of flaps: 1 Error: 'Cease' Sent: 0 Recv: 1 Peer ID: 10.255.71.161 Local ID: 10.255.124.107 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 Local Interface: e1-3/0/0.0 NLRI advertised by peer: inet-unicast inet-multicast inet-flow NLRI for this session: inet-unicast inet-multicast inet-flow Peer supports Refresh capability (2) Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 2 Received prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 3 Table inet.2 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Table inetflow.0 Bit: 30000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0

1212



Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 29 Sent 15 Checked 15 Input messages: Total 5549 Updates 2618 Refreshes 0 Octets 416486 Output messages: Total 2943 Updates 1 Refreshes 0 Octets 55995 Output Queue[0]: 0 Output Queue[1]: 0 Output Queue[2]: 0

Verifying Routes Purpose

Look at the flow routes. The sample output shows a flow route learned from BGP and a statically configured flow route. For locally configured flow routes (configured at the [edit routing-options flow] hierarchy level), the routes are installed by the flow protocol. Therefore, you can display the flow routes by specifying the table, as in show route table inetflow.0 or show route table instance-name.inetflow.0, where instance-name is the routing instance name. Or, you can display all locally configured flow routes across multiple routing instances by running the show route protocol flow command. If a flow route is not locally configured, but received from the router’s BGP peer, this flow route is installed in the routing table by BGP. You can display the flow routes by specifying the table or by running show route protocol bgp, which displays all BGP routes (flow and non-flow).

Action

From operational mode, run the show route table inetflow.0 command. user@host> show route table inetflow.0 inetflow.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.12.44.1,*/term:1 *[Flow/5] 00:04:22 Fictitious *,10.12.44.1/term:2 *[Flow/5] 00:09:34 Fictitious

user@host> show route table inetflow.0 extensive inetflow.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) 7.7.7.7,8.8.8.8/term:1 (1 entry, 1 announced) TSI: KRT in dfwd; Action(s): accept,count *Flow Preference: 5 Next hop type: Fictitious Address: 0x8d383a4 Next-hop reference count: 3 State: Local AS: 65000 Age: 9:50 Task: RT Flow Announcement bits (1): 0-Flow AS path: I


1213


Meaning

A flow route represents a term of a firewall filter. When you configure a flow route, you specify the match conditions and the actions. In the match attributes, you can match a source address, a destination address, and other qualifiers such as the port and the protocol. For a single flow route that contains multiple match conditions, all the match conditions are encapsulated in the prefix field of the route. When you issue the show route command on a flow route, the prefix field of the route is displayed with all of the match conditions. 10.12.44.1,* means that the matching condition is match destination 10.12.44.1/32. If the prefix in the output were *,10.12.44.1, this would mean that the match condition was match source 10.12.44.1/32. If the matching conditions contain both a source and a destination, the asterisk is replaced with the address. The term-order numbers indicate the sequence of the terms (flow routes) being evaluated in the firewall filter. The show route extensive command displays the actions for each term (route). Verifying Flow Validation

Purpose Action

Display flow route information. From operational mode, run the show route flow validation detail command. user@host> show route flow validation detail inet.0: 0.0.0.0/0 Internal node: best match, inconsistent 10.0.0.0/8 Internal node: no match, inconsistent 10.12.42.0/24 Internal node: no match, consistent, next-as: 65003 Active unicast route Dependent flow destinations: 1 Origin: 10.255.124.106, Neighbor AS: 65003 10.12.42.1/32 Flow destination (1 entries, 1 match origin) Unicast best match: 10.12.42.0/24 Flags: Consistent 10.131.0.0/16 Internal node: no match, consistent, next-as: 65001 Active unicast route Dependent flow destinations: 5000 Origin: 10.12.99.2, Neighbor AS: 65001 10.131.0.0/19 Internal node: best match 10.131.0.0/20 Internal node: best match 10.131.0.0/21

Verifying Firewall Filters Purpose Action

1214

Display the firewall filters that are installed in the kernel. From operational mode, run the show firewall command.



user@host> show firewall Filter: __default_bpdu_filter__ Filter: __dynamic_default_inet__ Counters: Name 10.12.42.1,* 196.1.28/23,* 196.1.30/24,* 196.1.31/24,* 196.1.32/24,* 196.1.56/21,* 196.1.68/24,* 196.1.69/24,* 196.1.70/24,* 196.1.75/24,* 196.1.76/24,*

Bytes 0 0 0 0 0 0 0 0 0 0 0

Packets 0 0 0 0 0 0 0 0 0 0 0

Verifying System Logging When Exceeding the Number of Allowed Flow Routes Purpose

Action

If you configure a limit on the number of flow routes installed, as described in “Limiting the Number of Flow Routes Installed in a Routing Table” on page 1210, view the system log message when the threshold is reached. From operational mode, run the show log command. user@host> show log flow-routes-log-file Jul 12 08:19:01 host rpd[2748]: RPD_RT_MAXROUTES_WARN: Number of routes (1000) in table inetflow.0 exceeded warning threshold (50 percent of configured maximum 1000)

Verifying System Logging When Exceeding the Number of Prefixes Received on a BGP Peering Session Purpose

Action

If you configure a limit on the number of flow routes installed, as described in “Limiting the Number of Prefixes Received on a BGP Peering Session” on page 1210, view the system log message when the threshold is reached. From operational mode, run the show log command. user@host> show log flow-routes-log-file Jul 12 08:44:47 host rpd[2748]: 10.12.99.2 (External AS 65001): Shutting down peer due to exceeding configured maximum prefix-limit(1000) for inet-flow nlri: 1001

Enabling Layer 2 VPN and VPLS Signaling You can enable BGP to carry Layer 2 VPN and VPLS NLRI messages. To enable VPN and VPLS signaling, include the family statement: family { l2vpn { signaling { prefix-limit { maximum number; teardown ;


1215


} } } }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. To configure a maximum number of prefixes, include the prefix-limit statement: prefix-limit { maximum number; teardown ; }

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. When you set the maximum number of prefixes, a message is logged when that number is reached. If you include the teardown statement, the session is torn down when the maximum number of prefixes is reached. If you specify a percentage, messages are logged when the number of prefixes reaches that percentage. Once the session is torn down, it is reestablished in a short time. Include the idle-timeout statement to keep the session down for a specified amount of time, or forever. If you specify forever, the session is reestablished only after you use the clear bgp neighbor command. Related Documentation

•


•


Example: Configuring BGP and CLNS •

Understanding BGP for CLNS VPNs on page 1216

•

Example: Configuring BGP for CLNS VPNs on page 1217

•

Enabling BGP to Carry CLNS Routes on page 1218

Understanding BGP for CLNS VPNs BGP extensions allow BGP to carry Connectionless Network Service (CLNS) virtual private network (VPN) network layer reachability information (NLRI) between provider edge (PE) routers. Each CLNS route is encapsulated into a CLNS VPN NLRI and propagated between remote sites in a VPN. CLNS is a Layer 3 protocol similar to IP version 4 (IPv4). CLNS uses network service access points (NSAPs) to address end systems. This allows for a seamless autonomous system (AS) based on International Organization for Standardization (ISO) NSAPs.

NOTE: CLNS is supported for the J Series Services Router only.

A single routing domain consisting of ISO NSAP devices are considered to be CLNS islands. CLNS islands are connected together by VPNs.

1216



You can configure BGP to exchange ISO CLNS routes between PE routers connecting various CLNS islands in a VPN using multiprotocol BGP extensions. These extensions are the ISO VPN NLRIs. Each CLNS network island is treated as a separate VPN routing and forwarding instance (VRF) instance on the PE router. You can configure CLNS on the global level, group level, and neighbor level.

Example: Configuring BGP for CLNS VPNs This example shows how to create a BGP group for CLNS VPNs, define the BGP peer neighbor address for the group, and define the family. •


•


•


•


Requirements Before you begin, configure the network interfaces. See the Junos OS Interfaces Configuration Guide for Security Devices.

Overview In this example, you create the BGP group called pedge-pedge, define the BGP peer neighbor address for the group as 10.255.245.215, and define the BGP family.


To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set protocols bgp group pedge-pedge neighbor 10.255.245.213 set protocols bgp family iso-vpn unicast


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure BGP for CLNS VPNs: 1.

Configure the BGP group and define the BGP peer neighbor address. [edit protocols bgp] user@host# set group pedge-pedge neighbor 10.255.245.213

2.

Define the family. [edit protocols bgp] user@host# set family iso-vpn unicast


1217


3.


Verification Confirm that the configuration is working properly. Verifying the Neighbor Status Purpose Action

Display information about the BGP peer. From operational mode, run the show bgp neighbor 10.255.245.213 command. Look for iso-vpn-unicast in the output. user@host> show bgp neighbor 10.255.245.213 Peer: 10.255.245.213+179 AS 200 Local: 10.255.245.214+3770 AS 100 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: Address families configured: iso-vpn-unicast Local Address: 10.255.245.214 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.255.245.213 Local ID: 10.255.245.214 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 NLRI advertised by peer: iso-vpn-unicast NLRI for this session: iso-vpn-unicast Peer supports Refresh capability (2) Table bgp.isovpn.0 Bit: 10000 RIB State: BGP restart is complete RIB State: VPN restart is complete Send state: in sync Active prefixes: 3 Received prefixes: 3 Suppressed due to damping: 0 Advertised prefixes: 3 Table aaaa.iso.0 RIB State: BGP restart is complete RIB State: VPN restart is complete Send state: not advertising Active prefixes: 3 Received prefixes: 3 Suppressed due to damping: 0 Last traffic (seconds): Received 6 Sent 5 Checked 5 Input messages: Total 1736 Updates 4 Refreshes 0 Octets 33385 Output messages: Total 1738 Updates 3 Refreshes 0 Octets 33305 Output Queue[0]: 0 Output Queue[1]: 0

Enabling BGP to Carry CLNS Routes Connectionless Network Service (CLNS) is a Layer 3 protocol similar to IP version 4 (IPv4). CLNS uses network service access points (NSAPs) to address end systems. This allows for a seamless autonomous system (AS) based on International Organization for Standardization (ISO) NSAPs.

1218




A single routing domain consisting of ISO NSAP devices are considered to be CLNS islands. CLNS islands are connected together by VPNs. You can configure BGP to exchange ISO CLNS routes between provider edge (PE) routers connecting various CLNS islands in a virtual private network (VPN) using multiprotocol BGP extensions. These extensions are the ISO VPN NLRIs. To enable multiprotocol BGP (MP-BGP) to carry CLNS VPN NLRIs, include the iso-vpn statement: iso-vpn { unicast { prefix-limit number; rib-group group-name; } }

To limit the number of prefixes from a peer, include the prefix-limit statement. To specify a routing table group, include the rib-group statement. For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. Each CLNS network island is treated as a separate VRF instance on the PE router. You can configure CLNS on the global level, group level, and neighbor level. For sample configurations, see the following sections: •

Example: Enabling CLNS Between Two Routers on page 1219

•

Example: Configuring CLNS Within a VPN on page 1221

Example: Enabling CLNS Between Two Routers Configure CLNS between two routers through a route reflector: On Router 1: [edit protocols bgp] protocols { bgp { local-address 10.255.245.195; group pe-pe { type internal; neighbor 10.255.245.194 { family iso-vpn { unicast; } } } }


1219


} [edit routing-instances] routing-instances { aaaa { instance-type vrf; interface fe-0/0/0.0; interface so-1/1/0.0; interface lo0.1; route-distinguisher 10.255.245.194:1; vrf-target target:11111:1; protocols { isis { export dist-bgp; no-ipv4-routing; no-ipv6-routing; clns-routing; interface all; } } } } On Router 2: [edit protocols bgp] protocols { bgp { group pe-pe { type internal; local-address 10.255.245.198; family route-target; neighbor 10.255.245.194 { family iso-vpn { unicast; } } } } } [edit routing-instances] routing-instances { aaaa { instance-type vrf; interface lo0.1; interface so-0/1/2.0; interface so-0/1/3.0; route-distinguisher 10.255.245.194:1; vrf-target target:11111:1; routing-options { rib aaaa.iso.0 { static { iso-route 47.0005.80ff.f800.0000.bbbb.1022/104 next-hop 47.0005.80ff.f800.0000.aaaa.1000.1921.6800.4196.00; } } } protocols { isis {

1220



export dist-bgp; no-ipv4-routing; no-ipv6-routing; clns-routing; interface all; } } } } On Route Reflector: [edit protocols bgp] protocols { bgp { group pe-pe { type internal; local-address 10.255.245.194; family route-target; neighbor 10.255.245.195 { cluster 0.0.0.1; } neighbor 10.255.245.198 { cluster 0.0.0.1; } } } }

Example: Configuring CLNS Within a VPN Configure CLNS on three PE routers within a VPN: On PE Router 1: [edit protocols bgp] protocols { mpls { interface all; } bgp { group asbr { type external; local-address 10.245.245.3; neighbor 10.245.245.1 { multihop; family iso-vpn { unicast; } peer-as 200; } } } } [edit routing-instances] routing-instances { aaaa { instance-type vrf; interface lo0.1;


1221


interface t1-3/0/0.0; interface fe-5/0/1.0; route-distinguisher 10.245.245.1:1; vrf-target target:11111:1; protocols { isis { export dist-bgp; no-ipv4-routing; no-ipv6-routing; clns-routing; interface all; } } } } On PE Router 2: [edit protocols bgp] protocols { bgp { group asbr { type external; multihop; family iso-vpn { unicast; } neighbor 10.245.245.2 { peer-as 300; } neighbor 10.245.245.3 { peer-as 100; } } } } [edit routing-instances] routing-instances { aaaa { instance-type vrf; interface lo0.1; route-distinguisher 10.245.245.1:1; vrf-target target:11111:1; } } On PE Router 3: [edit protocols bgp] protocols { bgp { group asbr { type external; multihop; local-address 10.245.245.2; neighbor 10.245.245.1 { family iso-vpn { unicast; } peer-as 200;

1222



} } } } [edit routing-instances] routing-instances { aaaa { instance-type vrf; interface lo0.1; interface fe-0/0/1.0; interface t1-3/0/0.0; route-distinguisher 10.245.245.1:1; vrf-target target:11111:1; protocols { isis { export dist-bgp; no-ipv6-routing; clns-routing; interface all; } } } }


•


•


Examples: Configuring TCP and BGP Security •

Understanding TCP and BGP Security on page 1223

•

Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers on page 1224

•

Example: Configuring a Filter to Limit TCP Access to a Port Based On a Prefix List on page 1229

•

Example: Limiting TCP Segment Size for BGP on page 1232

Understanding TCP and BGP Security BGP peers are established by manual configuration between routing devices to create a TCP session on port 179. A BGP-enabled device periodically sends keepalive messages to maintain the connection. Among routing protocols, BGP is unique in using TCP as its transport protocol. For detailed information about the security issues associated with BGP’s use of TCP as a transport protocol, see RFC 4272, BGP Security Vulnerabilities Analysis.


1223


Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers This example shows how to configure a standard stateless firewall filter that limits certain TCP and Internet Control Message Protocol (ICMP) traffic destined for the Routing Engine. •


•


•


•



Overview In this example, you create a stateless firewall filter that blocks all TCP connection attempts to port 179 from all requesters except the specified BGP peers. The stateless firewall filter filter_bgp179 matches all packets from the directly connected interfaces on Device A and Device B to the destination port number 179. Figure 69 on page 1224 shows the topology used in this example. Device C attempts to make a TCP connection to Device E. Device E blocks the connection attempt. This example shows the configuration on Device C and Device E.

Figure 69: Typical Network with BGP Peer Sessions

10.2

A AS 22

E

10.6

B

10.10

C

g040870

AS 17

10.1 10.5 10.9

Configuration The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode. To configure this example, perform the following tasks: •


1224

Configuring Device E on page 1225




configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. Device C

set interfaces ge-1/2/0 unit 10 description to-E set interfaces ge-1/2/0 unit 10 family inet address 10.10.10.10/30 set protocols bgp group external-peers type external set protocols bgp group external-peers peer-as 17 set protocols bgp group external-peers neighbor 10.10.10.9 set routing-options autonomous-system 22

Device E

set interfaces ge-1/2/0 unit 0 description to-A set interfaces ge-1/2/0 unit 0 family inet address 10.10.10.1/30 set interfaces ge-1/2/1 unit 5 description to-B set interfaces ge-1/2/1 unit 5 family inet address 10.10.10.5/30 set interfaces ge-1/0/0 unit 9 description to-C set interfaces ge-1/0/0 unit 9 family inet address 10.10.10.9/30 set interfaces lo0 unit 2 family inet filter input filter_bgp179 set interfaces lo0 unit 2 family inet address 192.168.0.1/32 set protocols bgp group external-peers type external set protocols bgp group external-peers peer-as 22 set protocols bgp group external-peers neighbor 10.10.10.2 set protocols bgp group external-peers neighbor 10.10.10.6 set protocols bgp group external-peers neighbor 10.10.10.10 set routing-options autonomous-system 17 set firewall family inet filter filter_bgp179 term 1 from source-address 10.10.10.2/32 set firewall family inet filter filter_bgp179 term 1 from source-address 10.10.10.6/32 set firewall family inet filter filter_bgp179 term 1 from destination-port bgp set firewall family inet filter filter_bgp179 term 1 then accept set firewall family inet filter filter_bgp179 term 2 then reject

Configuring Device E Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure the stateless firewall filter that blocks all TCP connection attempts to port 179 from all requestors except specified BGP peers: 1.

Configure the interfaces. user@E# set interfaces ge-1/2/0 unit 0 description to-A user@E# set interfaces ge-1/2/0 unit 0 family inet address 10.10.10.1/30 user@E# set interfaces ge-1/2/1 unit 5 description to-B user@E# set interfaces ge-1/2/1 unit 5 family inet address 10.10.10.5/30 user@E# set interfaces ge-1/0/0 unit 9 description to-C user@E# set interfaces ge-1/0/0 unit 9 family inet address 10.10.10.9/30

2.

Configure BGP. [edit protocols bgp group external-peers] user@E# set type external user@E# set peer-as 22 user@E# set neighbor 10.10.10.2


1225


user@E# set neighbor 10.10.10.6 user@E# set neighbor 10.10.10.10 3.

Configure the autonomous system (AS) number. [edit routing-options] user@E# set autonomous-system 17

4.

Define the filter term that accepts TCP connection attempts to port 179 from the specified BGP peers. [edit firewall family inet filter filter_bgp179] user@E# set term 1 from source-address 10.10.10.2/32 user@E# set term 1 from source-address 10.10.10.6/32 user@E# set term 1 from destination-port bgp user@E# set term 1 then accept

5.

Define the other filter term to reject packets from other sources. [edit firewall family inet filter filter_bgp179] user@E# set term 2 then reject

6.

Apply the firewall filter to the loopback interface. [edit interfaces lo0 unit 2 family inet] user@E# set filter input filter_bgp179 user@E# set address 192.168.0.1/32

Results

From configuration mode, confirm your configuration by entering the show firewall, show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@E# show firewall family inet { filter filter_bgp179 { term 1 { from { source-address { 10.10.10.2/32; 10.10.10.6/32; } destination-port bgp; } then accept; } term 2 { then { reject; } } } } user@E# show interfaces lo0 { unit 2 { family inet {

1226



filter { input filter_bgp179; } address 192.168.0.1/32; } } } ge-1/2/0 { unit 0 { description to-A; family inet { address 10.10.10.1/30; } } } ge-1/2/1 { unit 5 { description to-B; family inet { address 10.10.10.5/30; } } } ge-1/0/0 { unit 9 { description to-C; family inet { address 10.10.10.9/30; } } } user@E# show protocols bgp { group external-peers { type external; peer-as 22; neighbor 10.10.10.2; neighbor 10.10.10.6; neighbor 10.10.10.10; } } ospf { area 0.0.0.0 { interface fe-1/2/0.1; interface 10.255.14.179; } } user@R0# show routing-options autonomous-system 17;

If you are done configuring the device, enter commit from configuration mode. Repeat the procedure, where appropriate, for every BGP-enabled device in the network, using the appropriate interface names and addresses for each BGP-enabled device.


1227



Verifying That the Filter Is Configured on page 1228

•

Verifying the TCP Connections on page 1228

•

Monitoring Traffic on the Interfaces on page 1228

Verifying That the Filter Is Configured Purpose Action

Make sure that the filter is listed in output of the show firewall filter command. user@E> show firewall filter filter_bgp179 Filter: filter_bgp179

Verifying the TCP Connections Purpose Action

Verify the TCP connections. From operational mode, run the show system connections extensive command on Device C and Device E. The output on Device C shows the attempt to establish a TCP connection. The output on Device E shows that connections are established with Device A and Device B only. user@C> show system connections extensive | match 10.10.10 tcp4

0

0

10.10.10.9.51872

10.10.10.10.179

SYN_SENT

user@E> show system connections extensive | match 10.10.10 tcp4 tcp4 tcp4 tcp4

0 0 0 0

0 0 0 0

10.10.10.5.179 10.10.10.6.62096 10.10.10.1.179 10.10.10.2.61506

10.10.10.6.62096 10.10.10.5.179 10.10.10.2.61506 10.10.10.1.179

ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED

Monitoring Traffic on the Interfaces Purpose

Action

Compare the traffic on an interface that establishes a TCP connection with the traffic on an interface that does not establish a TCP connection. From operational mode, run the monitor traffic command on the Device E interface to Device B and on the Device E interface to Device C. In the first example, acknowledgment (ack) messages are received. In the second example, ack messages are not received. user@E> monitor traffic size 1500 interface ge-1/2/1.5 19:02:49.700912 Out IP 10.10.10.5.bgp > 10.10.10.6.62096: P 3330573561:3330573580(19) ack 915601686 win 16384 : BGP, length: 19 19:02:49.801244 In IP 10.10.10.6.62096 > 10.10.10.5.bgp: . ack 19 win 16384 19:03:03.323018 In IP 10.10.10.6.62096 > 10.10.10.5.bgp: P 1:20(19) ack 19 win 16384 : BGP, length: 19 19:03:03.422418 Out IP 10.10.10.5.bgp > 10.10.10.6.62096: . ack 20 win 16384

1228



19:03:17.220162 Out IP 10.10.10.5.bgp > 10.10.10.6.62096: P 19:38(19) ack 20 win 16384 : BGP, length: 19 19:03:17.320501 In IP 10.10.10.6.62096 > 10.10.10.5.bgp: . ack 38 win 16384 user@E> monitor traffic size 1500 interface ge-1/0/0.9 18:54:20.175471 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 18:54:23.174422 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 18:54:26.374118 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 18:54:29.573799 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 18:54:32.773493 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 18:54:35.973185 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384

Example: Configuring a Filter to Limit TCP Access to a Port Based On a Prefix List This example shows how to configure a standard stateless firewall filter that limits certain TCP and Internet Control Message Protocol (ICMP) traffic destined for the Routing Engine: •


•


•


•


Requirements No special configuration beyond device initialization is required before configuring this example.

Overview In this example, you create a stateless firewall filter that blocks all TCP connection attempts to port 179 from all requesters except the specified BGP peers. The source prefix list plist_bgp179 specifies the list of source prefixes that contain allowed BGP peers. The stateless firewall filter filter_bgp179 matches all packets from the source prefix list plist_bgp179 to the destination port number 179.

Configuration The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode. •

Configure the Filter on page 1230


1229



To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set policy-options prefix-list plist_bgp179 apply-path "protocols bgp group neighbor " set firewall family inet filter filter_bgp179 term 1 from source-address 0.0.0.0/0 set firewall family inet filter filter_bgp179 term 1 from source-prefix-list plist_bgp179 except set firewall family inet filter filter_bgp179 term 1 from destination-port bgp set firewall family inet filter filter_bgp179 term 1 then reject set firewall family inet filter filter_bgp179 term 2 then accept set interfaces lo0 unit 0 family inet filter input filter_bgp179 set interfaces lo0 unit 0 family inet address 127.0.0.1/32

Configure the Filter Step-by-Step Procedure

To configure the filter: •

Expand the prefix list bgp179 to include all prefixes pointed to by the BGP peer group defined by protocols bgp group neighbor . [edit policy-options prefix-list plist_bgp179] user@host# set apply-path "protocols bgp group neighbor "

•

Define the filter term that rejects TCP connection attempts to port 179 from all requesters except the specified BGP peers. [edit firewall family inet filter filter_bgp179] user@host# set term term1 from source-address 0.0.0.0/0 user@host# set term term1 from source-prefix-list bgp179 except user@host# set term term1 from destination-port bgp user@host# set term term1 then reject

•

Define the other filter term to accept all packets. [edit firewall family inet filter filter_bgp179] user@host# set term term2 then accept

•

Apply the firewall filter to the loopback interface. [edit interfaces lo0 unit 0 family inet] user@host# set filter input filter_bgp179 user@host# set address 127.0.0.1/32

Results

From configuration mode, confirm your configuration by entering the show firewall, show interfaces ,and show policy-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show firewall family inet { filter filter_bgp179 { term 1 { from { source-address { 0.0.0.0/0; }

1230



source-prefix-list { plist_bgp179 except; } destination-port bgp; } then { reject; } } term 2 { then { accept; } } } } user@host# show interfaces lo0 { unit 0 { family inet { filter { input filter_bgp179; } address 127.0.0.1/32; } } } user@host# show policy-options prefix-list plist_bgp179 { apply-path "protocols bgp group neighbor "; }


Verification Confirm that the configuration is working properly. Displaying the Firewall Filter Applied to the Loopback Interface Purpose

Action

Verify that the firewall filter filter_bgp179 is applied to the IPv4 input traffic at logical interface lo0.0. Use the show interfaces statistics operational mode command for logical interface lo0.0, and include the detail option. Under the Protocol inet section of the command output section, the Input Filters field displays the name of the stateless firewall filter applied to the logical interface in the input direction: [edit] user@host> show interfaces statistics lo0.0 detail


1231


Logical interface lo0.0 (Index 321) (SNMP ifIndex 16) (Generation 130) Flags: SNMP-Traps Encapsulation: Unspecified Traffic statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol inet, MTU: Unlimited, Generation: 145, Route table: 0 Flags: Sendbcast-pkt-to-re Input Filters: filter_bgp179 Addresses, Flags: Primary Destination: Unspecified, Local: 127.0.0.1, Broadcast: Unspecified, Generation: 138

Example: Limiting TCP Segment Size for BGP This example shows how to prevent Internet Control Message Protocol (ICMP) vulnerability issues when you are using maximum transmission unit (MTU) discovery to avoid BGP packet fragmentation. •


•


•


•



Overview TCP negotiates a maximum segment size (MSS) value during session connection establishment between two peers. The MSS value negotiated is primarily based on the maximum transmission unit (MTU) of the interfaces to which the communicating peers are directly connected. However in the network, due to variation in link MTU on the path taken by the TCP packets, some packets that are well within the MSS value might be fragmented when the packet size exceeds the link's MTU. TCP path MTU discovery helps avoid BGP packet fragmentation. However, enabling TCP path MTU discovery creates ICMP vulnerability. To prevent these ICMP vulnerability issues, you can configure the TCP MSS globally, or for each BGP peer to prevent fragmentation of packets sent to the BGP peer from the local routing device and sent by the BGP peer to the local routing device.

1232



To configure the TCP MSS value, include the tcp-mss statement with a segment size from 1 through 4096. If the router receives a TCP packet with the SYN bit and MSS option set and the MSS option specified in the packet is larger than the MSS value specified by the tcp-mss statement, the router replaces the MSS value in the packet with the lower value specified by the tcp-mss statement. The configured MSS value is used as the maximum segment size for the sender. The assumption is that the TCP MSS value used by the sender to communicate with the BGP neighbor is the same as the TCP MSS value that the sender can accept from the BGP neighbor. If the MSS value from the BGP neighbor is less than the MSS value configured, the MSS value from the BGP neighbor is used as the maximum segment size for the sender. This feature is supported with TCP over IPv4 and TCP over IPv6. Topology Diagram Figure 70 on page 1233 shows the topology used in this example.

Figure 70: TCP Maximum Segment Size for BGP

R0

MSS = 2000 2000

R1

1000

R2

2000

R3

BGP Session

g041159

MSS = 2000


R0

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set interfaces fe-1/2/0 unit 1 family inet address 1.1.0.1/30 set interfaces lo0 unit 1 family inet address 10.255.14.179/32 set protocols bgp group-int tcp-mss 2020 set protocols bgp group int type internal set protocols bgp group int local-address 10.255.14.179 set protocols bgp group int mtu-discovery set protocols bgp group int neighbor 10.255.71.24 tcp-mss 2000 set protocols bgp group int neighbor 10.255.14.177 set protocols bgp group int neighbor 10.0.14.4 tcp-mss 4000 set protocols ospf area 0.0.0.0 interface fe-1/2/0.1 set protocols ospf area 0.0.0.0 interface 10.255.14.179 set routing-options autonomous-system 65000


1233



The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Router R0: 1.


2.

Configure an interior gateway protocol (IGP). [edit protocols ospf area 0.0.0.0] user@R0# set interface fe-1/2/0.1 user@R0# set interface 10.255.14.179

3.

Configure one or more BGP groups. [edit protocols bgp group int] user@R0# set type internal user@R0# set local-address 10.255.14.179

4.

Configure MTU discovery to prevent packet fragmentation. [edit protocols bgp group int] user@R0# set mtu-discovery

5.

Configure the BGP neighbors, with the TCP MSS set globally for the group or specifically for the various neighbors. [edit protocols bgo group int] user@R0# set tcp-mss 2020 user@R0# set neighbor 10.255.14.177 user@R0# set neighbor 10.255.71.24 tcp-mss 2000 user@R0# set neighbor 10.0.14.4 tcp-mss 4000

The TCP MSS neighbor setting overrides the group setting. 6.

Configure the local autonomous system (AS). [edit routing-options] user@R0# set autonomous-system 65000

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R0# show interfaces fe-1/2/0 { unit 1 { family inet { address 1.1.0.1/30; } } } lo0 { unit 1 {

1234



family inet { address 10.255.14.179/32; } } } user@R0# show protocols bgp { group int { type internal; local-address 10.255.14.179; mtu-discovery; tcp-mss 2020; neighbor 10.255.71.24 { tcp-mss 2000; } neighbor 10.255.14.177; neighbor 10.0.14.4 { tcp-mss 4000; } } } ospf { area 0.0.0.0 { interface fe-1/2/0.1; interface 10.255.14.179; } } user@R0# show routing-options autonomous-system 65000;


Verification To confirm that the configuration is working properly, run the following commands: •

show system connections extensive | find , to check the negotiated

TCP MSS value •

monitor traffic interface, to monitor BGP traffic and to make sure that the configured

TCP MSS value is used as the MSS option in TCP SYN packet Related Documentation

•


•



1235


Example: Configuring BGP Route Advertisement •

Understanding Route Advertisement on page 1236

•

Example: Configuring BGP Prefix-Based Outbound Route Filtering on page 1240

Understanding Route Advertisement All routing protocols use the Junos OS routing table to store the routes that they learn and to determine which routes they should advertise in their protocol packets. Routing policy allows you to control which routes the routing protocols store in and retrieve from the routing table. For information about routing policy, see the Junos OS Routing Policy Configuration Guide. When configuring BGP routing policy, you can perform the following tasks: •

Applying Routing Policy on page 1236

•

Setting BGP to Advertise Inactive Routes on page 1237

•

Configuring BGP to Advertise the Best External Route to Internal Peers on page 1237

•

Configuring How Often BGP Exchanges Routes with the Routing Table on page 1239

•

Disabling Suppression of Route Advertisements on page 1239

Applying Routing Policy You define routing policy at the [edit policy-options] hierarchy level. To apply policies you have defined for BGP, include the import and export statements within the BGP configuration. For information about defining policy, see the Junos OS Routing Policy Configuration Guide. You can apply policies as follows: •

BGP global import and export statements—Include these statements at the [edit protocols bgp] hierarchy level (for routing instances, include these statements at the [edit routing-instances routing-instance-name protocols bgp] hierarchy level).

•

Group import and export statements—Include these statements at the [edit protocols bgp group group-name] hierarchy level (for routing instances, include these statements at the [edit routing-instances routing-instance-name protocols bgp group group-name] hierarchy level).

•

Peer import and export statements—Include these statements at the [edit protocols bgp group group-name neighbor address] hierarchy level (for routing instances, include these statements at the [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address] hierarchy level).

A peer-level import or export statement overrides a group import or export statement. A group-level import or export statement overrides a global BGP import or export statement.

1236



To apply policies, see the following sections: •

Applying Policies to Routes Being Imported into the Routing Table from BGP on page 1237

•

Applying Policies to Routes Being Exported from the Routing Table into BGP on page 1237

Applying Policies to Routes Being Imported into the Routing Table from BGP To apply policy to routes being imported into the routing table from BGP, include the import statement, listing the names of one or more policies to be evaluated: import [ policy-names ];

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. If you specify more than one policy, they are evaluated in the order specified, from first to last, and the first matching filter is applied to the route. If no match is found, BGP places into the routing table only those routes that were learned from BGP routing devices. Applying Policies to Routes Being Exported from the Routing Table into BGP To apply policy to routes being exported from the routing table into BGP, include the export statement, listing the names of one or more policies to be evaluated: export [ policy-names ];

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. If you specify more than one policy, they are evaluated in the order specified, from first to last, and the first matching filter is applied to the route. If no routes match the filters, the routing table exports into BGP only the routes that it learned from BGP.

Setting BGP to Advertise Inactive Routes By default, BGP stores the route information it receives from update messages in the Junos OS routing table, and the routing table exports only active routes into BGP, which BGP then advertises to its peers. To have the routing table export to BGP the best route learned by BGP even if Junos OS did not select it to be an active route, include the advertise-inactive statement: advertise-inactive;


Configuring BGP to Advertise the Best External Route to Internal Peers In general, deployed BGP implementations do not advertise the external route with the highest local preference value to internal peers unless it is the best route. Although this behavior was required by an earlier version of the BGP version 4 specification, RFC 1771, it was typically not followed in order to minimize the amount of advertised information and to prevent routing loops. However, there are scenarios in which advertising the best external route is beneficial, in particular, situations that can result in IBGP route oscillation.


1237


In Junos OS Release 9.3 and later, you can configure BGP to advertise the best external route into an internal BGP (IBGP) mesh group, a route reflector cluster, or an autonomous system (AS) confederation, even when the best route is an internal route.

NOTE: In order to configure the advertise-external statement on a route reflector, you must disable intracluster reflection with the no-client-reflect statement.

When a routing device is configured as a route reflector for a cluster, a route advertised by the route reflector is considered internal if it is received from an internal peer with the same cluster identifier or if both peers have no cluster identifier configured. A route received from an internal peer that belongs to another cluster, that is, with a different cluster identifier, is considered external. In a confederation, when advertising a route to a confederation border router, any route from a different confederation sub-AS is considered external. You can also configure BGP to advertise the external route only if the route selection process reaches the point where the multiple exit discriminator (MED) metric is evaluated. As a result, an external route with an AS path worse (that is, longer) than that of the active path is not advertised. Junos OS also provides support for configuring a BGP export policy that matches on the state of an advertised route. You can match on either active or inactive routes. For more information, see the Junos OS Routing Policy Configuration Guide. To configure BGP to advertise the best external path to internal peers, include the advertise-external statement: advertise-external;

NOTE: The advertise-external statement is supported at both the group and neighbor level. If you configure the statement at the neighbor level, you must configure it for all neighbors in a group. Otherwise, the group is automatically split into different groups. For a complete list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement.

To configure BGP to advertise the best external path only if the route selection process reaches the point where the MED value is evaluated, include the conditional statement: advertise-external { conditional; }


1238



Configuring How Often BGP Exchanges Routes with the Routing Table BGP stores the route information it receives from update messages in the routing table, and the routing table exports active routes from the routing table into BGP. BGP then advertises the exported routes to its peers. By default, the exchange of route information between BGP and the routing table occurs immediately after the routes are received. This immediate exchange of route information might cause instabilities in the network reachability information. To guard against this, you can delay the time between when BGP and the routing table exchange route information. To configure how often BGP and the routing table exchange route information, include the out-delay statement: out-delay seconds;

By default, the routing table retains some of the route information learned from BGP. To have the routing table retain all or none of this information, include the keep statement: keep (all | none);

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements. The routing table can retain the route information learned from BGP in one of the following ways: •

Default (omit the keep statement)—Keep all route information that was learned from BGP, except for routes whose AS path is looped and whose loop includes the local AS.

•

keep all—Keep all route information that was learned from BGP.

•

keep none—Discard routes that were received from a peer and that were rejected by

import policy or other sanity checking, such as AS path or next hop. When you configure keep none for the BGP session and the inbound policy changes, Junos OS forces readvertisement of the full set of routes advertised by the peer. In an AS path healing situation, routes with looped paths theoretically could become usable during a soft reconfiguration when the AS path loop limit is changed. However, there is a significant memory usage difference between the default and keep all because it is common for a peer to readvertise routes back to the peer from which it learned them. The default behavior is not to waste memory on such routes.

Disabling Suppression of Route Advertisements Junos OS does not advertise the routes learned from one EBGP peer back to the same external BGP (EBGP) peer. In addition, the software does not advertise those routes back to any EBGP peers that are in the same AS as the originating peer, regardless of the routing instance. You can modify this behavior by including the advertise-peer-as statement in the configuration. To disable the default advertisement suppression, include the advertise-peer-as statement: advertise-peer-as;


1239


NOTE: The route suppression default behavior is disabled if the as-override statement is included in the configuration.

If you include the advertise-peer-as statement in the configuration, BGP advertises the route regardless of this check. To restore the default behavior, include the no-advertise-peer-as statement in the configuration: no-advertise-peer-as;

If you include both the as-override and no-advertise-peer-as statements in the configuration, the no-advertise-peer-as statement is ignored. You can include these statements at multiple hierarchy levels. For a list of hierarchy levels at which you can include these statements, see the statement summary section for these statements.

Example: Configuring BGP Prefix-Based Outbound Route Filtering This example shows how to configure a Juniper Networks router to accept route filters from remote peers and perform outbound route filtering using the received filters. •


•


•


•




•


Overview You can configure a BGP peer to accept route filters from remote peers and perform outbound route filtering using the received filters. By filtering out unwanted updates, the sending peer saves resources needed to generate and transmit updates, and the receiving peer saves resources needed to process updates. This feature can be useful, for example, in a virtual private network (VPN) in which subsets of customer edge (CE) devices are not capable of processing all the routes in the VPN. The CE devices can use prefix-based outbound route filtering to communicate to the provider edge (PE) routing device to transmit only a subset of routes, such as routes to the main data centers only. The maximum number of prefix-based outbound route filters that a BGP peer can accept is 5000. If a remote peer sends more than 5000 outbound route filters to a peer address, the additional filters are discarded, and a system log message is generated.

1240



You can configure interoperability for the routing device as a whole or for specific BGP groups or peers only. Topology In the sample network, Device CE1 is a router from another vendor. The configuration shown in this example is on Juniper Networks Router PE1. Figure 71 on page 1241 shows the sample network.

Figure 71: BGP Prefix-Based Outbound Route Filtering

PE1

CE1

P

PE2

CE3

Other Vendor

g041113

CE4

CE2



PE1

set protocols bgp group cisco-peers type external set protocols bgp group cisco-peers description “to CE1” set protocols bgp group cisco-peers local-address 192.168.165.58 set protocols bgp group cisco-peers peer-as 35 set protocols bgp group cisco-peers outbound-route-filter bgp-orf-cisco-mode set protocols bgp group cisco-peers outbound-route-filter prefix-based accept inet set protocols bgp group cisco-peers neighbor 192.168.165.56 set routing-options autonomous-system 65500


The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Router PE1 to accept route filters from Device CE1 and perform outbound route filtering using the received filters: 1.

Configure the local autonomous system. [edit routing-options] user@PE1# set autonomous-system 65500

2.

Configure external peering with Device CE1. [edit protocols bgp group cisco-peers] user@PE1# set type external user@PE1# set description “to CE1” user@PE1# set local-address 192.168.165.58


1241


user@PE1# set peer-as 35 user@PE1# set neighbor 192.168.165.56 3.

Configure Router PE1 to accept IPv4 route filters from Device CE1 and perform outbound route filtering using the received filters. [edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter prefix-based accept inet

4.

(Optional) Enable interoperability with routing devices that use the vendor-specific compatibility code of 130 for outbound route filters and the code type of 128. The IANA standard code is 3, and the standard code type is 64. [edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter bgp-orf-cisco-mode

Results

From configuration mode, confirm your configuration by entering the show protocols and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@PE1# show protocols group cisco-peers { type external; description “to CE1”; local-address 192.168.165.58; peer-as 35; outbound-route-filter { bgp-orf-cisco-mode; prefix-based { accept { inet; } } } neighbor 192.168.165.56; } user@PE1# show routing-options autonomous-system 65500;



Verifying the Outbound Route Filter on page 1242

•

Verifying the BGP Neighbor Mode on page 1243

Verifying the Outbound Route Filter Purpose Action

Display information about the prefix-based outbound route filter received from Device CE1. From operational mode, enter the show bgp neighbor orf detail command. user@PE1> show bgp neighbor orf 192.168.165.56 detail

1242



Peer: 192.168.165.56 Type: External Group: cisco-peers inet-unicast Filter updates recv: Filter: prefix-based Updates recv: Received filter entries: seq 10 2.2.0.0/16 deny seq 20 3.3.0.0/16 deny seq 30 4.4.0.0/16 deny seq 40 5.5.0.0/16 deny

4 Immediate: receive 4 minlen minlen minlen minlen

0

0 maxlen 0 24 maxlen 0 0 maxlen 28 24 maxlen 28

Verifying the BGP Neighbor Mode Purpose

Action

Verify that the bgp-orf-cisco-mode setting is enabled for the peer by making sure that the ORFCiscoMode option is displayed in the show bgp neighbor command output. From operational mode, enter the show bgp neighbor command. user@PE1> show bgp neighbor Peer: 192.168.165.56 AS 35 Local: 192.168.165.58 AS 65500 Type: External State: Active Flags: Last State: Idle Last Event: Start Last Error: None Export: [ adv_stat ] Options: Options: Address families configured: inet-unicast Local Address: 192.168.165.58 Holdtime: 90 Preference: 170 Number of flaps: 0 Trace options: detail open detail refresh Trace file: /var/log/orf size 5242880 files 20


•


•


Example: Configuring BFD for BGP •

Understanding BFD for BGP on page 1243

•

Example: Configuring BFD on Internal BGP Peer Sessions on page 1244

Understanding BFD for BGP The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures in a network. Hello packets are sent at a specified, regular interval. A neighbor failure is detected when the routing device stops receiving a reply after a specified interval. BFD works with a wide variety of network environments and topologies. The failure detection timers for BFD have shorter time limits than default failure detection mechanisms, providing faster detection. These timers are also adaptive and can be adjusted to be adjusted. For example, the timers can adapt to a higher value if the adjacency fails, or a neighbor can negotiate a higher value for a timer than the one configured.


1243


In Junos OS Release 8.3 and later, BFD is supported on internal BGP (IBGP) and multihop external BGP (EBGP) sessions as well as on single-hop EBGP sessions. In Junos OS Release 9.1 through Junos OS Release 11.1, BFD supports IPv6 interfaces in static routes only. In Junos OS Release 11.2 and later, BFD supports IPv6 interfaces with BGP.

Example: Configuring BFD on Internal BGP Peer Sessions This example shows how to configure internal BGP (IBGP) peer sessions with the Bidirectional Forwarding Detection (BFD) protocol to detect failures in a network. •


•


•


•



Overview The minimum configuration to enable BFD on IBGP sessions is the bfd-liveness-detection minimum-interval statement in the BGP configuration of all neighbors participating in the BFD session. The minimum-interval statement specifies the minimum transmit and receive intervals for failure detection. Specifically, this value represents the minimum interval at which the local routing device transmits hello packets as well as the minimum interval that the routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a value from 1 through 255,000 milliseconds. Optionally, you can specify the minimum transmit and receive intervals separately using the minimum-receive-interval and transmit-interval minimal-interval statements. For information about these and other optional BFD configuration statements, see bfd-liveness-detection.

1244





•


•

For BFD sessions to remain up during a Routing Engine switchover event when nonstop active routing (NSR) is configured, specify a minimum interval of 2500 ms for Routing Engine-based sessions. For distributed BFD sessions with nonstop active routing configured, the minimum interval recommendations are unchanged and depend only on your network deployment.

BFD is supported on the default routing instance (the main router), routing instances, and logical systems. This example shows BFD on logical systems. Figure 72 on page 1245 shows a typical network with internal peer sessions.


192.168.6.5 AS 17

A

192.163.6.4 C

B

g040732

192.168.40.4


Device A

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems A interfaces lt-1/2/0 unit 1 description to-B set logical-systems A interfaces lt-1/2/0 unit 1 encapsulation ethernet


1245


set logical-systems A interfaces lt-1/2/0 unit 1 peer-unit 2 set logical-systems A interfaces lt-1/2/0 unit 1 family inet address 10.10.10.1/30 set logical-systems A interfaces lo0 unit 1 family inet address 192.168.6.5/32 set logical-systems A protocols bgp group internal-peers type internal set logical-systems A protocols bgp group internal-peers traceoptions file bgp-bfd set logical-systems A protocols bgp group internal-peers traceoptions flag bfd detail set logical-systems A protocols bgp group internal-peers local-address 192.168.6.5 set logical-systems A protocols bgp group internal-peers export send-direct set logical-systems A protocols bgp group internal-peers bfd-liveness-detection minimum-interval 1000 set logical-systems A protocols bgp group internal-peers neighbor 192.163.6.4 set logical-systems A protocols bgp group internal-peers neighbor 192.168.40.4 set logical-systems A protocols ospf area 0.0.0.0 interface lo0.1 passive set logical-systems A protocols ospf area 0.0.0.0 interface lt-1/2/0.1 set logical-systems A policy-options policy-statement send-direct term 2 from protocol direct set logical-systems A policy-options policy-statement send-direct term 2 then accept set logical-systems A routing-options router-id 192.168.6.5 set logical-systems A routing-options autonomous-system 17

1246

Device B

set logical-systems B interfaces lt-1/2/0 unit 2 description to-A set logical-systems B interfaces lt-1/2/0 unit 2 encapsulation ethernet set logical-systems B interfaces lt-1/2/0 unit 2 peer-unit 1 set logical-systems B interfaces lt-1/2/0 unit 2 family inet address 10.10.10.2/30 set logical-systems B interfaces lt-1/2/0 unit 5 description to-C set logical-systems B interfaces lt-1/2/0 unit 5 encapsulation ethernet set logical-systems B interfaces lt-1/2/0 unit 5 peer-unit 6 set logical-systems B interfaces lt-1/2/0 unit 5 family inet address 10.10.10.5/30 set logical-systems B interfaces lo0 unit 2 family inet address 192.163.6.4/32 set logical-systems B protocols bgp group internal-peers type internal set logical-systems B protocols bgp group internal-peers local-address 192.163.6.4 set logical-systems B protocols bgp group internal-peers export send-direct set logical-systems B protocols bgp group internal-peers bfd-liveness-detection minimum-interval 1000 set logical-systems B protocols bgp group internal-peers neighbor 192.168.40.4 set logical-systems B protocols bgp group internal-peers neighbor 192.168.6.5 set logical-systems B protocols ospf area 0.0.0.0 interface lo0.2 passive set logical-systems B protocols ospf area 0.0.0.0 interface lt-1/2/0.2 set logical-systems B protocols ospf area 0.0.0.0 interface lt-1/2/0.5 set logical-systems B policy-options policy-statement send-direct term 2 from protocol direct set logical-systems B policy-options policy-statement send-direct term 2 then accept set logical-systems B routing-options router-id 192.163.6.4 set logical-systems B routing-options autonomous-system 17

Device C

set logical-systems C interfaces lt-1/2/0 unit 6 description to-B set logical-systems C interfaces lt-1/2/0 unit 6 encapsulation ethernet set logical-systems C interfaces lt-1/2/0 unit 6 peer-unit 5 set logical-systems C interfaces lt-1/2/0 unit 6 family inet address 10.10.10.6/30 set logical-systems C interfaces lo0 unit 3 family inet address 192.168.40.4/32 set logical-systems C protocols bgp group internal-peers type internal set logical-systems C protocols bgp group internal-peers local-address 192.168.40.4 set logical-systems C protocols bgp group internal-peers export send-direct set logical-systems C protocols bgp group internal-peers bfd-liveness-detection minimum-interval 1000



set logical-systems C protocols bgp group internal-peers neighbor 192.163.6.4 set logical-systems C protocols bgp group internal-peers neighbor 192.168.6.5 set logical-systems C protocols ospf area 0.0.0.0 interface lo0.3 passive set logical-systems C protocols ospf area 0.0.0.0 interface lt-1/2/0.6 set logical-systems C policy-options policy-statement send-direct term 2 from protocol direct set logical-systems C policy-options policy-statement send-direct term 2 then accept set logical-systems C routing-options router-id 192.168.40.4 set logical-systems C routing-options autonomous-system 17

Configuring Device A Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Device A: 1.

Set the CLI to Logical System A. user@host> set cli logical-system A

2.

Configure the interfaces. [edit interfaces lt-1/2/0 unit 1] user@host:A# set description to-B user@host:A# set encapsulation ethernet user@host:A# set peer-unit 2 user@host:A# set family inet address 10.10.10.1/30 [edit interfaces lo0 unit 1] user@host:A# set family inet address 192.168.6.5/32

3.

Configure BGP. The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C. [edit protocols bgp group internal-peers] user@host:A# set type internal user@host:A# set local-address 192.168.6.5 user@host:A# set export send-direct user@host:A# set neighbor 192.163.6.4 user@host:A# set neighbor 192.168.40.4

4.

Configure BFD. [edit protocols bgp group internal-peers] user@host:A# set bfd-liveness-detection minimum-interval 1000

You must configure the same minimum interval on the connecting peer. 5.

(Optional) Configure BFD tracing. [edit protocols bgp group internal-peers] user@host:A# set traceoptions file bgp-bfd user@host:A# set traceoptions flag bfd detail

You must configure the same minimum interval on the connecting peer.


1247


6.

Configure OSPF. [edit protocols ospf area 0.0.0.0] user@host:A# set interface lo0.1 passive user@host:A# set interface lt-1/2/0.1

7.

Configure a policy that accepts direct routes. Other useful options for this scenario might be to accept routes learned through OSPF or local routes. [edit policy-options policy-statement send-direct term 2] user@host:A# set from protocol direct user@host:A# set then accept

8.

Configure the router ID and the autonomous system (AS) number. [edit routing-options] user@host:A# set router-id 192.168.6.5 user@host:A# set autonomous-system 17

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host:A# show interfaces lt-1/2/0 { unit 1 { description to-B; encapsulation ethernet; peer-unit 2; family inet { address 10.10.10.1/30; } } } lo0 { unit 1 { family inet { address 192.168.6.5/32; } } } user@host:A# show policy-options policy-statement send-direct { term 2 { from protocol direct; then accept; } } user@host:A# show protocols bgp { group internal-peers { type internal; traceoptions {

1248



file bgp-bfd; flag bfd detail; } local-address 192.168.6.5; export send-direct; bfd-liveness-detection { minimum-interval 1000; } neighbor 192.163.6.4; neighbor 192.168.40.4; } } ospf { area 0.0.0.0 { interface lo0.1 { passive; } interface lt-1/2/0.1; } } user@host:A# show routing-options router-id 192.168.6.5; autonomous-system 17;

If you are done configuring the device, enter commit from configuration mode. Repeat these steps for all BFD sessions in the topology.


Verifying That BFD Is Enabled on page 1249

•

Verifying That BFD Sessions Are Up on page 1250

•

Viewing Detailed BFD Events on page 1250

•

Viewing Detailed BFD Events After Deactivating and Reactivating a Loopback Interface on page 1251

Verifying That BFD Is Enabled Purpose Action

Verify that BFD is enabled between the IBGP peers. From operational mode, enter the show bgp neighbor command. You can use the | match bfd filter to narrow the output. user@host:A> show bgp neighbor | match bfd Options: BFD: enabled, up Trace file: /var/log/A/bgp-bfd size 131072 files 10 Options: BFD: enabled, up Trace file: /var/log/A/bgp-bfd size 131072 files 10

Meaning

The output shows that Logical System A has two neighbors with BFD enabled. When BFD is not enabled, the output says BFD: disabled, down, and the option


1249


is absent. If BFD is enabled and the session is down, the output is BFD: enabled, down. The output also shows that BFD-related events are being written to a log file because trace operations are configured. Verifying That BFD Sessions Are Up Purpose Action

Verify that the BFD sessions are up, and view details about the BFD sessions. From operational mode, enter the show bfd session extensive command. user@host:A> show bfd session extensive Detect Transmit Address State Interface Time Interval Multiplier 192.163.6.4 Up 3.000 1.000 3 Client BGP, TX interval 1.000, RX interval 1.000 Session up time 00:54:40 Local diagnostic None, remote diagnostic None Remote state Up, version 1 Logical system 12, routing table index 25 Min async interval 1.000, min slow interval 1.000 Adaptive async TX interval 1.000, RX interval 1.000 Local min TX interval 1.000, minimum RX interval 1.000, multiplier 3 Remote min TX interval 1.000, min RX interval 1.000, multiplier 3 Local discriminator 10, remote discriminator 9 Echo mode disabled/inactive Multi-hop route table 25, local-address 192.168.6.5 Detect Transmit Address State Interface Time Interval Multiplier 192.168.40.4 Up 3.000 1.000 3 Client BGP, TX interval 1.000, RX interval 1.000 Session up time 00:48:03 Local diagnostic None, remote diagnostic None Remote state Up, version 1 Logical system 12, routing table index 25 Min async interval 1.000, min slow interval 1.000 Adaptive async TX interval 1.000, RX interval 1.000 Local min TX interval 1.000, minimum RX interval 1.000, multiplier 3 Remote min TX interval 1.000, min RX interval 1.000, multiplier 3 Local discriminator 14, remote discriminator 13 Echo mode disabled/inactive Multi-hop route table 25, local-address 192.168.6.5 2 sessions, 2 clients Cumulative transmit rate 2.0 pps, cumulative receive rate 2.0 pps

Meaning

The TX interval 1.000, RX interval 1.000 output represents the setting configured with the minimum-interval statement. All of the other output represents the default settings for BFD. To modify the default settings, include the optional statements under the bfd-liveness-detection statement. Viewing Detailed BFD Events

Purpose Action

1250

Check the BFD trace file to assist in troubleshooting, if needed. From operational mode, enter the file show /var/log/A/bgp-bfd command.



user@host:A> file show /var/log/A/bgp-bfd Aug 15 17:07:25 trace_on: Tracing to "/var/log/A/bgp-bfd" started Aug 15 17:07:26.492190 bgp_peer_init: BGP peer 192.163.6.4 (Internal AS 17) local address 192.168.6.5 not found. Leaving peer idled Aug 15 17:07:26.493176 bgp_peer_init: BGP peer 192.168.40.4 (Internal AS 17) local address 192.168.6.5 not found. Leaving peer idled Aug 15 17:07:32.597979 task_connect: task BGP_17.192.163.6.4+179 addr 192.163.6.4+179: No route to host Aug 15 17:07:32.599623 bgp_connect_start: connect 192.163.6.4 (Internal AS 17): No route to host Aug 15 17:07:36.869394 task_connect: task BGP_17.192.168.40.4+179 addr 192.168.40.4+179: No route to host Aug 15 17:07:36.870624 bgp_connect_start: connect 192.168.40.4 (Internal AS 17): No route to host Aug 15 17:08:04.599220 task_connect: task BGP_17.192.163.6.4+179 addr 192.163.6.4+179: No route to host Aug 15 17:08:04.601135 bgp_connect_start: connect 192.163.6.4 (Internal AS 17): No route to host Aug 15 17:08:08.869717 task_connect: task BGP_17.192.168.40.4+179 addr 192.168.40.4+179: No route to host Aug 15 17:08:08.869934 bgp_connect_start: connect 192.168.40.4 (Internal AS 17): No route to host Aug 15 17:08:36.603544 advertising receiving-speaker only capabilty to neighbor 192.163.6.4 (Internal AS 17) Aug 15 17:08:36.606726 bgp_read_message: 192.163.6.4 (Internal AS 17): 0 bytes buffered Aug 15 17:08:36.609119 Initiated BFD session to peer 192.163.6.4 (Internal AS 17): address=192.163.6.4 ifindex=0 ifname=(none) txivl=1000 rxivl=1000 mult=3 ver=255 Aug 15 17:08:36.734033 advertising receiving-speaker only capabilty to neighbor 192.168.40.4 (Internal AS 17) Aug 15 17:08:36.738436 Initiated BFD session to peer 192.168.40.4 (Internal AS 17): address=192.168.40.4 ifindex=0 ifname=(none) txivl=1000 rxivl=1000 mult=3 ver=255 Aug 15 17:08:40.537552 BFD session to peer 192.163.6.4 (Internal AS 17) up Aug 15 17:08:40.694410 BFD session to peer 192.168.40.4 (Internal AS 17) up

Meaning

Before the routes are established, the No route to host message appears in the output. After the routes are established, the last two lines show that both BFD sessions come up. Viewing Detailed BFD Events After Deactivating and Reactivating a Loopback Interface

Purpose

Action

Check to see what happens after bringing down a router and then bringing it back up. To simulate bringing down a router, deactivate the loopback interface on Logical System B. •

From configuration mode, enter the deactivate logical-systems B interfaces lo0 unit 2 family inet command. user@host# deactivate logical-systems B interfaces lo0 unit 2 family inet user@host# commit

•

From operational mode, enter the file show /var/log/A/bgp-bfd command. user@host:A> file show /var/log/A/bgp-bfd


1251


... Aug 15 17:20:55.995648 bgp_read_v4_message:9747: NOTIFICATION received from 192.163.6.4 (Internal AS 17): code 6 (Cease) subcode 6 (Other Configuration Change) Aug 15 17:20:56.004508 Terminated BFD session to peer 192.163.6.4 (Internal AS 17) Aug 15 17:21:28.007755 task_connect: task BGP_17.192.163.6.4+179 addr 192.163.6.4+179: No route to host Aug 15 17:21:28.008597 bgp_connect_start: connect 192.163.6.4 (Internal AS 17): No route to host •

From configuration mode, enter the activate logical-systems B interfaces lo0 unit 2 family inet command. user@host:A# activate logical-systems B interfaces lo0 unit 2 family inet user@host:A# commit

•

From operational mode, enter the file show /var/log/A/bgp-bfd command. user@host:A> file show /var/log/A/bgp-bfd ... Aug 15 17:25:53.623743 advertising receiving-speaker only capabilty to neighbor 192.163.6.4 (Internal AS 17) Aug 15 17:25:53.631314 Initiated BFD session to peer 192.163.6.4 (Internal AS 17): address=192.163.6.4 ifindex=0 ifname=(none) txivl=1000 rxivl=1000 mult=3 ver=255 Aug 15 17:25:57.570932 BFD session to peer 192.163.6.4 (Internal AS 17) up


•


•


Example: Configuring BFD Authentication for BGP •

Understanding BFD Authentication for BGP on page 1252

•


Understanding BFD Authentication for BGP Bidirectional Forwarding Detection protocol (BFD) enables rapid detection of communication failures between adjacent systems. By default, authentication for BFD sessions is disabled. However, when you run BFD over Network Layer protocols, the risk of service attacks can be significant. We strongly recommend using authentication if you are running BFD over multiple hops or through insecure tunnels. Beginning with Junos OS Release 9.6, Junos OS supports authentication for BFD sessions running over BGP. BFD authentication is not supported on MPLS OAM sessions. BFD authentication is only supported in the domestic image and is not available in the export image. You authenticate BFD sessions by specifying an authentication algorithm and keychain, and then associating that configuration information with a security authentication keychain using the keychain name.

1252



The following sections describe the supported authentication algorithms, security keychains, and level of authentication that can be configured: •


•


•




authenticate the BFD session. One or more passwords can be configured. This method is the least secure and should be used only when BFD sessions are not subject to packet interception. •




method works in the same manner as keyed MD5, but the sequence number is updated with every packet. Although more secure than keyed MD5 and simple passwords, this method might take additional time to authenticate the session. •




works in the same manner as keyed SHA, but the sequence number is updated with every packet. Although more secure than keyed SHA and simple passwords, this method might take additional time to authenticate the session.



1253



Strict Versus Loose Authentication By default, strict authentication is enabled and authentication is checked at both ends of each BFD session. Optionally, to smooth migration from nonauthenticated sessions to authenticated sessions, you can configure loose checking. When loose checking is configured, packets are accepted without authentication being checked at each end of the session. This feature is intended for transitional periods only.

Example: Configuring BFD Authentication for BGP Beginning with Junos OS Release 9.6, you can configure authentication for BFD sessions running over BGP. Only three steps are needed to configure authentication on a BFD session: 1.

Specify the BFD authentication algorithm for the BGP protocol.

2. Associate the authentication keychain with the BGP protocol. 3. Configure the related security authentication keychain.

The following sections provide instructions for configuring and viewing BFD authentication on BGP: •


•


Configuring BFD Authentication Parameters BFD authentication can be configured for the entire BGP protocol, or a specific BGP group, neighbor, or routing instance.

1254



The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure BFD authentication: 1.

Specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use. [edit] user@host# set protocols bgp bfd-liveness-detection authentication algorithm keyed-sha-1 user@host# set protocols bgp group bgp-gr1 bfd-liveness-detection authentication algorithm keyed-sha-1 user@host# set protocols bgp group bgp-gr1 neighbor 10.10.10.7 bfd-liveness-detection authentication algorithm keyed-sha-1

NOTE: Nonstop active routing is not supported with meticulous-keyed-md5 and meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms might go down after a switchover.

2. Specify the keychain to be used to associate BFD sessions on BGP with the unique

security authentication keychain attributes. The keychain name you specify must match a keychain name configured at the [edit security authentication key-chains] hierarchy level. [edit] user@host# set protocols bgp bfd-liveness-detection authentication keychain bfd-bgp user@host# set protocols bgp group bgp-gr1 bfd-liveness-detection authentication keychain bfd-bgp user@host# set protocols bgp group bgp-gr1 neighbor 10.10.10.7 bfd-liveness-detection authentication keychain bfd-bgp



The matching key-chain-name as specified in Step 2.

•


•


•

The time at which the authentication key becomes active, yyyy-mm-dd.hh:mm:ss. [edit security]


1255


user@host# set authentication-key-chains key-chain bfd-bgp key 53 secret $9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm start-time 2009-06-14.10:00:00 4. (Optional) Specify loose authentication checking if you are transitioning from

nonauthenticated sessions to authenticated sessions. [edit] user@host# set protocols bgp bfd-liveness-detection authentication loose-check user@host# set protocols bgp group bgp-gr1 bfd-liveness-detection authentication loose-check user@host# set protocols bgp group bgp-gr1 neighbor 10.10.10.7 bfd-liveness-detection authentication loose-check 5. (Optional) View your configuration using the show bfd session detail or show bfd



Viewing Authentication Information for BFD Sessions You can view the existing BFD authentication configuration using the show bfd session detail and show bfd session extensive commands. The following example shows BFD authentication configured for the bgp-gr1 BGP group. It specifies the keyed SHA-1 authentication algorithm and a keychain name of bfd-bgp. The authentication keychain is configured with two keys. Key 1 contains the secret data “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm” and a start time of June 1, 2009, at 9:46:02 AM PST. Key 2 contains the secret data “$9$a5jiKW9l.reP38ny.TszF2/9” and a start time of June 1, 2009, at 3:29:20 PM PST. [edit protocols bgp] group bgp-gr1 { bfd-liveness-detection { authentication { algorithm keyed-sha-1; key-chain bfd-bgp; } } } [edit security] authentication key-chains { key-chain bfd-bgp { key 1 { secret “$9$ggaJDmPQ6/tJgF/AtREVsyPsnCtUHm”; start-time “2009-6-1.09:46:02 -0700”; } key 2 { secret “$9$a5jiKW9l.reP38ny.TszF2/9”; start-time “2009-6-1.15:29:20 -0700”; } }

1256



}

If you commit these updates to your configuration, you see output similar to the following. In the output for the show bfd sessions detail command, Authenticate is displayed to indicate that BFD authentication is configured. For more information about the configuration, use the show bfd sessions extensive command. The output for this command provides the keychain name, the authentication algorithm and mode for each client in the session, and the overall BFD authentication configuration status, keychain name, and authentication algorithm and mode. show bfd session detail

user@host# show bfd session detail Detect Transmit Address State Interface Time Interval 50.0.0.2 Up ge-0/1/5.0 0.900 0.300 Client BGP, TX interval 0.300, RX interval 0.300, Authenticate Session up time 3d 00:34 Local diagnostic None, remote diagnostic NbrSignal Remote state Up, version 1 Replicated



Multiplier 3

user@host# show bfd session extensive Detect Transmit Address State Interface Time Interval Multiplier 50.0.0.2 Up ge-0/1/5.0 0.900 0.300 3 Client BGP, TX interval 0.300, RX interval 0.300, Authenticate keychain bfd-bgp, algo keyed-sha-1, mode strict Session up time 00:04:42 Local diagnostic None, remote diagnostic NbrSignal Remote state Up, version 1 Replicated Min async interval 0.300, min slow interval 1.000 Adaptive async TX interval 0.300, RX interval 0.300 Local min TX interval 0.300, minimum RX interval 0.300, multiplier 3 Remote min TX interval 0.300, min RX interval 0.300, multiplier 3 Local discriminator 2, remote discriminator 2 Echo mode disabled/inactive Authentication enabled/active, keychain bfd-bgp, algo keyed-sha-1, mode strict

•


•


Example: Advertising Multiple BGP Paths to a Destination •

Understanding the Advertisement of Multiple Paths to a Single Destination in BGP on page 1257

•


Understanding the Advertisement of Multiple Paths to a Single Destination in BGP BGP peers advertise routes to each other in update messages. BGP stores its routes in the Junos OS routing table (inet.0). For each prefix in the routing table, the routing protocol process selects a single best path, called the active path. Unless you configure BGP to advertise multiple paths to the same destination, BGP advertises only the active path.


1257


Instead of advertising only the active path to a destination, you can configure BGP to advertise multiple paths to the destination. Within an autonomous system (AS), the availability of multiple exit points to reach a destination provides the following benefits: •

Fault tolerance—Path diversity leads to reduction in restoration time after failure. For instance, a border router after receiving multiple paths to the same destination can precompute a backup path and have it ready so that when the primary path becomes invalid, the border router can use the backup to quickly restore connectivity. Without a backup path, the restoration time depends on BGP reconvergence, which includes withdraw and advertisement messages in the network before a new best path can be learned.

•

Load balancing—The availability of multiple paths to reach the same destination enables load balancing of traffic, if the routing within the AS meets certain constraints.

•

Maintenance—The availability of alternate exit points allows for graceful maintenance operation of routers.

The following limitations apply to advertising multiple routes in BGP: •

IPv4 unicast (family inet unicast) routes only.

•

Internal BGP (IBGP) peers only. No support on external BGP (EBGP) peers.

•

Master instance only. No support for routing instances.

•

No support for nonstop active routing (NSR).

•

No BGP Monitoring Protocol (BMP) support.

•

No support for EBGP sessions between confederations.

•

Prefix policies enable you to filter routes on a router that is configured to advertise multiple paths to a destination. However, prefix policies can only match routes. Prefix policies cannot change the attributes of routes.

Example: Advertising Multiple Paths in BGP In this example, BGP routers are configured to advertise multiple paths instead of advertising only the active path. Advertising multiple paths in BGP is specified in Internet draft draft-ietf-idr-add-paths-04.txt, Advertisement of Multiple Paths in BGP. •


•


•


•


Requirements This example uses the following hardware and software components:

1258

•

Eight BGP-speaking devices.

•

Five of the BGP-enabled devices do not necessarily need to be routers. For example, they can be EX Series Ethernet Switches.



•

Three of the BGP-enabled devices are configured to send multiple paths or receive multiple paths (or both send and receive multiple paths). These three BGP-enabled devices must be M Series Multiservice Edge Routers, MX Series 3D Universal Edge Routers, or T Series Core Routers.

•

The three routers must be running Junos OS Release 11.4 or later.

Overview In this example, Router R5, Router R6, and Router R7 redistribute static routes into BGP. Router R1 and Router R4 are route reflectors. Router R2 and Router R3 are clients to Route Reflector R1. Router R8 is a client to Route Reflector R4. Route reflection is optional when multiple-path advertisement is enabled in BGP. With the add-path send path-count 6 configuration, Router R1 is configured to send up to six paths (per destination) to Router R4. With the add-path receive configuration, Router R4 is configured to receive multiple paths from Router R1. With the add-path send path-count 6 configuration, Router R4 is also configured to send up to six paths to Router R8. With the add-path receive configuration, Router R8 is configured to receive multiple paths from Router R4. The add-path send prefix-policy allow_199 policy configuration (along with the corresponding route filter) limits Router R4 to sending multiple paths for only the 199.1.1.1/32 route. Topology Diagram Figure 73 on page 1259 shows the topology used in this example.

Figure 73: Advertisement of Multiple Paths in BGP R6

EBGP

R2 IBGP Route Reflector 2

R7

EBGP

R3

IBGP

R1

R4

R8

Route Reflector 1

R5


g040706

EBGP

1259


Configuration


1260

•

Configuring Router R1 on page 1262

•


•


•


•


•


•


•



Router R1

set interfaces fe-0/0/0 unit 12 family inet address 10.0.12.1/24 set interfaces fe-0/0/1 unit 13 family inet address 10.0.13.1/24 set interfaces fe-1/0/0 unit 14 family inet address 10.0.14.1/24 set interfaces fe-1/2/0 unit 15 family inet address 10.0.15.1/24 set interfaces lo0 unit 10 family inet address 10.0.0.10/32 set protocols bgp group rr type internal set protocols bgp group rr local-address 10.0.0.10 set protocols bgp group rr cluster 10.0.0.10 set protocols bgp group rr neighbor 10.0.0.20 set protocols bgp group rr neighbor 10.0.0.30 set protocols bgp group e1 type external set protocols bgp group e1 neighbor 10.0.15.2 local-address 10.0.15.1 set protocols bgp group e1 neighbor 10.0.15.2 peer-as 2 set protocols bgp group rr_rr type internal set protocols bgp group rr_rr local-address 10.0.0.10 set protocols bgp group rr_rr neighbor 10.0.0.40 family inet unicast add-path send path-count 6 set protocols ospf area 0.0.0.0 interface lo0.10 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.12 set protocols ospf area 0.0.0.0 interface fe-0/0/1.13 set protocols ospf area 0.0.0.0 interface fe-1/0/0.14 set protocols ospf area 0.0.0.0 interface fe-1/2/0.15 set routing-options router-id 10.0.0.10 set routing-options autonomous-system 1

Router R2

set interfaces fe-1/2/0 unit 21 family inet address 10.0.12.2/24 set interfaces fe-1/2/1 unit 26 family inet address 10.0.26.1/24 set interfaces lo0 unit 20 family inet address 10.0.0.20/32 set protocols bgp group rr type internal set protocols bgp group rr local-address 10.0.0.20 set protocols bgp group rr neighbor 10.0.0.10 export set_nh_self set protocols bgp group e1 type external set protocols bgp group e1 neighbor 10.0.26.2 peer-as 2 set protocols ospf area 0.0.0.0 interface lo0.20 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.21 set protocols ospf area 0.0.0.0 interface fe-1/2/1.28



set policy-options policy-statement set_nh_self then next-hop self set routing-options autonomous-system 1

Router R3

set interfaces fe-1/0/1 unit 31 family inet address 10.0.13.2/24 set interfaces fe-1/0/2 unit 37 family inet address 10.0.37.1/24 set interfaces lo0 unit 30 family inet address 10.0.0.30/32 set protocols bgp group rr type internal set protocols bgp group rr local-address 10.0.0.30 set protocols bgp group rr neighbor 10.0.0.10 export set_nh_self set protocols bgp group e1 type external set protocols bgp group e1 neighbor 10.0.37.2 peer-as 2 set protocols ospf area 0.0.0.0 interface lo0.30 passive set protocols ospf area 0.0.0.0 interface fe-1/0/1.31 set protocols ospf area 0.0.0.0 interface fe-1/0/2.37 set policy-options policy-statement set_nh_self then next-hop self set routing-options autonomous-system 1

Router R4

set interfaces fe-1/2/0 unit 41 family inet address 10.0.14.2/24 set interfaces fe-1/2/1 unit 48 family inet address 10.0.48.1/24 set interfaces lo0 unit 40 family inet address 10.0.0.40/32 set protocols bgp group rr type internal set protocols bgp group rr local-address 10.0.0.40 set protocols bgp group rr family inet unicast add-path receive set protocols bgp group rr neighbor 10.0.0.10 set protocols bgp group rr_client type internal set protocols bgp group rr_client local-address 10.0.0.40 set protocols bgp group rr_client cluster 10.0.0.40 set protocols bgp group rr_client neighbor 10.0.0.80 family inet unicast add-path send path-count 6 set protocols bgp group rr_client neighbor 10.0.0.80 family inet unicast add-path send prefix-policy allow_199 set protocols ospf area 0.0.0.0 interface fe-1/2/0.41 set protocols ospf area 0.0.0.0 interface lo0.40 passive set protocols ospf area 0.0.0.0 interface fe-1/2/1.48 set routing-options autonomous-system 1 set policy-options policy-statement allow_199 from route-filter 199.1.1.1/32 exact set policy-options policy-statement allow_199 then accept

Router R5

set interfaces fe-1/2/0 unit 51 family inet address 10.0.15.2/24 set interfaces lo0 unit 50 family inet address 10.0.0.50/32 set protocols bgp group e1 type external set protocols bgp group e1 neighbor 10.0.15.1 export s2b set protocols bgp group e1 neighbor 10.0.15.1 peer-as 1 set policy-options policy-statement s2b from protocol static set policy-options policy-statement s2b from protocol direct set policy-options policy-statement s2b then as-path-expand 2 set policy-options policy-statement s2b then accept set routing-options autonomous-system 2 set routing-options static route 199.1.1.1/32 reject set routing-options static route 198.1.1.1/32 reject

Router R6

set interfaces fe-1/2/0 unit 62 family inet address 10.0.26.2/24 set interfaces lo0 unit 60 family inet address 10.0.0.60/32 set protocols bgp group e1 type external set protocols bgp group e1 neighbor 10.0.26.1 export s2b


1261


set protocols bgp group e1 neighbor 10.0.26.1 peer-as 1 set policy-options policy-statement s2b from protocol static set policy-options policy-statement s2b from protocol direct set policy-options policy-statement s2b then accept set routing-options autonomous-system 2 set routing-options static route 199.1.1.1/32 reject set routing-options static route 198.1.1.1/32 reject

Router R7

set interfaces fe-1/2/0 unit 73 family inet address 10.0.37.2/24 set interfaces lo0 unit 70 family inet address 10.0.0.70/32 set policy-options policy-statement s2b from protocol static set policy-options policy-statement s2b from protocol direct set policy-options policy-statement s2b then accept set protocols bgp group e1 type external set protocols bgp group e1 neighbor 10.0.37.1 export s2b set protocols bgp group e1 neighbor 10.0.37.1 peer-as 1 set routing-options autonomous-system 2 set routing-options static route 199.1.1.1/32 reject

Router R8

set interfaces fe-1/2/0 unit 84 family inet address 10.0.48.2/24 set interfaces lo0 unit 80 family inet address 10.0.0.80/32 set protocols bgp group rr type internal set protocols bgp group rr local-address 10.0.0.80 set protocols bgp group rr neighbor 10.0.0.40 family inet unicast add-path receive set protocols ospf area 0.0.0.0 interface lo0.80 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.84 set routing-options autonomous-system 1

Configuring Router R1 Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure Router R1: 1.

Configure the interfaces to Router R2, Router R3, Router R5, and Router R4, and configure the loopback (lo0) interface. [edit interfaces] user@R1# set fe-0/0/0 unit 12 family inet address 10.0.12.1/24 user@R1# set fe-0/0/1 unit 13 family inet address 10.0.13.1/24 user@R1# set fe-1/0/0 unit 14 family inet address 10.0.14.1/24 user@R1# set fe-1/2/0 unit 15 family inet address 10.0.15.1/24 user@R1#set lo0 unit 10 family inet address 10.0.0.10/32

2.

Configure BGP on the interfaces, and configure IBGP route reflection. [edit protocols bgp] user@R1# set group rr type internal user@R1# set group rr local-address 10.0.0.10

1262



user@R1# set group rr cluster 10.0.0.10 user@R1# set group rr neighbor 10.0.0.20 user@R1# set group rr neighbor 10.0.0.30 user@R1# set group rr_rr type internal user@R1# set group rr_rr local-address 10.0.0.10 user@R1# set group e1 type external user@R1# set group e1 neighbor 10.0.15.2 local-address 10.0.15.1 user@R1# set group e1 neighbor 10.0.15.2 peer-as 2 3.

Configure Router R1 to send up to six paths to its neighbor, Router R4. The destination of the paths can be any destination that Router R1 can reach through multiple paths. [edit protocols bgp] user@R1# set group rr_rr neighbor 10.0.0.40 family inet unicast add-path send path-count 6

4.

Configure OSPF on the interfaces. [edit protocols ospf] user@R1# set area 0.0.0.0 interface lo0.10 passive user@R1# set area 0.0.0.0 interface fe-0/0/0.12 user@R1# set area 0.0.0.0 interface fe-0/0/1.13 user@R1# set area 0.0.0.0 interface fe-1/0/0.14 user@R1# set area 0.0.0.0 interface fe-1/2/0.15

5.

Configure the router ID and the autonomous system number. [edit routing-options] user@R1# set router-id 10.0.0.10 user@R1# set autonomous-system 1

6.

If you are done configuring the device, commit the configuration. user@R1# commit

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R1# show interfaces fe-0/0/0 { unit 12 { family inet { address 10.0.12.1/24; } } } fe-0/0/1 { unit 13 { family inet { address 10.0.13.1/24; } }


1263


} fe-1/0/0 { unit 14 { family inet { address 10.0.14.1/24; } } } fe-1/2/0 { unit 15 { family inet { address 10.0.15.1/24; } } } lo0 { unit 10 { family inet { address 10.0.0.10/32; } } } user@R1# show protocols bgp { group rr { type internal; local-address 10.0.0.10; cluster 10.0.0.10; neighbor 10.0.0.20; neighbor 10.0.0.30; } group e1 { type external; neighbor 10.0.15.2 { local-address 10.0.15.1; peer-as 2; } } group rr_rr { type internal; local-address 10.0.0.10; neighbor 10.0.0.40 { family inet { unicast { add-path { send { path-count 6; } } } } } } } ospf {

1264



area 0.0.0.0 { interface lo0.10 { passive; } interface fe-0/0/0.12; interface fe-0/0/1.13; interface fe-1/0/0.14; interface fe-1/2/0.15; } } user@R1# show routing-options router-id 10.0.0.10; autonomous-system 1;


To configure Router R2: 1.

Configure the loopback (lo0) interface and the interfaces to Router R6 and Router R1. [edit interfaces] user@R2# set fe-1/2/0 unit 21 family inet address 10.0.12.2/24 user@R2# set fe-1/2/1 unit 26 family inet address 10.0.26.1/24 user@R2# set lo0 unit 20 family inet address 10.0.0.20/32

2.

Configure BGP and OSPF on Router R2’s interfaces. [edit protocols] user@R2# set bgp group rr type internal user@R2# set bgp group rr local-address 10.0.0.20 user@R2# set bgp group e1 type external user@R2# set bgp group e1 neighbor 10.0.26.2 peer-as 2 user@R2# set ospf area 0.0.0.0 interface lo0.20 passive user@R2# set ospf area 0.0.0.0 interface fe-1/2/0.21 user@R2# set ospf area 0.0.0.0 interface fe-1/2/1.28

3.

For routes sent from Router R2 to Router R1, advertise Router R2 as the next hop, because Router R1 does not have a route to Router R6’s address on the 10.0.26.0/24 network. [edit] user@R2# set policy-options policy-statement set_nh_self then next-hop self user@R2# set protocols bgp group rr neighbor 10.0.0.10 export set_nh_self

4.

Configure the autonomous system number. [edit] user@R2# set routing-options autonomous-system 1


1265


5.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R2# show interfaces fe-1/2/0 { unit 21 { family inet { address 10.0.12.2/24; } } } fe-1/2/1 { unit 26 { family inet { address 10.0.26.1/24; } } } lo0 { unit 20 { family inet { address 10.0.0.20/32; } } } user@R2# show policy-options policy-statement set_nh_self { then { next-hop self; } } user@R2# show protocols bgp { group rr { type internal; local-address 10.0.0.20; neighbor 10.0.0.10 { export set_nh_self; } } group e1 { type external; neighbor 10.0.26.2 { peer-as 2; } } } ospf {

1266



area 0.0.0.0 { interface lo0.20 { passive; } interface fe-1/2/0.21; interface fe-1/2/1.28; } } user@R2# show routing-options autonomous-system 1;



Configure the loopback (lo0) interface and the interfaces to Router R7 and Router R1. [edit interfaces] user@R3# set fe-1/0/1 unit 31 family inet address 10.0.13.2/24 user@R3# set fe-1/0/2 unit 37 family inet address 10.0.37.1/24 user@R3# set lo0 unit 30 family inet address 10.0.0.30/32

2.

Configure BGP and OSPF on Router R3’s interfaces. [edit protocols] user@R3# set bgp group rr type internal user@R3# set bgp group rr local-address 10.0.0.30 user@R3# set bgp group e1 type external user@R3# set bgp group e1 neighbor 10.0.37.2 peer-as 2 user@R3# set ospf area 0.0.0.0 interface lo0.30 passive user@R3# set ospf area 0.0.0.0 interface fe-1/0/1.31 user@R3# set ospf area 0.0.0.0 interface fe-1/0/2.37

3.

For routes sent from Router R3 to Router R1, advertise Router R3 as the next hop, because Router R1 does not have a route to Router R7’s address on the 10.0.37.0/24 network. [edit] user@R3# set policy-options policy-statement set_nh_self then next-hop self user@R3# set protocols bgp group rr neighbor 10.0.0.10 export set_nh_self

4.


5.



1267


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R3# show interfaces fe-1/0/1 { unit 31 { family inet { address 10.0.13.2/24; } } } fe-1/0/2 { unit 37 { family inet { address 10.0.37.1/24; } } } lo0 { unit 30 { family inet { address 10.0.0.30/32; } } } user@R3# show policy-options policy-statement set_nh_self { then { next-hop self; } } user@R3# show protocols bgp { group rr { type internal; local-address 10.0.0.30; neighbor 10.0.0.10 { export set_nh_self; } } group e1 { type external; neighbor 10.0.37.2 { peer-as 2; } } } ospf { area 0.0.0.0 { interface lo0.30 { passive; }

1268



interface fe-1/0/1.31; interface fe-1/0/2.37; } } user@R3# show routing-options autonomous-system 1;



Configure the interfaces to Router R1 and Router R8, and configure the loopback (lo0) interface. [edit interfaces] user@R4# set fe-1/2/0 unit 41 family inet address 10.0.14.2/24 user@R4# set fe-1/2/1 unit 48 family inet address 10.0.48.1/24 user@R4# set lo0 unit 40 family inet address 10.0.0.40/32

2.

Configure BGP on the interfaces, and configure IBGP route reflection. [edit protocols bgp] user@R4# set group rr type internal user@R4# set group rr local-address 10.0.0.40 user@R4# set group rr neighbor 10.0.0.10 user@R4# set group rr_client type internal user@R4# set group rr_client local-address 10.0.0.40 user@R4# set group rr_client cluster 10.0.0.40

3.

Configure Router R4 to send up to six paths to its neighbor, Router R8. The destination of the paths can be any destination that Router R4 can reach through multiple paths. [edit protocols bgp] user@R4# set group rr_client neighbor 10.0.0.80 family inet unicast add-path send path-count 6

4.

Configure Router R4 to receive multiple paths from its neighbor, Router R1. The destination of the paths can be any destination that Router R1 can reach through multiple paths. [edit protocols bgp] user@R4# set group rr family inet unicast add-path receive

5.

Configure OSPF on the interfaces. [edit protocols ospf] user@R4# set area 0.0.0.0 interface fe-1/2/0.41 user@R4# set area 0.0.0.0 interface lo0.40 passive user@R4# set area 0.0.0.0 interface fe-1/2/1.48


1269


6.

Configure a policy that allows Router R4 to send Router R8 multiple paths to the 199.1.1.1/32 route. Router R4 receives multiple paths for the 198.1.1.1/32 route and the 199.1.1.1/32 route. However, because of this policy, Router R4 only sends multiple paths for the 199.1.1.1/32 route. [edit] user@R4# set protocols bgp group rr_client neighbor 10.0.0.80 family inet unicast add-path send prefix-policy allow_199 user@R4# set policy-options policy-statement allow_199 from route-filter 199.1.1.1/32 exact user@R4# set policy-options policy-statement allow_199 then accept

7.

Configure the autonomous system number. [edit routing-options] user@R4# set autonomous-system 1

8.


Results

From configuration mode, confirm your configuration by entering the show interfaces, policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R4# show interfaces fe-1/2/0 { unit 41 { family inet { address 10.0.14.2/24; } } } fe-1/2/1 { unit 48 { family inet { address 10.0.48.1/24; } } } lo0 { unit 40 { family inet { address 10.0.0.40/32; } } } user@R4# show policy-options policy-statement allow_199 { from { route-filter 199.1.1.1/32 exact; } then accept;

1270



} user@R4# show protocols bgp { group rr { type internal; local-address 10.0.0.40; family inet { unicast { add-path { receive; } } } neighbor 10.0.0.10; } group rr_client { type internal; local-address 10.0.0.40; cluster 10.0.0.40; neighbor 10.0.0.80 { family inet { unicast { add-path { send { path-count 6; prefix-policy allow_199; } } } } } } } ospf { area 0.0.0.0 { interface lo0.40 { passive; } interface fe-1/2/0.41; interface fe-1/2/1.48; } } user@R4# show routing-options autonomous-system 1;



Configure the loopback (lo0) interface and the interface to Router R1. [edit interfaces] user@R5# set fe-1/2/0 unit 51 family inet address 10.0.15.2/24 user@R5# set lo0 unit 50 family inet address 10.0.0.50/32


1271


2.

Configure BGP on Router R5’s interface. [edit protocols] user@R5# set bgp group e1 type external user@R5# set bgp group e1 neighbor 10.0.15.1 peer-as 1

3.

Create static routes for redistribution into BGP. [edit] user@R5# set routing-options static route 199.1.1.1/32 reject user@R5# set routing-options static route 198.1.1.1/32 reject

4.

Redistribute static and direct routes into BGP. [edit] user@R5# set protocols bgp group e1 neighbor 10.0.15.1 export s2b user@R5# set policy-options policy-statement s2b from protocol static user@R5# set policy-options policy-statement s2b from protocol direct user@R5# set policy-options policy-statement s2b then as-path-expand 2 user@R5# set policy-options policy-statement s2b then accept

5.


6.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R5# show interfaces fe-1/2/0 { unit 51 { family inet { address 10.0.15.2/24; } } } lo0 { unit 50 { family inet { address 10.0.0.50/32; } } } user@R5# show policy-options policy-statement s2b { from protocol [ static direct ]; then { as-path-expand 2; accept; }

1272



} user@R5# show protocols bgp { group e1 { type external; neighbor 10.0.15.1 { export s2b; peer-as 1; } } } user@R5# show routing-options static { route 198.1.1.1/32 reject; route 199.1.1.1/32 reject; } autonomous-system 2;




2.


3.

Create static routes for redistribution into BGP. [edit] user@R6# set routing-options static route 199.1.1.1/32 reject user@R6# set routing-options static route 198.1.1.1/32 reject

4.

Redistribute static and direct routes from Router R6’s routing table into BGP. [edit] user@R6# set protocols bgp group e1 neighbor 10.0.26.1 export s2b user@R6# set policy-options policy-statement s2b from protocol static user@R6# set policy-options policy-statement s2b from protocol direct user@R6# set policy-options policy-statement s2b then accept

5.


6.



1273


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R6# show interfaces fe-1/2/0 { unit 62 { family inet { address 10.0.26.2/24; } } } lo0 { unit 60 { family inet { address 10.0.0.60/32; } } } user@R6# show policy-options policy-statement s2b { from protocol [ static direct ]; then accept; } user@R6# show protocols bgp { group e1 { type external; neighbor 10.0.26.1 { export s2b; peer-as 1; } } } user@R6# show routing-options static { route 198.1.1.1/32 reject; route 199.1.1.1/32 reject; } autonomous-system 2;




1274



2.


3.

Create a static route for redistribution into BGP. [edit] user@R7# set routing-options static route 199.1.1.1/32 reject

4.

Redistribute static and direct routes from Router R7’s routing table into BGP. [edit] user@R7# set protocols bgp group e1 neighbor 10.0.37.1 export s2b user@R7# set policy-options policy-statement s2b from protocol static user@R7# set policy-options policy-statement s2b from protocol direct user@R7# set policy-options policy-statement s2b then accept

5.


6.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R7# show interfaces fe-1/2/0 { unit 73 { family inet { address 10.0.37.2/24; } } } lo0 { unit 70 { family inet { address 10.0.0.70/32; } } } user@R7# show policy-options policy-statement s2b { from protocol [ static direct ]; then accept; } user@R7# show protocols bgp { group e1 {


1275


type external; neighbor 10.0.37.1 { export s2b; peer-as 1; } } } user@R7# show routing-options static { route 199.1.1.1/32 reject; } autonomous-system 2;




2.

Configure BGP and OSPF on Router R8’s interface. [edit protocols] user@R8# set bgp group rr type internal user@R8# set bgp group rr local-address 10.0.0.80 user@R8# set ospf area 0.0.0.0 interface lo0.80 passive user@R8# set ospf area 0.0.0.0 interface fe-1/2/0.84

3.

Configure Router R8 to receive multiple paths from its neighbor, Router R4. The destination of the paths can be any destination that Router R4 can reach through multiple paths. [edit protocols] user@R8# set bgp group rr neighbor 10.0.0.40 family inet unicast add-path receive

4.


5.


Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@R8# show interfaces fe-1/2/0 {

1276



unit 84 { family inet { address 10.0.48.2/24; } } } lo0 { unit 80 { family inet { address 10.0.0.80/32; } } } user@R8# show protocols bgp { group rr { type internal; local-address 10.0.0.80; neighbor 10.0.0.40 { family inet { unicast { add-path { receive; } } } } } } ospf { area 0.0.0.0 { interface lo0.80 { passive; } interface fe-1/2/0.84; } } user@R8# show routing-options autonomous-system 1;

Verification •

Verifying That the BGP Peers Have the Ability to Send and Receive Multiple Paths on page 1278

•

Verifying That Router R1 Is Advertising Multiple Paths on page 1278

•

Verifying That Router R4 Is Receiving and Advertising Multiple Paths on page 1279

•

Verifying That Router R8 Is Receiving Multiple Paths on page 1279

•

Checking the Path ID on page 1280


1277


Verifying That the BGP Peers Have the Ability to Send and Receive Multiple Paths Purpose

Action

Make sure that one or both of the following strings appear in the output of the show bgp neighbor command: •

NLRI's for which peer can receive multiple paths: inet-unicast

•

NLRI's for which peer can send multiple paths: inet-unicast

user@R1> show bgp neighbor 10.0.0.40 Peer: 10.0.0.40+179 AS 1 Local: 10.0.0.10+65237 AS 1 Type: Internal State: Established Flags: ... NLRI's for which peer can receive multiple paths: inet-unicast ... user@R4> show bgp neighbor 10.0.0.10 Peer: 10.0.0.10+65237 AS 1 Local: 10.0.0.40+179 AS 1 Type: Internal State: Established Flags: ... NLRI's for which peer can send multiple paths: inet-unicast ... user@R4> show bgp neighbor 10.0.0.80 Peer: 10.0.0.80+55416 AS 1 Local: 10.0.0.40+179 AS 1 Type: Internal State: Established (route reflector client)Flags: ,,, NLRI's for which peer can receive multiple paths: inet-unicast ... user@R8> show bgp neighbor 10.0.0.40 Peer: 10.0.0.40+179 AS 1 Local: 10.0.0.80+55416 AS 1 Type: Internal State: Established Flags: ... NLRI's for which peer can send multiple paths: inet-unicast ...

Verifying That Router R1 Is Advertising Multiple Paths Purpose

Action

Meaning

1278

Make sure that multiple paths to the 198.1.1.1/32 destination and multiple paths to the 199.1.1.1/32 destination are advertised to Router R4. user@R1> show route advertising-protocol bgp 10.0.0.40 inet.0: 21 destinations, 25 routes (21 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.50/32 10.0.15.2 100 2 2 I * 10.0.0.60/32 10.0.0.20 100 2 I * 10.0.0.70/32 10.0.0.30 100 2 I * 198.1.1.1/32 10.0.0.20 100 2 I 10.0.15.2 100 2 2 I * 199.1.1.1/32 10.0.0.20 100 2 I 10.0.0.30 100 2 I 10.0.15.2 100 2 2 I * 200.1.1.0/30 10.0.0.20 100 2 I

When you see one prefix and more than one next hop, it means that multiple paths are advertised to Router R4.



Verifying That Router R4 Is Receiving and Advertising Multiple Paths Purpose

Action

Make sure that multiple paths to the 199.1.1.1/32 destination are received from Router R1 and advertised to Router R8. Make sure that multiple paths to the 198.1.1.1/32 destination are received from Router R1, but only one path to this destination is advertised to Router R8. user@R4> show route receive-protocol bgp 10.0.0.10 inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.50/32 10.0.15.2 100 2 2 I * 10.0.0.60/32 10.0.0.20 100 2 I * 10.0.0.70/32 10.0.0.30 100 2 I * 198.1.1.1/32 10.0.0.20 100 2 I 10.0.15.2 100 2 2 I * 199.1.1.1/32 10.0.0.20 100 2 I 10.0.0.30 100 2 I 10.0.15.2 100 2 2 I * 200.1.1.0/30 10.0.0.20 100 2 I

user@R4> show route advertising-protocol bgp 10.0.0.80 inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.50/32 10.0.15.2 100 2 2 I * 10.0.0.60/32 10.0.0.20 100 2 I * 10.0.0.70/32 10.0.0.30 100 2 I * 198.1.1.1/32 10.0.0.20 100 2 I * 199.1.1.1/32 10.0.0.20 100 2 I 10.0.0.30 100 2 I 10.0.15.2 100 2 2 I * 200.1.1.0/30 10.0.0.20 100 2 I

Meaning

The show route receive-protocol command shows that Router R4 receives two paths to the 198.1.1.1/32 destination and three paths to the 199.1.1.1/32 destination. The show route advertising-protocol command shows that Router R4 advertises only one path to the 198.1.1.1/32 destination and advertises all three paths to the 199.1.1.1/32 destination. Because of the prefix-policy that is applied to Router R4, Router R4 does not advertise multiple paths to the 198.1.1.1/32 destination. Router R4 advertises only one path to the 198.1.1.1/32 destination even though it receives multiple paths to this destination. Verifying That Router R8 Is Receiving Multiple Paths

Purpose

Action

Make sure that Router R8 receives multiple paths to the 199.1.1.1/32 destination through Router R4. Make sure that Router R8 receives only one path to the 198.1.1.1/32 destination through Router R4. user@R8> show route receive-protocol bgp 10.0.0.40 inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.50/32 10.0.15.2 100 2 2 I * 10.0.0.60/32 10.0.0.20 100 2 I * 10.0.0.70/32 10.0.0.30 100 2 I


1279


* 198.1.1.1/32 * 199.1.1.1/32

* 200.1.1.0/30

10.0.0.20 10.0.0.20 10.0.0.30 10.0.15.2 10.0.0.20

100 100 100 100 100

2 2 2 2 2

I I I 2 I I

Checking the Path ID Purpose

Action

On the downstream devices, Router R4 and Router R8, verify that a path ID uniquely identifies the path. Look for the Addpath Path ID: string. user@R4> show route 199.1.1.1/32 detail inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) 199.1.1.1/32 (3 entries, 3 announced) *BGP Preference: 170/-101 Next hop type: Indirect Next-hop reference count: 9 Source: 10.0.0.10 Next hop type: Router, Next hop index: 676 Next hop: 10.0.14.1 via lt-1/2/0.41, selected Protocol next hop: 10.0.0.20 Indirect next hop: 92041c8 262146 State: Local AS: 1 Peer AS: 1 Age: 1:44:37 Metric2: 2 Task: BGP_1.10.0.0.10+65237 Announcement bits (3): 2-KRT 3-BGP RT Background 4-Resolve tree 1 AS path: 2 I (Originator) Cluster list: 10.0.0.10 AS path: Originator ID: 10.0.0.20 Accepted Localpref: 100 Router ID: 10.0.0.10 Addpath Path ID: 1 BGP Preference: 170/-101 Next hop type: Indirect Next-hop reference count: 4 Source: 10.0.0.10 Next hop type: Router, Next hop index: 676 Next hop: 10.0.14.1 via lt-1/2/0.41, selected Protocol next hop: 10.0.0.30 Indirect next hop: 92042ac 262151 State: Inactive reason: Not Best in its group - Router ID Local AS: 1 Peer AS: 1 Age: 1:44:37 Metric2: 2 Task: BGP_1.10.0.0.10+65237 Announcement bits (1): 3-BGP RT Background AS path: 2 I (Originator) Cluster list: 10.0.0.10 AS path: Originator ID: 10.0.0.30 Accepted Localpref: 100 Router ID: 10.0.0.10 Addpath Path ID: 2 BGP Preference: 170/-101 Next hop type: Indirect Next-hop reference count: 4 Source: 10.0.0.10 Next hop type: Router, Next hop index: 676

1280



Next hop: 10.0.14.1 via lt-1/2/0.41, selected Protocol next hop: 10.0.15.2 Indirect next hop: 92040e4 262150 State: Inactive reason: AS path Local AS: 1 Peer AS: 1 Age: 1:44:37 Metric2: 2 Task: BGP_1.10.0.0.10+65237 Announcement bits (1): 3-BGP RT Background AS path: 2 2 I Accepted Localpref: 100 Router ID: 10.0.0.10 Addpath Path ID: 3 user@R8> show route 199.1.1.1/32 detail inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden) 199.1.1.1/32 (3 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Indirect Next-hop reference count: 9 Source: 10.0.0.40 Next hop type: Router, Next hop index: 1045 Next hop: 10.0.48.1 via lt-1/2/0.84, selected Protocol next hop: 10.0.0.20 Indirect next hop: 91fc0e4 262148 State: Local AS: 1 Peer AS: 1 Age: 1:56:51 Metric2: 3 Task: BGP_1.10.0.0.40+179 Announcement bits (2): 2-KRT 4-Resolve tree 1 AS path: 2 I (Originator) Cluster list: 10.0.0.40 10.0.0.10 AS path: Originator ID: 10.0.0.20 Accepted Localpref: 100 Router ID: 10.0.0.40 Addpath Path ID: 1 BGP Preference: 170/-101 Next hop type: Indirect Next-hop reference count: 4 Source: 10.0.0.40 Next hop type: Router, Next hop index: 1045 Next hop: 10.0.48.1 via lt-1/2/0.84, selected Protocol next hop: 10.0.0.30 Indirect next hop: 91fc1c8 262152 State: Inactive reason: Not Best in its group - Router ID Local AS: 1 Peer AS: 1 Age: 1:56:51 Metric2: 3 Task: BGP_1.10.0.0.40+179 AS path: 2 I (Originator) Cluster list: 10.0.0.40 10.0.0.10 AS path: Originator ID: 10.0.0.30 Accepted Localpref: 100 Router ID: 10.0.0.40 Addpath Path ID: 2 BGP Preference: 170/-101 Next hop type: Indirect Next-hop reference count: 4 Source: 10.0.0.40


1281


Next hop type: Router, Next hop index: 1045 Next hop: 10.0.48.1 via lt-1/2/0.84, selected Protocol next hop: 10.0.15.2 Indirect next hop: 91fc2ac 262153 State: Inactive reason: AS path Local AS: 1 Peer AS: 1 Age: 1:56:51 Metric2: 3 Task: BGP_1.10.0.0.40+179 AS path: 2 2 I (Originator) Cluster list: 10.0.0.40 AS path: Originator ID: 10.0.0.10 Accepted Localpref: 100 Router ID: 10.0.0.40 Addpath Path ID: 3


•


•


Example: Configuring BGP Monitoring Protocol •

Understanding the BGP Monitoring Protocol on page 1282

•

Example: Configuring the BGP Monitoring Protocol on page 1282

Understanding the BGP Monitoring Protocol The BGP Monitoring Protocol (BMP) is a protocol to allow a monitoring station to receive routes from a BGP-enabled device. The monitoring station receives all routes, not just the active routes. BMP uses route monitoring messages (which are essentially encapsulated BGP update messages) and a few other message types for statistics and state changes. All messages flow from the router to the monitoring station. The data is collected from the Adjacency-RIB-In routing tables. The Adjacency-RIB-In tables are the pre-policy tables, meaning that the routes in these tables have not been filtered or modified by routing policies.

NOTE: The Local-RIB tables are the post-policy tables.

Example: Configuring the BGP Monitoring Protocol This example shows how to enable the BGP Monitoring Protocol (BMP). The Junos OS implementation of BMP is based on Internet draft draft-scudder-bmp-01.txt, BGP Monitoring Protocol.

1282

•


•


•


•




Requirements •


•


•

Configure BGP and routing policies.

•

Configure a monitoring station to listen on a particular TCP port.

Overview To configure the monitoring station to which BMP data is sent, you must configure both the station-address and station-port statements. For the station address, you can specify either the IP address or the name of the monitoring station. For name, specify a valid URL. For the station port, specify a TCP port. BMP operates over TCP. The monitoring station is configured to listen on a particular TCP port, and the router is configured to establish an active connection to that port and to send messages on that TCP connection. You configure BMP in the default routing instance only. However, BMP applies to routes in the default routing instance and to routes in other routing instances. You can optionally specify how often to send data to the monitoring station. The default is 1 hour. To modify this interval, include the statistics-timeout seconds statement. For seconds, you can specify a value from 15 through 65,535. By default, the routing device stops collecting BMP data when it exceeds a threshold of 10 MB. You can modify the value of this threshold by including the memory-limit bytes statement. For bytes, specify a value from 1,048,576 to 52,428,800. If the routing device stops collecting BMP data after exceeding the configured memory threshold, the router waits 10 minutes before attempting to resume the BMP session. Figure 74 on page 1283 shows a sample topology. In this example, BMP is configured on Router PE1. The server address is 192.168.64.180. The listening TCP port on the server is port 11019.

Figure 74: BMP Topology Server

CE1

PE1

fxp0 P

PE2

CE2

g041149

fxp0




1283


configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set routing-options bmp station-address 192.168.64.180 set routing-options bmp station-port 11019


The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure BMP: 1.

Configure the receiving station address. [edit routing-options] user@PE1# set bmp station-address 192.168.64.180

2.

Configure the receiving station port. [edit routing-options] user@PE1# set bmp station-port 11019

Results

From configuration mode, confirm your configuration by entering the show routing-options command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@PE1# show routing-options bmp { station-address 192.168.64.180; station-port 11019; }

Verification Verifying That BMP is Operating Purpose

Action


1284

Run the show bgp bmp command to display a set of statistics and the current BMP session state on the router. user@PE1> show bgp bmp BMP station address/port: 192.168.64.180+11019 BMP session state: DOWN Memory consumed by BMP: 0 Statistics timeout: 15 Memory limit: 10485760 Memory connect retry timeout: 600

•


•




Example: Configuring BGP Trace Operations •

Understanding Trace Operations for BGP Protocol Traffic on page 1285

•

Example: Viewing BGP Trace Files on Logical Systems on page 1286

Understanding Trace Operations for BGP Protocol Traffic You can trace various BGP protocol traffic to help you debug BGP protocol issues. To trace BGP protocol traffic, include the traceoptions statement at the [edit protocols bgp] hierarchy level. For routing instances, include the traceoptions statement at the [edit routing-instances routing-instance-name protocols bgp] hierarchy level. traceoptions { file filename ; flag flag ; }

You can specify the following BGP protocol-specific trace options using the flag statement: •

4byte-as—4-byte AS events.

•

bfd—BFD protocol events.

•

damping—Damping operations.

•

graceful-restart—Graceful restart events.

•

keepalive—BGP keepalive messages.

•

nsr-synchronization—Nonstop active routing synchronization events.

•

open—BGP open packets. These packets are sent between peers when they are

establishing a connection. •

packets—All BGP protocol packets.

•

refresh—BGP refresh packets.

•

update—BGP update packets. These packets provide routing updates to BGP systems.

Global tracing options are inherited from the configuration set by the traceoptions statement at the [edit routing-options] hierarchy level. You can override the following global trace options for the BGP protocol using the traceoptions flag statement included at the [edit protocols bgp] hierarchy level: •


•




•


•



1285


•


•


•



detail—Detailed trace information.

•

filter—Filter trace information. Applies only to route and damping tracing flags.

•

receive—Packets being received.

•

send—Packets being transmitted.

NOTE: Use the all trace flag and the detail flag modifier with caution because these might cause the CPU to become very busy.

NOTE: If you only enable the update flag, received keepalive messages do not generate a trace message.

You can filter trace statements and display only the statement information that passes through the filter by specifying the filter flag modifier. The filter modifier is only supported for the route and damping tracing flags. The match-on statement specifies filter matches based on prefixes. It is used to match on route filters.

NOTE: Per-neighbor trace filtering is not supported on a BGP per-neighbor level for route and damping flags. Trace option filtering support is on a peer group level.

Example: Viewing BGP Trace Files on Logical Systems This example shows how to list and view files that are stored on a logical system. •


•


•


•


Requirements

1286

•

You must have the view privilege for the logical system.

•

Configure a network, such as the BGP network shown in “Example: Configuring Internal BGP Peering Sessions on Logical Systems” on page 1012.



Overview Logical systems have their individual directory structure created in the /var/logical-systems/logical-system-name directory. It contains the following subdirectories: •

/config—Contains the active configuration specific to the logical system.

•

/log—Contains system log and tracing files specific to the logical system.

To maintain backward compatibility for the log files with previous versions of Junos OS, a symbolic link (symlink) from the /var/logs/logical-system-name directory to the /var/logical-systems/logical-system-name directory is created when a logical system is configured. •

/tmp—Contains temporary files specific to the logical system.

The file system for each logical system enables logical system users to view trace logs and modify logical system files. Logical system administrators have full access to view and modify all files specific to the logical system. Logical system users and administrators can save and load configuration files at the logical-system level using the save and load configuration mode commands. In addition, they can also issue the show log, monitor, and file operational mode commands at the logical-system level. This example shows how to configure and view a BGP trace file on a logical system. The steps can be adapted to apply to trace operations for any Junos OS hierarchy level that supports trace operations.

TIP: To view a list of hierarchy levels that support tracing operations, enter the help apropos traceoptions command in configuration mode.

Configuration


•

Configuring Trace Operations on page 1288

•

Viewing the Trace File on page 1288

•

Deactivating and Reactivating Trace Logging on page 1290

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set logical-systems A protocols bgp group internal-peers traceoptions file bgp-log set logical-systems A protocols bgp group internal-peers traceoptions file size 10k set logical-systems A protocols bgp group internal-peers traceoptions file files 2 set logical-systems A protocols bgp group internal-peers traceoptions flag update detail


1287


Configuring Trace Operations Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide. To configure the trace operations: 1.

Configure trace operations on the logical system. [edit logical-systems A protocols bgp group internal-peers] user@host# set traceoptions file bgp-log user@host# set traceoptions file size 10k user@host# set traceoptions file files 2 user@host# set traceoptions flag update detail

2.


Viewing the Trace File Step-by-Step Procedure

To view the trace file: 1.

In operational mode on the main router, list the directories on the logical system. user@host> file list /var/logical-systems/A /var/logical-systems/A: config/ log/ tmp/

2.

In operational mode on the main router, list the log files on the logical system. user@host> file list /var/logical-systems/A/log/ /var/logical-systems/A/log: bgp-log

3.

View the contents of the bgp-log file. user@host> file show /var/logical-systems/A/log/bgp-log Aug 10 17:12:01 trace_on: Tracing to "/var/log/A/bgp-log" started Aug 10 17:14:22.826182 bgp_peer_mgmt_clear:5829: NOTIFICATION sent to 192.163.6.4 (Internal AS 17): code 6 (Cease) subcode 4 (Administratively Reset), Reason: Management session cleared BGP neighbor Aug 10 17:14:22.826445 bgp_send: sending 21 bytes to 192.163.6.4 (Internal AS 17) Aug 10 17:14:22.826499 Aug 10 17:14:22.826499 BGP SEND 192.168.6.5+64965 -> 192.163.6.4+179 Aug 10 17:14:22.826559 BGP SEND message type 3 (Notification) length 21 Aug 10 17:14:22.826598 BGP SEND Notification code 6 (Cease) subcode 4 (Administratively Reset) Aug 10 17:14:22.831756 bgp_peer_mgmt_clear:5829: NOTIFICATION sent to 192.168.40.4 (Internal AS 17): code 6 (Cease) subcode 4 (Administratively Reset), Reason: Management session cleared BGP neighbor Aug 10 17:14:22.831851 bgp_send: sending 21 bytes to 192.168.40.4 (Internal

1288



AS 17) Aug 10 17:14:22.831901 Aug 10 17:14:22.831901 BGP SEND 192.168.6.5+53889 -> 192.168.40.4+179 Aug 10 17:14:22.831959 BGP SEND message type 3 (Notification) length 21 Aug 10 17:14:22.831999 BGP SEND Notification code 6 (Cease) subcode 4 (Administratively Reset) ... 4.

Filter the output of the log file. user@host> file show /var/logical-systems/A/log/bgp-log | match "flags 0x40" Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug Aug

5.

10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

17:14:54.867460 17:14:54.867595 17:14:54.867650 17:14:54.867692 17:14:54.884529 17:14:54.884581 17:14:54.884628 17:14:54.884667 17:14:54.911377 17:14:54.911422 17:14:54.911466 17:14:54.911507 17:14:54.916008 17:14:54.916054 17:14:54.916100 17:14:54.916143 17:14:54.920304 17:14:54.920348 17:14:54.920393 17:14:54.920434

BGP SEND flags 0x40 code Origin(1): IGP BGP SEND flags 0x40 code ASPath(2) length 0: BGP SEND flags 0x40 code NextHop(3): 192.168.6.5 BGP SEND flags 0x40 code LocalPref(5): 100 BGP RECV flags 0x40 code Origin(1): IGP BGP RECV flags 0x40 code ASPath(2) length 0: BGP RECV flags 0x40 code NextHop(3): 192.163.6.4 BGP RECV flags 0x40 code LocalPref(5): 100 BGP RECV flags 0x40 code Origin(1): IGP BGP RECV flags 0x40 code ASPath(2) length 0: BGP RECV flags 0x40 code NextHop(3): 192.168.40.4 BGP RECV flags 0x40 code LocalPref(5): 100 BGP SEND flags 0x40 code Origin(1): IGP BGP SEND flags 0x40 code ASPath(2) length 0: BGP SEND flags 0x40 code NextHop(3): 192.168.6.5 BGP SEND flags 0x40 code LocalPref(5): 100 BGP RECV flags 0x40 code Origin(1): IGP BGP RECV flags 0x40 code ASPath(2) length 0: BGP RECV flags 0x40 code NextHop(3): 10.0.0.10 BGP RECV flags 0x40 code LocalPref(5): 100

View the tracing operations in real time. user@host> clear bgp neighbor logical-system A Cleared 2 connections

CAUTION: Clearing the BGP neighbor table is disruptive in a production environment.

6.

Run the monitor start command with an optional match condition. user@host> monitor start A/bgp-log | match 0.0.0.0/0 Aug 10 19:21:40.773467 Aug 10 19:21:40.773685 Aug 10 19:21:40.773778 Aug 10 19:21:40.773832 l2afcb 0x0

BGP RECV 0.0.0.0/0 bgp_rcv_nlri: 0.0.0.0/0 bgp_rcv_nlri: 0.0.0.0/0 belongs to meshgroup bgp_rcv_nlri: 0.0.0.0/0 qualified bnp->ribact 0x0

7.

Pause the monitor command by pressing Esc-Q. To unpause the output, press Esc-Q again.

8.

Halt the monitor command by pressing Enter and typing monitor stop. [Enter]


1289


user@host> monitor stop 9.

When you are finished troubleshooting, consider deactivating trace logging to avoid any unnecessary impact to system resources. [edit protocols bgp group internal-peers] user@host:A# deactivate traceoptions user@host:A# commit

When configuration is deactivated, it appears in the configuration with the inactive tag.To reactivate trace operations, use the activate configuration-mode statement. [edit protocols bgp group internal-peers] user@host:A# show

type internal; inactive: traceoptions { file bgp-log size 10k files 2; flag update detail; flag all; } local-address 192.168.6.5; export send-direct; neighbor 192.163.6.4; neighbor 192.168.40.4; 10.

To reactivate trace operations, use the activate configuration-mode statement. [edit protocols bgp group internal-peers] user@host:A# activate traceoptions user@host:A# commit

Deactivating and Reactivating Trace Logging Step-by-Step Procedure

To deactivate and reactivate the trace file: 1.

When you are finished troubleshooting, consider deactivating trace logging to avoid an unnecessary impact to system resources. [edit protocols bgp group internal-peers] user@host:A# deactivate traceoptions user@host:A# commit

When configuration is deactivated, the statement appears in the configuration with the inactive tag. [edit protocols bgp group internal-peers] user@host:A# show

type internal; inactive: traceoptions { file bgp-log size 10k files 2; flag update detail; flag all; } local-address 192.168.6.5; export send-direct;

1290



neighbor 192.163.6.4; neighbor 192.168.40.4; 2.

To reactivate logging, use the activate configuration-mode statement. [edit protocols bgp group internal-peers] user@host:A# activate traceoptions user@host:A# commit

Results

From configuration mode, confirm your configuration by entering the show logical-systems A protocols bgp group internal-peers command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. user@host# show logical-systems A protocols bgp group internal-peers traceoptions { file bgp-log size 10k files 2; flag update detail; }

Verification Confirm that the configuration is working properly. Verifying That the Trace Log File Is Operating Purpose Action


Make sure that events are being written to the log file. user@host:A> show log bgp-log Aug 12 11:20:57 trace_on: Tracing to "/var/log/A/bgp-log" started

•


•



1291


1292


CHAPTER 35

Summary of BGP Configuration Statements The following sections explain each of the BGP configuration statements. The statements are organized alphabetically.

[edit protocols bgp] Hierarchy Level Several statements in the [edit protocols mpls] hierarchy are valid at numerous locations within it. To make the complete hierarchy easier to read, the repeated statements are listed in “Common BGP Family Options” on page 1293 and that section is referenced at the appropriate locations in “Complete [edit protocols bgp] Hierarchy” on page 1294. •

Common BGP Family Options on page 1293

•

Complete [edit protocols bgp] Hierarchy on page 1294

Common BGP Family Options This section lists statements that are valid at the following hierarchy levels, and is referenced at those levels in “Complete [edit protocols bgp] Hierarchy” on page 1294 instead of the statements being repeated. •

[edit protocols bgp family inet (any | flow | labeled-unicast | multicast | unicast)]

•

[edit protocols bgp family inet6 (any | labeled-unicast | multicast | unicast)]

•

[edit protocols bgp family (inet-mdt | inet-mvpn | inet6-mvpn | l2vpn) signaling]

•

[edit protocols bgp family inet-vpn (any | flow | multicast | unicast)]

•

[edit protocols bgp family inet6-vpn (any | multicast | unicast)]

•

[edit protocols bgp family iso-vpn unicast]

The common BGP family options are as follows: accepted-prefix-limit { maximum number; teardown ; } loops number; prefix-limit {


1293


maximum number; teardown ; } rib-group group-name;

Complete [edit protocols bgp] Hierarchy The statement hierarchy listed in this section can also be included at the [edit logical-systems logical-system-name] hierarchy level. protocols { bgp { disable; accept-remote-nexthop; advertise-external ; advertise-inactive; (advertise-peer-as | no-advertise-peer-as); authentication-algorithm (aes-128-cmac-96 | hmac-sha-1-96 | md5); authentication-key key; authentication-key-chain key-chain; bfd-liveness-detection { authentication { algorithm (keyed-md5 | keyed-sha-1 | meticulous-keyed-md5 | meticulous-keyed-sha-1 | simple-password); key-chain key-chain-name; loose-check; } detection-time { threshold milliseconds; } holddown-interval milliseconds; minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; session-mode (automatic | multihop | single-hop); transmit-interval { minimum-interval milliseconds; threshold milliseconds; } version (1 | automatic); } cluster cluster-identifier; damping; description text-description; export [ policy-names ]; family family-name { ... the family subhierarchies appear after the main [edit protocols bgp] hierarchy ... } graceful-restart { disable; restart-time seconds; stale-routes-time seconds; } group group-name { ... the group subhierarchy appears after the main [edit protocols bgp] hierarchy ...

1294


Chapter 35: Summary of BGP Configuration Statements

} hold-time seconds; idle-after-switch-over (seconds | forever); import [ policy-names ]; include-mp-next-hop; ipsec-sa ipsec-sa; keep (all | none); local-address address; local-as autonomous-system < alias> ; local-interface interface-name; local-preference local-preference; log-updown; metric-out (metric | igp (delay-med-update | offset) | minimum-igp offset); mtu-discovery; multihop { no-nexthop-change; ttl ttl-value; } no-aggregator-id; no-client-reflect; out-delay seconds; outbound-route-filter { bgp-orf-cisco-mode; prefix-based { accept { inet; inet6; } } } passive; path-selection { always-compare-med; as-path-ignore; cisco-non-deterministic; external-router-id; med-plus-igp { igp-multiplier number; med-multiplier number; } } peer-as autonomous-system; preference preference; remove-private; tcp-mss segment-size; traceoptions { file filename ; flag flag ; } vpn-apply-export; } bgp { family inet { (any | multicast) {


1295


... statements in Common BGP Family Options on page 1293 ... } flow { ... statements in Common BGP Family Options on page 1293 PLUS ... no-validate [ validation-procedure-names ]; } labeled-unicast { ... statements in Common BGP Family Options on page 1293 PLUS ... aggregate-label { community community-name; } explicit-null connected-only; per-group-label; resolve-vpn; rib inet.3; traffic-statistics { file filename ; interval seconds; } } unicast { ... statements in Common BGP Family Options on page 1293 PLUS ... add-path { send { path-count number; prefix-policy [ policy-names ]; } receive; } topology name { community target identifier; } } } } bgp { family inet6 { (any | multicast) { ... statements in Common BGP Family Options on page 1293 ... } labeled-unicast { ... statements in Common BGP Family Options on page 1293 PLUS ... aggregate-label { community community-name: } explicit-null; per-group-label; traffic-statistics { file filename ; interval seconds; } } unicast {

1296



... statements in Common BGP Family Options on page 1293 PLUS ... topology name { community target identifier; } } } } bgp { family (inet-mdt | inet-mvpn | inet6-mvpn | l2vpn) { signaling { ... statements in Common BGP Family Options on page 1293 ... } } } bgp { family inet-vpn { (any | multicast | unicast) { ... statements in Common BGP Family Options on page 1293 PLUS ... aggregate-label ; } flow { ... statements in Common BGP Family Options on page 1293 ... } } } bgp { family inet6-vpn { (any | multicast | unicast) { ... statements in Common BGP Family Options on page 1293 PLUS ... aggregate-label ; } } } bgp { family iso-vpn { unicast { ... statements in Common BGP Family Options on page 1293 PLUS ... aggregate-label ; } } } bgp { family route-target { accepted-prefix-limit { maximum number; teardown ; } advertise-default; external-paths number; prefix-limit { maximum number;


1297


teardown ; } } } bgp { group group-name { ... same statements as at the [edit protocols bgp] hierarchy level PLUS ... allow [ all ip-prefix ]; as-override; multipath ; neighbor address { ... the neighbor subhierarchy appears after the main [edit protocols bgp group group-name] hierarchy ... } type (external | internal); ... BUT NOT ... disable; # NOT valid at this level group group-name { ... } # NOT valid at this level path-selection { ... } # NOT valid at this level } group group-name { neighbor address { ... same statements as at the [edit protocols bgp] hierarchy level PLUS ... as-override; multipath ; ... BUT NOT ... disable; # NOT valid at this level group group-name { ... } # NOT valid at this level neighbor address { ... } # NOT valid at this level path-selection { ... } # NOT valid at this level } } } }


1298

•

Notational Conventions Used in Junos OS Configuration Hierarchies

•

[edit protocols] Hierarchy Level



accept-remote-nexthop Syntax Hierarchy Level

Release Information

Description


accept-remote-nexthop; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced in Junos OS Release 8.5. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify that a single-hop EBGP peer accept a remote next hop with which it does not share a common subnet. Configure a separate import policy on the EBGP peer to specify the remote next hop. You cannot configure the multihop statement at the same time. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

multipath on page 1359

•

Example: Configuring Single-Hop EBGP Peers to Accept Remote Next Hops on page 1119

•



1299


accepted-prefix-limit Syntax

Hierarchy Level

Release Information

1300

accepted-prefix-limit { maximum number; teardown idle-timeout (forever | minutes); } [edit logical-systems logical-system-name protocols bgp family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name protocols bgp family route-target], [edit logical-systems logical-system-name protocols bgp group group-name family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name protocols bgp group group-name family route-target], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family route-target], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family route-target], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family route-target], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family route-target], [edit protocols bgp family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit protocols bgp family route-target], [edit protocols bgp group group-name family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit protocols bgp group group-name family route-target], [edit protocols bgp group group-name neighbor address family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit protocols bgp group group-name neighbor address family route-target], [edit routing-instances routing-instance-name protocols bgp family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit routing-instances routing-instance-name protocols bgp family route-target], [edit routing-instances routing-instance-name protocols bgp group group-name family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family route-target], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family route-target]

Statement introduced in Junos OS Release 9.2. Statement introduced in Junos OS Release 9.2 for EX Series switches.



Description

Options

Configure a limit to the number of prefixes that can be accepted on a BGP peer session. When that limit is exceeded, a system log message is sent. You can optionally specify to reset the BGP session when the number of accepted prefixes exceeds the specified limit. idle-timeout (forever | minutes)—Specify that a BGP session that has been reset is not

reestablished until after the specified timeout period. Specify forever to prevent the BGP session from being reestablished until the clear bgp neighbor command is issued. maximum number—Limit the number of prefixes that can be accepted on a BGP peer

session. A system log message is sent when that number is exceeded. 32

Range: 1 through 4,294,967,295 (2

– 1)

teardown —Specify to reset the BGP peer session when the

specified limit to the number of prefixes that can be accepted is exceeded. If you specify a percentage, a system log message is sent when the accepted number of prefixes on the BGP session exceeds the specified percentage of the configured limit. After a BGP session is reset, it is reestablished within a short time unless you include the idle-timeout statement. Range: 1 through 100 Range: 1 through 2400 Required Privilege Level Related Documentation


prefix-limit on page 1377

•



1301


add-path Syntax

Hierarchy Level


add-path { send { path-count number; prefix-policy [ policy-names ]; } receive; [edit logical-systems logical-system-name protocols bgp group group-name family inet unicast], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet unicast], [edit protocols bgp group group-name family inet unicast], [edit protocols bgp group group-name neighbor address family inet unicast]

Statement introduced in Junos OS Release 11.3. Enable advertisement of multiple paths to a destination, instead of advertising only the active path. The remaining statements are explained separately.


1302



•




advertise-external Syntax

Hierarchy Level

Release Information

Description

Options

advertise-external { conditional; } [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor neighbor-address]

Statement introduced in Junos OS Release 9.3. Statement introduced in Junos OS Release 9.3 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Have BGP advertise the best external route into an IBGP mesh group, a route reflector cluster, or an AS confederation even if the best route is an internal route. conditional—(Optional) Advertise the best external path only if the route selection process

reaches the point at which the multiple exit discriminator (MED) metric is evaluated. As a result, an external path with an AS path worse than that of the active path is not advertised. Required Privilege Level Related Documentation


advertise-inactive on page 1304

•



1303


advertise-inactive Syntax Hierarchy Level

Release Information

Description


1304

advertise-inactive; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Have BGP advertise the best route even if the routing table did not select it to be an active route. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •




advertise-peer-as Syntax Hierarchy Level

Release Information


advertise-peer-as; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Disable the default behavior of suppressing AS routes. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



1305


aggregate-label Syntax

Hierarchy Level

Release Information

Description Options

aggregate-label { community community-name; } [edit logical-systems logical-system-name protocols bgp family inet labeled-unicast], [edit logical-systems logical-system-name protocols bgp family inet-vpn labeled-unicast], [edit protocols bgp family inet labeled-unicast], [edit protocols bgp family inet-vpn labeled-unicast], [edit protocols bgp family inet6 labeled-unicast]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable aggregate labels for VPN traffic. community community-name—Specify the name of the community to which to apply the

aggregate label. Required Privilege Level Related Documentation

1306


Configuring Aggregate Labels for VPNs



allow Syntax Hierarchy Level

Release Information

Description

allow (all | [ network/mask-length ]); [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Implicitly configure BGP peers, allowing peer connections from any of the specified networks or hosts. To configure multiple BGP peers, configure one or more networks and hosts within a single allow statement or include multiple allow statements.

NOTE: You cannot define a BGP group with dynamic peers with BGP authentication enabled.

Options

all—Allow all addresses, which is equivalent to 0.0.0.0/0 (or ::/0). network/mask-length—IPv6 or IPv4 network number of a single address or a range of

allowable addresses for BGP peers, followed by the number of significant bits in the subnet mask.

NOTE: You cannot define a BGP group with dynamic peers with authentication enabled.





1307


as-override Syntax Hierarchy Level

Release Information

Description

as-override; [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Compare the AS path of an incoming advertised route with the AS number of the BGP peer under the group and replace all occurrences of the peer AS number in the AS path with its own AS number before advertising the route to the peer.

NOTE: The as-override statement is specific to a particular BGP group. This statement does not affect peers from the same remote AS configured in different groups.

Enabling the AS override feature allows routes originating from an AS to be accepted by a router residing in the same AS. Without AS override enabled, the routing device refuses the route advertisement once the AS path shows that the route originated from its own AS. This is done by default to prevent route loops. The as-override statement overrides this default behavior. Note that enabling the AS override feature may result in routing loops. Use this feature only for specific applications that require this type of behavior, and in situations with strict network control. One application is the IGP protocol between the provider edge routing device and the customer edge routing device in a virtual private network. Required Privilege Level Related Documentation

1308


Configuring BGP Groups and Peers

•




authentication-algorithm Syntax Hierarchy Level

Release Information

Description Options

authentication-algorithm algorithm; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced in Junos OS Release 8.0. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure an authentication algorithm type. algorithm—Type of authentication algorithm. Specify md5, hmac-sha-1-96, or aes-128-cmac-96 as the algorithm type.





1309



Release Information

Description

Options

authentication-key key; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure an MD5 authentication key (password). Neighboring routing devices use the same password to verify the authenticity of BGP packets sent from this system. key—Authentication password. It can be up to 126 characters. Characters can include

any ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”). Required Privilege Level Related Documentation

1310





authentication-key-chain Syntax Hierarchy Level

Release Information

Description Options

authentication-key-chain key-chain; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced in Junos OS Release 8.0. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Apply and enable an authentication keychain to the routing device. key-chain—Authentication keychain name. It can be up to 126 characters. Characters can

include any ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”). Required Privilege Level Related Documentation



•

Configuring the Authentication Key Update Mechanism for BGP and LDP Routing Protocols

•


•



1311


auto-discovery-only Syntax Hierarchy Level


auto-discovery-only; [edit logical-systems logical-system-name protocols bgp family l2vpn], [edit logical-systems logical-system-name protocols bgp group group-name family l2vpn], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family l2vpn], [edit logical-systems logical-system-name routing-instances instance-name protocols bgp family l2vpn], [edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name family l2vpn], [edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name neighbor address family l2vpn], [edit protocols bgp family l2vpn], [edit protocols bgp group group-name family l2vpn], [edit protocols bgp group group-name neighbor address family l2vpn], [edit routing-instances instance-name protocols bgp family l2vpn], [edit routing-instances instance-name protocols bgp group group-name family l2vpn], [edit routing-instances instance-name protocols bgp group group-name neighbor address family l2vpn]

Statement introduced in Junos OS Release 10.4R2. Enable the router to process only the autodiscovery network layer reachability information (NLRI) update messages for LDP-based Layer 2 VPN and VPLS update messages (BGP_L2VPN_AD_NLRI) (FEC 129). Specifically, the auto-discovery-only statement notifies the routing process (rpd) to expect autodiscovery-related NLRI messages so that information can be deciphered and used by LDP and VPLS. The auto-discovery-only statement must be configured on all provider edge (PE) routers in a VPLS. If you configure route reflection, the auto-discovery-only statement is also required on provider (P) routers that act as the route reflector in supporting FEC 129-related updates.


1312


Example: Configuring BGP Autodiscovery for LDP VPLS




bfd-liveness-detection { authentication { algorithm algorithm-name; key-chain key-chain-name; ; } detection-time { threshold milliseconds; } holddown-interval milliseconds; minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; session-mode (automatic | multihop | single-hop); transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); }

Hierarchy Level

[edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Release Information

Statement introduced in Junos OS Release 8.1. Statement introduced in Junos OS Release 9.0 for EX Series switches. detection-time threshold and transmit-interval threshold options introduced in Junos OS Release 8.2 Support for logical routers introduced in Junos OS Release 8.3. Support for IBGP and multihop EBGP sessions introduced in Junos OS Release 8.3. holddown-interval statement introduced in Junos OS Release 8.5. You can configure this statement only for EBGP peers at the [edit protocols bgp group group-name neighbor address] hierarchy level. no-adaptation statement introduced in Junos OS Release 9.0. Support for BFD authentication introduced in Junos OS Release 9.6.


1313


Support for BFD on IPv6 interfaces with BGP introduced in Junos OS Release 11.2. Description

Configure bidirectional failure detection timers and authentication. For IBGP and multihop EBGP support, configure the bfd-liveness-detection statement at the global [edit bgp protocols] hierarchy level. You can also configure IBGP and multihop support for a routing instance or a logical system.

1314



Options

authentication algorithm algorithm-name (Optional)—Configure the algorithm used to

authenticate the specified BFD session: simple-password, keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1. authentication key-chain key-chain-name (Optional)—Associate a security key with the

specified BFD session using the name of the security keychain. The keychain name must match one of the keychains configured in the authentication-key-chains key-chain statement at the [edit security] hierarchy level. authentication loose-check—(Optional) Configure loose authentication checking on the

BFD session. Use only for transitional periods when authentication may not be configured at both ends of the BFD session. detection-time threshold milliseconds (Optional)—Configure a threshold. When the BFD

session detection time adapts to a value equal to or greater than the threshold, a single trap and a single system log message are sent. holddown-interval milliseconds (Optional)—Configure an interval specifying how long a

BFD session must remain up before a state change notification is sent. When you configure the hold-down interval for the BFD protocol for EBGP, the BFD session is unaware of the BGP session during this time. In this case, if the BGP session goes down during the configured hold-down interval, BFD already assumes it is down and does not send a state change notification. The holddown-interval statement is supported only for EBGP peers at the [edit protocols bgp group group-name neighbor address] hierarchy level. If the BFD session goes down and then comes back up during the configured hold-down interval, the timer is restarted. You must configure the hold-down interval on both EBGP peers. If you configure the hold-down interval for a multihop EBGP session, you must also configure a local IP address by including the local-address statement at the [edit protocols bgp group group-name] hierarchy level. Range: 0 through 255,000 Default: 0 minimum-interval milliseconds (Required)—Configure the minimum intervals at which

the local routing device transmits hello packets and then expects to receive a reply from a neighbor with which it has established a BFD session. This value represents the minimum interval at which the local routing device transmits hello packets as well as the minimum interval that the routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a value in the range from 1 through 255,000 milliseconds. Optionally, instead of using this statement, you can specify the minimum transmit and receive intervals separately (using the minimum-receive-interval and transmit-interval minimal-interval statements). Range: 1 through 255,000 minimum-receive-interval milliseconds (Optional)— Configure only the minimum interval

at which the local routing device expects to receive a reply from a neighbor with which it has established a BFD session. Range: 1 through 255,000


1315


multiplier number (Optional)—Configure the number of hello packets not received by a

neighbor that causes the originating interface to be declared down. Range: 1 through 255 Default: 3 no-adaptation (Optional)—Configure BFD sessions not to adapt to changing network

conditions. We recommend that you not disable BFD adaptation unless it is preferable to not to have BFD adaptation enabled in your network. transmit-interval threshold milliseconds (Optional)—Configure a threshold. When the

BFD session transmit interval adapts to a value greater than the threshold, a single trap and a single system message are sent. The interval threshold must be greater than the minimum transmit interval. 32

Range: 0 through 4,294,967,295 (2

– 1)

transmit-interval minimum-interval milliseconds (Optional)—Configure only the minimum

interval at which the local routing device transmits hello packets to a neighbor with which it has established a BFD session. Range: 1 through 255,000 version (Optional)—Configure the BFD version to detect.

Range: 1 or automatic (autodetect the BFD version) Default: automatic The remaining statements are explained separately. Required Privilege Level Related Documentation



•


•


•

1316



bgp Syntax Hierarchy Level

Release Information


bgp { ... } [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit protocols], [edit routing-instances routing-instance-name protocols]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable BGP on the routing device or for a routing instance. BGP is disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Enabling BGP


1317


bgp-orf-cisco-mode Syntax

bgp-orf-cisco-mode;

Hierarchy Level

[edit logical-systems logical-system-name protocols bgp outbound-route-filter], [edit logical-systems logical-system-name protocols bgp group group-name outbound-route-filter], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address outbound-route-filter], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp outbound-route-filter], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name outbound-route-filter, [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address outbound-route-filter], [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options outbound-route-filter], [edit logical-systems logical-system-name routing-options outbound-route-filter], [edit protocols bgp outbound-route-filter], [edit protocols bgp group group-name outbound-route-filter], [edit protocols bgp group group-name neighbor address outbound-route-filter], [edit routing-instances routing-instance-name protocols bgp outbound-route-filter], [edit routing-instances routing-instance-name protocols bgp group group-name outbound-route-filter], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address outbound-route-filter], [edit routing-instances routing-instance-name routing-options outbound-route-filter], [edit routing-options outbound-route-filter]

Release Information

Statement introduced in Junos OS Release 9.2. Statement introduced in Junos OS Release 9.2 for EX Series switches. Support for the BGP group and neighbor hierarchy levels introduced in Junos OS Release 9.2. Support for the BGP group and neighbor hierarchy levels introduced in Junos OS Release 9.3 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series.

Description

Enable interoperability with routing devices that use the vendor-specific outbound route filter compatibility code of 130 and code type of 128.

NOTE: To enable interoperability for all BGP peers configured on the routing device, include the statement at the [edit routing-options outbound-route-filter] hierarchy level.

Default Required Privilege Level

1318

Disabled routing—To view this statement in the configuration. routing-control—To add this statement to the configuration.




•


bmp Syntax


bmp { memory limit bytes; station-address (ip-address | name); station-port port-number; statistics-timeout seconds; } [edit routing-options]

Statement introduced in Junos OS Release 9.5. Statement introduced in Junos OS Release 9.5 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series.

Description

Configure the BGP Monitoring Protocol (BMP), which enables the routing device to collect data from the BGP Adjacency-RIB-In routing tables and periodically send that data to a monitoring station.

Options

memory-limit bytes—(Optional) Specify a threshold at which to stop collecting BMP data

if the limit is exceeded. Default: 10 MB Range: 1,048,576 through 52,428,800 station-address (ip-address | name)—Specify the IP address or a valid URL for the

monitoring where BMP data should be sent. station-port port-number—Specify the port number of the monitoring station to use when

sending BMP data. statistics-timeout seconds—(Optional) Specify how often to send BMP data to the

monitoring station. Required Privilege Level Related Documentation


Example: Configuring the BGP Monitoring Protocol on page 1282


1319


cluster Syntax Hierarchy Level

Release Information

Description

cluster cluster-identifier; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the cluster identifier to be used by the route reflector cluster in an internal BGP group.

CAUTION: If you configure both route reflection and VPNs on the same routing device, the following modifications to the route reflection configuration cause current BGP sessions to be reset: •

Adding a cluster ID—If a BGP session shares the same AS number with the group where you add the cluster ID, all BGP sessions are reset regardless of whether the BGP sessions are contained in the same group.

•

Creating a new route reflector—If you have an IBGP group with an AS number and create a new route reflector group with the same AS number, all BGP sessions in the IBGP group and the new route reflector group are reset.

NOTE: If you change the address family specified in the [edit protocols bgp family] hierarchy level, all current BGP sessions on the routing device are dropped and then reestablished.

1320




cluster-identifier—IPv6 or IPv4 address to use as the cluster identifier.


no-client-reflect on page 1365

•

Configuring BGP Route Reflection

confederation Syntax Hierarchy Level

Release Information

Description Options

confederation confederation-autonomous-system members [ autonomous-systems ]; [edit logical-systems logical-system-name routing-options], [edit routing-options]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the routing device’s confederation AS number. autonomous-system—AS numbers of the confederation members.

Range: 1 through 65,535 confederation-autonomous-system—Confederation AS number. Use one of the numbers

assigned to you by the NIC. Range: 1 through 65,535 Required Privilege Level Related Documentation



•



1321


damping Syntax Hierarchy Level

Release Information


1322

damping; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable route flap damping. Flap damping is disabled on the routing device. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Configuring Flap Damping for BGP Routes

•




description Syntax Hierarchy Level

Release Information


description text-description; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Text description of the global, group, or neighbor configuration. text-description—Text description of the configuration. It is limited to 255 characters.


Enabling BGP

•



1323



Release Information


1324

disable; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit protocols bgp], [edit routing-instances routing-instance-name protocols bgp]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Disable BGP on the system. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Enabling BGP



explicit-null Syntax Hierarchy Level

Release Information

Description

explicit-null; [edit logical-systems logical-system-name protocols mpls], [edit logical-systems logical-system-name protocols bgp family inet labeled-unicast], [edit logical-systems logical-system-name protocols bgp family inet6 labeled-unicast], [edit logical-systems logical-system-name protocols bgp group group-name family inet labeled-unicast], [edit logical-systems logical-system-name protocols bgp group group-name family inet6 labeled-unicast], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet labeled-unicast], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet6 labeled-unicast], [edit logical-systems logical-system-name protocols ldp], [edit logical-systems logical-system-name routing-instances instance-name protocols bgp family inet labeled-unicast], [edit logical-systems logical-system-name routing-instances instance-name protocols bgp family inet6 labeled-unicast], [edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name family inet labeled-unicast], [edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name family inet6 labeled-unicast], [edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name neighbor address family inet labeled-unicast], [edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name neighbor address family inet6 labeled-unicast], [edit logical-systems logical-system-name routing-instances instance-name protocols ldp], [edit protocols mpls], [edit protocols bgp family inet labeled-unicast], [edit protocols bgp family inet6 labeled-unicast], [edit protocols bgp group group-name family inet labeled-unicast], [edit protocols bgp group group-name family inet6 labeled-unicast], [edit protocols bgp group group-name neighbor address family inet labeled-unicast] [edit protocols bgp group group-name neighbor address family inet6 labeled-unicast], [edit protocols ldp], [edit routing-instances instance-name protocols bgp family inet labeled-unicast], [edit routing-instances instance-name protocols bgp family inet6 labeled-unicast], [edit routing-instances instance-name protocols bgp group group-name family inet labeled-unicast], [edit routing-instances instance-name protocols bgp group group-name family inet6 labeled-unicast], [edit routing-instances instance-name protocols bgp group group-name neighbor address family inet labeled-unicast], [edit routing-instances instance-name protocols bgp group group-name neighbor address family inet6 labeled-unicast], [edit routing-instances instance-name protocols ldp]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Advertise label 0 to the egress routing device of an LSP.


1325


Default


If you do not include the explicit-null statement in the configuration, label 3 (implicit null) is advertised. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Advertising Explicit Null Labels to BGP Peers


Release Information


1326

export [ policy-names ]; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Apply one or more policies to routes being exported from the routing table into BGP. policy-names—Name of one or more policies.


import on page 1337

•


•




family Syntax

family { (inet | inet6 | inet-vpn | inet6-vpn | iso-vpn) { (any | flow | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown ; } add-path { send { path-count number; prefix-policy [ policy-names ]; } receive; } loops number; prefix-limit { maximum number; teardown ; } rib-group group-name; } flow { no-validate policy-name; } labeled-unicast { accepted-prefix-limit { maximum number; teardown ; } aggregate-label { community community-name: } explicit-null { connected-only; } prefix-limit { maximum number; teardown ; } resolve-vpn; rib inet.3; rib-group group-name; } } route-target { accepted-prefix-limit { maximum number; teardown ; } advertise-default; external-paths number; prefix-limit {


1327


maximum number; teardown ; } } (inet-mdt | inet-mvpn | inet6-mvpn | l2vpn) { signaling { accepted-prefix-limit { maximum number; teardown ; } loops number; prefix-limit { maximum number; teardown ; } rib-group group-name } } }

Hierarchy Level

Release Information

Description

1328

[edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. inet-mvpn and inet6-mpvn statements introduced in Junos OS Release 8.4. inet-mdt statement introduced in Junos OS Release 9.4. Support for the loops statement introduced in Junos OS Release 9.6. Enable multiprotocol BGP (MP-BGP) by configuring BGP to carry network layer reachability information (NLRI) for address families other than unicast IPv4, to specify MP-BGP to carry NLRI for the IPv6 address family, or to carry NLRI for VPNs.



Options

any—Configure the family type to be both unicast and multicast. inet—Configure NLRI parameters for IPv4. inet6—Configure NLRI parameters for IPv6. inet-mdt—Configure NLRI parameters for the multicast distribution tree (MDT) subaddress

family identifier (SAFI) for IPv4 traffic in Layer 3 VPNs. inet-mvpn—Configure NLRI parameters for IPv4 for multicast VPNs. inet6-mvpn—Configure NLRI parameters for IPv6 for multicast VPNs. inet-vpn—Configure NLRI parameters for IPv4 for Layer 3 VPNs. inet6-vpn—Configure NLRI parameters for IPv6 for Layer 3 VPNs. iso-vpn—Configure NLRI parameters for IS-IS for Layer 3 VPNs. l2vpn—Configure NLRI parameters for IPv4 for MPLS-based Layer 2 VPNs and VPLS. labeled-unicast—Configure the family type to be labeled-unicast. This means that the

BGP peers are being used only to carry the unicast routes that are being used by labeled-unicast for resolving the labeled-unicast routes. This statement is supported only with inet and inet6. multicast—Configure the family type to be multicast. This means that the BGP peers are

being used only to carry the unicast routes that are being used by multicast for resolving the multicast routes. unicast—Configure the family type to be unicast. This means that the BGP peers only

carry the unicast routes that are being used for unicast forwarding purposes. The default family type is unicast. The remaining statements are explained separately. Required Privilege Level Related Documentation



•

local-as on page 1346

•



1329


flow Syntax

Hierarchy Level

Release Information

Description

flow { no-validate policy-name; } [edit protocols bgp group group-name family (inet | inet-vpn)], [edit protocols bgp group group-name neighbor address family (inet | inet-vpn)], [edit routing-instances routing-instance-name protocols bgp group group-name family (inet | inet-vpn)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet-vpn)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Enables BGP to support flow routes.

NOTE: This statement is supported for the default instance, VRF instance, and virtual-router instance only. It is configured with the instance-type statement at the [edit routing-instance instance-name] hierarchy level. For VPNs, this statement is supported for the default instance only. The remaining statements are explained separately.


1330






Hierarchy Level

Release Information

Description

graceful-restart { disable; restart-timeseconds; stale-routes-time seconds; } [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure graceful restart for BGP.

NOTE: If you configure graceful restart after a BGP session has been established, the BGP session restarts and the peers negotiate graceful restart capabilities.

Options

disable—Disable graceful restart for BGP. restart-time seconds—Time period when the restart is expected to be complete.

Range: 1 through 600 seconds Default: 120 seconds stale-routes-time seconds—Maximum time that stale routes are kept during restart.




•

Configuring Graceful Restart for BGP

•



1331


group Syntax

1332

group group-name { advertise-inactive; allow [ network/mask-length ]; authentication-key key; cluster cluster-identifier; damping; description text-description; export [ policy-names ]; family { (inet | inet6 | inet-vpn | inet6-vpn | l2-vpn) { (any | multicast | unicast | signaling) { accepted-prefix-limit { maximum number; teardown ; } add-path { send { path-count number; prefix-policy [ policy-names ]; } receive; } prefix-limit { maximum number; teardown ; } rib-group group-name; } flow { no-validate policy-name; } labeled-unicast { accepted-prefix-limit { maximum number; teardown ; } explicit-null { connected-only; } prefix-limit { maximum number; teardown ; } resolve-vpn; rib inet.3; rib-group group-name; } } route-target { accepted-prefix-limit { maximum number; teardown ;



} advertise-default; external-paths number; prefix-limit { maximum number; teardown ; } } } hold-time seconds; import [ policy-names ]; ipsec-sa ipsec-sa; keep (all | none); local-address address; local-as autonomous-system ; local-preference local-preference; log-updown; metric-out metric; multihop ; multipath { multiple-as; } no-aggregator-id; no-client-reflect; out-delay seconds; passive; peer-as autonomous-system; preference preference; remove-private; tcp-mss segment-size; traceoptions { file filename ; flag flag ; } type type; neighbor address { ... peer-specific-options ... } }

Hierarchy Level

Release Information

[edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit protocols bgp], [edit routing-instances routing-instance-name protocols bgp]



1333


Description

Define a BGP peer group. BGP peer groups share a common type, peer autonomous system (AS) number, and cluster ID, if present. To configure multiple BGP groups, include multiple group statements. By default, the group’s options are identical to the global BGP options. To override the global options, include group-specific options within the group statement. The group statement is one of the statements you must include in the configuration to run BGP on the routing device. Each group must contain at least one peer.

Options

group-name—Name of the BGP group.


1334





hold-time Syntax Hierarchy Level

Release Information

Description

hold-time seconds; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the hold-time value to use when negotiating a connection with the peer. The hold-time value is advertised in open packets and indicates to the peer the length of time that it should consider the sender valid. If the peer does not receive a keepalive, update, or notification message within the specified hold time, the BGP connection to the peer is closed and routing devices through that peer become unavailable. The hold time is three times the interval at which keepalive messages are sent. BGP on the local routing device uses the smaller of either the local hold-time value or the peer’s hold-time value received in the open message as the hold time for the BGP connection between the two peers.

Options

seconds—Hold time.

Range: 10 through 65,535 seconds Default: 90 seconds

TIP: When you set a hold time value to less than 20 seconds, we recommend that you also configure the BGP precision-timers statement. The precision-timers statement ensures that if scheduler slip messages occur, the routing device continues to send keepalive messages. When the precision-timers statement is included, keepalive message generation is performed in a dedicated kernel thread, which helps to prevent BGP session flaps.


1335




precision-timers on page 1375

idle-after-switch-over Syntax Hierarchy Level

Release Information

Description

Options

idle-after-switch-over (forever | seconds); [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address]

Statement introduced in Junos OS Release 9.5. Statement introduced in Junos OS Release 9.5 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure the routing device not to automatically reestablish BGP peer sessions after a nonstop active routing (NSR) switchover. This feature is particularly useful if you are using dynamic routing policies because the dynamic database is not synchronized with the backup Routing Engine when NSR is enabled. forever—Do not reestablish a BGP peer session after an NSR switchover until the clear bgp neighbor command is issued. seconds—Do not reestablish a BGP peer session after an NSR switchover until after the

specified period. 32


1336

– 1)


Preventing Automatic Reestablishment of BGP Peer Sessions After NSR Switchovers

•


•





Release Information

Description


import [ policy-names ]; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Apply one or more routing policies to routes being imported into the Junos OS routing table from BGP. policy-names—Name of one or more policies.


export on page 1326

•


•



1337


include-mp-next-hop Syntax Hierarchy Level

Release Information


1338

include-mp-next-hop; [edit logical-systems logical-system-name protocols bgp], [edit protocols bgp]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Enable multiprotocol updates to contain next-hop reachability information. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Examples: Configuring Multiprotocol BGP on page 1190



ipsec-sa Syntax Hierarchy Level



ipsec-sa ipsec-sa; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Apply a security association to BGP peers. You can apply the security association globally for all BGP peers, to a group of peers, or to an individual peer. ipsec-sa—Security association name.


Example: Using IPsec to Protect BGP Traffic on page 1064


1339


iso-vpn Syntax

Hierarchy Level


iso-vpn { unicast { prefix-limit number; rib-group group-name; } } [edit protocols bgp family], [edit protocols bgp group group-name family], [edit protocols bgp group group-name neighbor addressfamily], [edit routing-instances routing-instance-name protocols bgp family], [edit routing-instances routing-instance-name protocols bgp group group-name family], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family]

Statement introduced before Junos OS Release 7.4. Enable BGP to carry ISO VPN NLRI messages between PE routes connecting a VPN.


The remaining statements are explained separately in this chapter. Default Required Privilege Level Related Documentation

1340

Disabled. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Enabling BGP to Carry CLNS Routes on page 1218



keep Syntax Hierarchy Level

Release Information

Description

Default Options

keep (all | none); [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify whether routes learned from a BGP peer are retained in the routing table even if they contain an AS number that was exported from the local AS. If you do not include this statement, most routes are retained in the routing table. all—Retain all routes. none—Retain none of the routes. When keep none is configured for the BGP session and

the inbound policy changes, the Junos OS forces readvertisement of the full set of routes advertised by the peer. Required Privilege Level Related Documentation




1341


labeled-unicast Syntax

Hierarchy Level

Release Information

Description

labeled-unicast { accepted-prefix-limit { maximum number; teardown ; } aggregate-label { community community-name; } explicit-null { connected-only; } prefix-limit { maximum number; teardown ; } resolve-vpn; rib inet.3; rib-group group-name; } [edit logical-systems logical-system-name protocols bgp family (inet | inet6)], [edit logical-systems logical-system-name protocols bgp group group-name family (inet | inet6)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family (inet | inet6)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family (inet | inet6)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family (inet | inet6)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet6)], [edit protocols bgp family (inet | inet6)], [edit protocols bgp group group-name family (inet | inet6)], [edit protocols bgp group group-name neighbor address family (inet | inet6)], [edit routing-instances routing-instance-name protocols bgp family (inet | inet6)], [edit routing-instances routing-instance-name protocols bgp group group-name family (inet | inet6)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet6)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure the family type to be labeled-unicast. The remaining statements are explained separately.


1342





•



1343


local-address Syntax Hierarchy Level

Release Information

Description

local-address address; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the address of the local end of a BGP session. This address is used to accept incoming connections to the peer and to establish connections to the remote peer. When none of the operational interfaces are configured with the specified local address, a session with a BGP peer is placed in the idle state. You generally configure a local address to explicitly configure the system’s IP address from BGP’s point of view. This IP address can be either an IPv6 or IPv4 address. Typically, an IP address is assigned to a loopback interface, and that IP address is configured here. For internal BGP (IBGP) peering sessions, generally the loopback interface (lo0) is used to establish connections between the IBGP peers. The loopback interface is always up as long as the device is operating. If there is a route to the loopback address, the IBGP peering session stays up. If a physical interface address is used instead and that interface goes up and down, the IBGP peering session also goes up and down. Thus the loopback interface provides fault tolerance in case the physical interface or the link goes down, if the device has link redundancy. When a device peers with a remote device’s loopback interface address, the local device expects BGP update messages to come from (be sourced by) the remote device’s loopback interface address. The local-address statement enables you to specify the source information in BGP update messages. If you omit the local-address statement, the expected source of BGP update messages is based on the device’s source address selection rules, which normally result in the egress interface address being the expected source of update messages. When this happens, the peering session is not established because a mismatch exists between the expected source address (the egress interface

1344



of the peer) and the actual source (the loopback interface of the peer). To make sure that the expected source address matches the actual source address, specify the loopback interface address in the local-address statement.

NOTE: A BGP session can still be established when only one of the paired routers has a local address configured.

If you include the default-address-selection statement in the configuration, the software chooses the system default address as the source for most locally generated IP packets. For protocols in which the local address is unconstrained by the protocol specification, for example IBGP and multihop EBGP, if you do not configure a specific local address when configuring the protocol, the local address is chosen using the same methods as other locally generated IP packets. Default


If you do not configure a local address, BGP uses the routing device’s source address selection rules to set the local address. address—IPv6 or IPv4 address of the local end of the connection.


router-id on page 219

•

Enabling BGP


1345


local-as Syntax Hierarchy Level

Release Information

Description

local-as autonomous-system ; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. alias option introduced in Junos OS Release 9.5. no-prepend-global-as option introduced in Junos OS Release 9.6. Set the local AS number. In Junos OS Release 9.1 and later, the autonomous system (AS) numeric range in plain-number format is extended to provide BGP support for 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. In Junos OS Release 9.3 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65546 in plain-number format is represented as 1.10 in the AS-dot notation format.

Options

alias—(Optional) Configure the local AS as an alias of the global AS number configured

for the router at the [edit routing-options] hierarchy level. As a result, a BGP peer considers any local AS to which it is assigned as equivalent to the primary AS number configured for the routing device. When you use the alias option, only the AS (global or local) used to establish the BGP session is prepended in the AS path sent to the BGP neighbor. autonomous-system—AS number. 32

Range: 1 through 4,294,967,295 (2

– 1) in plain-number format

Range: 0.0 through 65535.65535 in AS-dot notation format loops number—(Optional) Specify the number of times detection of the AS number in

the AS_PATH attribute causes the route to be discarded or hidden. For example, if you configure loops 1, the route is hidden if the AS number is detected in the path

1346



one or more times. This is the default behavior. If you configure loops 2, the route is hidden if the AS number is detected in the path two or more times. Default: 1 Range: 1 through 10 no-prepend-global-as—(Optional) Specify to strip the global AS and to prepend only the

local AS in AS paths sent to external peers. private—(Optional) Configure to use the local AS only during the establishment of the

BGP session with a BGP neighbor but to hide it in the AS path sent to external BGP peers. Only the global AS is included in the AS path sent to external peers.

NOTE: The private and alias options are mutually exclusive. You cannot configure both options with the same local-as statement.




•

family on page 1327

•

Example: Configuring a Local AS for EBGP Sessions on page 1164


1347


local-interface Syntax Hierarchy Level

Release Information

Description


1348

local-interface interface-name; [edit logical-systems logical-system-name protocols bgp group group-name neighbor ipv6-link-local-address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor ipv6-link-local-address], [edit protocols bgp group group-name neighbor ipv6-link-local-address], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor ipv6-link-local-address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Specify the interface name of the EBGP peer that uses IPv6 link-local addresses. This peer is link-local in scope. interface-name—Interface name of the EBGP IPv6 peer.


Configuring EBGP Peer Using IPv6 Link-Local Addresses



local-preference Syntax Hierarchy Level

Release Information

Description

local-preference local-preference; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Modify the value of the LOCAL_PREF path attribute, which is a metric used by IBGP sessions to indicate the degree of preference for an external route. The route with the highest local preference value is preferred. The LOCAL_PREF path attribute always is advertised to internal BGP peers and to neighboring confederations. It is never advertised to external BGP peers.

Default Options

If you omit this statement, the LOCAL_PREF path attribute, if present, is not modified. local-preference—Preference to assign to routes learned from BGP or from the group or

peer. 32

Range: 0 through 4,294,967,295 (2

– 1)

Default: If the LOCAL_PREF path attribute is present, do not modify its value. If a BGP route is received without a LOCAL_PREF attribute, the route is handled locally (it is stored in the routing table and advertised by BGP) as if it were received with a LOCAL_PREF value of 100. By default, non-BGP routes that are advertised by BGP are advertised with a LOCAL_PREF value of 100. Required Privilege Level Related Documentation



•

Example: Configuring the Local Preference Value for BGP Routes on page 1131


1349


log-updown Syntax Hierarchy Level

Release Information

Description


1350

log-updown; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Log a message whenever a BGP peer makes a state transition. Messages are logged using the system logging mechanism located at the [edit system syslog] hierarchy level. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

traceoptions on page 1388

•

Configuring System Logging of BGP Peer State Transitions

•




logical-systems Syntax



logical-systems { logical-system-name { ...logical-system-configuration... } } [edit]

Statement introduced before Junos OS Release 7.4. Statement name changed from logical-routers in Junos OS Release 9.3. (M Series, MX Series, and T Series routers only) Configure a logical system. logical-system-name—Name of the logical system.


Configuring a Logical System


1351


loops Syntax Hierarchy Level


loops number; [edit logical-systems logical-system-name protocols bgp family address-family], [edit logical-systems logical-system-name protocols bgp group group-name family address-family], [edit logical-systems logical-system-name protocols bgp group group-name local-as], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family address-family], [edit logical-systems logical-system-nameprotocols bgp group group-name neighbor address local-as] [edit logical-systems logical-system-name protocols bgp local-as], [edit logical-systems logical-system-name routing-options autonomous-system as-number], [edit protocols bgp family address-family], [edit protocols bgp group group-name family address-family], [edit protocols bgp group group-name local-as], [edit protocols bgp group group-name neighbor address family address-family], [edit protocols bgp group group-name neighbor address local-as] [edit protocols bgp local-as], [edit routing-options autonomous-system as-number]

Statement introduced in Junos OS Release 9.6. Globally, for the local-AS BGP attribute, or the specified address family, allow the local device’s AS number to be in the received AS paths, and specify the number of times detection of the local device’s AS number in the AS_PATH attribute causes the route to be discarded or hidden. For example, if you configure loops 1, the route is hidden if the local device’s AS number is detected in the path one or more times. This prevents routing loops and is the default behavior. If you configure loops 2, the route is hidden if the local device’s AS number is detected in the path two or more times. Some examples of BGP address families are as follows: •

inet unicast

•

inet-vpn multicast

•

inet6 any

•

l2vpn auto-discovery-only

•

...

This list is truncated for brevity. For a complete list of protocol families for which you can specify the loops statement, enter the help apropos loops configuration command at the [edit protcols bgp] hierarchy level on your device. [edit protocols bgp] user@host# help apropos loops set family inet unicast loops Allow local AS in received AS paths set family inet unicast loops AS-Path loop count set family inet multicast loops

1352



Allow local AS in received AS paths set family inet multicast loops AS-Path loop count set family inet flow loops Allow local AS in received AS paths set family inet flow loops AS-Path loop count set family inet any loops Allow local AS in received AS paths set family inet any loops AS-Path loop count set family inet labeled-unicast loops Allow local AS in received AS paths ...

NOTE: When you configure the loops statement for a specific BGP address family, that value is used to evaluate the AS path for routes received by a BGP peer for the specified address family, rather than the loops value configured for the global AS number with the loops statement at the [edit routing-options autonomous-system as-number] hierarchy level.

Options

number—Number of times detection of the AS number in the AS_PATH attribute causes

the route to be discarded or hidden. Range: 1 through 10 Default: 1 Required Privilege Level Related Documentation



•

family on page 1327

•

local-as on page 1346


1353



Release Information

Description

metric-out (metric | minimum-igp offset | igp (delay-med-update | offset); [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. delay-med-update option introduced in Junos OS Release 9.0. Metric for all routes sent using the multiple exit discriminator (MED, or MULTI_EXIT_DISC) path attribute in update messages. This path attribute is used to discriminate among multiple exit points to a neighboring AS. If all other factors are equal, the exit point with the lowest metric is preferred. You can specify a constant metric value by including the metric option. For configurations in which a BGP peer sends third-party next hops that require the local system to perform next-hop resolution—IBGP configurations, configurations within confederation peers, or EBGP configurations that include the multihop command—you can specify a variable metric by including the minimum-igp or igp option. You can increase or decrease the variable metric calculated from the IGP metric (either from the igp or minimum-igp statement) by specifying a value for offset. The metric is increased by specifying a positive value for offset, and decreased by specifying a negative value for offset. In Junos OS Release 9.0 and later, you can specify that a BGP group or peer not advertise updates for the MED path attributes used to calculate IGP costs for BGP next hops unless the MED is lower. You can also configure an interval to delay when MED updates are sent by including the med-igp-update-interval minutes at the [edit routing-options] hierarchy level.

Options

delay-med-update—Specify that a BGP group or peer configured with the metric-out igp

statement not advertise MED updates unless the current MED value is lower than

1354



the previously advertised MED value, or another attribute associated with the route has changed, or the BGP peer is responding to a refresh route request.

NOTE: You cannot configure the delay-med–update statement at the global BGP level.

igp—Set the metric to the most recent metric value calculated in the IGP to get to the

BGP next hop. Routes learned from an EBGP peer usually have a next hop on a directly-connected interface and thus the IGP value is equal to zero. This is the value advertised. metric—Primary metric on all routes sent to peers. 32

Range: 0 through 4,294,967,295 (2

– 1)

Default: No metric is sent. minimum-igp—Set the metric to the minimum metric value calculated in the IGP to get

to the BGP next hop. If a newly calculated metric is greater than the minimum metric value, the metric value remains unchanged. If a newly calculated metric is lower, the metric value is lowered to that value. When you change a neighbor’s export policy from any configuration to a configuration that sets the minimum IGP offset on an exported route, the advertised MED is not updated if the value would increase as a result, even if the previous configuration does not use a minimum IGP-based MED value. This behavior helps to prevent unnecessary route flapping when an IGP cost changes, by not forcing a route update if the metric value increases past the previous lowest known value. offset—(Optional) Increases or decreases the metric by this value. 31

31

Range: –2 through 2 – 1 Default: None Required Privilege Level Related Documentation


med-igp-update-interval on page 190

•

Example: Configuring the MED Attribute Directly on page 1069


1355


mtu-discovery Syntax Hierarchy Level

Release Information

Description

mtu-discovery; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure TCP path maximum transmission unit (MTU) discovery. TCP path MTU discovery enables BGP to automatically discover the best TCP path MTU for each BGP session. In the Junos OS, TCP path MTU discovery is disabled by default for all BGP neighbor sessions. When MTU discovery is not enabled, TCP sessions that are not directly connected transmit packets of 512-byte maximum segment size (MSS). These small packets minimize the chances of packet fragmentation at a device along the path to the destination. However, because most links use an MTU of at least 1500 bytes, 512-byte packets do not result in the most efficient use of link bandwidth. For directly connected EBGP sessions, MTU mismatches prevent the BGP session from being established. As a workaround, enable path MTU discovery within the EBGP group. Path MTU discovery dynamically determines the MTU size on the network path between the source and the destination, with the goal of avoiding IP fragmentation. Path MTU discovery works by setting the Don’t Fragment (DF) bit in the IP headers of outgoing packets. When a device along the path has an MTU that is smaller than the packet, the device drops the packet. The device also sends back an ICMP Fragmentation Needed (Type 3, Code 4) message that contains the device’s MTU, thus allowing the source to reduce its path MTU appropriately. The process repeats until the MTU is small enough to traverse the entire path without fragmentation.


1356





•

Configuring the Junos OS for IPv6 Path MTU Discovery

•

Configuring the Junos OS for Path MTU Discovery on Outgoing GRE Tunnel Connections


1357


multihop Syntax

Hierarchy Level

Release Information

Description

multihop { no-nexthop-change; ttl ttl-value; } [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure an EBGP multihop session. An external confederation peer is a special case that allows unconnected third-party next hops. You do not need to configure multihop sessions explicitly in this particular case; multihop behavior is implied. If you have external BGP confederation peer-to-loopback addresses, you still need the multihop configuration. You cannot configure the accept-remote-nexthop statement at the same time.

Default

If you omit this statement, all EBGP peers are assumed to be directly connected (that is, you are establishing a nonmultihop, or “regular,” BGP session), and the default time-to-live (TTL) value is 1.

Options

no-nexthop-change—Specify that the BGP next-hop value not be changed. For route

advertisements, specify the no-nexthop-self option. ttl ttl-value—Configure the maximum TTL value for the TTL in the IP header of BGP

packets. Range: 1 through 255 Default: 64 (for multihop EBGP sessions, confederations, and IBGP sessions)

1358






multipath Syntax

Hierarchy Level

Release Information

Description

Options

multipath { multiple-as; } [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Allow load sharing among multiple EBGP paths and multiple IBGP paths. A path is considered a BGP equal-cost path (and will be used for forwarding) if a tie-break is performed. The tie-break is performed after the BGP route path selection step that chooses the next-hop path that is resolved through the IGP route with the lowest metric. All paths with the same neighboring AS, learned by a multipath-enabled BGP neighbor, are considered. multiple-as—Disable the default check requiring that paths accepted by BGP multipath

must have the same neighboring AS. Required Privilege Level Related Documentation



•

Example: Load-Balancing BGP Traffic on page 1115


1359


neighbor Syntax

1360

neighbor address { accept-remote-nexthop; advertise-external ; advertise-inactive; (advertise-peer-as | no-advertise-peer-as); as-override; authentication-algorithm algorithm; authentication-key key; authentication-key-chain key-chain; cluster cluster-identifier; damping; description text-description; export [ policy-names ]; family { (inet | inet6 | inet-mvpn | inet6-mpvn | inet-vpn | inet6-vpn | iso-vpn | l2-vpn) { (any | flow | multicast | unicast | signaling) { accepted-prefix-limit { maximum number; teardown ; } prefix-limit { maximum number; teardown ; } rib-group group-name; } flow { no-validate policy-name; } labeled-unicast { accepted-prefix-limit { maximum number; teardown ; } aggregate-label { community community-name: } explicit-null { connected-only; } prefix-limit { maximum number; teardown ; } resolve-vpn; rib inet.3; rib-group group-name; } } route-target { advertise-default; external-paths number;



accepted-prefix-limit { maximum number; teardown ; } prefix-limit { maximum number; teardown ; } } signaling { prefix-limit { maximum number; teardown ; } } } graceful-restart { disable; restart-time seconds; stale-routes-time seconds; } hold-time seconds; import [ policy-names ]; ipsec-sa ipsec-sa; keep (all | none); local-address address; local-as autonomous-system ; local-interface interface-name; local-preference preference; log-updown; metric-out (metric | minimum-igp | igp ); mtu-discovery; multihop ; multipath { multiple-as; } no-aggregator-id; no-client-reflect; out-delay seconds; passive; peer-as autonomous-system; preference preference; tcp-mss segment-size; traceoptions { file filename ; flag flag ; } vpn-apply-export; }

Hierarchy Level

[edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name]


1361


Release Information

Description

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Explicitly configure a neighbor (peer). To configure multiple BGP peers, include multiple neighbor statements. By default, the peer’s options are identical to those of the group. You can override these options by including peer-specific option statements within the neighbor statement. The neighbor statement is one of the statements you can include in the configuration to define a minimal BGP configuration on the routing device. (You can include an allow all statement in place of a neighbor statement.)

Options

address—IPv6 or IPv4 address of a single peer.


1362


Minimum BGP Configuration

•




no advertise-peer-as Syntax Hierarchy Level

Release Information


no-advertise-peer-as; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Reenable the default behavior of suppressing AS routes. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



1363


no-aggregator-id Syntax Hierarchy Level

Release Information

Description

no-aggregator-id; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Prevent different routers within an AS from creating aggregate routes that contain different AS paths. Junos OS performs route aggregation, which is the process of combining the characteristics of different routes so that only a single route is advertised. Aggregation reduces the amount of information that BGP must store and exchange with other BGP systems. When aggregation occurs, the local routing device adds the local AS number and the router ID to the aggregator path attiribute. The no-aggregator-id statement causes Junos OS to place a 0 in the router ID field and thus eliminate the possibility of having multiple aggregate advertisements in the network, each with different path information.


1364

If you omit this statement, the router ID is included in the BGP aggregator path attribute. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Update Messages on page 979



no-client-reflect Syntax Hierarchy Level

Release Information

Description


no-client-reflect; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Disable intracluster route redistribution by the system acting as the route reflector. Include this statement when the client cluster is fully meshed to prevent the sending of redundant route advertisements. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

cluster on page 1320

•

Configuring BGP Route Reflection


1365


no-validate Syntax Hierarchy Level

Release Information


1366

no-validate policy-name; [edit protocols bgp group group-name family (inet | inet flow)], [edit protocols bgp group group-name neighbor address family (inet | inet flow)], [edit routing-instances routing-instance-name protocols bgp group group-name family (inet | inet flow)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet flow)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Omits the flow route validation procedure after packets are accepted by a policy. policy-name—Import policy to match NLRI messages.





out-delay Syntax Hierarchy Level

Release Information

Description

Default

Options

out-delay seconds; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify how long a route must be present in the Junos OS routing table before it is exported to BGP. Use this time delay to help bundle routing updates. If you omit this statement, routes are exported to BGP immediately after they have been added to the routing table. seconds—Output delay time.





1367


outbound-route-filter Syntax

Hierarchy Level

Release Information

outbound-route-filter { bgp-orf-cisco-mode; prefix-based { accept { (inet | inet6); } } } [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced in Junos OS Release 9.2. Statement introduced in Junos OS Release 9.2 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series.

Description

Configure a BGP peer to accept outbound route filters from a remote peer.

Options

accept—Specify that outbound route filters from a BGP peer be accepted. inet—Specify that IPv4 prefix-based outbound route filters be accepted. inet6—Specify that IPv6 prefix-based outbound route filters be accepted.

NOTE: You can specify that both IPv4 and IPv6 outbound route filters be accepted.

prefix-based—Specify that prefix-based filters be accepted.

The bgp-orf-cisco-mode statement is explained separately. Required Privilege Level

1368





•


passive Syntax Hierarchy Level

Release Information

Description

Default


passive; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Do not send active open messages to the peer. Rather, wait for the peer to issue an open request. If you omit this statement, all explicitly configured peers are active, and each peer periodically sends open requests until its peer responds. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Example: Preventing BGP Session Flaps When VPN Families Are Configured on page 1023


1369


path-count Syntax Hierarchy Level


path-count number; [edit logical-systems logical-system-name protocols bgp group group-name family inet unicast add-path send], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet unicast add-path send], [edit protocols bgp group group-name family inet unicast add-path send], [edit protocols bgp group group-name family inet unicast add-path neighbor address family inet unicast add-path send]

Statement introduced in Junos OS Release 11.3. Specify the number of paths to a destination to advertise. number—Number of paths to a destination to advertise.


1370



•




path-selection Syntax

Hierarchy Level

Release Information

Description Default

Options

path-selection { (always-compare-med | cisco-non-deterministic | external-router-id); as-path-ignore; med-plus-igp { igp-multiplier number; med-multiplier number; } } [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit protocols bgp], [edit routing-instances routing-instance-name protocols bgp]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. med-plus-igp option introduced in Junos OS Release 8.1. as-path-ignore option introduced in Junos OS Release 10.2. Configure BGP path selection. If the path-selection statement is not included in the configuration, only the multiple exit discriminators (MEDs) of routes that have the same peer ASs are compared. always-compare-med—Always compare MEDs whether or not the peer ASs of the

compared routes are the same.

NOTE: We recommend that you configure the always-compare-med option.

as-path-ignore—Skip the third step of the of the algorithm that determines the active

route. By default, the third step of the algorithm evaluates the length of an AS path.

NOTE: The as-path-ignore statement is not supported with routing instances.

cisco-non-deterministic—Configure routing table path selection so that it is performed

using the same nondeterministic behavior as the Cisco IOS software. The active path is always first. All inactive, but eligible, paths follow the active path and are maintained in the order in which they were received, with the most recent path first. Ineligible paths remain at the end of the list.


1371


external-router-id—Compare the router ID between external BGP paths to determine the

active path. igp-multiplier number—The multiplier value for the IGP cost to a next-hop address. This

option is useful for making the MED and IGP cost comparable. Range: 1 through 1000 Default: 1 med-multiplier number—The multiplier value for the MED calculation. This option is useful

for making the MED and IGP cost comparable. Range: 1 through 1000 Default: 1 med-plus-igp—Add the IGP cost to the indirect next-hop destination to the MED before

comparing MED values for path selection. This statement only affects best-path selection. It does not affect the advertised MED. Required Privilege Level Related Documentation

1372



•




peer-as Syntax Hierarchy Level

Release Information

Description

peer-as autonomous-system; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the neighbor (peer) AS number. For EBGP, the peer is in another AS, so the AS number you specify in the peer-as statement must be different from the local router’s AS number, which you specify in the autonomous-system statement. For IBGP, the peer is in the same AS, so the two AS numbers that you specify in the autonomous-system and peer-as statements must be the same.. The autonomous system (AS) numeric range in plain-number format has been extended in Junos OS Release 9.1 to provide BGP support for 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. RFC 4893 introduces two new optional transitive BGP attributes, AS4_PATH and AS4_AGGREGATOR. These new attributes are used to propagate 4-byte AS path information across BGP speakers that do not support 4-byte AS numbers. RFC 4893 also introduces a reserved, well-known, 2-byte AS number, AS 23456. This reserved AS number is called AS_TRANS in RFC 4893. All releases of the Junos OS support 2-byte AS numbers. In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: .. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. With the introduction of 4-byte AS numbers, you might have a combination of routers that support 4-byte AS numbers and 2-byte AS numbers. For more information about what happens when establishing BGP peer relationships between 4-byte and 2-byte capable routers, see the following topics:


1373


Options

•

Establishing a Peer Relationship Between a 4-Byte Capable Router and a 2-Byte Capable Router Using a 2-Byte AS Number in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview.

•

Establishing a Peer Relationship Between a 4-Byte Capable Router and a 2-Byte Capable Router Using a 4-Byte AS Number in the Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview.

autonomous-system—AS number. 32

Range: 1 through 4,294,967,295 (2

– 1) in plain-number format for 4-byte AS numbers

Range: 1 through 65,535 in plain-number format for 2-byte AS numbers (this is a subset of the 4-byte range) Range: 0.0 through 65535.65535 in AS-dot notation format for 4-byte AS numbers Required Privilege Level Related Documentation



•


•


1374



precision-timers Syntax Hierarchy Level


precision-timers; [edit logical-systems logical-system-name protocols bgp], [edit protocols bgp]

Statement introduced in Junos OS Release 11.4. Enable BGP sessions to send frequent keepalive messages with a hold time as short as 10 seconds.

NOTE: The hold time is three times the interval at which keepalive messages are sent, and the hold time is the maximum number of seconds allowed to elapse between successive keepalive messages that BGP receives from a peer. When establishing a BGP connection with the local routing device, a peer sends an open message, which contains a hold-time value. BGP on the local routing device uses the smaller of either the local hold-time value or the peer’s hold-time value as the hold time for the BGP connection between the two peers. The default hold-time is 90 seconds, meaning that the default frequency for keepalive messages is 30 seconds. More frequent keepalive messages and shorter hold times might be desirable in large-scale deployments with many active sessions (such as edge or large VPN deployments). To configure the hold time and the frequency of keepalive messages, include the hold-time statement at the [edit protocols bgp] hierarchy level. You can configure the hold time at a logical system, routing instance, global, group, or neighbor level. When you set a hold time value to less than 20 seconds, we recommend that you also configure the BGP precision-timers statement. The precision-timers statement ensures that if scheduler slip messages occur, the routing device continues to send keepalive messages. When the precision-timers statement is included, keepalive message generation is performed in a dedicated kernel thread, which helps to prevent BGP session flaps.



hold-time on page 1335


1375



Release Information

Description

preference preference; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the preference for routes learned from BGP. At the BGP global level, the preference statement sets the preference for routes learned from BGP. You can override this preference in a BGP group or peer preference statement. At the group or peer level, the preference statement sets the preference for routes learned from the group or peer. Use this statement to override the preference set in the BGP global preference statement when you want to favor routes from one group or peer over those of another.

Options

preference—Preference to assign to routes learned from BGP or from the group or peer. 32

Range: 0 through 4,294,967,295 (2

– 1)

Default: 170 for the primary preference Required Privilege Level Related Documentation

1376


local-preference on page 1349

•




prefix-limit Syntax

Hierarchy Level

Release Information

Description

Options

prefix-limit { maximum number; teardown ; } [edit logical-systems logical-system-name protocols bgp family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name protocols bgp group group-name family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit protocols bgp family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit protocols bgp group group-name family (inet | inet6) (any | labeled-unicast | multicast | unicast)], [edit protocols bgp group group-name neighbor address family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit routing-instances routing-instance-name protocols bgp family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family (inet | inet6) (any | flow | labeled-unicast | multicast | unicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Limit the number of prefixes received on a BGP peer session and a rate-limit logging when injected prefixes exceed a set limit. maximum number—When you set the maximum number of prefixes, a message is logged

when that number is exceeded. 32

Range: 1 through 4,294,967,295 (2

– 1)

teardown —If you include the teardown statement, the session is torn down

when the maximum number of prefixes is reached. If you specify a percentage, messages are logged when the number of prefixes exceeds that percentage. After the session is torn down, it is reestablished in a short time unless you include the idle-timeout statement. Then the session can be kept down for a specified amount of time, or forever. If you specify forever, the session is reestablished only after you issue a clear bgp neighbor command. Range: 1 through 100


1377


idle-timeout (forever | timeout-in-minutes)—(Optional) If you include the idle-timeout

statement, the session is torn down for a specified amount of time, or forever. If you specify a period of time, the session is allowed to reestablish after this timeout period. If you specify forever, the session is reestablished only after you intervene with a clear bgp neighbor command. Range: 1 through 2400 Required Privilege Level Related Documentation


accepted-prefix-limit on page 1300

•


prefix-policy Syntax Hierarchy Level


prefix-policy [ policy-names ]; [edit logical-systems logical-system-name protocols bgp group group-name family inet unicast add-path send], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet unicast add-path send], [edit protocols bgp group group-name family inet unicast add-path send], [edit protocols bgp group group-name family inet unicast add-path neighbor address family inet unicast add-path send]

Statement introduced in Junos OS Release 11.3. Filter the paths to a destination to advertise. policy-names—Name of a policy (or a set of policies) configured at the [edit policy-options]

hierarchy level. The policy can match routes, but cannot change route attributes. Required Privilege Level Related Documentation

1378



•







receive; [edit logical-systems logical-system-name protocols bgp group group-name family inet unicast add-path], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet unicast add-path], [edit protocols bgp group group-name family inet unicast add-path], [edit protocols bgp group group-name family inet unicast add-path neighbor address family inet unicast add-path]

Statement introduced in Junos OS Release 11.3. Enable the router to receive multiple paths to a destination. You can enable the router to receive multiple paths from specified neighbors or from all neighbors. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •


•



1379


remove-private Syntax Hierarchy Level

Release Information

Description

remove-private; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. When advertising AS paths to remote systems, have the local system strip private AS numbers from the AS path. The numbers are stripped from the AS path starting at the left end of the AS path (the end where AS paths have been most recently added). The routing device stops searching for private ASs when it finds the first nonprivate AS or a peer’s private AS. If the AS path contains the AS number of the external BGP (EBGP) neighbor, BGP does not remove the private AS number.

NOTE: As of Junos OS 10.0R2 and higher, if there is a need to send prefixes to an EBGP peer that has an AS number that matches an AS number in the AS path, consider using the as-override statement instead of the remove-private statement.

The operation takes place after any confederation member ASs have already been removed from the AS path, if applicable. The Junos OS recognizes the set of AS numbers that is considered private, a range that is defined in the Internet Assigned Numbers Authority (IANA) assigned numbers document. The set of reserved AS numbers is in the range from 64,512 through 65,535. Required Privilege Level

1380





•

Example: Removing Private AS Numbers from AS Paths on page 1181

resolve-vpn Syntax Hierarchy Level



resolve-vpn; [edit logical-systems logical-system-name protocols bgp family inet labeled-unicast], [edit logical-systems logical-system-name protocols bgp group group-name family inet labeled-unicast], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet labeled-unicast], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet labeled-unicast], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family inet labeled-unicast], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet labeled-unicast], [edit protocols bgp family inet labeled-unicast], [edit protocols bgp group group-name family inet labeled-unicast], [edit protocols bgp group group-name neighbor address family inet labeled-unicast], [edit routing-instances routing-instance-name protocols bgp family inet labeled-unicast], [edit routing-instances routing-instance-name protocols bgp group group-name family inet labeled-unicast], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet labeled-unicast]

Statement introduced before Junos OS Release 7.4. Allow labeled routes to be placed in the inet.3 routing table for route resolution. These routes are then resolved for PE router connections where the remote PE is located across another AS. For a PE router to install a route in the VRF, the next hop must resolve to a route stored within the inet.3 table. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •



1381


rib Syntax Hierarchy Level



1382

rib inet.3; [edit logical-systems logical-system-name protocols bgp family inet labeled-unicast], [edit logical-systems logical-system-name protocols bgp group group-name family inet labeled-unicast], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet labeled-unicast], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet labeled-unicast], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family inet labeled-unicast], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet labeled-unicast], [edit protocols bgp family inet labeled-unicast], [edit protocols bgp group group-name family inet labeled-unicast], [edit protocols bgp group group-name neighbor address family inet labeled-unicast], [edit routing-instances routing-instance-name protocols bgp family inet labeled-unicast], [edit routing-instances routing-instance-name protocols bgp group group-name family inet labeled-unicast], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address inet labeled-unicast]

Statement introduced before Junos OS Release 7.4. You can allow both labeled and unlabeled routes to be exchanged in a single session. The labeled routes are placed in the inet.3 routing table, and both labeled and unlabeled unicast routes can be sent or received by the router. inet.3—Name of the routing table.






Release Information

Description Options

rib-group group-name; [edit logical-systems logical-system-name protocols bgp family inet (any | labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name family inet (any | labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet (any | labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet (any | labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family inet (any | labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (any | labeled-unicast | unicast | multicast)], [edit protocols bgp family inet (any | labeled-unicast | unicast | multicast)], [edit protocols bgp group group-name family inet (any | labeled-unicast | unicast | multicast)], [edit protocols bgp group group-name neighbor address family inet (any | labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp family inet (any | labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (any | labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (any | labeled-unicast | unicast | multicast)]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Add unicast prefixes to unicast and multicast tables. group-name—Name of the routing table group. The name must start with a letter and

can include letters, numbers, and hyphens. You generally specify only one routing table group. Required Privilege Level Related Documentation



•


•


•


•



1383


route-target Syntax

Hierarchy Level


Options

route-target { accepted-prefix-limit { maximum number; teardown ; } advertise-default; external-paths number; prefix-limit { maximum number; teardown ; } } [edit logical-systems logical-system-name protocols bgp family], [edit logical-systems logical-system-name protocols bgp group group-name family], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family], [edit protocols bgp family], [edit protocols bgp group group-name family], [edit protocols bgp group group-name neighbor address family], [edit routing-instances routing-instance-name protocols bgp group group-name family], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family]

Statement introduced before Junos OS Release 7.4. Limit the number of prefixes advertised on BGP peers specifically to the peers that need the updates. advertise-default—Advertise default routes and suppress more specific routes. external-paths number—Number of external paths accepted for route filtering.

Range: 1 through 256 paths Default: 1 path The remaining statements are explained separately. Required Privilege Level Related Documentation

1384


Enabling BGP Route Target Filtering



send Syntax

Hierarchy Level


send { path-count number; prefix-policy [ policy-names ]; } [edit logical-systems logical-system-name protocols bgp group group-name family inet unicast add-path], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet unicast add-path], [edit protocols bgp group group-name family inet unicast add-path], [edit protocols bgp group group-name family inet unicast add-path neighbor address family inet unicast add-path]

Statement introduced in Junos OS Release 11.3. Enable advertisement of multiple paths to a destination, instead of advertising only the active path. The remaining statements are explained separately.




•



1385


session-mode Syntax Hierarchy Level


session-mode (automatic | multihop | single-hop); [edit logical-systems logical-system-name protocols bgp bfd-liveness-detection], [edit logical-systems logical-system-name protocols bgp group group-name bfd-liveness-detection], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address bfd-liveness-detection], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp bfd-liveness-detection], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name bfd-liveness-detection], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address bfd-liveness-detection], [edit protocols bgp], [edit protocols bgp group group-name bfd-liveness-detection], [edit protocols bgp group group-name neighbor address bfd-liveness-detection], [edit routing-instances routing-instance-name protocols bgp bfd-liveness-detection], [edit routing-instances routing-instance-name protocols bgp group group-name bfd-liveness-detection], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address bfd-liveness-detection]

Statement introduced in Junos OS Release 11.1. Configure BFD session mode to be single-hop or multihop. By default, BGP uses single-hop BFD sessions if the peer is directly connected to the router’s interface. BGP uses multihop BFD sessions if the peer is not directly connected to the router’s interface. If the peer session’s local-address option is configured, the directly connected check is based partly on the source address that would be used for BGP and BFD. For backward compatibility, you can override the default behavior by configuring the single-hop or multihop option. Prior to Junos OS Release 11.1, the behavior was to assume that iBGP peer sessions are multi-hop.

Options

automatic—Configures BGP to use single-hop BFD sessions if the peer is directly connected

to the router’s interface, and multihop BFD sessions if the peer is not directly connected to the router’s interface multihop—Configures BGP to use multihop BFD sessions. single-hop—Configures BGP to use single-hop BFD sessions.

Default: automatic Required Privilege Level Related Documentation

1386



•




tcp-mss Syntax Hierarchy Level

Release Information


tcp-mss segment-size; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor neighbor-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor neighbor-name], [edit protocols bgp], [edit protocol bgp group group-name], [edit protocols bgp group group-name neighbor neighbor-name], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor neighbor-name]

Statement introduced in Junos OS Release 8.1. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Configure the maximum segment size (MSS) for the TCP connection for BGP neighbors. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Example: Limiting TCP Segment Size for BGP on page 1232


1387


traceoptions Syntax

Hierarchy Level

Release Information

Description

traceoptions { file filename ; flag flag ; } [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address], [edit routing-instances routing-instance-name protocols bgp], [edit routing-instances routing-instance-name protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. 4byte-as statement introduced in Junos OS Release 9.2. 4byte-as statement introduced in Junos OS Release 9.2 for EX Series switches. Configure BGP protocol-level tracing options. To specify more than one tracing operation, include multiple flag statements.

NOTE: The traceoptions statement is not supported on QFabric switches.

Default

Options

The default BGP protocol-level tracing options are inherited from the routing protocols traceoptions statement included at the [edit routing-options] hierarchy level. The default group-level trace options are inherited from the BGP protocol-level traceoptions statement. The default peer-level trace options are inherited from the group-level traceoptions statement. disable—(Optional) Disable the tracing operation. You can use this option is to disable

a single operation when you have defined a broad group of tracing operations, such as all. file name—Name of the file to receive the output of the tracing operation. Enclose the

name within quotation marks. All files are placed in the directory /var/log. We recommend that you place BGP tracing output in the file bgp-log.

1388



files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and

so on, until the maximum number of trace files is reached. Then, the oldest trace file is overwritten. If you specify a maximum number of files, you must also specify a maximum file size with the size option. Range: 2 through 1000 files Default: 10 files flag—Tracing operation to perform. To specify more than one tracing operation, include

multiple flag statements. BGP Tracing Flags •

4byte-as—4-byte AS events.

•

bfd—BFD protocol events.

•

damping—Damping operations.

•

graceful-restart—Graceful restart events.

•

keepalive—BGP keepalive messages. If you enable the the BGP update flag only, received

keepalive messages do not generate a trace message. •

nsr-synchronization—Nonstop routing synchronization events.

•

open—Open packets. These packets are sent between peers when they are establishing

a connection. •

packets—All BGP protocol packets.

•

refresh—BGP refresh packets.

•

update—Update packets. These packets provide routing updates to BGP systems. If

you enable only this flag, received keepalive messages do not generate a trace message. Use the keepalive flag to generate a trace message for keepalive messages. Global Tracing Flags •


•


•




•


•


•


•



1389




detail—Provide detailed trace information.

•

filter—Provide filter trace information. Applies only to route and damping tracing flags.

•

receive—Trace the packets being received.

•

send—Trace the packets being transmitted.




1390


log-updown on page 1350 statement

•

Understanding Trace Operations for BGP Protocol Traffic on page 1285

•




type Syntax Hierarchy Level

Release Information

Description

type type; [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], [edit protocols bgp group group-name], [edit routing-instances routing-instance-name protocols bgp group group-name]

Statement introduced before Junos OS Release 7.4. Statement introduced in Junos OS Release 9.0 for EX Series switches. Statement introduced in Junos OS Release 11.3 for the QFX Series. Specify the type of BGP peer group. When configuring a BGP group, you can indicate whether the group is an IBGP group or an EBGP group. All peers in an IBGP group are in the same AS, while peers in an EBGP group are in different ASs and normally share a subnet.

Options


type—Type of group: •

external—External group, which allows inter-AS BGP routing

•

internal—Internal group, which allows intra-AS BGP routing




1391


vpn-apply-export Syntax Hierarchy Level



1392

vpn-apply-export; [edit logical-systems logical-system-name protocols bgp], [edit logical-systems logical-system-name protocols bgp group group-name], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address], [edit protocols bgp], [edit protocols bgp group group-name], [edit protocols bgp group group-name neighbor address]

Statement introduced before Junos OS Release 7.4. Apply a BGP export policy in addition to a VPN routing and forwarding (VRF) export policy to routes. The default action is to accept. routing—To view this statement in the configuration. routing-control—To add this statement to the configuration. •

Configuring Policies for the VRF Table on PE Routers in VPNs


PART 7

Indexes •

Index on page 1395

•

Index of Statements and Commands on page 1423


1393


1394


Index Symbols #, comments in configuration statements...................xlii ( ), in syntax descriptions....................................................xlii < >, in syntax descriptions....................................................xli [ ], in configuration statements.........................................xlii { }, in configuration statements........................................xlii | (pipe), in syntax descriptions..........................................xlii

A ABRs See area border routers accept firewall filters action........................................................................116 accept-remote-nexthop statement...........................1299 usage guidelines...........................................................1119 accepted-prefix-limit statement.................................1300 usage guidelines.........................................................1194 access statement..................................................................143 access-internal statement................................................144 access-profile statement routing instances..........................................................291 action modifiers, firewall filters........................................116 actions routing policy.................................................................681 activate OSPF.......................................................................508 active aggregate routes........................................................95 active routes.................................................................6, 7, 1150 active statement aggregate routes...........................................................145 usage guidelines...................................................101 generated routes...........................................................145 usage guidelines..................................................109 static routes....................................................................145 usage guidelines....................................................79 add-path statement BGP usage guidelines................................................1258 address statement...............................................................927 usage guidelines..........................................................924 administrative distance..............................................10, 1143 BGP See preference statement


advertise statement............................................................928 usage guidelines..........................................................924 advertise-external statement.......................................1303 usage guidelines.........................................................1237 advertise-inactive statement........................................1304 usage guidelines...............................................1146, 1237 advertise-peer-as statement........................................1305 usage guidelines.........................................................1239 advertising multiple paths to a destination BGP..........................................................1302, 1370, 1385 aggregate routes............................................................95, 146 preferences.............................................................10, 1143 aggregate statement...........................................................146 usage guidelines.............................................................95 aggregate-label statement............................................1306 aggregator statement.........................................................148 alert (system logging severity level)..............................197 all (tracing flag)....................................................................229 allow statement..................................................................1307 alternate preferences...............................................................6 always compare, BGP MED option.............................1069 always-compare-med option....................................7, 1150 any-sender statement RIP.....................................................................................867 usage guidelines..........................................................857 apply-path statement firewall filter match condition...............................1229 area border routers backbone area See backbone area description......................................................................513 overview.........................................................................498 area statement .....................................................................750 usage guidelines, backbone.....................................514 usage guidelines, multiarea......................................516 area-range statement..........................................................751 usage guidelines..........................................................558 areas See area border routers; backbone area; NSSAs; stub areas overview.........................................................................498 AS boundary routers overview.........................................................................499 AS external link advertisements....................................502 AS path ignoring in route selection........................................1153 as-override statement.....................................................1308 as-path (tracing flag).......................................................1388

1395


as-path statement...............................................................148 aggregate routes usage guidelines..................................................100 generated routes usage guidelines..................................................108 static routes usage guidelines....................................................76 as-path-ignore usage guidelines...........................................7, 1150, 1153 as-path-ignore option........................................................1371 ASs configuring..............................................................120, 151 paths.................................................................................977 aggregate routes........................................100, 148 generated routes........................................148, 160 operations, tracing...........................................1388 static routes....................................................76, 148 private, removing..................................1180, 1181, 1380 ASs (autonomous systems) area border routers......................................................513 breaking into confederations................................1049 stub areas See stub areas auth (tracing flag)...............................................................890 authentication See of routes algorithm BGP........................................................................1058 IS-IS.........................................................................349 BGP...................................................................................979 IPsec OSPFv2........................................................586, 595 OSPFv3 .................................................................595 IS-IS..................................................................................349 keychains BGP........................................................................1058 IS-IS.........................................................................349 MD5 BGP........................................................................1058 multiple keys........................................................592 OSPFv2..................................................................586 single key...............................................................590 OSPFv2...........................................................................586 OSPFv3............................................................................587 simple OSPFv2..................................................................586 RIP............................................................................843 authentication configuration BFD...........................................89, 366, 623, 848, 1254

1396

authentication-algorithm statement BGP.................................................................................1309 usage guidelines...............................................1058 IS-IS usage guidelines.................................................350 authentication-key statement BGP..................................................................................1310 usage guidelines...............................................1058 IS-IS..................................................................................434 usage guidelines........................................347, 350 RIP....................................................................................868 usage guidelines.................................................843 authentication-key-chain statement..................435, 1311 BGP usage guidelines...............................................1058 IS-IS usage guidelines.................................................350 usage guidelines........................................................1058 authentication-type statement IS-IS..................................................................................436 usage guidelines..................................................347 RIP....................................................................................869 usage guidelines.................................................843 auto-discovery-only statement BGP...................................................................................1312 auto-export routing instance............................................................150 auto-export statement.......................................................150 usage guidelines.................................................274, 278 autonomous statement....................................................949 usage guidelines..........................................................946 autonomous systems See ASs autonomous-system statement......................................151 usage guidelines...........................................................120

B backbone area configuring......................................................................514 description......................................................................513 overview.........................................................................498 backbone router overview.........................................................................499 backup-spf-options statement OSPF.................................................................................753 bandwidth-based metrics OSPF................................................................................567 bandwidth-based-metrics statement.........................754 usage guidelines...........................................................572


Index

BFD authentication...............................................................621 authentication configuration.....................89, 366, 623, 848, 1254 configuring......................................................................618 protocol..........................81, 356, 615, 844, 1243, 1244 traceoptions statement usage guidelines....................................................86 with IBGP...........................................................1243, 1244 bfd statement.........................................................................153 bfd-liveness-detection statement BGP...................................................................................1313 usage guidelines................................................1244 IS-IS..................................................................................437 usage guidelines.................................................356 OSPF................................................................................756 usage guidelines..................................................618 RIP.....................................................................................870 usage guidelines.................................................844 static routes....................................................................155 usage guidelines...............................................71, 81 BGP See multipath administrative distance.....................................10, 1143 advertising multiple paths to a destination.................1257, 1258, 1302, 1370, 1385 aggregator path attribute.......................................1364 AS numbers, peers.....................................................1373 ASs See ASs authentication.......................................979, 1058, 1310 authentication algorithm.......................................1309 authentication keychain............................................1311 autonomous system override...............................1308 best external route advertising............................................................1237 BFD................................................1243, 1244, 1313, 1386 BGP_L2VPN_AD_NLRI...............................................1312 CLNS......................................................................1217, 1218 communities aggregate routes...................................................99 generated routes..................................................107 static routes.............................................................75 confederations....................................................162, 1321 configuration statements.......................................1293 description....................................................................1001 EBGP IPv6 peering.....................................................990 enabling on router.......................................................1317 external (EBGP)................................................977, 1001 FEC 129............................................................................1312 filtering paths to a destination..............................1378


graceful restart.............................................................1331 groups.......................................................982, 1067, 1332 hold time.............................................................979, 1335 identifier..........................................................................979 idle-after-switch-over statement.......................1336 ignoring the AS path attribute in route selection.....................................................................1153 indirect next hops........................................................1119 injecting OSPF routes into BGP..................681, 1029 internal (IBGP)...................................................977, 1001 IP address.......................................................................979 IPsec.......................................................1063, 1064, 1339 IPv6..................................................................................1196 logical systems...................................................990 keepalive messages......................................980, 1388 LDP-based Layer 2 VPN and VPLS update messages ..................................................................1312 local address....................................................1001, 1344 local AS.......................................................1161, 1164, 1174 local interface.............................................................1348 local preference.................................................1130, 1131 MED........................................................1069, 1082, 1095 messages.......................................................................978 MP-BGP..............................................................1190, 1327 MTU discovery............................................................1356 multihop sessions.....................................................1358 multipath configuration.............................................1115 Multitopology Routing configuring..............................................................321 neighbors BGP, peers See BGP, peers NLRI..................................................................................979 IPv4 VPN...............................................................1190 IPv6 VPN...............................................................1190 open messages.....................................979, 1023, 1369 outbound route filter................................................1240 outbound route filters interoperability....................................................1318 overview.............................................................976, 1000 packets, tracing..........................................................1388 passive mode..............................................................1023 path attributes....................................................977, 979 peers...............................................977, 1001, 1067, 1360 point-to-point peer session (configuration editor).........................................................................983 policy, routing...................................................1326, 1337 precedence...................................................................1236 preferences.......................................10, 1143, 1145, 1376

1397


prefix-limit accepted...............................................................1194 received..................................................................1193 private AS............................................................1180, 1181 receiving multiple paths to a destination..........1379 resolve routes to other tables................................1195 route reflection................................................1320, 1365 route target filtering..................................................1384 router identifier.....................................................122, 219 routes................................................................................977 routing instances configure................................................................250 routing tables delays in exchanging routes...............1239, 1367 nonactive routes..........................1146, 1237, 1304 retaining routes...................................................1341 scaling.............................................................................1375 session drops...............................................................1022 set local AS number.................................................1346 system log messages...............................................1023 TCP.......................................................................976, 1000 TCP segment size.......................................................1232 tracing operations.....................................................1388 4-byte AS events...............................................1285 BFD protocol events........................................1285 damping operations........................................1285 description...........................................................1285 graceful restart..................................................1285 keepalive messages.........................................1285 NSR synchronization.......................................1285 open PDUs...........................................................1285 policy processing..............................................1285 protocol task processing................................1285 protocol timer processing..............................1285 refresh PDUs.......................................................1285 route information..............................................1285 state transitions.................................................1285 update PDUs......................................................1285 type, group.....................................................................1391 update messages........................................................979 version supported...........................................976, 1000 VPNs preventing session flaps................................1023 with BFD.............................................................1243, 1244 BGP (Border Gateway Protocol) confederations See BGP confederations for CLNS VPN NLRI.....................................................1217 internal peer session (configuration editor)........................................................................1001

1398

peering sessions See BGP peers; BGP sessions point-to-point internal peer session logical systems...................................................1012 route reflectors See BGP route reflectors route-flap damping...................................................1186 BGP confederations creating (configuration editor)..............................1051 description...................................................................1049 route-flap damping...................................................1186 BGP groups confederations (configuration editor)................1051 BGP Monitoring Protocol..................................................1319 configuring....................................................................1282 BGP peers external (configuration editor)..............................983 internal............................................................................1012 internal (configuration editor)..............................1001 point-to-point connections....................................982 BGP route reflectors cluster of clusters......................................................1034 creating (configuration editor).............................1035 description...................................................................1033 multiple clusters........................................................1033 BGP sessions internal............................................................................1012 internal (configuration editor)..............................1001 point-to-point external (configuration editor).........................................................................983 sample peering session............................................982 bgp statement.......................................................................1317 bgp-orf-cisco-mode usage guidelines........................................................1240 bgp-orf-cisco-mode statement....................................1318 BGP_L2VPN_AD_NLRI........................................................1312 Bidirectional Forwarding Detection See BFD bmp statement....................................................................1319 usage guidelines.........................................................1282 BOOTP accepting packets........................................................132 Border Gateway Protocol See BGP braces, in configuration statements................................xlii brackets angle, in syntax descriptions......................................xli square, in configuration statements.......................xlii brief statement......................................................................159 aggregate routes usage guidelines...................................................101 generated routes usage guidelines..................................................109


Index

broadcast mode, router discovery.................................924 broadcast statement..........................................................928 usage guidelines..........................................................924

C check-zero statement........................................................872 usage guidelines...........................................................851 checksum statement.........................................................439 usage guidelines..........................................................369 Cisco non-deterministic, BGP MED option..............1069 cisco-non-deterministic option.......................7, 1150, 1371 class of service-based forwarding, configure............272 CLNS.......................................................................................1340 BGP.........................................................................1217, 1218 static routes.....................................................................70 CLNS (Connectionless Network Service) VPNs BGP, to carry CLNS VPN NLRI................................1217 clns-routing statement IS-IS..................................................................................439 usage guidelines.................................................402 cluster statement...............................................................1320 usage guidelines........................................................1035 clusters See BGP route reflectors color statement aggregate routes...........................................................201 usage guidelines....................................................98 generated routes..........................................................201 usage guidelines..................................................106 static routes....................................................................201 usage guidelines....................................................74 comments, in configuration statements.......................xlii communities aggregate routes..................................................99, 160 generated routes...........................................................107 static routes............................................................75, 160 community statement aggregate routes..........................................................160 usage guidelines....................................................98 generated routes..........................................................160 usage guidelines...................................................107 Multitopology Routing...............................................326 usage guidelines...................................................321 static routes...................................................................160 usage guidelines....................................................75 complete sequence number PDUs, IS-IS See IS-IS, complete sequence number PDUs confederation statement.........................................162, 1321 usage guidelines............................................................122


confederations......162, 1049, 1321 See BGP c o n f e d e r a t i o n s config-internal (tracing flag)...........................................229 configuration mode, CLI statement hierarchy.......................................................17 contributing routes aggregate routes............................................................95 generated routes..........................................................103 conventions text and syntax................................................................xli count (firewall filter action)...............................................116 credibility-protocol-preference traffic engineering IS-IS..........................................................................491 critical (system logging severity level)..........................197 cryptographic-address statement................................965 usage guidelines..........................................................962 csn (tracing flag).................................................................489 csnp-interval statement...................................................440 usage guidelines..........................................................369 curly braces, in configuration statements.....................xlii current-hop-limit statement...........................................950 usage guidelines..........................................................943 customer support...................................................................xlii contacting JTAC..............................................................xlii

D damping......................................................................1322, 1388 damping (tracing flag).....................................................1388 damping statement...........................................................1322 usage guidelines..........................................................1187 database description packets.........................................501 database-protection statement OSPF................................................................................760 dead-interval statement....................................................762 usage guidelines...........................................................610 debug (system logging severity level)...........................197 default route configuring on logical systems.............428, 719, 725 default-lifetime statement..............................................950 usage guidelines..........................................................943 default-lsa statement.........................................................763 usage guidelines..........................................................528 default-metric statement.................................................764 usage guidelines................................................524, 528

1399


defaults statement aggregate statement..................................................146 usage guidelines....................................................95 generate statement......................................................172 usage guidelines..................................................103 static statement...........................................................223 usage guidelines.....................................................61 delay statement IS-IS.................................................................................486 OSPF.................................................................................819 delay-med-update statement usage guidelines........................................................1095 demand-circuit statement OSPF................................................................................765 usage guidelines..................................................547 RIP.....................................................................................873 usage guidelines..................................................857 usage guidelines............................................................671 description statement.............................................292, 1323 usage guidelines.........................................................1001 designated router configuring.......................................................................511 controlling election.......................................................511 IS-IS...................................................................................391 OSPF................................................................................509 destination-networks statement....................................163 usage guidelines...........................................................134 destination-port (firewall filter match condition).............................................................................114 detection-time statement BFD....................................................................................155 BGP...................................................................................1313 IS-IS..................................................................................437 DHCP accepting.........................................................................132 diagnosis verifying OSPF host reachability............................747 verifying OSPF neighbors.........................................745 verifying OSPF routes................................................746 verifying OSPF-enabled interfaces.......................744 disable statement BGP..................................................................................1324 graceful restart usage guidelines...................................................132 IS-IS..................................................................................442 graceful restart....................................................446 LDP synchronization.........................................443 usage guidelines......................................389, 400

1400

OSPF.................................................................................767 LDP synchronization..........................................766 router discovery...........................................................929 routing options usage guidelines...................................................127 disabling multicast on an interface.................................127 discard (firewall filter action)............................................116 discard statement aggregate routes..........................................................164 generated routes..........................................................164 discard statement, in static statement usage guidelines.............................................................63 documentation comments on..................................................................xlii domain-id statement.........................................................768 usage guidelines..........................................................284 domain-vpn-tag statement.............................................768 usage guidelines..........................................................284 dscp (firewall filter match condition)............................114 duplicating routes from one routing table into another.....................278 Dynamic Host Configuration Protocol DHCP See DHCP dynamic tunnels....................................................................165 source................................................................................221 dynamic-tunnels statement.............................................165 usage guidelines...........................................................134

E EBGP See BGP EBGP (external BGP) route-flap damping...................................................1186 EBGP IPv6 peering, BGP...................................................990 emergency (system logging severity level).................197 enable statement routing options...............................................................181 usage guidelines...................................................127 enabling multicast on an interface.................................127 equal-cost paths..................................................................6, 11 error (system logging severity level)..............................197 error (tracing flag) IS-IS.................................................................................489 neighbor discovery.....................................................958 OSPF................................................................................824 RIP....................................................................................890 RIPng.................................................................................917 router discovery...........................................................936


Index

Ethernet interfaces, unnumbered as next-hop interface for static routes..................64 configuration example.........................................67 example tracing ospf traffic.......................................................739 except (firewall filter match condition).........................114 expiration (tracing flag)......................................................917 neighbor discovery.....................................................958 explicit-null statement.....................................................1325 export statement BGP.................................................................................1326 usage guidelines.................................................1237 forwarding table...........................................................166 usage guidelines..........................................125, 128 IS-IS..................................................................................443 usage guidelines.................................................406 OSPF................................................................................769 RIP.....................................................................................874 usage guidelines.................................................855 RIPng...............................................................................905 usage guidelines................................................900 export statement, for routing policies........................1029 export-rib statement...........................................................166 usage guidelines............................................................123 external-preference statement IS-IS..................................................................................444 usage guidelines.................................................393 OSPF.................................................................................770 usage guidelines..................................................574 external-router-id option.............................................7, 1150

F family statement BGP..................................................................................1327 usage guidelines................................................1190 IS-IS..................................................................................445 usage guidelines.................................................398 fate-sharing statement.......................................................167 fault tolerance advertising multiple paths to a destination....................................................1257, 1258 FBF, configuring.....................................................................270 FEC 129.....................................................................................1312 file command logical systems...........................................................1286 filter statement......................................................................168 usage guidelines............................................................118


filter-based forwarding configuring......................................................................270 Multitopology Routing................................................321 filtering paths to a destination BGP..................................................................................1378 flap damping.........................................................................1186 parameters....................................................................1187 flash (tracing flag)...............................................................229 flood reduction......................................................................565 flood-reduction statement................................................771 flooding (tracing flag)........................................................824 flow routes...............................................................................169 BGP.................................................................................1202 flow statement............................................................169, 1327 usage guidelines.................................................113, 1202 font conventions......................................................................xli forwarding table aggregate routes..................................................101, 159 generated routes.................................................109, 159 overview...............................................................................5 policy, routing................................................................166 static routes.............61, 77, 78, 79, 101, 109, 145, 179, 210 synchronizing......................................................................5 forwarding-cache statement............................................170 usage guidelines...........................................................128 forwarding-class (firewall filter action)........................116 forwarding-table statement.............................................170 usage guidelines...........................................................128 fragment-offset (firewall filter match condition).............................................................................114 fragmentation avoiding..........................................................................1232 full mesh requirement fulfilling with confederations................................1049 fulfilling with route reflectors................................1033 full statement.........................................................................159 aggregate routes usage guidelines...................................................101 generated routes usage guidelines..................................................109 full-neighbors statement OSPF usage guidelines..................................................618

G general (tracing flag)..........................................................229 neighbor discovery.....................................................958 RIPng.................................................................................917

1401


generate statement..............................................................172 usage guidelines..................................................103, 105 generated routes....................................................................172 preferences.............................................................10, 1143 graceful restart.......................................................................132 disabling.........................................................................628 disabling strict LSA checking..................................639 enabling..........................................................................628 grace period interval..................................................628 OSPFv2 helper mode disabling.................................................................632 re-enabling............................................................632 OSPFv3 helper mode disabling.................................................................635 re-enabling............................................................635 overview..........................................................................626 graceful-restart (tracing flag) IS-IS.................................................................................489 OSPF................................................................................824 graceful-restart statement BGP...................................................................................1331 IS-IS.................................................................................446 usage guidelines..................................................397 OSPF.................................................................................772 RIP.....................................................................................875 usage guidelines.................................................856 RIPng...............................................................................906 usage guidelines..................................................901 usage guidelines.................................................132, 626 grace period..........................................................628 helper mode...............................................632, 635 strict LSA checking............................................639 group statement BGP..................................................................................1332 RIP.....................................................................................876 usage guidelines.................................................854 RIPng................................................................................907 usage guidelines.................................................899 groups OSPF areas.....................................................................516

hello-authentication-key statement............................447 IS-IS usage guidelines.................................................390 hello-authentication-key-chain statement..............448 hello-authentication-type statement.........................449 usage guidelines..........................................................390 hello-interval statement IS-IS.................................................................................450 usage guidelines.................................................390 OSPF.................................................................................774 usage guidelines..................................................610 hello-padding statement...................................................451 usage guidelines...........................................................401 helper-disable statement IS-IS.................................................................................446 usage guidelines...........................................................397 hold-time statement BGP.................................................................................1335 IS-IS..................................................................................452 LDP synchronization..........................................453 usage guidelines..................................................391 OSPF LDP synchronization..........................................775 holddown (tracing flag)...........................................890, 917 neighbor discovery.....................................................958 holddown statement IS-IS.................................................................................486 OSPF.................................................................................819 RIP.....................................................................................878 usage guidelines.................................................853 RIPng...............................................................................908 usage guidelines.................................................898 holddown-interval statement BFD static routes...........................................................155 BFD (static routes usage guidelines.....................................................81 host reachability verifying for an OSPF network.................................747

I H hello (tracing flag) IS-IS.................................................................................489 hello packets IS-IS..................................................................................339 OSPF.................................................................................501

1402

IBGP See BGP IBGP (internal BGP) full mesh (configuration editor)............................982 ICMP router discovery.........................................................923 icmp-code (firewall filter match condition)................114 icmp-type (firewall filter match condition).................114 icons defined, notice................................................................xl


Index

identifiers BGP See BGP, identifier router See router identifier idle-after-switch-over statement................................1336 ignore statement..................................................................928 usage guidelines..........................................................924 ignore-attached-bit statement......................................454 usage guidelines..........................................................343 ignore-lsp-metrics statement IS-IS..................................................................................454 usage guidelines.................................................399 OSPF.................................................................................775 IGP plus MED, BGP option..............................................1069 igp shortcuts overview.........................................................................648 import statement BGP..................................................................................1337 usage guidelines.................................................1237 OSPF.................................................................................776 RIP.....................................................................................879 usage guidelines.................................................852 RIPng...............................................................................909 usage guidelines.................................................897 route resolution..............................................................174 usage guidelines..................................................136 import statement, for routing policies.......................1029 import-policy statement....................................................175 usage guidelines............................................................123 import-rib statement...........................................................176 usage guidelines............................................................123 include-mp-next-hop statement.................................1338 independent domain overview..........................................................................289 independent-domain statement.....................................177 usage guidelines..........................................................289 indirect next hop...........................................................136, 178 indirect-next-hop statement............................................178 usage guidelines...........................................................136 ineligible statement............................................................935 inet.0 routing table...................................................................4 inet.1 routing table.....................................................................4 inet.2 routing table............................................................4, 60 inet.3 routing table....................................................................4 inet6.0 routing table.........................................................4, 60 info (system logging severity level)................................197 info (tracing flag).................................................................936 input statement.....................................................................178 usage guidelines............................................................118


install statement...................................................................179 usage guidelines..............................................................77 instance type, configuring.................................................266 instance-export statement...............................................180 usage guidelines...........................................................274 instance-import statement..............................................180 usage guidelines...........................................................274 instance-name.inet.0 routing table...................................4 instance-role statement....................................................294 instance-type statement..................................................293 usage guidelines..........................................................266 instances routing, multiple...........................................................235 inter-area-prefix-export statement OSPFv3.............................................................................777 usage guidelines..........................................................695 inter-area-prefix-import statement OSPFv3............................................................................778 usage guidelines..........................................................704 interface broadcast configuring.............................................................541 point-to-multipoint configuring............................................................546 point-to-point configuring.............................................................541 interface statement IS-IS........................................................................295, 455 usage guidelines.................................................355 multicast scoping.........................................................182 usage guidelines..................................................126 multicast via static routes..........................................181 neighbor discovery.......................................................951 usage guidelines.................................................942 OSPF.......................................................................295, 779 usage guidelines........................................541, 543 router discovery...........................................................930 routing options usage guidelines...................................................127 static routes usage guidelines....................................................64 interface-group (firewall filter match condition).............................................................................114 interface-routes statement...............................................183 usage guidelines...........................................................125 interface-type statement...................................................781 usage guidelines..........................................................543

1403


interfaces broadcast.......................................................................540 demand circuit.............................................................540 NBMA..............................................................................540 overview.........................................................................540 passive............................................................................540 passive traffic engineering mode.........................540 peer..................................................................................540 point-to-multipoint....................................................540 point-to-point..............................................................540 interfaces descriptive text.................................................292 Intermediate System-to-Intermediate System protocol See IS-IS internal routers description.....................................................................498 overview.........................................................................499 Internet Control Message Protocol router discovery See router discovery IPsec authentication OSPFv2...........................................................................586 OSPFv3............................................................................587 IPsec security associations OSPFv2...........................................................................586 OSPFv3............................................................................587 ipsec-sa statement.............................................................783 BGP.................................................................................1339 OSPF usage guidelines...................................................671 usage guidelines..............................................595, 1064 ipv4-multicast statement IS-IS..................................................................................456 usage guidelines...........................................................372 ipv4-multicast-metric statement..................................457 usage guidelines...........................................................372 IPv6 addressing..........................................................................13 representation.........................................................14 structure....................................................................14 types............................................................................14 benefits...............................................................................12 BGP..................................................................................1196 EBGP link-local peering...........................................990 header fields......................................................................13 logical systems............................................................990 ipv6-multicast statement IS-IS..................................................................................457 ipv6-multicast-metric statement.................................458 ipv6-unicast statement.....................................................458 usage guidelines..........................................................387

1404

ipv6-unicast-metric statement......................................459 IS-IS addresses.......................................................................338 areas................................................................................388 authentication.................................347, 349, 434, 472 CSNP........................................................................472 hello..........................................................................473 hitless keychain...................................................350 PSNP.......................................................................476 authentication keychain.................................435, 448 BFD..........................................................................356, 437 checksum.............................................................369, 401 CLNS......................................................................402, 439 export BGP routes..............................................402 pure ISO network...............................................402 complete sequence number PDUs.............................................339, 369, 440, 489 configuration statements.........................................343 configuring on logical systems......................419, 428 designated router...............................................391, 482 disabling.....................................................389, 405, 442 IPv4 multicast topology....................................372 IPv4 unicast topology........................................372 IPv6 multicast topology....................................372 IPv6 routing..........................................................405 IPv6 unicast topology.......................................387 enabling...............................................................405, 460 IPv6 routing..........................................................405 errored packets............................................................489 graceful restart...................................................397, 446 disable.....................................................................397 hello interval.........................................................390, 450 packet authentication...........................390, 449 packet authentication key...............................447 PDUs.............................................................339, 489 hold time................................................................391, 452 hold-down timer disabling..................................................................471 interfaces........................................................................455 IP fast reroute...............................................................409 IPv4 unicast topology.................................................477 IPv6 unicast topology......................................458, 476 label-switched path....................................................461 LDP synchronization........................................369, 443 hold time................................................................453 level properties global......................................................................463 interfaces..............................................................464


Index

link protection IS-IS...........................................................................411 link-protection statement.......................................465 link-state PDUs See IS-IS, LSPs loop-free alternate routes.......................................409 loose authentication........................................401, 465 LSPs.......................................................................339, 489 errored.....................................................................418 interval..........................................................370, 466 lifetime..........................................................394, 467 tracing....................................................................489 mesh groups..............................................370, 418, 469 metrics..........................................................391, 392, 483 IPv6..........................................................................459 multicast......................................................457, 458 normal....................................................................470 traffic engineering..............................................487 wide...............................................................393, 492 multicast reverse-path forwarding......................400 multicast topologies.......................371, 372, 456, 457 IPv4..........................................................................474 IPv6..........................................................................475 network PDUs...............................................................337 no-eligible-backup statement................................473 node link protection............................................411, 477 NSAP................................................................................338 overloaded, marking router as......................395, 478 packets See IS-IS, PDUs padding...................................................................401, 451 partial sequence number PDUs..................339, 489 PDUs................................................................................339 point-to-point interface.................................387, 480 policy, routing.....................................................406, 443 preferences...................10, 393, 406, 444, 480, 1143 prefix limit.............................................................394, 481 protocol data units See IS-IS, PDUs route tagging.................................................................340 routing domains..........................................................464 routing instances configure.................................................................251 routing instances minimum configuration.........245 RSVP LSP backup paths............................................412 SPF delay calculations.............................................489 standards supported.................................................340 topology.........................................................................488 tracing operations......................................................489 complete sequence number PDUs..............416 CSN PDUs..............................................................416 description.............................................................416


error PDUs..............................................................416 graceful restart.....................................................416 hello PDUs.............................................................416 LDP synchronization..........................................416 LSP generation.....................................................416 LSPs.........................................................................416 NSR synchronization..........................................416 partial sequence number PDUs....................416 policy processing.................................................416 protocol task processing..................................416 protocol timer processing................................416 route information................................................416 SPF delay calculations......................................416 state transitions...................................................416 traffic engineering support......................391, 398, 400, 442, 485, 491 wide metrics..................................................................393 isis statement.......................................................................460 usage guidelines...........................................................347 ISO addresses.......................................................................338 system identifier..........................................................338 iso-vpn statement.............................................................1340 usage guidelines................................................1217, 1218

K keep statement....................................................................1341 usage guidelines.........................................................1239 keepalive (tracing flag) BGP.................................................................................1388 keepalive messages...........................................................980 kernel (tracing flag).............................................................229 key-length statement........................................................966 usage guidelines..........................................................963 key-pair statement.............................................................966 usage guidelines..........................................................963 keychain BGP.................................................................................1058 IS-IS..................................................................................349 overview........................................................................1057

L label-switched path advertising configuring............................................................659 label-switched-path advertising overview.................................................................659

1405


label-switched-path statement IS-IS...................................................................................461 usage guidelines.................................................394 OSPF................................................................................784 usage guidelines.................................................659 labeled-unicast statement.............................................1342 last resort, route of generated routes See generated routes Layer 2 VPN routing instances minimum configuration....................................245 LDP routing instances configure multiple..............................................255 minimum configuration...................................246 LDP-based Layer 2 VPN and VPLS update messages BGP...................................................................................1312 ldp-synchronization statement IS-IS..................................................................................462 usage guidelines.................................................369 OSPF................................................................................785 usage guidelines.................................................583 level statement IS-IS interfaces..............................................................464 protocol..................................................................463 usage guidelines..........................................................388 lifetime statement................................................................931 usage guidelines..........................................................925 link-mtu statement.............................................................952 usage guidelines..........................................................943 link-protection statement................................................465 OSPF................................................................................786 link-protection-statement usage guidelines............................................................411 link-state acknowledgment packets See OSPF, link-state acknowledgment packets link-state advertisements See OSPF, link-state advertisements link-state PDUs See IS-IS, LSPs load balancing advertising multiple paths to a destination....................................................1257, 1258 load sharing.................................................................................11 load-balance statement usage guidelines...........................................................1115 local AS BGP...............................................................1161, 1164, 1174

1406

local statement OSPF.................................................................................816 usage guidelines...................................................671 local-address statement BFD....................................................................................155 usage guidelines.....................................................81 BGP.................................................................................1344 usage guidelines.........................................................1001 local-as statement............................................................1346 usage guidelines...............................................1164, 1174 local-interface statement BGP.................................................................................1348 usage guidelines.........................................................990 local-preference statement...........................................1349 usage guidelines...........................................................1131 log (firewall filter action)....................................................116 log-updown statement....................................................1350 BGP usage guidelines................................................1023 logging routing protocol process...................................135, 197 logging, routing protocol process...........................135, 197 logical systems configuring default route........................428, 719, 725 configuring IS-IS.................................................419, 428 configuring OSPF..............................713, 719, 725, 730 configuring routing policy.......................428, 719, 725 EBGP with IPv6 interfaces..........................................990 internal BGP..................................................................1012 viewing system files on...........................................1286 logical-systems statement..............................................1351 loops statement BGP address family...................................................1352 loose-authentication-check statement IS-IS..................................................................................465 usage guidelines..................................................401 loss-priority (firewall filter action)..................................116 LSAs See OSPF, link-state advertisements lsp (tracing flag)..................................................................489 lsp-generation (tracing flag)...........................................489 lsp-interval statement.......................................................466 usage guidelines..........................................................370 lsp-lifetime statement.......................................................467 usage guidelines..........................................................394 lsp-metric-into-summary statement...........................787 lsp-next-hop statement.....................................................184 usage guidelines............................................................68 lsp-next-hop, static routes......................................184, 198


Index

LSPs..........................................................................................339 MPLS, fate-sharing......................................................167 See also IS-IS, LSPs, MPLS

M managed-configuration statement..............................952 usage guidelines..........................................................944 manuals comments on..................................................................xlii martian addresses........................................................110, 185 martians statement.............................................................185 usage guidelines.............................................................112 match conditions firewall filters overview...................................................................114 routing policy................................................................680 max-advertisement-interval statement...........932, 953 ICMP usage guidelines.................................................925 neighbor discovery usage guidelines.................................................945 max-areas statement........................................................468 usage guidelines..........................................................393 max-retrans-time statement.........................................880 maximum-paths statement.............................................187 usage guidelines..........................................................288 maximum-prefixes statement........................................189 usage guidelines..........................................................288 MD5 authentication..........................................................1058 BGP.................................................................................1058 multiple keys configuring............................................................592 single key configuring............................................................590 understanding..............................................................586 md5 statement OSPF................................................................................788 usage guidelines multiple keys........................................................592 single key...............................................................590 MED See BGP MED (multiple exit discriminator) always compare option..........................................1069 Cisco non-deterministic option...........................1069 plus IGP option..........................................................1069 med-igp-update-interval statement............................190 usage guidelines........................................................1095 med-plus-igp statement...................................................1371 usage guidelines.....................................................7, 1150


members statement usage guidelines............................................................122 mesh groups................................................................370, 469 mesh-group statement.....................................................469 usage guidelines..........................................................370 message-size statement...................................................881 usage guidelines..........................................................852 metric traffic engineering.......................................................648 metric statement...................................................................191 aggregate routes...........................................................192 usage guidelines....................................................98 BGP usage guidelines...............................................1082 CLNS usage guidelines....................................................70 generated routes...........................................................192 IS-IS..................................................................................470 usage guidelines..................................................391 OSPF................................................................................789 usage guidelines........................................568, 671 qualified next hop........................................................193 usage guidelines....................................................64 static routes....................................................................192 usage guidelines.............................................68, 74 metric-in statement RIP.....................................................................................882 RIPng................................................................................910 usage guidelines.................................................898 usage guidelines..........................................................852 metric-out statement BGP.................................................................................1354 usage guidelines...............................................1069 RIP.....................................................................................883 usage guidelines.................................................856 RIPng..................................................................................911 usage guidelines................................................900 metric-type statement........................................................791 usage guidelines...........................................................791 metrics IS-IS...............................................................391, 392, 483 OSPF........................................................................567, 812 RIP....................................................................................856 RIPng....................................................................898, 900 static routes......................................................................74 min-advertisement-interval statement............933, 953 neighbor discovery usage guidelines.................................................945 usage guidelines..........................................................925

1407


minimum-interval usage guidelines.........................................................1244 minimum-interval statement BFD....................................................................................155 usage guidelines.....................................................81 BGP...................................................................................1313 IS-IS..................................................................................437 OSPF................................................................................756 usage guidelines..................................................618 RIP.....................................................................................870 usage guidelines.................................................844 minimum-receive-interval statement BFD....................................................................................155 usage guidelines.....................................................81 BFD (BGP) usage guidelines................................................1244 BGP...................................................................................1313 IS-IS..................................................................................437 usage guidelines.................................................356 OSPF................................................................................756 RIP.....................................................................................870 usage guidelines.................................................844 minimum-receive-ttl statement BFD....................................................................................155 BFD (static routes) usage guidelines.....................................................81 MP-BGP...............................................................60, 1190, 1327 MPLS ultimate-hop popping..............................................1325 mpls.0 routing table.................................................................4 MSDP configuring multiple instances...............................256 MSDP routing instances, minimum configuration.....................................................................246 mtu-discovery statement...............................................1356 multiarea adjacency OSPF................................................................................533 multiarea network................................................................516 multicast scoping.............................................................................126 multicast statement............................................................194 router discovery...........................................................934 usage guidelines.................................................924 routing options usage guidelines..................................................126 multicast-rpf-routes statement.....................................470 IS-IS usage guidelines................................................400

1408

multihop BGP..................................................................................1105 multihop statement..........................................................1358 usage guidelines.........................................................1105 multipath statement.........................................................1359 usage guidelines...........................................................1115 multiple active routes..............................................................6 multiplier statement BFD....................................................................................155 usage guidelines.....................................................81 BFD (BGP) usage guidelines................................................1244 BGP...................................................................................1313 IS-IS..................................................................................437 usage guidelines.................................................356 OSPF................................................................................756 usage guidelines..................................................618 RIP.....................................................................................870 usage guidelines.................................................844 multiprotocol BGP IPv6 example...............................................................1196 multiprotocol BGP (MP-BGP)............................1190, 1327 Multitopology Routing BGP configuring..............................................................321 community statement..............................................326 filter-based forwarding...............................................321 OSPF configuring..............................................................314 overview.........................................................................309 static routes...................................................................320 topologies configuring..............................................................313

N neighbor discovery autoconfiguration.......................................................944 autonomous........................................................946 basics...............................................................................939 configuration statements..................................34, 941 enabling..........................................................................942 frequency.......................................................................945 hop limit..........................................................................943 MTU option....................................................................943 neighbor solicitation, frequency............................945 onlink...............................................................................946 preferred lifetime.........................................................947 prefix information.......................................................946 reachable time.............................................................945


Index

router advertisements...............................................942 router lifetime...............................................................943 standards documents..............................................940 valid lifetime..................................................................947 neighbor statement BGP.................................................................................1360 OSPF.................................................................................792 usage guidelines.................................................546 RIP....................................................................................884 usage guidelines.................................................842 RIPng.................................................................................912 usage guidelines.................................................897 neighbor-discovery statement........................................967 usage guidelines..........................................................962 neighbors BGP........................................................................977, 1001 OSPF................................................................................543 RIP.....................................................................................842 RIPng................................................................................897 network layer reachability information See BGP, NLRI See NLRI network link advertisements...........................................502 network PDUs........................................................................337 network protocol data units See IS-IS, network PDUs network service access point..........................................338 network-summary-export statement..........................793 usage guidelines..........................................................695 network-summary-import statement.........................794 usage guidelines..........................................................704 networks sample BGP confederations.................................1050 sample BGP MED use.............................................1068 sample BGP peer session........................................982 sample BGP route reflector (one cluster)......................................................................1033 sample BGP route reflectors (cluster of clusters)....................................................................1034 sample BGP route reflectors (multiple clusters)....................................................................1034 sample multiarea OSPF routing.............................513 sample OSPF network with stubs and NSSAs..........................................................................523 sample OSPF topology.............................................746 next-hop statement.............................................................195 CLNS usage guidelines....................................................70 next-table statement usage guidelines.............................................................63


NLRI BGP_L2VPN_AD_NLRI...............................................1312 NLRI (network layer reachability information), BGP for CLNS..........................................................................1217 NLRI, BGP................................................................................979 no-adaptation BFD (BGP) usage guidelines................................................1244 no-adaptation statement BFD....................................................................................155 BFD (IS-IS) usage guidelines.................................................356 BFD (static routes) usage guidelines.....................................................81 BGP...................................................................................1313 IS-IS..................................................................................437 OSPF................................................................................756 RIP.....................................................................................870 usage guidelines.................................................844 no-adjacency-down-notification statement..............471 configuration guidelines............................................415 no-adjacency-holddown statement..............................471 usage guidelines...........................................................401 no-advertise-peer-as statement.................................1363 usage guidelines.........................................................1239 no-aggregator-id statement..........................................1364 no-authentication-check statement............................472 usage guidelines...........................................................347 no-autonomous statement usage guidelines..........................................................946 no-check-zero statement.................................................872 usage guidelines...........................................................851 no-client-reflect statement...........................................1365 no-csnp-authentication statement..............................472 usage guidelines...........................................................347 no-domain-vpn-tag statement......................................794 no-eligible-backup statement........................................473 OSPF................................................................................795 no-hello-authentication statement..............................473 usage guidelines...........................................................347 no-indirect-next-hop statement usage guidelines...........................................................136 no-install statement............................................................179 usage guidelines..............................................................77 no-interface-state-traps statement.............................796 no-ipv4-multicast statement..........................................474 usage guidelines...........................................................372 no-ipv4-routing statement...............................................474

1409


no-ipv6-multicast statement..........................................475 usage guidelines...........................................................372 no-ipv6-routing statement...............................................475 usage guidelines..........................................................405 no-ipv6-unicast statement..............................................476 no-link-mtu statement .....................................................952 usage guidelines..........................................................943 no-managed-configuration statement.......................952 usage guidelines..........................................................944 no-neighbor-down-notification statement...............796 usage guidelines...........................................................415 no-nssa-abr statement......................................................797 usage guidelines..........................................................528 no-on-link statement usage guidelines..........................................................946 no-other-stateful-configuration statement usage guidelines..........................................................944 no-prepend-global-as statement usage guidelines.........................................................1164 no-psnp-authentication statement..............................476 usage guidelines...........................................................347 no-readvertise statement.................................................205 usage guidelines............................................................80 no-retain statement.............................................................210 usage guidelines.............................................................78 no-rfc-1583 statement......................................................798 usage guidelines..........................................................538 no-unicast-topology statement......................................477 usage guidelines...........................................................372 no-validate statement.....................................................1366 no-vrf-advertise statement.............................................295 usage guidelines..........................................................283 node-link-protection statement.....................................477 OSPF................................................................................799 usage guidelines IS-IS...........................................................................411 nonstop-routing statement..............................................196 usage guidelines............................................................137 normal (tracing flag)..........................................................229 neighbor discovery.....................................................958 RIPng.................................................................................917 not-so-stubby areas See NSSAs configuring.....................................................................528 notice (system logging severity level)...........................197 notice icons defined................................................................xl NPDUs See IS-IS, network PDUs NSAP.........................................................................................338 nssa configuring.....................................................................528

1410

nssa statement....................................................................800 usage guidelines..........................................................528 NSSAs (not-so-stubby areas) description......................................................................522 overview.........................................................................500

O on-link statement................................................................954 usage guidelines..........................................................946 open messages, BGP..........................................................979 Open Shortest Path First See OSPF options statement................................................................197 usage guidelines...........................................................135 ORF BGP.................................................................................1240 OSPF activation.......................................................................508 adjacencies....................................................................750 area border routers.....513, 558 See area border r o u t e r s areas..................................................................................513 configuring............................................................750 See also area border routers; backbone area; NSSAs; stub areas AS external link advertisements...........................502 authentication...............................................................752 md5..........................................................................788 simple......................................................................818 backbone...............................................................514, 750 backbone area See backbone area backup-spf-options statement.............................753 bandwidth-based metrics.......................................754 configuring.............................................................572 BFD...........................................................................615, 756 configuration overview.............................................508 configuring on logical systems..............713, 719, 725 configuring, router identifier.....................................510 controlling designated router election..................511 cost See OSPF, metrics database description packets.................................501 database protection configuring............................................................678 overview..................................................................677 statement..............................................................760 dead interval..................................................................610 default route.................................................................499 default routing policy.................................................503 demand circuits............................................................547 designated router....................................509, 543, 810


Index

domain ID configuring............................................................284 enabling.............................................295, 540, 779, 801 enabling, description.......................510, 514, 516, 519 error packets.................................................................824 flood-reduction statement........................................771 graceful restart ...................................................626, 772 hello interval...............................................610, 774, 807 hello packets..................................................................501 import policy configuring on logical systems......................730 interface types...............................................................781 IPsec authentication OSPFv2 .................................................................595 OSPFv3 .................................................................595 label-switched path...................................................784 LDP synchronization..................................................766 configuring............................................................583 hold time.................................................................775 overview.................................................................583 link-protection statement........................................786 link-state acknowledgment packets..............................502 advertisements.................................502, 610, 813 flooding packets.................................................824 request packets...................................................501 update packets...................................................502 LSAs See OSPF, link-state advertisements metrics..........................................................567, 789, 812 traffic engineering..............................................823 multiarea adjacency configuring............................................................534 overview.................................................................533 multiarea network........................................................516 NBMA networks...........................................................543 neighbors...................................................543, 792, 800 network link advertisements..................................502 no-eligible-backup statement...............................795 no-interface-state-traps..........................................796 node-link-protection statement...........................799 nonbroadcast, multiaccess networks.................543 NSSAs....................................................................763, 764 overload bit...................................................................803 packets.......................................................500, 502, 824 passive mode.....................................................550, 805 peer interfaces.............................................................806


policy, routing.......................................................769, 776 network summaries................................695, 704 network summaries, overview......................695 route install priority............................................691 preferences.........................................10, 770, 808, 1143 prefix limit............................................................563, 809 refresh..............................................................................565 route cost See OSPF, metrics route preference..........................................................495 route selection.............................................................566 route summarization.........................................558, 751 route-type-community statement........................815 usage guidelines.................................................284 router dead interval.....................................................762 router identifier.....................................................122, 510 router link advertisements.......................................502 routing algorithm..............................................495, 580 routing instances..........................................................601 routing instances, configure multiple...................247 sham link.........................................................................816 single-area network.....................................................514 SPF...............................................................495, 580, 824 stub areas.............................................................763, 764 summary link advertisements...............................502 supported software standards..............................504 tags aggregate routes..........................................101, 227 generated routes........................................109, 227 static routes....................................................77, 227 timers..............................................................................609 topological database................................................494 tracing operations.......................................................824 database description PDUs............................738 demand circuit extensions..............................738 error PDUs.............................................................738 event........................................................................738 graceful restart....................................................738 hello PDUs.............................................................738 LDP synchronization..........................................738 link-state acknowledgement PDUs............738 link-state analysis PDUs..................................738 link-state PDUs...................................................738 link-state request PDUs...................................738 link-state updates PDUs..................................738 NSR synchronization.........................................738 packet dump........................................................738 policy processing................................................738 protocol task processing..................................738 protocol timer processing...............................738

1411


restart-signaling..................................................738 route information................................................738 SPF calculations.................................................738 state transitions..................................................738 traffic control................................................................566 traffic engineering features..................................................................828 lsp metrics..............................................................775 support....................................................................817 transmission delay.............................................610, 831 transmit interval...........................................................832 virtual links............................................................519, 834 OSPF (Open Shortest Path First) injecting OSPF routes into BGP..................681, 1029 sample network topology........................................746 verifying host reachability.........................................747 verifying neighbors......................................................745 verifying RIP-enabled interfaces............................744 verifying routes.............................................................746 OSPF areas virtual links......................................................................519 OSPF database protection...............................................677 OSPF interfaces verifying...........................................................................744 OSPF metric configuring.....................................................................568 OSPF neighbors, verifying.................................................745 OSPF reference bandwidth configuring.....................................................................568 ospf statement......................................................................801 ospf3 statement..................................................................802 OSPFv2 authentication configuring.......................................588, 590, 592 overview.................................................................586 restart-signaling..........................................................824 sham link........................................................................670 OSPFv3 authentication..............................................................783 overview.................................................................587 enabling..........................................................................802 multiple address families configuring............................................................554 understanding.....................................................554 overview..........................................................................497 routing instances, configure multiple..................248 supported software standards..............................504 other-stateful-configuration statement.....................955 usage guidelines..........................................................944

1412

out-delay statement..........................................................1367 usage guidelines.........................................................1239 outbound-route-filter usage guidelines........................................................1240 outbound-route-filter statement BGP.................................................................................1368 overload statement IS-IS..................................................................................478 usage guidelines.................................................395 OSPF................................................................................803 usage guidelines...........................................................577 overloaded configuring routing devices......................................577 routing devices..............................................................576

P p2mp-lsp-next-hop statement.......................................198 usage guidelines............................................................68 packet-dump (tracing flag).............................................824 packet-length (firewall filter match condition)..........114 packets (tracing flag) BGP.................................................................................1388 IS-IS.................................................................................489 neighbor discovery.....................................................958 OSPF................................................................................824 RIP....................................................................................890 RIPng.................................................................................917 router discovery...........................................................936 parentheses, in syntax descriptions................................xlii parse (tracing flag)..............................................................229 partial sequence number PDUs See IS-IS, partial sequence number PDUs passive statement...............................................................805 aggregate routes...........................................................145 usage guidelines...................................................101 BGP.................................................................................1369 usage guidelines................................................1023 generated routes...........................................................145 usage guidelines..................................................109 IS-IS..................................................................................479 usage guidelines.......................................389, 392 OSPF usage guidelines.................................................550 static routes....................................................................145 usage guidelines....................................................79 passive traffic-engineering mode support............................................................................656 path attributes, BGP..................................................977, 979


Index

path-count statement......................................................1370 BGP usage guidelines................................................1258 path-selection statement.................................................1371 usage guidelines.....................................................7, 1150 PDUs See IS-IS, PDUs peer interfaces configuring.....................................................................552 peer-as statement..............................................................1373 peer-interface statement.................................................806 usage guidelines..........................................................552 peering sessions See BGP peers; BGP sessions per-packet load balancing................................................128 per-packet statement usage guidelines...........................................................1115 physical interfaces, descriptive text..............................292 PIM configuring multiple instances...............................263 PIM routing instances, minimum configuration.....................................................................248 Ping Host page, output for BGP.....................................989 ping-interval statement....................................................296 point-to-point statement................................................480 usage guidelines..........................................................387 policers firewall filter action.......................................................116 policy (tracing flag).............................................................229 neighbor discovery.....................................................958 RIPng.................................................................................917 policy statement aggregate routes..........................................................199 usage guidelines..................................................102 generated routes..........................................................199 usage guidelines...................................................110 policy, routing aggregate routes...........................................................102 BGP......................................................................1326, 1337 forwarding table...........................................................166 generated routes...........................................................110 IS-IS.......................................................................406, 443 OSPF.......................................................................769, 776 network summaries................................695, 704 network summaries, overview......................695 precedence...................................................................1236 RIP...........................................................................874, 879 RIPng....................................................................905, 909 routing instance............................................................180 policy-based instance export, configuring..................274


poll-interval statement......................................................807 usage guidelines..........................................................543 port (firewall filter match condition)..............................114 ppm statement....................................................................200 usage guidelines...........................................................140 precedence (firewall filter match condition)..............114 precistion-timers statement BGP..................................................................................1375 preference statement.........................................................202 aggregate routes...........................................................201 usage guidelines....................................................98 BGP..................................................................................1376 usage guidelines.................................................1145 CLNS static routes usage guidelines....................................................70 generated routes..........................................................201 usage guidelines..................................................106 IS-IS.................................................................................480 usage guidelines.................................................393 OSPF...............................................................................808 usage guidelines..................................................574 RIP....................................................................................885 usage guidelines.................................................855 RIPng.................................................................................913 usage guidelines................................................900 static routes....................................................................201 usage guidelines.....................................64, 68, 74 preferences active routes........................................................6, 7, 1150 aggregate routes...................................................98, 201 generated routes..........................................10, 1143 alternate preferences......................................................6 default......................................................................10, 1143 generated routes..........................................................106 IS-IS............................................10, 393, 444, 480, 1143 modifying with configuration statements...............10, 1143 OSPF......................................................................770, 808 overview...............................................................................6 RIP..............................................................................10, 1143 static routes............................10, 64, 68, 74, 201, 1143 tie-breaker preferences..................................................6 preferred-lifetime statement..........................................955 usage guidelines..........................................................947 prefix limit IS-IS.........................................................................394, 481 OSPF.....................................................................563, 809 prefix list statement firewall filter match condition...............................1229

1413


prefix statement...................................................................202 neighbor discovery.....................................................956 usage guidelines.................................................942 usage guidelines...........................................................126 prefix-based usage guidelines........................................................1240 prefix-export-limit statement IS-IS...................................................................................481 usage guidelines.................................................394 OSPF...............................................................................809 usage guidelines.................................................563 prefix-limit statement........................................................1377 usage guidelines...............................................1193, 1215 prefix-policy statement....................................................1378 BGP usage guidelines................................................1258 primary routing tables.........................................................123 priority statement IS-IS..................................................................................482 usage guidelines..................................................391 OSPF.................................................................................810 usage guidelines....................................................511 router discovery............................................................935 private statement usage guidelines..........................................................1174 propagation, suppressing.................................................1186 protocol data units..............................................................339 See also IS-IS, PDUs protocols firewall filter match condition..................................114 match condition firewall filters..........................................................114 protocols statement............................................................297 psn (tracing flag).................................................................489 PSNP IS-IS See IS-IS, partial sequence number PDUs

Q qualified-bum-pruning-mode statement..................299 qualified-next-hop statement..............................203, 204 CLNS usage guidelines....................................................70 usage guidelines............................................................64

R rapid-runs statement IS-IS.................................................................................486 OSPF.................................................................................819

1414

reachability verifying for OSPF network hosts...........................747 reachable-time statement...............................................956 usage guidelines..........................................................945 readvertise statement........................................................205 usage guidelines............................................................80 realm statement.....................................................................811 usage guidelines..........................................................554 receive routes...........................................................................63 receive statement...............................................................1379 BGP usage guidelines................................................1258 RIP....................................................................................886 usage guidelines.................................................853 RIPng.................................................................................914 usage guidelines.................................................898 static routes usage guidelines....................................................63 receiving multiple paths to a destination BGP..................................................................................1379 redirect (tracing flag).........................................................936 redirected routes...........................................................10, 1143 reference-bandwidth statement....................................812 IS-IS..................................................................................483 usage guidelines................................................392, 568 regex-parse (tracing flag).................................................229 reject firewall filters action........................................................................116 reject option to static statement....................................223 usage guidelines.............................................................63 remove-private statement.............................................1380 usage guidelines...........................................................1181 resolution statement..........................................................206 usage guidelines...........................................................136 resolution-ribs statement.................................................207 usage guidelines...........................................................136 resolve statement................................................................208 usage guidelines............................................................80 resolve-vpn statement......................................................1381 usage guidelines..........................................................1195 restart-duration statement..............................................209 graceful restart usage guidelines...................................................132 IS-IS.................................................................................446 usage guidelines...........................................................397 restart-signaling (tracing flag) OSPFv2...........................................................................824


Index

retain statement....................................................................210 usage guidelines......................................................78, 92 retransmit-interval statement.........................................813 usage guidelines...........................................................610 retransmit-timer statement.............................................957 usage guidelines..........................................................945 RFC 1583 disabling.........................................................................538 OSPFv2...........................................................................538 rib statement BGP.................................................................................1382 Multitopology Routing static routes...........................................................327 route resolution.............................................................214 usage guidelines..................................................136 routing tables.................................................................212 usage guidelines............................................................60 rib-group statement.............................................................215 BGP.................................................................................1383 usage guidelines................................................1190 IS-IS.................................................................................484 OSPF.................................................................................814 usage guidelines.................................................602 RIP.....................................................................................887 usage guidelines.................................................853 usage guidelines..................................................125, 278 rib-groups statement..........................................................216 usage guidelines............................................................123 RIB-groups, static routes.....................................................69 RIP authentication...................................................843, 868 BFD...................................................................................844 configuration statements........................................839 demand circuit retransmission timer..................880 demand circuits overview.................................................................857 packets...................................................................858 disable graceful restart.............................................856 disabling address checks.........................................867 enabling.................................................................841, 887 graceful restart...................................................856, 875 groups..............................................................................854 hold-down timer..........................................................878 metrics..................................................................882, 883 neighbors.............................................................842, 884 packets............................................................................836 policy, routing......................................................874, 879 preferences........................................10, 855, 885, 1143 reserved fields...............................................................872


rib-group messages...................................................853 rib-group statement usage guidelines.................................................853 route timeout...............................................................888 routing instances, configure multiple..................263 standards documents...............................................836 tracing operations authentication.....................................................863 description............................................................863 error PDUs.............................................................863 hold-down processing.....................................863 NSR synchronization.........................................863 policy processing................................................863 protocol task processing.................................863 protocol timer processing...............................863 request PDUs.......................................................863 route expiration processing............................863 route information...............................................863 state transitions..................................................863 trigger updates....................................................863 update PDUs........................................................863 UDP, use of....................................................................835 update interval.............................................................892 update messages....................................852, 853, 881 rip statement.........................................................................887 usage guidelines...........................................................841 RIPng configuration statements........................................895 disable restart...............................................................901 enabling...........................................................................915 graceful restart...................................................901, 906 groups.............................................................................899 holddown timer...........................................................908 metrics...........................................................898, 910, 911 neighbors...............................................................897, 912 overview..........................................................................893 packets...........................................................................894 policy, routing.........................................900, 905, 909 preferences..........................................................900, 913 route timeout.................................................................915 standards documents..............................................894 tracing operations description.............................................................901 error PDUs..............................................................901 hold-down processing......................................901 NSR synchronization.........................................901 policy processing.................................................901 protocol task processing..................................901 protocol timer processing................................901

1415


request PDUs........................................................901 route expiration processing.............................901 route information................................................901 state transitions...................................................901 triggered updates................................................901 update PDUs.........................................................901 UDP, use of....................................................................893 update interval..............................................................919 ripng statement.....................................................................915 usage guidelines..........................................................896 route aggregate statement usage guidelines....................................................95 generate statement usage guidelines..................................................103 static statement...........................................................223 route (tracing flag) neighbor discovery.....................................................958 RIPng.................................................................................917 routing..............................................................................229 route advertisements stub areas and NSSAs, to control.........................522 route authentication peering sessions.........................................................1057 route distinguisher................................................................218 route injection...............................681, 684, 687, 691, 1029 route limit, configuring.......................................................288 paths..................................................................................187 prefix.................................................................................189 route of last resort See generated routes route preference external routes.............................................................568 internal routes..............................................................568 route recording.......................................................................218 route redistribution.....................681, 684, 687, 691, 1029 route reflectors See BGP route reflectors BGP.................................................................................1035 route resolution......................................................................136 BGP..................................................................................1381 route selection OSPF................................................................................566 preference......................................................................568 route statement......................................................................217 access...............................................................................143 access-internal.............................................................144 aggregate statement..................................................146 generate statement......................................................172 metric.................................................................................191 next-hop..........................................................................195

1416

preference......................................................................202 qualified-next-hop.....................................................204 route access.......................................................................217 access-internal......................................................217 static statement usage guidelines.....................................................61 tag.....................................................................................228 route summarization configuring.....................................................................558 route-distinguisher statement.......................................300 usage guidelines..........................................................269 route-distinguisher-id statement...................................218 usage guidelines...........................................................133 route-flap damping............................................................1186 parameters....................................................................1187 route-record statement......................................................218 usage guidelines............................................................123 route-target statement....................................................1384 route-timeout statement RIP....................................................................................888 usage guidelines.................................................853 RIPng.................................................................................915 usage guidelines.................................................898 route-type-community statement.................................815 usage guidelines..........................................................284 router advertisements..........................924, 925, 932, 933 router discovery configuration statements.........................................923 designated router, configuring................................935 router advertisements............................921, 922, 924 router solicitations.......................................................921 server operation............................................................921 server, enabling..................................................924, 935 standards documents...............................................922 tracing operations.............................................925, 936 router functionality.............................................................498 router identifier..............................................................122, 219 configuring......................................................................510 router link advertisements................................................502 router-advertisement statement...................................957 router-discovery (tracing flag).......................................936 router-discovery statement.............................................935 usage guidelines..........................................................924 router-id statement..............................................................219 usage guidelines............................................................122 routes aggregate See aggregate routes contributing.............................................................95, 103


Index

duplicating from one routing table into another........................................................................278 static See static routes Routing Information Protocol See RIP Routing Information Protocol next generation See RIPng routing instances BGP...................................................................................244 configure.........................................................................264 IS-IS..................................................................................245 configuration example......................................252 LDP..........................................................................246, 255 MSDP...............................................................................256 multiple...........................................................................235 router.......................................................................252 second router.......................................................252 multiprotocol BGP-based multicast VPNs.............................................................................247 OSPF.................................................................................247 configuration example...........................256, 603 OSPFv3.................................................................248, 602 PIM..........................................................................248, 263 policy-based auto-export configuration example.............274 instance-import configuration example..............................................................276 RIP...........................................................................249, 263 router identifier..............................................................218 routing instances, OSPF introduction....................................................................601 routing policies applying.........................................................................1029 configuration tasks..........................681, 684, 687, 691, 1029, 1187 export statement......................................................1029 import statement......................................................1029 injecting routes from one protocol into another............................................................681, 1029 OSPF import policy...........................................687, 691 redistributing static routes into OSPF.................684 reducing update messages with flap damping....................................................................1186 route redistribution............681, 684, 687, 691, 1029 route-flap damping...................................................1186 routing policy actions..............................................................................681 configuring on logical systems.............428, 719, 725 default OSPF policies................................................503 match conditions........................................................680


overview..........................................................................503 terms...............................................................................680 routing protocol databases...................................................3 routing solutions BGP confederations, for scaling problems...................................................................1051 BGP route reflectors, for scaling problems..................................................................1035 NSSAs, to control route advertisement..............522 reducing update messages with flap damping....................................................................1186 stub areas, to control route advertisement..........................................................522 routing table verifying OSPF routes................................................746 routing tables BGP, delays in exchanging routes........................1239 creating.....................................................................60, 212 default...............................................................................60 default unicast................................................................60 duplicating routes between.....................................278 export local routes.......................................................125 flow routes.......................................................................60 group.......123, 125, 166, 168, 176, 215, 216, 814, 1383 import policy...................................................................175 inet.0.....................................................................................4 inet.1.......................................................................................4 inet.2..............................................................................4, 60 inet.3......................................................................................4 inet6.0...........................................................................4, 60 instance-name.inet.0..................................................60 instance-name.inetflow.0..........................................60 instance-name.init.0.......................................................4 mpls.0...................................................................................4 nonactive routes, exchanging with BGP.......................................................1146, 1237, 1304 overview...............................................................................4 policy, routing................................................................180 primary..............................................................................123 secondary........................................................................123 synchronizing......................................................................5 routing-instance (firewall filter action).........................116 routing-instances statement...........................................302 usage guidelines.............................239, 240, 250, 251 routing-options statement................................................219 RSVP preferences.............................................................10, 1143 RSVP LSP metrics ignoring...........................................................................648

1417


S sample (firewall filter action)...........................................116 scope statement..................................................................220 usage guidelines...........................................................126 scoping, multicast.................................................................126 secondary import and export policies, configure..............................................................................273 secondary routing tables....................................................123 secondary statement OSPF interface..............................................................815 usage guidelines................................................533, 534 Secure Neighbor Discovery cryptographic addresses configuring............................................................962 cryptographic-address statement.......................965 enabling..........................................................................962 neighbor-discovery statement...............................967 security-level statement..........................................969 timestamp statement...............................................970 secure statement................................................................968 security-level statement...................................................969 send statement.......................................................1302, 1385 BGP usage guidelines................................................1258 RIP....................................................................................889 usage guidelines.................................................853 RIPng.................................................................................916 usage guidelines.................................................898 session-mode statement BGP.................................................................................1386 sham link configuring.......................................................................671 overview..........................................................................670 sham-link statement...........................................................816 usage guidelines............................................................671 sham-link-remote statement..........................................816 usage guidelines............................................................671 shortcuts statement IS-IS..................................................................................485 usage guidelines.................................................398 OSPF.................................................................................817 Shortest Path First See SPF algorithm show bgp neighbor command......................................1054 explanation..................................................................1055 show bgp summary command....................................1056 explanation..................................................................1056 show ospf interface command.......................................744 explanation....................................................................744 show ospf neighbor command.......................................745

1418

show ospf route command..............................................746 explanation....................................................................746 simple authentication configuring OSPFv2..................................................................588 OSPFv2...........................................................................586 simple-password statement............................................818 usage guidelines..........................................................588 single-area network, OSPF................................................514 source-address statement................................................221 usage guidelines...........................................................134 source-port (firewall filter match condition)..............114 source-routing statement..................................................221 usage guidelines............................................................141 SPF.............................................................................................337 spf (tracing flag) IS-IS.................................................................................489 OSPF................................................................................824 SPF algorithm options............................................................................580 overview..........................................................................495 spf-options statement IS-IS.................................................................................486 usage guidelines.................................................396 OSPF.................................................................................819 usage guidelines..........................................................580 SSM groups, IGMP...................................................................127 ssm-groups statement.......................................................222 usage guidelines............................................................127 state (tracing flag) neighbor discovery.....................................................958 RIPng.................................................................................917 routing protocols.........................................................229 stateless firewall filters accepting Routing Engine traffic from trusted sources example: blocking TCP access....................1224 example: blocking Telnet and SSH access...............................................................1229 examples blocking TCP access........................................1224 blocking Telnet and SSH access.................1229 static options static routes.......................................................................71 static routes......................................................................61, 223 BFD..............................................................................81, 155 Multitopology Routing...............................................320 preferences.............................................................10, 1143


Index

static statement....................................................................223 usage guidelines..............................................................61 stub areas configuring.....................................................................524 description......................................................................522 overview.........................................................................499 stub statement......................................................................821 usage guidelines..........................................................524 sub-ASs, BGP......................................................................1049 subautonomous systems, BGP....................................1049 summaries statement........................................................822 usage guidelines..........................................................524 summary LSA........................................................................502 summary LSAs advertising LSP metric..............................................648 support, technical See technical support synchronizing routing information......................................5 syntax conventions.................................................................xli syslog (firewall filter action)..............................................116 syslog statement routing options..............................................................197 usage guidelines...................................................135 system ID See ISO, system identifier system identifier See ISO, system identifier system log messages routing protocol process...................................135, 197

T tag statement...............................................................227, 228 aggregate routes usage guidelines...................................................101 generated routes usage guidelines..................................................109 static routes usage guidelines.....................................................77 task (tracing flag).................................................................229 neighbor discovery.....................................................958 RIPng.................................................................................917 tcp-mss statement............................................................1387 BGP usage guidelines................................................1232 te-metric statement IS-IS..................................................................................487 OSPF................................................................................823 usage guidelines.................................................391, 654 technical support contacting JTAC..............................................................xlii terms routing policy................................................................680


threshold statement...........................................................228 BFD (BGP) usage guidelines................................................1244 BGP...................................................................................1313 IS-IS..................................................................................437 usage guidelines.................................................356 RIP usage guidelines.................................................844 usage guidelines...........................................................128 tie-breaker preferences...........................................................6 timer (tracing flag)......................................................229, 917 neighbor discovery.....................................................958 timers OSPF...............................................................................609 timestamp statement........................................................970 topologies statement IS-IS.................................................................................488 Multitopology Routing...............................................328 usage guidelines...................................................313 topology sample BGP confederations.................................1050 sample BGP MED use.............................................1068 sample BGP peer session........................................982 sample BGP route reflector (one cluster)......................................................................1033 sample BGP route reflectors (cluster of clusters)....................................................................1034 sample BGP route reflectors (multiple clusters)....................................................................1034 sample multiarea OSPF routing.............................513 sample OSPF network...............................................746 sample OSPF network with stubs and NSSAs..........................................................................523 topology statement filter-based forwarding Multitopology Routing......................................330 usage guidelines...................................................321 Multitopology Routing................................................331 OSPF........................................................................332 OSPF interface.....................................................333 usage guidelines..................................................314 topology-id statement Multitopology Routing...............................................334 totally stubby areas configuring.....................................................................524 description......................................................................522 trace files logical systems .................................................................................1286

1419


traceoptions statement BFD.....................................................................................153 usage guidelines....................................................86 BGP.................................................................................1388 description...........................................................1285 IS-IS.................................................................................489 description.............................................................416 neighbor discovery.....................................................958 usage guidelines..................................................947 OSPF......................................................................738, 824 RIP..........................................................................863, 890 RIPng........................................................................901, 917 router discovery...........................................................936 usage guidelines.................................................925 routing protocols.........................................................229 description.............................................................138 Secure Neighbor Discovery.......................................971 Traceroute page results for OSPF............................................................747 tracing flags all.......................................................................................229 as-path..........................................................................1388 auth..................................................................................890 config-internal..............................................................229 csn....................................................................................489 damping........................................................................1388 error IS-IS.........................................................................489 neighbor discovery.............................................958 OSPF.......................................................................824 RIP...........................................................................890 RIPng........................................................................917 router discovery..................................................936 expiration.........................................................................917 neighbor discovery.............................................958 flash..................................................................................229 flooding...........................................................................824 general.............................................................................229 neighbor discovery.............................................958 RIPng........................................................................917 graceful restart IS-IS.........................................................................489 OSPF.......................................................................824 hello IS-IS.........................................................................489 holddown..............................................................890, 917 neighbor discovery.............................................958 info....................................................................................936

1420

keepalive BGP........................................................................1388 kernel................................................................................229 lsp.....................................................................................489 lsp-generation..............................................................489 normal.............................................................................229 neighbor discovery.............................................958 RIPng........................................................................917 packet-dump................................................................824 packets BGP........................................................................1388 IS-IS.........................................................................489 neighbor discovery.............................................958 OSPF.......................................................................824 RIP...........................................................................890 RIPng........................................................................917 router discovery..................................................936 parse.................................................................................229 policy................................................................................229 neighbor discovery.............................................958 RIPng........................................................................917 psn....................................................................................489 redirect............................................................................936 regex-parse....................................................................229 route neighbor discovery.............................................958 RIPng........................................................................917 routing.....................................................................229 router-discovery..........................................................936 spf IS-IS.........................................................................489 OSPF.......................................................................824 state neighbor discovery.............................................958 RIPng........................................................................917 routing protocols.................................................229 task....................................................................................229 neighbor discovery.............................................958 RIPng........................................................................917 timer.................................................................................229 neighbor discovery.............................................958 RIPng........................................................................917 trigger.....................................................................890, 917 neighbor discovery.............................................958 update neighbor discovery.............................................958 RIP...........................................................................890 RIPng........................................................................917


Index

tracing operations BGP.....................................................................1285, 1388 IS-IS........................................................................416, 489 neighbor discovery.....................................................958 OSPF......................................................................738, 824 RIP..........................................................................863, 890 RIPng........................................................................901, 917 router discovery.................................................925, 936 routing protocols................................................138, 229 tracing ospf configuring......................................................................739 traffic control OSPF................................................................................566 traffic engineering advertising LSP metric in summary LSAs.........648 database credibility value.......................................648 enabling..........................................................................650 ignoring RSVP LSP metrics.....................................648 igp shortcuts.................................................................648 metric....................................................................648, 654 ospf protocol preference.........................................648 support...........................................................................648 traffic engineering database OSPF support...............................................................828 traffic-engineering statement IS-IS...................................................................................491 usage guidelines.................................................398 lsp-metric-info-summary usage guidelines.................................................650 OSPF................................................................................828 OSPF passive TE mode............................................830 usage guidelines.................................................656 shortcuts usage guidelines.................................................650 usage guidelines..........................................................650 transit areas overview.........................................................................500 transit-delay statement.....................................................831 usage guidelines...........................................................610 transmit-interval statement............................................832 BFD..............................................................................21, 155 BGP...................................................................................1313 IS-IS..................................................................................437 trigger (tracing flag)..................................................890, 917 neighbor discovery.....................................................958 tunnel-type statement........................................................231 usage guidelines...........................................................134 type statement.....................................................................1391 type-7 statement.................................................................833


U unicast reverse path check................................................231 unicast RPF example configuration................................................132 fail filters...........................................................................132 unicast-reverse-path statement.....................................231 usage guidelines............................................................131 unnumbered Ethernet interfaces as next-hop interface for static routes configuration example.........................................67 unnumbered SONET/SDH interfaces as next-hop interface for static routes..................64 update (tracing flag) neighbor discovery.....................................................958 RIP....................................................................................890 RIPng.................................................................................917 update messages BGP...................................................................................979 update-interval statement RIP.....................................................................................892 usage guidelines.................................................853 RIPng.................................................................................919 usage guidelines.................................................898

V valid-lifetime statement...................................................959 usage guidelines..........................................................947 validation statement usage guidelines............................................................113 verification BFD for IS-IS..................................................................362 BGP session flap prevention.................................1028 BMP.................................................................................1284 IS-IS policy......................................................................431 multicast topology for IS-IS.....................................378 network interfaces......................................................1277 OSPF.........................................................................717, 735 OSPF host reachability..............................................747 OSPF neighbors............................................................745 OSPF policy..........................................................723, 728 OSPF routes...................................................................746 OSPF-enabled interfaces.........................................744 tracing.............................................................................1291 version statement BFD....................................................................................155 usage guidelines.....................................................81 BFD (BGP) usage guidelines................................................1244 BGP...................................................................................1313

1421


IS-IS..................................................................................437 usage guidelines.................................................356 OSPF................................................................................756 RIP.....................................................................................870 usage guidelines.................................................844 virtual link, through the backbone area........................513 virtual links configuring......................................................................519 overview.........................................................................498 virtual-link statement........................................................834 usage guidelines...........................................................519 vlan-model statement......................................................304 VPLS routing instances minimum configuration....................................249 vpn-apply-export statement.........................................1392 VPNs BGP preventing session flaps................................1023 VRF export policy................................................................1392 VRF table label, configuring.............................................283 VRF target, configuring......................................................283 vrf-export statement..........................................................303 usage guidelines...........................................................273 vrf-import statement.........................................................303 usage guidelines...........................................................273 vrf-table-label statement................................................304 usage guidelines..........................................................283 vrf-target statement...........................................................305 usage guidelines..........................................................283

W warning (system logging severity level).......................197 wide-metrics-only statement.........................................492 usage guidelines..........................................................393

1422


Index of Statements and Commands A accept-remote-nexthop statement...........................1299 accepted-prefix-limit statement.................................1300 access statement..................................................................143 access-internal statement................................................144 access-profile statement routing instances..........................................................291 active statement aggregate routes...........................................................145 generated routes...........................................................145 static routes....................................................................145 address statement...............................................................927 advertise statement............................................................928 advertise-external statement.......................................1303 advertise-inactive statement........................................1304 advertise-peer-as statement........................................1305 aggregate statement...........................................................146 aggregate-label statement............................................1306 aggregator statement.........................................................148 allow statement..................................................................1307 any-sender statement RIP.....................................................................................867 area statement......................................................................750 area-range statement..........................................................751 as-override statement.....................................................1308 as-path statement...............................................................148 authentication-algorithm statement BGP.................................................................................1309 authentication-key statement BGP..................................................................................1310 IS-IS..................................................................................434 RIP....................................................................................868 authentication-key-chain statement..................435, 1311 authentication-type statement IS-IS..................................................................................436 RIP....................................................................................869


auto-discovery-only statement BGP...................................................................................1312 auto-export statement.......................................................150 autonomous statement....................................................949 autonomous-system statement......................................151

B backup-spf-options statement OSPF.................................................................................753 bandwidth-based-metrics statement.........................754 bfd statement.........................................................................153 bfd-liveness-detection statement BGP...................................................................................1313 IS-IS..................................................................................437 OSPF................................................................................756 RIP.....................................................................................870 static routes....................................................................155 bgp statement.......................................................................1317 bgp-orf-cisco-mode statement....................................1318 bmp statement....................................................................1319 brief statement......................................................................159 broadcast statement..........................................................928

C check-zero statement........................................................872 checksum statement.........................................................439 clns-routing statement IS-IS..................................................................................439 cluster statement...............................................................1320 color statement aggregate routes...........................................................201 generated routes..........................................................201 static routes....................................................................201 community statement aggregate routes..........................................................160 generated routes..........................................................160 Multitopology Routing...............................................326 static routes...................................................................160 confederation statement.........................................162, 1321 credibility-protocol-preference traffic engineering IS-IS..........................................................................491 cryptographic-address statement................................965 csnp-interval statement...................................................440 current-hop-limit statement...........................................950

D damping statement...........................................................1322

1423


database-protection statement OSPF................................................................................760 dead-interval statement....................................................762 default-lifetime statement..............................................950 default-lsa statement.........................................................763 default-metric statement.................................................764 defaults statement aggregate statement..................................................146 generate statement......................................................172 static statement...........................................................223 delay statement IS-IS.................................................................................486 OSPF.................................................................................819 demand-circuit statement OSPF................................................................................765 RIP.....................................................................................873 description statement.............................................292, 1323 destination-networks statement....................................163 detection-time statement BFD....................................................................................155 BGP...................................................................................1313 IS-IS..................................................................................437 disable statement BGP..................................................................................1324 IS-IS..................................................................................442 graceful restart....................................................446 LDP synchronization.........................................443 OSPF.................................................................................767 LDP synchronization..........................................766 discard statement aggregate routes..........................................................164 generated routes..........................................................164 domain-id statement.........................................................768 domain-vpn-tag statement.............................................768 dynamic-tunnels statement.............................................165

E enable statement routing options...............................................................181 explicit-null statement.....................................................1325 export statement BGP.................................................................................1326 forwarding table...........................................................166 IS-IS..................................................................................443 OSPF................................................................................769 RIP.....................................................................................874 RIPng...............................................................................905 export-rib statement...........................................................166

1424

external-preference statement IS-IS..................................................................................444 OSPF.................................................................................770

F family statement BGP..................................................................................1327 IS-IS..................................................................................445 fate-sharing statement.......................................................167 filter statement......................................................................168 flood-reduction statement................................................771 flow statement............................................................169, 1327 forwarding-cache statement............................................170 forwarding-table statement.............................................170 full statement.........................................................................159

G generate statement..............................................................172 graceful-restart statement BGP...................................................................................1331 IS-IS.................................................................................446 OSPF.................................................................................772 RIP.....................................................................................875 RIPng...............................................................................906 group statement BGP..................................................................................1332 RIP.....................................................................................876 RIPng................................................................................907

H hello-authentication-key statement............................447 hello-authentication-key-chain statement..............448 hello-authentication-type statement.........................449 hello-interval statement IS-IS.................................................................................450 OSPF.................................................................................774 hello-padding statement...................................................451 helper-disable statement IS-IS.................................................................................446 hold-time statement BGP.................................................................................1335 IS-IS..................................................................................452 LDP synchronization..........................................453 OSPF LDP synchronization..........................................775 holddown statement IS-IS.................................................................................486 OSPF.................................................................................819


Index of Statements and Commands

RIP.....................................................................................878 RIPng...............................................................................908 holddown-interval statement BFD static routes...........................................................155

I idle-after-switch-over statement................................1336 ignore statement..................................................................928 ignore-attached-bit statement......................................454 ignore-lsp-metrics statement IS-IS..................................................................................454 OSPF.................................................................................775 import statement BGP..................................................................................1337 OSPF.................................................................................776 RIP.....................................................................................879 RIPng...............................................................................909 route resolution..............................................................174 import-policy statement....................................................175 import-rib statement...........................................................176 include-mp-next-hop statement.................................1338 independent-domain statement.....................................177 indirect-next-hop statement............................................178 ineligible statement............................................................935 input statement.....................................................................178 install statement...................................................................179 instance-export statement...............................................180 instance-import statement..............................................180 instance-role statement....................................................294 instance-type statement..................................................293 inter-area-prefix-export statement OSPFv3.............................................................................777 inter-area-prefix-import statement OSPFv3............................................................................778 interface statement IS-IS........................................................................295, 455 multicast scoping.........................................................182 multicast via static routes..........................................181 neighbor discovery.......................................................951 OSPF.......................................................................295, 779 interface-routes statement...............................................183 interface-type statement...................................................781 ipsec-sa statement.............................................................783 BGP.................................................................................1339 ipv4-multicast statement IS-IS..................................................................................456 ipv4-multicast-metric statement..................................457


ipv6-multicast statement IS-IS..................................................................................457 ipv6-multicast-metric statement.................................458 ipv6-unicast statement.....................................................458 ipv6-unicast-metric statement......................................459 isis statement.......................................................................460 iso-vpn statement.............................................................1340

K keep statement....................................................................1341 key-length statement........................................................966 key-pair statement.............................................................966

L label-switched-path statement IS-IS...................................................................................461 OSPF................................................................................784 labeled-unicast statement.............................................1342 ldp-synchronization statement IS-IS..................................................................................462 OSPF................................................................................785 level statement IS-IS interfaces..............................................................464 protocol..................................................................463 lifetime statement................................................................931 link-mtu statement.............................................................952 link-protection statement................................................465 OSPF................................................................................786 local statement OSPF.................................................................................816 local-address statement BFD....................................................................................155 BGP.................................................................................1344 local-as statement............................................................1346 local-interface statement BGP.................................................................................1348 local-preference statement...........................................1349 log-updown statement....................................................1350 logical-systems statement..............................................1351 loops statement BGP address family...................................................1352 loose-authentication-check statement IS-IS..................................................................................465 lsp-interval statement.......................................................466 lsp-lifetime statement.......................................................467 lsp-metric-into-summary statement...........................787 lsp-next-hop statement.....................................................184

1425


M managed-configuration statement..............................952 martians statement.............................................................185 max-advertisement-interval statement...........932, 953 max-areas statement........................................................468 max-retrans-time statement.........................................880 maximum-paths statement.............................................187 maximum-prefixes statement........................................189 md5 statement OSPF................................................................................788 med-igp-update-interval statement............................190 med-plus-igp statement...................................................1371 mesh-group statement.....................................................469 message-size statement...................................................881 metric statement...................................................................191 aggregate routes...........................................................192 generated routes...........................................................192 IS-IS..................................................................................470 OSPF................................................................................789 qualified next hop........................................................193 static routes....................................................................192 metric-in statement RIP.....................................................................................882 RIPng................................................................................910 metric-out statement BGP.................................................................................1354 RIP.....................................................................................883 RIPng..................................................................................911 metric-type statement........................................................791 min-advertisement-interval statement............933, 953 minimum-interval statement BFD....................................................................................155 BGP...................................................................................1313 IS-IS..................................................................................437 OSPF................................................................................756 RIP.....................................................................................870 minimum-receive-interval statement BFD....................................................................................155 BGP...................................................................................1313 IS-IS..................................................................................437 OSPF................................................................................756 RIP.....................................................................................870 minimum-receive-ttl statement BFD....................................................................................155 mtu-discovery statement...............................................1356 multicast statement............................................................194 router discovery...........................................................934 multicast-rpf-routes statement.....................................470 multihop statement..........................................................1358

1426

multipath statement.........................................................1359 multiplier statement BFD....................................................................................155 BGP...................................................................................1313 IS-IS..................................................................................437 OSPF................................................................................756 RIP.....................................................................................870

N neighbor statement BGP.................................................................................1360 OSPF.................................................................................792 RIP....................................................................................884 RIPng.................................................................................912 neighbor-discovery statement........................................967 network-summary-export statement..........................793 network-summary-import statement.........................794 next-hop statement.............................................................195 no-adaptation statement BFD....................................................................................155 BGP...................................................................................1313 IS-IS..................................................................................437 OSPF................................................................................756 RIP.....................................................................................870 no-adjacency-down-notification statement..............471 no-adjacency-holddown statement..............................471 no-advertise-peer-as statement.................................1363 no-aggregator-id statement..........................................1364 no-authentication-check statement............................472 no-check-zero statement.................................................872 no-client-reflect statement...........................................1365 no-csnp-authentication statement..............................472 no-eligible-backup statement........................................473 OSPF................................................................................795 no-hello-authentication statement..............................473 no-install statement............................................................179 no-interface-state-traps statement.............................796 no-ipv4-multicast statement..........................................474 no-ipv4-routing statement...............................................474 no-ipv6-multicast statement..........................................475 no-ipv6-routing statement...............................................475 no-ipv6-unicast statement..............................................476 no-link-mtu statement......................................................952 no-managed-configuration statement.......................952 no-neighbor-down-notification statement...............796 no-nssa-abr statement......................................................797 no-psnp-authentication statement..............................476 no-readvertise statement.................................................205 no-retain statement.............................................................210



no-rfc-1583 statement......................................................798 no-unicast-topology statement......................................477 no-validate statement.....................................................1366 no-vrf-advertise statement.............................................295 node-link-protection statement.....................................477 OSPF................................................................................799 nonstop-routing statement..............................................196 nssa statement....................................................................800

O on-link statement................................................................954 options statement................................................................197 OSPF database protection statement..............................................................760 ospf statement......................................................................801 ospf3 statement..................................................................802 other-stateful-configuration statement.....................955 out-delay statement..........................................................1367 outbound-route-filter statement BGP.................................................................................1368 overload statement IS-IS..................................................................................478 OSPF................................................................................803

generated routes..........................................................201 IS-IS.................................................................................480 OSPF...............................................................................808 RIP....................................................................................885 RIPng.................................................................................913 static routes....................................................................201 preferred-lifetime statement..........................................955 prefix statement...................................................................202 neighbor discovery.....................................................956 prefix-export-limit statement IS-IS...................................................................................481 OSPF...............................................................................809 prefix-limit statement........................................................1377 prefix-policy statement....................................................1378 priority statement IS-IS..................................................................................482 OSPF.................................................................................810 router discovery............................................................935 protocols statement............................................................297

Q qualified-bum-pruning-mode statement..................299 qualified-next-hop statement..............................203, 204

R P p2mp-lsp-next-hop statement.......................................198 passive statement...............................................................805 aggregate routes...........................................................145 BGP.................................................................................1369 generated routes...........................................................145 IS-IS..................................................................................479 static routes....................................................................145 path-count statement......................................................1370 path-selection statement.................................................1371 peer-as statement..............................................................1373 peer-interface statement.................................................806 ping-interval statement....................................................296 point-to-point statement................................................480 policy statement aggregate routes..........................................................199 generated routes..........................................................199 poll-interval statement......................................................807 ppm statement....................................................................200 precistion-timers statement BGP..................................................................................1375 preference statement.........................................................202 aggregate routes...........................................................201 BGP..................................................................................1376


rapid-runs statement IS-IS.................................................................................486 OSPF.................................................................................819 reachable-time statement...............................................956 readvertise statement........................................................205 realm statement.....................................................................811 receive statement...............................................................1379 RIP....................................................................................886 RIPng.................................................................................914 reference-bandwidth statement....................................812 IS-IS..................................................................................483 remove-private statement.............................................1380 resolution statement..........................................................206 resolution-ribs statement.................................................207 resolve statement................................................................208 resolve-vpn statement......................................................1381 restart-duration statement..............................................209 IS-IS.................................................................................446 retain statement....................................................................210 retransmit-interval statement.........................................813 retransmit-timer statement.............................................957

1427


rib statement BGP.................................................................................1382 Multitopology Routing static routes...........................................................327 route resolution.............................................................214 routing tables.................................................................212 rib-group statement.............................................................215 BGP.................................................................................1383 IS-IS.................................................................................484 OSPF.................................................................................814 RIP.....................................................................................887 rib-groups statement..........................................................216 rip statement.........................................................................887 ripng statement.....................................................................915 route statement......................................................................217 access...............................................................................143 access-internal.............................................................144 aggregate statement..................................................146 generate statement......................................................172 metric.................................................................................191 next-hop..........................................................................195 preference......................................................................202 qualified-next-hop.....................................................204 route access.......................................................................217 access-internal......................................................217 tag.....................................................................................228 route-distinguisher statement.......................................300 route-distinguisher-id statement...................................218 route-record statement......................................................218 route-target statement....................................................1384 route-timeout statement RIP....................................................................................888 RIPng.................................................................................915 route-type-community statement.................................815 router-advertisement statement...................................957 router-discovery statement.............................................935 router-id statement..............................................................219 routing-instances statement...........................................302 routing-options statement................................................219

S scope statement..................................................................220 secondary statement OSPF interface..............................................................815 secure statement................................................................968 security-level statement...................................................969

1428

send statement.......................................................1302, 1385 RIP....................................................................................889 RIPng.................................................................................916 session-mode statement BGP.................................................................................1386 sham-link statement...........................................................816 sham-link-remote statement..........................................816 shortcuts statement IS-IS..................................................................................485 OSPF.................................................................................817 simple-password statement............................................818 source-address statement................................................221 source-routing statement..................................................221 spf-options statement IS-IS.................................................................................486 OSPF.................................................................................819 ssm-groups statement.......................................................222 static statement....................................................................223 stub statement......................................................................821 summaries statement........................................................822 syslog statement routing options..............................................................197

T tag statement...............................................................227, 228 tcp-mss statement............................................................1387 te-metric statement IS-IS..................................................................................487 OSPF................................................................................823 threshold statement...........................................................228 BGP...................................................................................1313 IS-IS..................................................................................437 timestamp statement........................................................970 topologies statement IS-IS.................................................................................488 Multitopology Routing...............................................328 topology statement filter-based forwarding Multitopology Routing......................................330 Multitopology Routing................................................331 OSPF........................................................................332 OSPF interface.....................................................333 topology-id statement Multitopology Routing...............................................334 traceoptions statement BGP.................................................................................1388 IS-IS.................................................................................489 neighbor discovery.....................................................958 OSPF......................................................................738, 824



RIP..........................................................................863, 890 RIPng........................................................................901, 917 router discovery...........................................................936 routing protocols.........................................................229 Secure Neighbor Discovery.......................................971 traffic-engineering statement IS-IS...................................................................................491 OSPF................................................................................828 OSPF passive TE mode............................................830 transit-delay statement.....................................................831 transmit-interval statement............................................832 BFD..............................................................................21, 155 BGP...................................................................................1313 IS-IS..................................................................................437 tunnel-type statement........................................................231 type statement.....................................................................1391 type-7 statement.................................................................833

U unicast-reverse-path statement.....................................231 update-interval statement RIP.....................................................................................892 RIPng.................................................................................919

V valid-lifetime statement...................................................959 version statement BFD....................................................................................155 BGP...................................................................................1313 IS-IS..................................................................................437 OSPF................................................................................756 RIP.....................................................................................870 virtual-link statement........................................................834 vlan-model statement......................................................304 vpn-apply-export statement.........................................1392 vrf-export statement..........................................................303 vrf-import statement.........................................................303 vrf-table-label statement................................................304 vrf-target statement...........................................................305

W wide-metrics-only statement.........................................492


1429


1430
