Config Guide Routing Ospf
-
Upload
selvakumar2k2 -
Category
Documents
-
view
271 -
download
0
Transcript of Config Guide Routing Ospf
-
7/28/2019 Config Guide Routing Ospf
1/246
Junos OS
Junos OS OSPF Configuration Guide
Release
11.4
Published: 2011-11-08
Revision1
Copyright 2011, Juniper Networks, Inc.
-
7/28/2019 Config Guide Routing Ospf
2/246
Juniper Networks, Inc.1194North Mathilda AvenueSunnyvale, California 94089USA408-745-2000www.juniper.net
Thisproduct includesthe Envoy SNMPEngine, developed by EpilogueTechnology,an IntegratedSystems Company.Copyright 1986-1997,
Epilogue Technology Corporation.All rights reserved. This program and its documentation were developed at privateexpense, and no part
of them is in thepublic 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 Kirtons EGP, UC Berkeleys routing daemon (routed), and DCNs
HELLO routing protocol. Development of Gated has beensupported in part by the National Science Foundation. Portions of the GateD
software copyright 1988, Regentsof theUniversityof California.All rights reserved. Portionsof theGateD 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 theirrespective 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 byJuniper Networks or components thereof might be covered by oneor more of thefollowingpatents 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 Junos OS OSPF Configuration GuideCopyright 2011, Juniper Networks, Inc.
All rights reserved.
Revision History
November 2011Revision 1; initial release
The informationin this document is currentas of thedatelisted in the revisionhistory.
END USER LICENSE AGREEMENT
The Juniper Networks product that is thesubject of this technical documentationconsists of (or is intended for usewith)Juniper Networks
software. Useof such software is subject to theterms and conditions of theEnd User License Agreement (EULA) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to theterms and conditions
of that EULA.
Copyright 2011, Juniper Networks, Inc.ii
http://www.juniper.net/support/eula.htmlhttp://www.juniper.net/support/eula.html -
7/28/2019 Config Guide Routing Ospf
3/246
Table of Contents
Part 1 Overview
Chapter 1 Introduction to OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
OSPF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
OSPF Default Route Preference Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
OSPF Routing Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
OSPF Three-Way Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
OSPF Version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
OSPF Areas and Router Functionality Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Area Border Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Backbone Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
AS Boundary Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Backbone Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Internal Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Stub Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Not-So-Stubby Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Transit Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Packets Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
OSPF Packet Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Hello Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Database Description Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Link-State Request Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Link-State Update Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Link-State Acknowledgment Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Link-State Advertisement Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
OSPF External Metrics Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
OSPF Designated Router Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
OSPF Extensions to Support Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . 14
OSPF IGP Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
OSPF Database Protection Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapter 2 Introduction to OSPF Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 17
BFD Authentication for OSPF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
BFD Authentication Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Security Authentication Keychains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Strict Versus Loose Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Loop-Free Alternate Routes for OSPF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
iiiCopyright 2011, Juniper Networks, Inc.
-
7/28/2019 Config Guide Routing Ospf
4/246
Part 2 Configuration
Chapter 3 OSPF Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Configuring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Minimum OSPF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Configuring OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Configuring the OSPF Backbone Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuring OSPF Nonbackbone Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuring OSPF Stub Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuring OSPF Not-So-Stubby Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Configuring OSPF Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Example: Configuring an OSPF Virtual Link . . . . . . . . . . . . . . . . . . . . . . . 32
Disabling Export of LSAs into NSSAs Attached to ASBR ABRs . . . . . . . . . . . . . . . 33
Example: Disabling OSPFv2 Compatibility with RFC 1583 . . . . . . . . . . . . . . . . . . . 33
Configuring OSPF on Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Configuring an Interface on a Broadcast or Point-to-Point Network . . . . . . . 35
Configuring an Interface on a Point-to-Multipoint Network . . . . . . . . . . . . . . 35Configuring an Interface on a Nonbroadcast, Multiaccess Network . . . . . . . . 36
Configuring an OSPF Demand Circuit Interface . . . . . . . . . . . . . . . . . . . . . . . . 37
Example: Configuring Multiarea Adjacency for OSPF . . . . . . . . . . . . . . . . . . . . . . . 37
Example: Configuring Multiple Address Families for OSPFv3 . . . . . . . . . . . . . . . . . 41
Configuring Authentication for OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Example: Configuring IPsec Authentication for an OSPFv2 Interface . . . . . . 46
Example: Configuring a Transition of MD5 Keys . . . . . . . . . . . . . . . . . . . . . . . 47
Example: Configuring MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Configuring Authentication for OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Example: Limiting the Number of Prefixes Exported to OSPF . . . . . . . . . . . . . . . . 48
Example: Controlling OSPF Designated Router Election . . . . . . . . . . . . . . . . . . . . 50
Example: Summarizing Ranges of Routes in OSPF Link-State
Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Example: Controlling the Cost of Individual OSPF Network Segments . . . . . . . . . 57
Example: Dynamically Adjusting OSPF Interface Metrics Based on
Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Example: Controlling OSPF Route Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Example: Configuring OSPF Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Configuring OSPF Refresh and Flooding Reduction in Stable Topologies . . . . . . . 71
Example: Configuring BFD for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Configuring BFD Authentication for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Configuring BFD Authentication Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Viewing Authentication Information for BFD Sessions . . . . . . . . . . . . . . . . . . 78
Example: Configuring Synchronization Between LDP and IGPs . . . . . . . . . . . . . . . 79
Example: Configuring Graceful Restart for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Example: Configuring SPF Algorithm Options for OSPF . . . . . . . . . . . . . . . . . . . . 86
Example: Configuring a Passive OSPF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Example: Configuring OSPF Passive Traffic Engineering Mode . . . . . . . . . . . . . . . 91
Example: Advertising Label-Switched Paths into OSPFv2 . . . . . . . . . . . . . . . . . . 93
Example: Configuring OSPF to Make Routing Devices Appear Overloaded . . . . 104
Example: Enabling OSPF Traffic Engineering Support . . . . . . . . . . . . . . . . . . . . . 107
Copyright 2011, Juniper Networks, Inc.iv
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
5/246
Example: Configuring the Traffic Engineering Metric for a Specific OSPF
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Applying Policies to OSPF Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Configuring Import and Export Policies for Network Summaries . . . . . . . . . . 114
Configuring Priority for Prefixes in Import Policy . . . . . . . . . . . . . . . . . . . . . . . 115
Example: Configuring a Route Filter Policy to Specify Priority for Prefixes
Learned Through OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configuring OSPF Routing Table Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Example: Configuring OSPFv2 Sham Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Example: Configuring OSPFv2 Peer interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Configuring Link Protection for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Configuring Node-Link Protection for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Excluding an OSPF Interface as a Backup for a Protected Interface . . . . . . . . . . 126
Configuring Backup SPF Options for Protected OSPF Interfaces . . . . . . . . . . . . . 127
Configuring RSVP Label-Switched Paths as Backup Paths for OSPF . . . . . . . . . 129
Example: Tracing OSPF Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Configuring OSPF Database Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Part 3 Administration
Chapter 4 Summary ofOSPF Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . 139
area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
area-range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
backup-spf-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
bandwidth-based-metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
bfd-liveness-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
database-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
dead-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
default-lsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
default-metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
demand-circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
disable (LDP Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
disable (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
domain-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
domain-vpn-tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
external-preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
flood-reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
graceful-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
hello-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
hold-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
ignore-lsp-metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
inter-area-prefix-export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
inter-area-prefix-import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
interface-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
ipsec-sa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
vCopyright 2011, Juniper Networks, Inc.
Table of Contents
-
7/28/2019 Config Guide Routing Ospf
6/246
label-switched-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
ldp-synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
link-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
lsp-metric-into-summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
md5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
metric-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
network-summary-export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
network-summary-import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
no-domain-vpn-tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
no-eligible-backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
no-interface-state-traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
no-neighbor-down-notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
no-nssa-abr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
no-rfc-1583 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
node-link-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189nssa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
ospf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
ospf3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
passive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
peer-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
poll-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
prefix-export-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
reference-bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202retransmit-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
rib-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
route-type-community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
secondary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
sham-link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
sham-link-remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
simple-password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
spf-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
stub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
te-metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
traffic-engineering (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
traffic-engineering (Passive TE Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
transit-delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
transmit-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
type-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
virtual-link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Copyright 2011, Juniper Networks, Inc.vi
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
7/246
Chapter 5 OSPF Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
OSPF Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Part 4 IndexIndex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
viiCopyright 2011, Juniper Networks, Inc.
Table of Contents
-
7/28/2019 Config Guide Routing Ospf
8/246
Copyright 2011, Juniper Networks, Inc.viii
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
9/246
List of Figures
Part 1 Overview
Chapter 1 Introduction to OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Figure 1: OSPF Three-Way Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Part 2 Configuration
Chapter 3 OSPF Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 2: IPv4 Unicast Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Figure 3: Summarizing Ranges of Routes in OSPF . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 4: OSPF Metric Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 5: Advertising an LSP into OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 6: OSPFv2 Sham Link Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
ixCopyright 2011, Juniper Networks, Inc.
-
7/28/2019 Config Guide Routing Ospf
10/246
Copyright 2011, Juniper Networks, Inc.x
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
11/246
List of Tables
Part 1 Overview
Chapter 1 Introduction to OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table 1: Default Route Preference Values for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . 5
xiCopyright 2011, Juniper Networks, Inc.
-
7/28/2019 Config Guide Routing Ospf
12/246
Copyright 2011, Juniper Networks, Inc.xii
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
13/246
PART 1
Overview
Introduction to OSPF on page 3
Introduction to OSPF Configuration Guidelines on page 17
1Copyright 2011, Juniper Networks, Inc.
-
7/28/2019 Config Guide Routing Ospf
14/246
Copyright 2011, Juniper Networks, Inc.2
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
15/246
CHAPTER 1
Introduction to OSPF
OSPF Overview on page 4
OSPF Areas and Router Functionality Overview on page 8
Packets Overview on page 10
OSPF External Metrics Overview on page 13
OSPF Designated Router Overview on page 13
OSPF Extensions to Support Traffic Engineering on page 14
OSPF Database Protection Overview on page 15
3Copyright 2011, Juniper Networks, Inc.
-
7/28/2019 Config Guide Routing Ospf
16/246
OSPF Overview
OSPFis an interiorgateway protocol (IGP) that routespackets within a singleautonomous
system (AS). OSPF uses link-state information to make routing decisions, making route
calculationsusing the shortest-path-first(SPF) algorithm(also referred to asthe Dijkstra
algorithm). Each router running OSPF floods link-state advertisements throughout the
AS or area that contain information about that routers 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 asa result explicitly supportsIP subnetting and the tagging of externally
derivedroutinginformation. OSPFalso provides forthe authenticationof routing updates.
OSPF routes IP packets based solely on the destination IP address contained in the IP
packet header. OSPFquickly detects topological changes, suchas whenrouter 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, andlink-state information foreach router is flooded throughout that
area. All routers maintain summarized topologies of other areas within an AS. Withineach 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 canparticipate in the ASsrouting.
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
OSPFlink-state data. Eachexternalroutecanbe taggedby the advertisingrouter, enablingthe passing of additional information between routers on the boundaries of the AS.
NOTE: By default, Junos OS is compatible with RFC 1583, OSPFVersion2. 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 33.
Copyright 2011, Juniper Networks, Inc.4
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
17/246
This topic describes the following information:
OSPF Default Route Preference Values on page 5
OSPF Routing Algorithm on page 5
OSPF Three-Way Handshake on page 6
OSPF Version 3 on page 7
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 1 on page 5 lists the default preference values
for OSPF.
Table 1: Default Route Preference Values for OSPF
Statement to Modify Default PreferenceDefault PreferenceHow Route Is Learned
OSPF preference10OSPF internal route
OSPF external-preference150OSPF AS external routes
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 devicestarts, it initializes OSPF andwaitsfor indications from lower-level
protocols that therouter interfaces are functional. The routing device thenusesthe OSPF
hello protocol to acquire neighbors, bysending hello packetsto itsneighbors 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 forthe network.Thisrouting 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 formadjacencies with some of its newly acquired
neighbors.(On multiaccess networks, onlythe designated router and backup designated
router formadjacencies withotherrouting devices.)Adjacenciesdeterminethe 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
adjacencieshave beenestablished, pairs of adjacentrouters synchronizetheir topological
databases.
5Copyright 2011, Juniper Networks, Inc.
Introduction to OSPF
-
7/28/2019 Config Guide Routing Ospf
18/246
A routing device sends LSA packets to advertise its state periodically and when its state
changes. These packets include information about the routing devices adjacencies,
which allows detection of nonoperational routing devices.
Using a reliable algorithm, the routing device floods LSAs throughout the area, whichensures 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
destinationsoutside itsareaand then advertisethese pathsto the areas internal routers.
Autonomoussystem (AS)boundary routersfloodinformation aboutexternalautonomous
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 Figure1 on page 6.
Figure 1: OSPF Three-Way Handshake
In Figure 1 on page 6, 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.
Copyright 2011, Juniper Networks, Inc.6
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
19/246
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.
Related
Documentation
Understanding OSPF Areas and Backbone Areas
OSPF Configuration Overview
JunosOSOSPFVersion 3 for IPv6 Feature Guide
7Copyright 2011, Juniper Networks, Inc.
Introduction to OSPF
http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/feature-guide-ospf-v3-for-ipv6-tc/feature-guide-ospf-v3-for-ipv6-tc.pdfhttp://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/feature-guide-ospf-v3-for-ipv6-tc/feature-guide-ospf-v3-for-ipv6-tc.pdf -
7/28/2019 Config Guide Routing Ospf
20/246
-
7/28/2019 Config Guide Routing Ospf
21/246
the backbone is an internal router on the backbone, and the backbones topology is
hidden from the other areas in the AS.
The routing devices that make up the backbone must be physically contiguous. If they
arenot, youmust configure virtuallinksto create the appearanceof 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 joinedby a virtuallink asif 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 calledAS 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 areas 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.
9Copyright 2011, Juniper Networks, Inc.
Introduction to OSPF
-
7/28/2019 Config Guide Routing Ospf
22/246
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. Anot-so-stubby area (NSSA) allows external routes to beflooded within the area. These routes arethen 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
anotherarea if the backbone is more than two hops away from an area). Thetraffic does
not originate in, nor is it destined for, the transit area.
Related
Documentation
OSPF Overview on page 4
Packets Overview on page 10
OSPF Configuration Overview
Understanding OSPF Areas and Backbone Areas
Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas
Packets Overview
There are several types of link-state advertisement (LSA) packets.
This topic describes the following information:
OSPF Packet Header on page 10
Hello Packets on page 11
Database Description Packets on page 11
Link-State Request Packets on page 11
Link-State Update Packets on page 12
Link-State Acknowledgment Packets on page 12
Link-State Advertisement Packet Types on page 12
OSPF Packet Header
AllOSPFv2packetshave a common24-byteheader, andOSPFv3packetshave 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:
Version numberThe current OSPF version number. This can be either 2 or 3.
TypeType of OSPF packet.
Packet lengthLength of the packet, in bytes, including the header.
Copyright 2011, Juniper Networks, Inc.10
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
23/246
Router IDIP address of the router from which the packet originated.
Area IDIdentifier 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. .
ChecksumFletcher checksum.
Authentication(OSPFv2 only)Authentication schemeand authenticationinformation.
Instance ID(OSPFv3 only) Identifier used when there are multiple OSPFv3 realms
configured on a link.
Hello Packets
Routers periodically sendhello 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 notpossible, so you must configure all neighbors statically as described in Example:
Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network.)
Hello packets consist of the OSPF header plus the following fields:
Network mask(OSPFv2 only) Network mask associated with the interface.
Hello intervalHowoftenthe routersendshello packets.All routers on a sharednetwork
must use the same hello interval.
OptionsOptional capabilities of the router.
Router priorityThe routers priority to become the designated router.
Router dead intervalHow long the router waits without receiving any OSPF packetsfrom a router before declaring that router to be down. All routers on a shared network
must use the same router dead interval.
Designated routerIP address of the designated router.
Backup designated routerIP address of the backup designated router.
NeighborIP addressesof therouters from which valid hello packets have beenreceived
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 OSPFheader, packet sequence number, and the link-state advertisements 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.
These packets consist of the OSPF headerplus fields that uniquely identify the database
information that the router is seeking.
11Copyright 2011, Juniper Networks, Inc.
Introduction to OSPF
-
7/28/2019 Config Guide Routing Ospf
24/246
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 thatsupport 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 advertisementsNumber of link-state advertisements included in this
packet.
Link-state advertisementsThe 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:
Router link advertisementsAre sent by all routers to describe the state and cost ofthe routers links to the area. These link-state advertisements are flooded throughout
a single area only.
NetworklinkadvertisementsAresentbydesignated routersto describe all the routers
attached to the network. These link-state advertisements are flooded throughout a
single area only.
Summary link advertisementsAre 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 destinationsoutside the area but within the AS.These
link-state advertisements are flooded throughout the advertisements associated
areas.
AS external link advertisementAre 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.
Copyright 2011, Juniper Networks, Inc.12
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
25/246
Each link-state advertisement packet begins with a common 20-byte header.
Related
Documentation
OSPF Overview on page 4
OSPF Areas and Router Functionality Overview on page 8
OSPF Configuration Overview
OSPF Designated Router Overview on page 13
Understanding OSPFv2 Authentication
OSPF Timers Overview
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 thecost 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 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 routingdevices 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.
OSPFuses the router identifier fortwo mainpurposes: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
13Copyright 2011, Juniper Networks, Inc.
Introduction to OSPF
-
7/28/2019 Config Guide Routing Ospf
26/246
priorities tie, the routing device with the highest router identifier, which is typically the
routing devices 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 loopbackinterface.Otherwise, the first hardware interface with an IP addressis 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 theleast chanceof becoming a designatedrouter. A priority of 255meansthe routing
device is always the designated router.
Related
Documentation
Example: Configuring an OSPF Router Identifier
Example: Controlling OSPF Designated Router Election on page 50
OSPF 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 OSPF.
Specifically, OSPF generates opaque (link-state advertisements (LSAs), which carry
traffic engineering parameters. Theparameters areusedto populatethe 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.
OSPF IGP Shortcuts
In OSPF, you can configure shortcuts, which allow OSPF to use an LSP as the next hop
asif it were a logical interface from the ingress routing deviceto the egressrouting device.
The 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 OSPF SPFcalculations. 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.
NOTE: Whenever possible, use OSPF IGP shortcuts instead of traffic
engineering shortcuts.
Copyright 2011, Juniper Networks, Inc.14
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
27/246
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
customeredge routersusing OSPFas the routingprotocol.An overrunlink-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 limitsthe numberof times thedatabase canenterthe 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
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.
Related
Documentation
Configuring OSPF Database Protection on page 135
database-protection on page 150
15Copyright 2011, Juniper Networks, Inc.
Introduction to OSPF
-
7/28/2019 Config Guide Routing Ospf
28/246
Copyright 2011, Juniper Networks, Inc.16
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
29/246
CHAPTER 2
Introduction to OSPF ConfigurationGuidelines
BFD Authentication for OSPF Overview on page 17
Loop-Free Alternate Routes for OSPF Overview on page 19
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
authenticationfor BFDsessions runningover OSPFv2.BFD authenticationis notsupported
on MPLS OAMsessions. BFDauthenticationis only supported in thedomestic 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 17
Security Authentication Keychains on page 18
Strict Versus Loose Authentication on page 18
BFD Authentication Algorithms
Junos OS supports the following algorithms for BFD authentication:
simple-passwordPlain-text password. One to 16 bytes of plain text are used to
authenticate the BFDsession.One or more passwords canbe configured. This method
is theleast secureand should be used only when BFDsessions are notsubjectto packet
interception.
keyed-md5Keyed Message Digest 5 hash algorithm for sessions with transmit and
receive intervals greater than 100 ms. To authenticate the BFD session, keyed MD5
17Copyright 2011, Juniper Networks, Inc.
-
7/28/2019 Config Guide Routing Ospf
30/246
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 thesequence 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-md5Meticulous keyed Message Digest 5 hash algorithm. This
methodworks in thesame manneras keyed MD5, butthe sequence numberis updated
with every packet. Although more secure than keyed MD5 and simple passwords, this
method might take additional time to authenticate the session.
keyed-sha-1Keyed 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-1Meticulous keyed Secure Hash Algorithm I. This method
works in the same manner as keyed SHA, but the sequence number is updated with
everypacket.Although more securethan keyed SHAand simplepasswords, thismethod
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.
Security Authentication Keychains
The security authentication keychain defines the authentication attributes used for
authentication keyupdates.When the security authenticationkeychainis 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 thesecret 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.
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
Copyright 2011, Juniper Networks, Inc.18
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
31/246
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.
RelatedDocumentation
Configuring BFD Authentication for OSPF on page 76
Example: Configuring BFD for OSPF on page 72
bfd-liveness-detection on page 146
authentication-key-chains statement in theJunosOSSystemBasicsConfigurationGuide
show bfd session command in theJunosOSRoutingProtocols and PoliciesCommand
Reference
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
repairand implements thebackuppathwhenthe linkfor a primary next hopfor a particular
route is no longer available. With local repair, the Packet Forwarding Engine can correct
a path failure before it receives precomputedpathsfrom 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. Todetermine 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.
19Copyright 2011, Juniper Networks, Inc.
Introduction to OSPF Configuration Guidelines
http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/config-guide-system-basics/config-guide-system-basics.pdfhttp://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/swcmdref-protocols/swcmdref-protocols.pdfhttp://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/swcmdref-protocols/swcmdref-protocols.pdfhttp://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/swcmdref-protocols/swcmdref-protocols.pdfhttp://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/swcmdref-protocols/swcmdref-protocols.pdfhttp://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/config-guide-system-basics/config-guide-system-basics.pdf -
7/28/2019 Config Guide Routing Ospf
32/246
Junos OS provides two mechanisms for route redundancy for OSPF through alternate
loop-free routes:
LinkprotectionOffers per-linktrafficprotection.Use linkprotectionwhenyouassume
that only a single link might become unavailable but that the neighboring node on theprimary path would still be available through another interface.
Node-link protectionEstablishes 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.
Related
Documentation
Configuring Link Protection for OSPF on page 124
Configuring Node-Link Protection for OSPF on page 125
Excluding an OSPF Interface as a Backup for a Protected Interface on page 126
Configuring Backup SPF Options for Protected OSPF Interfaces on page 127
Configuring RSVP Label-Switched Paths as Backup Paths for OSPF on page 129
Copyright 2011, Juniper Networks, Inc.20
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
33/246
PART 2
Configuration
OSPF Configuration Guidelines on page 23
21Copyright 2011, Juniper Networks, Inc.
-
7/28/2019 Config Guide Routing Ospf
34/246
Copyright 2011, Juniper Networks, Inc.22
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
35/246
CHAPTER 3
OSPF Configuration Guidelines
Configuring OSPF on page 24
Minimum OSPF Configuration on page 29
Configuring OSPF Areas on page 29
Disabling Export of LSAs into NSSAs Attached to ASBR ABRs on page 33
Example: Disabling OSPFv2 Compatibility with RFC 1583 on page 33
Configuring OSPF on Interfaces on page 34
Example: Configuring Multiarea Adjacency for OSPF on page 37
Example: Configuring Multiple Address Families for OSPFv3 on page 41
Configuring Authentication for OSPFv2 on page 44
Configuring Authentication for OSPFv3 on page 48
Example: Limiting the Number of Prefixes Exported to OSPF on page 48
Example: Controlling OSPF Designated Router Election on page 50
Example: Summarizing Ranges of Routes in OSPFLink-State Advertisementson page52
Example: Controlling the Cost of Individual OSPF Network Segments on page 57
Example: Dynamically AdjustingOSPF InterfaceMetrics Based onBandwidth on page 61
Example: Controlling OSPF Route Preferences on page 63
Example: Configuring OSPF Timers on page 66
Configuring OSPF Refresh and Flooding Reduction in Stable Topologies on page 71
Example: Configuring BFD for OSPF on page 72
Configuring BFD Authentication for OSPF on page 76
Example: Configuring Synchronization Between LDP and IGPs on page 79
Example: Configuring Graceful Restart for OSPF on page 82
Example: Configuring SPF Algorithm Options for OSPF on page 86
Example: Configuring a Passive OSPF Interface on page 89
Example: Configuring OSPF Passive Traffic Engineering Mode on page 91
Example: Advertising Label-Switched Paths into OSPFv2 on page 93
Example: Configuring OSPF to Make Routing Devices Appear Overloaded on page 104
Example: Enabling OSPF Traffic Engineering Support on page 107
23Copyright 2011, Juniper Networks, Inc.
-
7/28/2019 Config Guide Routing Ospf
36/246
Example: Configuring the Traffic Engineering Metric for a Specific OSPF
Interface on page 112
Applying Policies to OSPF Routes on page 114
Configuring OSPF Routing Table Groups on page 117
Example: Configuring OSPFv2 Sham Links on page 117
Example: Configuring OSPFv2 Peer interfaces on page 123
Configuring Link Protection for OSPF on page 124
Configuring Node-Link Protection for OSPF on page 125
Excluding an OSPF Interface as a Backup for a Protected Interface on page 126
Configuring Backup SPF Options for Protected OSPF Interfaces on page 127
Configuring RSVP Label-Switched Paths as Backup Paths for OSPF on page 129
Example: Tracing OSPF Protocol Traffic on page 130
Configuring OSPF Database Protection on page 135
Configuring OSPF
To configure OSPF version 2 (usually referred to simply as OSPF), you include the
following statements:
protocols {
ospf {
disable;
export [policy-names ];
external-preferencepreference;
graceful-restart {
disable;
helper-disable;no-strict-lsa-checking;
notify-durationseconds;
restart-duration seconds;
}
import [policy-names ];
no-nssa-abr;
no-rfc-1583;
overload {
timeoutseconds;
}
preferencepreference;
prefix-export-limit;
rib-groupgroup-name;
reference-bandwidthreference-bandwidth;
sham-link {
localaddress;
}
spf-options {
delaymilliseconds;
rapid-runsnumber;
holddown milliseconds;
}
Copyright 2011, Juniper Networks, Inc.24
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
37/246
traffic-engineering {
advertise-unnumbered-interfaces;
multicast-rpf-routes;
no-topology;
shortcuts {ignore-lsp-metrics;
lsp-metric-into-summary;
}
}
traceoptions {
file filename ;
flag flag ;
}
areaarea-id{
area-rangenetwork/mask-length ;
interfaceinterface-name {
disable;
authentication {
md5key-id{key [key-values ];
start-time time;
}
simple-passwordkey;
}
bfd-liveness-detection {
authentication {
algorithmalgorithm-name;
key-chainkey-chain-name;
loose-check;
}
detection-time {
thresholdmilliseconds;
}full-neighbors-only;
minimum-intervalmilliseconds;
minimum-receive-intervalmilliseconds;
multipliernumber;
no-adaptation;
transmit-interval {
thresholdmilliseconds;
minimum-intervalmilliseconds;
}
version (1 | automatic);
}
dead-intervalseconds;
demand-circuit;
flood-reduction;hello-intervalseconds;
interface-type type;
ipsec-saname;
ldp-synchronization {
disable;
hold-timeseconds;
}
metricmetric;
neighboraddress;
25Copyright 2011, Juniper Networks, Inc.
OSPF Configuration Guidelines
-
7/28/2019 Config Guide Routing Ospf
38/246
no-interface-state-traps;
passive {
traffic-engineering {
remote-node-idaddress;
}}
poll-intervalseconds;
prioritynumber;
retransmit-intervalseconds;
secondary;
te-metricmetric;
topology (ipv4-multicast |name) {
metricmetric;
}
transit-delayseconds;
}
label-switched-pathname metricmetric;
network-summary-export [policy-names ];
network-summary-import [policy-names ];nssa {
area-rangenetwork/mask-length ;
default-lsa {
default-metricmetric;
metric-type type;
type-7;
}
(summaries | no-summaries);
}
peer-interfaceinterface-name {
disable;
dead-intervalseconds;
demand-circuit;
flood-reduction;hello-intervalseconds;
retransmit-intervalseconds;
transit-delayseconds;
}
sham-link-remoteaddress {
demand-circuit;
flood-reduction;
ipsec-saname;
metricmetric;
}
}
stub ;
virtual-link neighbor-idrouter-idtransit-areaarea-id{
disable;authentication {
md5key-id{
key [key-values ];
}
simple-passwordkey;
}
dead-intervalseconds;
demand-circuit;
flood-reduction;
Copyright 2011, Juniper Networks, Inc.26
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
39/246
hello-intervalseconds;
ipsec-saname;
retransmit-intervalseconds;
topology (ipv4-multicast |name) disable;
transit-delayseconds;}
}
}
Fora list of hierarchy levels atwhichyou canincludethesestatements,see thestatement
summary sections for these statements.
To configure OSPF version 3 (OSPFv3), you include the following statements:
protocols {
ospf3 {
disable;
export [policy-names ];
external-preferencepreference;
graceful-restart {
disable;
helper-disable;
notify-durationseconds;
restart-duration seconds;
}
import [policy-names ];
overload {
timeoutseconds;
}
preferencepreference;
prefix-export-limit;
reference-bandwidthreference-bandwidth;
realm (ipv4-unicast | ipv4-multicast | ipv6-multicast);
rib-groupgroup-name;
spf-options {
delaymilliseconds;
holddown milliseconds;
rapid-runsnumber;
}
traceoptions {
file filename ;
flag flag ;
}
areaarea-id{
area-rangenetwork/mask-length ;
interfaceinterface-name {
bfd-liveness-detection {detection-time {
thresholdmilliseconds;
}
full-neighbors-only;
minimum-intervalmilliseconds;
minimum-receive-intervalmilliseconds;
multipliernumber;
no-adaptation;
transmit-interval {
27Copyright 2011, Juniper Networks, Inc.
OSPF Configuration Guidelines
-
7/28/2019 Config Guide Routing Ospf
40/246
thresholdmilliseconds;
minimum-intervalmilliseconds;
}
version (1 | automatic);
}disable;
dead-intervalseconds;
flood-reduction;
hello-intervalseconds;
ipsec-saname;
metricmetric;
passive {
traffic-engineering {
remote-node-idaddress;
}
}
prioritynumber;
retransmit-intervalseconds;
transit-delayseconds;}
inter-area-prefix-exportpolicy-name;
inter-area-prefix-importpolicy-name;
nssa {
area-rangenetwork/mask-length ;
default-lsa {
default-metricmetric;
metric-type type;
type-7;
}
(summaries | no-summaries);
}
stub ;
virtual-link neighbor-idrouter-idtransit-areaarea-id{disable;
dead-intervalseconds;
hello-intervalseconds;
flood-reduction;
ipsec-saname;
retransmit-intervalseconds;
transit-delayseconds;
}
}
}
}
Fora list of hierarchy levels atwhichyou canincludethesestatements,see thestatement
summary sections for these statements.
By default, OSPFv2 and OSPFv3 are disabled.
NOTE: In this topic, the term OSPFrefers to both OSPFv2 and OSPFv3.
Copyright 2011, Juniper Networks, Inc.28
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
41/246
Related
Documentation
JunosOSOSPFVersion 3 for IPv6 FeatureGuide
Minimum OSPF Configuration
You must create a backbone area if your network consists of multiple areas. An area
border router (ABR) must have at least one interface in the backbone area, or it must
have a virtual link to a routing device in the backbone area. To do this, include at least
the following statements. All other OSPF configuration statements are optional.
protocols {
(ospf | ospf3 ) {
area 0 {
interfaceinterface-name;
}
}
}
Fora list of hierarchy levels atwhichyou canincludethesestatements,see thestatement
summary sections for these statements.
NOTE: When you configure OSPFv2 on an interface, you must also include
the family inet statement at the [edit interfacesinterface-nameunit
logical-unit-number] hierarchy level. When you configure OSPFv3 on an
interface, you must also include the family inet6 statement at the [edit
interfacesinterface-nameunit logical-unit-number] hierarchy level.
Configuring OSPF Areas
You can group the routing devices in a single autonomous system (AS) into areas to
reducethe amount of link-state advertisement(LSA)traffic on the networkand to reduce
the size of the topological databases that OSPF routing devices must maintain. If you
do this, the AS must contain a single backbone area and optionally can contain any
number of nonbackbone areas. 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 connectivity. You also can configure stub areas, which are areas through
which AS external advertisements are not flooded, and not-so-stubby areas (NSSAs),
which allow external routes to be flooded within an area.
Junos OS supports active backbone detection.Activebackbone detection is implemented
to verify that area border routers are connectedto the backbone. If the connection to thebackbonearea is lost, thenthe routing devices defaultmetric is not advertised,effectively
rerouting traffic through another area border router with a valid connection to the
backbone.
Active backbone detection enables transit through an area border router (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.
29Copyright 2011, Juniper Networks, Inc.
OSPF Configuration Guidelines
http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/feature-guide-ospf-v3-for-ipv6-tc/feature-guide-ospf-v3-for-ipv6-tc.pdfhttp://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/feature-guide-ospf-v3-for-ipv6-tc/feature-guide-ospf-v3-for-ipv6-tc.pdf -
7/28/2019 Config Guide Routing Ospf
42/246
To configure areas, you can perform the following tasks:
Configuring the OSPF Backbone Area on page 30
Configuring OSPF Nonbackbone Areas on page 30
Configuring OSPF Stub Areas on page 30
Configuring OSPF Not-So-Stubby Areas on page 31
Configuring OSPF Virtual Links on page 32
Configuring the OSPF Backbone Area
You must create a backbone area if your network consists of multiple areas. An ABR
must have at least one interface in the backbone area, or it must have a virtual link to a
routing device in the backbone area. The backbone comprises all ABRs and all routing
devices that are not included in any other area. You configure all these routing devices
by including the area 0.0.0.0 statement:
area 0.0.0.0;
For a list of hierarchy levels at which you can include this statement, see the statement
summary section for the statement.
Configuring OSPF Nonbackbone Areas
Each OSPF area consists of routing devices configured with the same area number. To
configure a routing device to be in an area, include the area statement. The area ID can
be any number except 0.0.0.0, which is reserved for the backbone area.
areaarea-id;
For a list of hierarchy levels at which you can include this statement, see the statement
summary section for the statement.
Configuring OSPF Stub Areas
Stub areas are areas into which OSPF does not flood AS external advertisements. You
might want to configure stub areas when much of the topological database consists of
AS external advertisements and you want to minimize the size of the topological
databases on an areas routing devices.
You cannot configure an area as both a stub area and a not-so-stubby area (NSSA).
To configure a stub area, include the stub statement:
areaarea-id{
stub ;}
For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.
To inject a default route with a specified metric value into the area, include the
default-metric optionand a metric value. Thedefaultroutematches anydestination that
is not explicitly reachable from within the area.
Copyright 2011, Juniper Networks, Inc.30
Junos OS OSPF Configuration Guide
-
7/28/2019 Config Guide Routing Ospf
43/246
To have the stub areas not advertise summary routes into the stub area, include the
no-summaries option. Only the default route is advertised, and only if you include the
default-metric option. The default route injected into the NSSA is a Type 3 LSA.
You must include the stub statement when configuring all routing devices that are in thestub area.
NOTE: In Junos OS Release 8.5 and later, a router-identifier interface that is
notconfiguredto runOSPFis no longer advertisedas a stub networkin OSPF
link-state advertisements. For more information about how to configure a
router identifier, see Configuring Router Identifiers for BGP and OSPF.
In Junos OS Release 8.5and later, OSPF advertisesa localroutewith a prefix
length of 32 as a stub link if the loopbackinterface is configuredwith a prefix
lengthother than 32.OSPF also advertisesthe directroutewith theconfigured
mask length, as in earlier releases.
Configuring OSPF Not-So-Stubby Areas
An OSPF stub area has no external routes, so you cannot redistribute from another
protocol into a stub area. An 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.
You cannot configure an area to be both a stub area and an NSSA.
To configure an NSSA, include the nssa statement:
areaarea-id{nssa {
area-rangenetwork/mask-length ;
default-lsa {
default-metricmetric;
metric-type type;
type-7;
}
(summaries | no-summaries);
}
}
For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.
By default, a default routeis notadvertised. To advertisea default routewith thespecified
metric within the area, include the default-metric statement. You canconfigure thisoption
only on ABRs.
To prevent an ABR from advertising summary routes into an NSSA, include the
no-summaries statement. If you include the default-metric option in addition to the
no-summaries statement, only the default route is advertised. The default route is a
Type 3 LSA injected into the NSSA. To flood summary LSAs into the NSSA area, include
31Copyright 2011, Juniper Networks, Inc.
OSPF Configuration Guidelines
-
7/28/2019 Config Guide Routing Ospf
44/246
the summaries statement. When summaries is configured (which is the default if the
no-summaries statement is not specified), a Type 7 LSA is sent. To define the type of
metric, include the metric-type statement.
To aggregate external routes learned within the area when a route is advertised to otherareas, include one or more area-range statements. If you also include the restrict option,
the aggregate is not advertised, effectively creating a route filter. All external routes
learned withinthe area that do not fall into the rangeof oneof the prefixes are advertised
individually to other areas. To restrict an exact area range, include the exact option. For
an example, you can suppress the exact 0/0 prefix from being advertised from a NSSA
area into the backbone area by including both the exact and restrict options. To override
the metric for the IP address range and configure a specific metric value, include the
override-metric option.
Configuring OSPF Virtual Links
If any routing device on the backbone is not physically connected to the backbone itself,
you must establish a virtual connection between that routing device and the backbone.
You can establish a virtual connection between ABRs by configuring an OSPF virtual link.
To configure an OSPF virtual link, include the virtual-link statement when configuring the
backbone area (area 0):
virtual-link neighbor-idrouter-idtransit-areaarea-id;
To configure an OSPFv3 virtual link, include the virtual-link statement when configuring
the backbone area (area 0):
virtual-link neighbor-idrouter-idtransit-areaarea-id;
For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.
Specify the router ID (as an IPv4 address) of the routing device at the other end of the
virtual link. This router must be an ABR that is physically connected to the backbone.
Also, specify the number of the area through which the virtual link transits.
For the virtual connection to work, you also must configure a link to the backbone area
on the remote ABR (the routing device at the other end of the LSP).
Example: Configuring an OSPF Virtual Link
Configure an OSPF virtual link on the local router. This routing device must be an area
border router that i