Juniper OSPF

Junos® OS
OSPF User Guide
Published
2021-04-21
ii
Juniper Networks, Inc.

1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. All other trademarks, service marks, registered marks, 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.
Junos® OS OSPF User Guide

Copyright © 2021 Juniper Networks, Inc. All rights reserved.
The information in this document is current as of the date on the title page.
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 https://support.juniper.net/support/eula/. By downloading, installing or using such
software, you agree to the terms and conditions of that EULA.
iii
Table of Contents
About This Guide | xxi
1 OSPF Overview
Introduction to OSPF | 2
OSPF Overview | 2
OSPF Packets Overview | 7
Understanding OSPF External Metrics | 10
Supported OSPF and OSPFv3 Standards | 11
2 Understand OSPF Configurations

Understanding OSPF Configurations | 14
3 Configure OSPF Interfaces

Configuring OSPF Interfaces | 17
About OSPF Interfaces | 17
Example: Configuring an Interface on a Broadcast or Point-to-Point Network | 19
Requirements | 19
Overview | 19
Configuration | 20
Verification | 22
Example: Configuring OSPF Demand Circuits | 23
Requirements | 23
Overview | 24
Configuration | 25
Verification | 26
Example: Configuring a Passive OSPF Interface | 27
Requirements | 27
Overview | 28
Configuration | 28
Verification | 30
iv
Example: Configuring OSPFv2 Peer interfaces | 30
Requirements | 31
Overview | 31
Configuration | 31
Verification | 33
Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network | 33
Requirements | 34
Overview | 34
Configuration | 35
Verification | 37
Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint Network | 38
Requirements | 38
Overview | 39
Configuration | 39
Verification | 41
Understanding Multiple Address Families for OSPFv3 | 41
Example: Configuring Multiple Address Families for OSPFv3 | 42
Requirements | 42
Overview | 43
Configuration | 44
Verification | 47
4 Configure OSPF Areas

Configuring OSPF Areas | 49
Understanding OSPF Areas | 50
OSPF Designated Router Overview | 53
Example: Configuring an OSPF Router Identifier | 54
Requirements | 54
Overview | 55
Configuration | 55
Verification | 57
Example: Controlling OSPF Designated Router Election | 57

v
Requirements | 57
Overview | 57
Configuration | 58
Verification | 59
Understanding OSPF Areas and Backbone Areas | 60
Example: Configuring a Single-Area OSPF Network | 62
Requirements | 62
Overview | 62
Configuration | 63
Verification | 64
Example: Configuring a Multiarea OSPF Network | 65
Requirements | 65
Overview | 66
Configuration | 67
Verification | 70
Understanding Multiarea Adjacency for OSPF | 71
Example: Configuring Multiarea Adjacency for OSPF | 71
Requirements | 72
Overview | 72
Configuration | 73
Verification | 77
Understanding Multiarea Adjacencies for OSPFv3 | 78
Example: Configuring a Multiarea Adjacency for OSPFv3 | 79
Requirements | 79
Overview | 79
Configuration | 80
Verification | 87
Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas | 89
Example: Configuring OSPF Stub and Totally Stubby Areas | 90
Requirements | 90
Overview | 91
vi
Configuration | 93
Verification | 95
Example: Configuring OSPF Not-So-Stubby Areas | 96
Requirements | 96
Overview | 96
Configuration | 98
Verification | 102
Understanding OSPFv3 Stub and Totally Stubby Areas | 104
Example: Configuring OSPFv3 Stub and Totally Stubby Areas | 104
Requirements | 104
Overview | 105
Configuration | 106
Verification | 116
Understanding OSPFv3 Not-So-Stubby Areas | 120
Example: Configuring OSPFv3 Not-So-Stubby Areas | 120
Requirements | 120
Overview | 120
Configuration | 122
Verification | 133
Understanding Not-So-Stubby Areas Filtering | 140
Example: Configuring OSPFv3 Not-So-Stubby Areas with Filtering | 140
Requirements | 140
Overview | 140
Configuration | 141
Verification | 148
Understanding OSPF Virtual Links for Noncontiguous Areas | 151
Example: Configuring OSPF Virtual Links to Connect Noncontiguous Areas | 152
Requirements | 153
Overview | 153
Configuration | 154
Verification | 158
vii
Example: Configuring OSPFv3 Virtual Links | 159
Requirements | 159
Overview | 160
Configuration | 160
Verification | 174
5 Configure OSPF Route Control

Configuring OSPF Route Control | 195
Understanding OSPF Route Summarization | 195
Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements Sent into the
Backbone Area | 196
Requirements | 196
Overview | 197
Configuration | 199
Verification | 204
Example: Limiting the Number of Prefixes Exported to OSPF | 205
Requirements | 205
Overview | 205
Configuration | 206
Verification | 207
Understanding OSPF Traffic Control | 208
Example: Controlling the Cost of Individual OSPF Network Segments | 210
Requirements | 211
Overview | 211
Configuration | 213
Verification | 215
Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth | 217
Requirements | 219
Overview | 219
Verification | 220
Example: Controlling OSPF Route Preferences | 220
Requirements | 222
Overview | 222
viii
Verification | 223
Understanding OSPF Overload Function | 223
Example: Configuring OSPF to Make Routing Devices Appear Overloaded | 225
Requirements | 226
Overview | 226
Configuration | 227
Verification | 229
Understanding the SPF Algorithm Options for OSPF | 230
Example: Configuring SPF Algorithm Options for OSPF | 231
Requirements | 231
Overview | 232
Configuration | 233
Verification | 234
Configuring OSPF Refresh and Flooding Reduction in Stable Topologies | 235
Understanding Synchronization Between LDP and IGPs | 237
Example: Configuring Synchronization Between LDP and OSPF | 237
Requirements | 237
Overview | 238
Configuration | 238
Verification | 242
OSPFv2 Compatibility with RFC 1583 Overview | 242
Example: Disabling OSPFv2 Compatibility with RFC 1583 | 243
Requirements | 243
Overview | 243
Configuration | 244
Verification | 245
6 Configure OSPF Authentication

Configuring OSPF Authentication | 247
Understanding IPsec Authentication for OSPF Packets on EX Series Switches | 247
Understanding OSPFv2 Authentication | 250

ix
Example: Configuring Simple Authentication for OSPFv2 Exchanges | 253
Requirements | 254
Overview | 254
Configuration | 254
Verification | 256
Example: Configuring MD5 Authentication for OSPFv2 Exchanges | 257
Requirements | 257
Overview | 257
Configuration | 258
Verification | 260
Example: Configuring a Transition of MD5 Keys on an OSPFv2 Interface | 260
Requirements | 261
Overview | 261
Configuration | 262
Verification | 265
Using IPsec to Secure OSPFv3 Networks (CLI Procedure) | 265
Configuring Security Associations | 266
Securing OPSFv3 Networks | 267
Example: Configuring IPsec Authentication for an OSPF Interface | 267
Requirements | 267
Overview | 268
Configuration | 270
Verification | 275
7 Configure OSPF Routing Instances

Configuring OSPF Routing Instances | 278
Understanding OSPF Routing Instances | 278
Installing Routes from OSPF Routing Instances into the OSPF Routing Table Group | 280
Example: Configuring Multiple Routing Instances of OSPF | 281
Requirements | 281
Overview | 281
Configuration | 284
x
Verification | 290
8 Configure OSPF Timers

Configuring OSPF Timers | 293
OSPF Timers Overview | 293
Example: Configuring OSPF Timers | 294
Requirements | 294
Overview | 295
Configuration | 296
Verification | 302
9 Configure OSPF Fault Detection using BFD

Configuring OSPF Fault Detection using BFD | 304
Understanding BFD for OSPF | 304
Example: Configuring BFD for OSPF | 307
Requirements | 307
Overview | 307
Configuration | 309
Verification | 312
Understanding BFD Authentication for OSPF | 313
Configuring BFD Authentication for OSPF | 315
Configuring BFD Authentication Parameters | 315
Viewing Authentication Information for BFD Sessions | 317
10 Configure Graceful Restart for OSPF

Configuring Graceful Restart for OSPF | 321
Graceful Restart for OSPF Overview | 321
Example: Configuring Graceful Restart for OSPF | 323
Requirements | 323
Overview | 324
Configuration | 325
Verification | 329
Example: Configuring the Helper Capability Mode for OSPFv2 Graceful Restart | 330
xi
Requirements | 330
Overview | 331
Configuration | 331
Verification | 335
Requirements | 336
Overview | 336
Configuration | 337
Verification | 340
Example: Disabling Strict LSA Checking for OSPF Graceful Restart | 341
Requirements | 341
Overview | 342
Configuration | 342
Verification | 345
11 Configure Loop-Free Alternate Routes for OSPF

Configuring Loop-Free Alternate Routes for OSPF | 348
Per Prefix Loop Free Alternates for OSPF | 348
Configuring Per-Prefix LFA for OSPF | 349
Loop-Free Alternate Routes for OSPF Overview | 350
Configuring Link Protection for OSPF | 351
Configuring Node-Link Protection for OSPF | 352
Configuring Node to Link Protection Fallback for OSPF | 353
Excluding an OSPF Interface as a Backup for a Protected Interface | 354
Configuring Backup SPF Options for Protected OSPF Interfaces | 355
Configuring RSVP Label-Switched Paths as Backup Paths for OSPF | 357
Example: Configuring Loop-Free Alternate Routes for OSPF | 358
Requirements | 358
Overview | 358
Configuration | 359
Verification | 371
xii
Remote LFA over LDP Tunnels in OSPF Networks Overview | 386
Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network | 388
Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks | 389
Requirements | 390
Overview | 390
Configuration | 391
Verification | 402
12 Configure OSPF Support for Traffic Engineering

Configuring OSPF Support for Traffic Engineering | 412
OSPF Support for Traffic Engineering | 412
Example: Enabling OSPF Traffic Engineering Support | 414
Requirements | 414
Overview | 415
Configuration | 415
Verification | 421
Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface | 423
Requirements | 423
Overview | 423
Configuration | 423
Verification | 425
OSPF Passive Traffic Engineering Mode | 426
Example: Configuring OSPF Passive Traffic Engineering Mode | 426
Requirements | 426
Overview | 427
Configuration | 427
Verification | 429
Advertising Label-Switched Paths into OSPFv2 | 429
Example: Advertising Label-Switched Paths into OSPFv2 | 430
Requirements | 430
Overview | 430
Configuration | 432
xiii
Verification | 449
Static Adjacency Segment Identifier for OSPF | 450
Understanding Source Packet Routing in Networking (SPRING) | 453
How to Configure Flexible Algorithms in OSPF for Segment Routing Traffic Engineering | 457
Understanding OSPF Flexible Algorithm for Segment Routing | 458
Example: OSPF Flexible Algorithm | 467
Overview | 467
Requirements | 468
Configuration | 468
Verification | 489
| 497
| 497
| 497
13 Configure OSPF Database Protection

Configuring OSPF Database Protection | 499
OSPF Database Protection Overview | 499
14 Configure OSPF Routing Policy

Configuring OSPF Routing Policy | 503
Understanding Routing Policies | 503
Understanding OSPF Routing Policy | 507
Understanding Backup Selection Policy for OSPF Protocol | 509
Configuring Backup Selection Policy for the OSPF Protocol | 511
Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 518
Understanding Topology-Independent Loop-Free Alternate with Segment Routing for OSPF

| 519
Configuring Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 521
Example: Configuring Backup Selection Policy for the OSPF or OSPF3 Protocol | 522
Requirements | 523
xiv
Overview | 523
Configuration | 524
Verification | 550
Example: Injecting OSPF Routes into the BGP Routing Table | 557
Requirements | 557
Overview | 557
Configuration | 558
Verification | 561
Troubleshooting | 562
Example: Redistributing Static Routes into OSPF | 562
Requirements | 563
Overview | 563
Configuration | 564
Verification | 566
Example: Configuring an OSPF Import Policy | 567
Requirements | 567
Overview | 567
Configuration | 568
Verification | 572
Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through
OSPF | 573
Requirements | 573
Overview | 574
Configuration | 575
Verification | 579
Import and Export Policies for Network Summaries Overview | 580
Example: Configuring an OSPF Export Policy for Network Summaries | 580
Requirements | 580
Overview | 581
Configuration | 583
Verification | 592
Example: Configuring an OSPF Import Policy for Network Summaries | 593

xv
Requirements | 593
Overview | 593
Configuration | 595
Verification | 604
Example: Redistributing OSPF Routes into IS-IS | 605
Requirements | 606
Overview | 606
Configuration | 607
Verification | 615
15 Configure OSPFv2 Sham Links

Configuring OSPFv2 Sham Links | 621
OSPFv2 Sham Links Overview | 621
Example: Configuring OSPFv2 Sham Links | 623
Requirements | 623
Overview | 623
Configuration | 625
Verification | 633
16 Configure OSPF on Logical Systems

Configuring OSPF on Logical Systems | 638
OSPF Support for Logical Systems | 638
Example: Configuring OSPF on Logical Systems Within the Same Router | 639
Requirements | 639
Overview | 639
Configuration | 641
Verification | 646
17 Troubleshooting Network Issues

Troubleshooting Network Issues | 652
Working with Problems on Your Network | 652
Isolating a Broken Network Connection | 653
Identifying the Symptoms of a Broken Network Connection | 655
Isolating the Causes of a Network Problem | 657

xvi
Taking Appropriate Action for Resolving the Network Problem | 658
Evaluating the Solution to Check Whether the Network Problem Is Resolved | 660
Checklist for Tracking Error Conditions | 662
Configure Routing Protocol Process Tracing | 664
Configure Routing Protocol Tracing for a Specific Routing Protocol | 668
Monitor Trace File Messages Written in Near-Real Time | 671
Stop Trace File Monitoring | 672
18 Verifying and Monitoring OSPF

Verifying and Monitoring OSPF Configuration | 675
Verifying an OSPF Configuration | 675
Verifying OSPF-Enabled Interfaces | 675
Verifying OSPF Neighbors | 677
Verifying the Number of OSPF Routes | 678
Verifying Reachability of All Hosts in an OSPF Network | 680
Tracing OSPF Protocol Traffic | 681
Example: Tracing OSPF Protocol Traffic | 683
Requirements | 683
Overview | 683
Configuration | 685
Verification | 690
19 Configuration Statements
admin-group | 695
allow-route-leaking | 697
area | 699
area-range | 702
as-external | 704
authentication | 706
backup-selection (Protocols OSPF) | 708

xvii
backup-spf-options (Protocols OSPF) | 711
bandwidth-based-metrics | 714
bfd-liveness-detection (Protocols OSPF) | 716
context-identifier (Protocols OSPF) | 721
database-protection | 722
default-lsa | 725
definition (Protocols OSPF) | 728
flex-algorithm (Protocols OSPF) | 730
export | 732
graceful-restart (Protocols OSPF) | 734
import | 737
inter-area-prefix-export | 739
inter-area-prefix-import | 741
interface (Protocols OSPF) | 743
interface (Backup Selection OSPF) | 750
interface-type (Protocols OSPF) | 754
intra-area-prefix | 758
label-switched-path (Protocols OSPF) | 759
ldp-stitching (Protocols OSPF) | 761
link-protection (Protocols OSPF) | 762
lsa-refresh-interval | 764
mtu | 767
network-summary-export | 771
network-summary-import | 773
no-advertise-adjacency-segment (Protocols OSPF) | 775

xviii
no-domain-vpn-tag | 776
no-neighbor-down-notification | 778
no-nssa-abr | 779
no-rfc-1583 | 781
no-source-packet-routing (Protocols OSPF) | 783
node-segment (Protocols OSPF) | 785
nssa | 787
ospf | 789
ospf3 | 792
overload (Protocols OSPF) | 794
passive (Protocols OSPF) | 797
peer-interface (Protocols OSPF) | 799
post-convergence-lfa (Protocols OSPF) | 801
prefix-export-limit (Protocols OSPF) | 803
protocols | 805
realm | 809
reference-bandwidth (Protocols OSPF) | 811
rib-group (Protocols OSPF) | 813
routing-instances (Multiple Routing Entities) | 815
sham-link | 817
sham-link-remote | 819
shortcuts (Protocols OSPF) | 822
source-packet-routing (Protocols OSPF) | 824
spf-options (Protocols OSPF) | 827
stub | 830
xix
stub-network | 832
topology (OSPF) | 833
topology (OSPF Interface) | 836
traceoptions (Protocols OSPF) | 838
traffic-engineering (OSPF) | 843
traffic-engineering (Passive TE Mode) | 846
use-post-convergence-lfa (Protocols OSPF) | 849
virtual-link | 851
20 Operational Commands
clear bfd adaptation | 856
clear bfd session | 858
clear (ospf | ospf3) database | 860
clear (ospf | ospf3) database-protection | 864
clear (ospf | ospf3) io-statistics | 866
clear (ospf | ospf3) neighbor | 868
clear (ospf | ospf3) overload | 871
clear (ospf | ospf3) statistics | 873
show bfd session | 876
show (ospf | ospf3) backup coverage | 887
show (ospf | ospf3) backup lsp | 891
show (ospf | ospf3) backup neighbor | 895
show (ospf | ospf3) backup spf | 898
show ospf context-identifier | 902
show ospf database | 906
show ospf3 database | 916

xx
show (ospf | ospf3) interface | 929
show (ospf | ospf3) io-statistics | 939
show (ospf | ospf3) log | 941
show (ospf | ospf3) neighbor | 945
show (ospf | ospf3) overview | 955
show (ospf | ospf3) route | 963
show (ospf | ospf3) statistics | 972
show policy | 977
show route | 981
show route instance | 994
show route protocol | 1000

xxi
About This Guide
Use this guide to configure, monitor, and troubleshoot the OSPF routing protocol on your Juniper
Network devices.
Junos OS Routing Protocols Library for Routing Devices

1 CHAPTER
OSPF Overview
Introduction to OSPF | 2
2
Introduction to OSPF
IN THIS SECTION
OSPF Overview | 2
Understanding OSPF External Metrics | 10
Supported OSPF and OSPFv3 Standards | 11
OSPF Overview
IN THIS SECTION
OSPF Default Route Preference Values | 3
OSPF Routing Algorithm | 4
OSPF Three-Way Handshake | 5
OSPF Version 3 | 5
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.
3
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.
NOTE: On SRX Series devices, when only one link-protection is configured under the OSPF
interface, the device does not install an alternative route in the forwarding table. When the per-
packet load-balancing is enabled as a workaround, the device does not observe both the OSPF
metric and sending the traffic through both the interfaces.
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.
This topic describes the following information:
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
4 lists the default preference values for OSPF.
4
Table 1: Default Route Preference Values for OSPF
How Route Is Learned Default Preference Statement to Modify Default

Preference
OSPF internal route 10 OSPF preference
OSPF AS external routes 150 OSPF external-preference
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.
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.
5
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 1 on page 5.
Figure 1: OSPF Three-Way Handshake
In Figure 1 on page 5, 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.
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:
6
• 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.
SEE ALSO
Understanding OSPF Areas and Backbone Areas

Example: Disabling OSPFv2 Compatibility with RFC 1583
7
OSPF Packets Overview
IN THIS SECTION
OSPF Packet Header | 7
Hello Packets | 8
Database Description Packets | 8
Link-State Request Packets | 8
Link-State Update Packets | 9
Link-State Acknowledgment Packets | 9
Link-State Advertisement Packet Types | 9
There are several types of link-state advertisement (LSA) packets.
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:
• 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.
8
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.)
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. These packets consist of the
OSPF header plus fields that uniquely identify the database information that the router is seeking.
9
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:
• 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).
10
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.
SEE ALSO
Understanding OSPF Areas

Understanding OSPF Configurations
OSPF Designated Router Overview
Understanding OSPFv2 Authentication
OSPF Timers Overview
Understanding OSPF External Metrics
When OSPF exports route information from external autonomous systems (ASs), it includes a cost, or
external metric, in the route. OSPF supports 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. This means that Type 1 external metrics include the external
cost to the destination as well as the cost (metric) to reach the AS boundary router.
• Type 2 external metrics are greater than the cost of any path internal to the AS. Type 2 external
metrics use only the external cost to the destination and ignore the cost (metric) to reach the AS
boundary router.
By default, OSPF uses the Type 2 external metric.
Both Type 1 and Type 2 external metrics can be present in the AS at the same time. In that event, Type 1
external metrics always takes the precedence.
Type 1 external paths are always preferred over Type 2 external paths. When all paths are Type 2
external paths, the paths with the smallest advertised Type 2 metric are always preferred.
SEE ALSO
Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth

11
Supported OSPF and OSPFv3 Standards
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 1765, OSPF Database Overflow
• RFC 1793, Extending OSPF to Support Demand Circuits
• RFC 1850, OSPF Version 2 Management Information Base
• RFC 2154, OSPF with Digital Signatures
• 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 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 4136, OSPF Refresh and Flooding Reduction in Stable Topologies
• RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
Only interface switching is supported.
• 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

12
• RFC 5185, OSPF Multi-Area Adjacency
• RFC 5187, OSPFv3 Graceful Restart
• RFC 5250, The OSPF Opaque LSA Option
NOTE: RFC 4750, mentioned in this RFC as a "should" requirement is not supported.
However, RFC 1850, the predecessor to RFC 4750 is supported.
• RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates
• RFC 5340, OSPF for IPv6 (RFC 2740 is obsoleted by RFC 5340)
• RFC 5838, Support of Address Families in OSPFv3
• 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 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
SEE ALSO
Supported IPv6 Standards

Accessing Standards Documents on the Internet
2 CHAPTER
Understand OSPF Configurations

14
Understanding OSPF Configurations
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 Library for Routing Devices or the Junos OS Interfaces
Configuration Guide for Security Devices.
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:
15
• OSPF refers to both OSPF version 2 (OSPFv2) and OSPF version 3 (OSPFv3)
• OSPFv2 refers to OSPF version 2
• OSPFv3 refers to OSPF version 3

3 CHAPTER
Configure OSPF Interfaces
Configuring OSPF Interfaces | 17

17
Configuring OSPF Interfaces
IN THIS SECTION
Example: Configuring an Interface on a Broadcast or Point-to-Point Network | 19
Example: Configuring OSPF Demand Circuits | 23
Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint Network | 38
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.
18
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.
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.
SEE ALSO
Example: Configuring OSPF Passive Traffic Engineering Mode

19
Example: Configuring an Interface on a Broadcast or Point-to-Point

Network
IN THIS SECTION
Requirements | 19
Overview | 19
Configuration | 20
Verification | 22
This example shows how to configure an OSPF interface on a broadcast or point-to-point network.
Requirements
Before you begin:
• Configure the router identifiers for the devices in your OSPF network. See Example: Configuring an
OSPF Router Identifier.
• Control OSPF designated router election. See Example: Controlling OSPF Designated Router Election
• Configure a multiarea OSPF network. See Example: Configuring a Multiarea OSPF Network.
Overview
IN THIS SECTION
Topology | 20
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.
20
NOTE: Using both the interface name and the IP address of the same interface produces an
invalid configuration.
In this example, you configure interface ge-0/2/0 as an OSPFv2 interface in OSPF area 0.0.0.1.
Topology
Configuration
IN THIS SECTION
CLI Quick Configuration | 20
Procedure | 21
Results | 22
CLI Quick Configuration
To quickly configure an OSPF interface on a broadcast or point-to-point network and to allow the
inbound OSPF into the interfaces that are active, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network configuration, copy
and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from
configuration mode.
[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
set security zones security-zone Trust host-inbound-traffic protocols all
set security zones security-zone Trust host-inbound-traffic system-services all
set groups global security policies default-policy permit-all
set security zones security-zone Trust interfaces ge-0/2/0
21
Procedure
Step-by-Step Procedure
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.
5. To allow the inbound OSPF into the interfaces that are active.
[edit]
user@host# set security zones security-zone Trust host-inbound-traffic protocols all
user@host# set security zones security-zone Trust host-inbound-traffic system-services all
22
user@host# set groups global security policies default-policy permit-all

user@host# set security zones security-zone Trust interfaces ge-0/2/0
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;
}
}
}
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
IN THIS SECTION
Verifying the OSPF Interface | 23
Confirm that the configuration is working properly.

23
Verifying the OSPF Interface
Purpose
Verify the interface configuration. Depending on your deployment, the Type field might display LAN or
P2P.
Action
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
Example: Configuring OSPF Demand Circuits
IN THIS SECTION
Requirements | 23
Overview | 24
Configuration | 25
Verification | 26
This example shows how to configure an OSPF demand circuit interface.
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
NOTE: If you are using OSPF demand circuits over an ISDN link, you must configure an ISDN
interface and enable dial-on-demand routing.
• Configure a single-area OSPF network. See Example: Configuring a Single-Area OSPF Network.
24
Overview
IN THIS SECTION
Topology | 24
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.
In this example, you configure OSPF interface so-0/1/0 in OSPF area 0.0.0.1 as a demand circuit.
Topology
25
Configuration
IN THIS SECTION
Procedure | 25
Results | 26
To quickly configure an OSPF demand circuit interface, copy the following commands, paste them into a
text file, remove any line breaks, change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from
configuration mode.
[edit]
set protocols ospf area 0.0.0.1 interface so-0/1/0 demand-circuit
Procedure
To configure an OSPF demand circuit interface on one neighboring interface:
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit ]
26
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

user@host# commit
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;
}
}
}
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
Verifying the Status of Neighboring Interfaces | 27

27
Verifying the Status of Neighboring Interfaces
Purpose
Verify information about the neighboring interface. When the neighbor is configured for demand
circuits, a DC flag displays.
Action
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
IN THIS SECTION
Requirements | 27
Overview | 28
Configuration | 28
Verification | 30
This example shows how to configure a passive OSPF interface. A passive OSPF interface advertises its
address but does not run the OSPF protocol.
Requirements
Before you begin:
28
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.
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.
Configuration
IN THIS SECTION
Procedure | 29
Results | 29
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, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
[edit]
set protocols ospf area 0.0.0.1 interface ge-0/2/0 passive
29
Procedure
To configure a passive OSPF interface:
NOTE: For an OSPFv3 interface, include the ospf3 statement at the [edit protocols] hierarchy
level.
[edit]
2. Configure the passive interface.

user@host# set interface ge-0/2/0 passive

user@host# commit
Results

area 0.0.0.1 {
interface ge-0/2/0.0 {
passive;
}
}
30
Verification
IN THIS SECTION
Verifying the Status of OSPF Interfaces | 30
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
IN THIS SECTION
Requirements | 31
Overview | 31
Configuration | 31
Verification | 33
This example shows how to configure an OSPFv2 peer interface.

31
Requirements
Before you begin:
• Configure Generalized MPLS per your network requirements. .
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.
Configuration
IN THIS SECTION
Procedure | 32
Results | 32
To quickly configure an OSPFv2 peer interface, copy the following commands, paste them into a text
32
configuration mode.
[edit]
set protocols ospf area 0.0.0.0 peer-interface oxc1
Procedure
To configure a peer OSPFv2 interface used by the LMP:
[edit]
2. Configure the peer interface.

user@host# set peer-interface oxc1

user@host# commit
Results

area 0.0.0.0 {
peer-interface oxc1;
}
33
Verification
IN THIS SECTION
Verifying the Configured OSPFv2 Peer | 33
Verifying the Configured OSPFv2 Peer
Purpose
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.
Action
From operational mode, enter the show link-management command.
Example: Configuring an OSPFv2 Interface on a Nonbroadcast

Multiaccess Network
IN THIS SECTION
Requirements | 34
Overview | 34
Configuration | 35
Verification | 37
This example shows how to configure an OSPFv2 interface on a nonbroadcast multiaccess (NBMA)
network.
34
Requirements
Before you begin:
• Control OSPF designated router election. See Example: Controlling OSPF Designated Router
Election.
Overview
IN THIS SECTION
Topology | 35
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.
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 <eligible>—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.
35
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.
Topology
Configuration
IN THIS SECTION
Procedure | 36
Results | 37
To quickly configure an OSPFv2 interface on an NBMA network, copy the following commands, paste
them into a text file, remove any line breaks, change any details necessary to match your network
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter
commit from configuration mode.
[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
36
Procedure
To configure an OSPFv2 interface on an NBMA network:
[edit]
user@host# set interfaces at-0/1/0 unit 0 family inet address 192.0.2.1
[edit]
3. Assign the interface to the area.
In this example, include the eligible keyword to allow the neighbor to be a designated router.

user@host# set interface at-0/1/0 interface-type nbma neighbor 192.0.2.2 eligible
4. Configure the poll interval.

user@host# set interface at-0/1/0 poll-interval 130

user@host# commit
37
Results

at-0/1/0 {
unit 0 {
family inet {
address 192.0.2.1/32;
}
}
}

area 0.0.0.1 {
interface at-0/1/0.0 {
interface-type nbma;
neighbor 192.0.2.2 eligible;
poll-interval 130;
}
}
Verification
IN THIS SECTION
Purpose
Verify the interface configuration. Confirm that the Type field displays NBMA.
38
Action
From operational mode, enter the show ospf interface detail command.
SEE ALSO
Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint

Network
IN THIS SECTION
Requirements | 38
Overview | 39
Configuration | 39
Verification | 41
This example shows how to configure an OSPFv2 interface on a point-to-multipoint network.
Requirements
Before you begin:
39
Overview
IN THIS SECTION
Topology | 39
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.
Topology
Configuration
IN THIS SECTION
Procedure | 40
Results | 40
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
40
Procedure
To configure an OSPFv2 interface on a point-to-multipoint network:
[edit]
user@host# set interfaces at-0/1/0 unit 0 family inet address 192.0.2.2
[edit]
3. Assign the interface to the area and specify the neighbor.

user@host# set interface at-0/1/0 neighbor 192.0.2.1
To configure multiple neighbors, include a neighbor statement for each neighbor.

user@host# commit
Results

at-0/1/0 {
unit 0 {
family inet {
41
address 192.0.2.2/32;
}
}
}

area 0.0.0.1 {
interface at-0/1/0.0 {
neighbor 192.0.2.1;
}
}
Verification
IN THIS SECTION
Purpose
Verify the interface configuration. Confirm that the Type field displays P2MP.
Action
From operational mode, enter the show ospf interface detail command.
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.
42
Junos OS maps each address family to a separate realm as defined in RFC 5838, 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
IN THIS SECTION
Requirements | 42
Overview | 43
Configuration | 44
Verification | 47
This example shows how to configure multiple address families for OSPFv3.
Requirements
Before you begin:
43
Overview
IN THIS SECTION
Topology | 44
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 2 on page 44 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-
44
multicast statement, and you can advertise IPv6 multicast routes by including the realm-ipv6-multicast
statement.
Figure 2: IPv4 Unicast Realm
Topology
Configuration
IN THIS SECTION
Procedure | 45
Results | 46
45
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 the CLI User Guide.
To quickly configure multiple address families for OSPFv3, copy the following commands, paste them
into a text file, remove any line breaks, change any details necessary to match your network
[edit]
set interfaces fe-0/1/0 unit 0 family inet address 192.0.2.2/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
Procedure
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 192.0.2.2/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
46
4. Configure an IPv4 unicast realm. This allows OSPFv3 to support both IPv4 unicast and IPv6 unicast
routes.

user@host# set realm ipv4-unicast area 0.0.0.0 interface fe-0/1/0

user@host# commit
NOTE: Repeat this entire configuration on the neighboring device that is part of the realm.
Results

fe-0/1/0 {
unit 0 {
family inet {
address 192.0.2.2/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 {
47
}
Verification
IN THIS SECTION
Verifying the Link-State Database | 47
Verifying the Status of OSPFv3 Interfaces with Multiple Address Families | 47
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
Verify the status of the interface for the specified OSPFv3 realm, or address family.
Action
From operational mode, enter the show ospf3 interface realm ipv4-unicast command.
4 CHAPTER
Configure OSPF Areas
Configuring OSPF Areas | 49

49
Configuring OSPF Areas
IN THIS SECTION
OSPF Designated Router Overview | 53
Example: Configuring an OSPF Router Identifier | 54
Example: Controlling OSPF Designated Router Election | 57
Understanding OSPF Areas and Backbone Areas | 60
Example: Configuring a Single-Area OSPF Network | 62
Example: Configuring a Multiarea OSPF Network | 65
Understanding Multiarea Adjacency for OSPF | 71
Example: Configuring Multiarea Adjacency for OSPF | 71
Understanding Multiarea Adjacencies for OSPFv3 | 78
Example: Configuring a Multiarea Adjacency for OSPFv3 | 79
Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas | 89
Understanding OSPFv3 Stub and Totally Stubby Areas | 104
Example: Configuring OSPFv3 Stub and Totally Stubby Areas | 104
Understanding OSPFv3 Not-So-Stubby Areas | 120
Example: Configuring OSPFv3 Not-So-Stubby Areas | 120
Understanding Not-So-Stubby Areas Filtering | 140
Example: Configuring OSPFv3 Not-So-Stubby Areas with Filtering | 140
Understanding OSPF Virtual Links for Noncontiguous Areas | 151
Example: Configuring OSPFv3 Virtual Links | 159

50
Understanding OSPF Areas
IN THIS SECTION
Areas | 50
Area Border Routers | 51
Backbone Areas | 51
AS Boundary Routers | 51
Backbone Router | 51
Internal Router | 51
Stub Areas | 52
Not-So-Stubby Areas | 52
Transit Areas | 52
OSPF Area Types and Accepted LSAs | 52
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
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.

51
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 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.
52
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.
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.
OSPF Area Types and Accepted LSAs
The following table gives details about OSPF area types and accepted LSAs:
53
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
54
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.
Example: Configuring an OSPF Router Identifier
IN THIS SECTION
Requirements | 54
Overview | 55
Configuration | 55
Verification | 57
This example shows how to configure an OSPF router identifier.
Requirements
Before you begin:
• 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.
• Configure the device interfaces. See the Interfaces User Guide for Security Devices
55
Overview
The router identifier is used by OSPF to identify the routing device from which a packet originated.
Junos OS selects a router identifier according to the following set of rules:
1. By default, Junos OS selects the lowest configured physical IP address of an interface as the router
identifier.
2. If a loopback interface is configured, the IP address of the loopback interface becomes the router
identifier.
3. If multiple loopback interfaces are configured, the lowest loopback address becomes the router
identifier.
4. If a router identifier is explicitly configured using the router-id address statement under the [edit
routing-options] hierarchy level, the above three rules are ignored.
NOTE: 1. The router identifier behavior described here holds good even when configured under
[edit routing-instances routing-instance-name routing-options] and [edit logical-systems logical-
system-name routing-instances routing-instance-name routing-options] hierarchy levels.
2. If the router identifier is modified in a network, the link-state advertisements (LSAs) advertised
by the previous router identifier are retained in the OSPF database until the LSA retransmit
interval has timed out. Hence, it is strongly recommended that you explicitly configure the router
identifier under the [edit routing-options] hierarchy level to avoid unpredictable behavior if the
interface address on a loopback interface changes.
In this example, you configure the OSPF router identifier by setting its router ID value to the IP address
of the device, which is 192.0.2.24.
Configuration
IN THIS SECTION
Procedure | 56
Results | 56
56
To quickly configure an OSPF router identifier, copy the following commands, paste them into a text file,
remove any line breaks, change any details necessary to match your network configuration, copy and
paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration
mode.
[edit]
set routing-options router-id 192.0.2.24
Procedure
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 192.0.2.24
[edit]
user@host# commit
Results
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 192.0.2.24;
57
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
IN THIS SECTION
Requirements | 57
Overview | 57
Configuration | 58
Verification | 59
This example shows how to control OSPF designated router election.
Requirements
Before you begin:
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.
58
Configuration
IN THIS SECTION
Procedure | 58
Results | 59
To quickly configure an OSPF designated router election, copy the following commands, paste them into
a text file, remove any line breaks, change any details necessary to match your network configuration,
configuration mode.
[edit]
set protocols ospf area 0.0.0.3 interface ge-0/0/1 priority 200
Procedure
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.
[edit]
user@host# set protocols ospf area 0.0.0.3 interface ge-0/0/1 priority 200
59
[edit]
user@host# commit
Results

area 0.0.0.3 {
priority 200;
}
}
Verification
IN THIS SECTION
Verifying the Designated Router Election | 59
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.
60
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.
Understanding OSPF Areas and Backbone Areas
OSPF networks in an autonomous system (AS) are administratively grouped into . 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 . All interfaces on
internal routers are directly connected to networks within the area.
The central area of an AS, called the, 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
(ABRs). Figure 3 on page 60 shows an OSPF topology of three areas connected by two ABRs.
Figure 3: 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
61
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 3 on page 60, packets sent from
Router A to Router C are automatically routed through ABR B.
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 4 on page 61 shows a virtual link between a noncontiguous area
and the backbone area through an area connected to both.
Figure 4: OSPF Topology with a Virtual Link
In the topology shown in Figure 4 on page 61, 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.
62
Example: Configuring a Single-Area OSPF Network
IN THIS SECTION
Requirements | 62
Overview | 62
Configuration | 63
Verification | 64
This example shows how to configure a single-area OSPF network.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 63
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.
63
To use OSPF on the device, you must configure at least one OSPF area, such as the one shown in Figure
5 on page 63.
Figure 5: Typical Single-Area OSPF Network Topology
Topology
Configuration
IN THIS SECTION
Procedure | 64
Results | 64
To quickly configure a single-area OSPF network, copy the following commands, paste them into a text
configuration mode.
[edit]
64
Procedure
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
[edit]
user@host# commit
Results

area 0.0.0.0 {
}
Verification
IN THIS SECTION
Verifying the Interfaces in the Area | 65

65
Verifying the Interfaces in the Area
Purpose
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.
Action
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
IN THIS SECTION
Requirements | 65
Overview | 66
Configuration | 67
Verification | 70
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.
Requirements
Before you begin:
66
Overview
IN THIS SECTION
Topology | 66
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 6 on page
66, 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 6 on page 66. In this example, you create the backbone area, create
an additional area (area 2) and assign it unique area ID 0.0.0.2, and you configure Device B as the area
border router, where interface ge-0/0/0 participates in OSPF area 0 and interface ge-0/0/2 participates
in OSPF area 2.
Figure 6: Typical Multiarea OSPF Network Topology
Topology
67
Configuration
IN THIS SECTION
Procedure | 67
Results | 69
Procedure
To quickly configure a multiarea OSPF network, copy the following commands, paste them into a text
configuration mode.
Device A
[edit]
Device C
[edit]
Device B
[edit]
68
Device D
[edit]
Device E
[edit]
To configure a multiarea OSPF network:
1. Configure the backbone area.
NOTE: For an OSPFv3 network, include the ospf3 statement at the [edit protocols] hierarchy
level.
[edit]
user@A# set protocols ospf area 0.0.0.0 interface ge-0/0/0
user@A# set protocols ospf area 0.0.0.0 interface ge-0/0/1
[edit]
user@C# set protocols ospf area 0.0.0.0 interface ge-0/0/0
[edit]
user@B# set protocols ospf area 0.0.0.0 interface ge-0/0/0
2. Configure an additional area for your OSPF network.

69
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
user@D# set protocols ospf area 0.0.0.2 interface ge-0/0/2
[edit]
user@E# set protocols ospf area 0.0.0.2 interface ge-0/0/2
[edit]
user@host# commit
Results

area 0.0.0.0 {
}
user@C# show protocols ospf

area 0.0.0.0 {
}
user@B# show protocols ospf

area 0.0.0.0 {
70
}
area 0.0.0.2 {
}
user@D# show protocols ospf

area 0.0.0.2 {
}
user@E# show protocols ospf

area 0.0.0.2 {
}
Verification
IN THIS SECTION
Purpose
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.
71
Action
From operational mode, enter the show ospf interface command for OSPFv2, and enter the show ospf3
interface command for OSPFv3.
Understanding 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.
Example: Configuring Multiarea Adjacency for OSPF
IN THIS SECTION
Requirements | 72
Overview | 72
Configuration | 73
Verification | 77
72
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.
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.
73
• You cannot configure a secondary interface by its IP address.
Figure 7: Multiarea Adjacency in OSPF
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 statement. You configure interface so-0/0/0 on ABR R1 and
interface so-1/0/0 on ABR R2.
Configuration
IN THIS SECTION
Procedure | 74
Results | 76
To quickly configure a secondary logical interface for an OSPF area, copy the following commands, paste
74
Configuration on ABR R1:
[edit]
set interfaces so-0/0/0 unit 0 family inet address 192.0.2.45/24
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
[edit]
set protocols ospf area 0.0.0.2 interface so-1/0/0 secondary
Procedure
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.0.2.45/24
[edit]
75
2. Configure the router identifier.
[edit]
user@R1# set routing-options router-id 10.255.0.1
[edit]
3. On each ABR, configure the primary interface for the OSPF area.
[edit]
user@R1# set protocols ospf area 0.0.0.1 interface so-0/0/0
[edit ]
4. On each ABR, configure the secondary interface for the OSPF area.
[edit ]
user@R1# set protocols ospf area 0.0.0.2 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.

user@host# commit
76
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.
user@R1# show interfaces

so-0/0/0 {
unit 0 {
family inet {
address 192.0.2.45/24;
}
}
}
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 {
secondary;
}
}

so-0/0/0 {
unit 0 {
family inet {
address 192.0.2.37/24;
}
77
}
}

router-id 10.255.0.2;

area 0.0.0.1 {
}
area 0.0.0.2 {
secondary;
}
}
Verification
IN THIS SECTION
Verifying the Secondary Interface | 77
Verifying Neighbor Adjacencies | 78
Verifying the Secondary Interface
Purpose
Verify that the secondary interface appears for the configured area. The Secondary field is displayed if
the interface is configured as a secondary interface. The output might also show the same interface
listed in multiple areas.
78
Action
Purpose
Verify the interfaces configured for the specified area.
Action
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
Verify the primary and secondary neighbor adjacencies. The Secondary field displays if the neighbor is
on a secondary interface.
Action
From operational mode, enter the show ospf neighbor detail command for OSPFv2, and enter the show
ospf3 neighbor detail command for OSPFv3.
Understanding Multiarea Adjacencies for OSPFv3
An area is a set of networks and hosts within an OSPFv3 domain that have been administratively
grouped together. By default, a single interface can belong to only one OSPFv3 area. However, in some
situations, you might want to configure an interface to belong to more than one area to avoid
suboptimal routing. Doing so allows the corresponding link to be considered an intra-area link in
multiple areas and to be preferred over higher-cost intra-area links.
In Junos OS Release 9.2 and later, you can configure an 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
79
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.
An interface is considered to be primarily in one area. When you configure the same interface in another
area, it is considered to be secondarily in the other area. You designate the secondary area by including
the secondary statement at the [edit protocols ospf3 area area-number interface interface-name]
hierarchy level.
Example: Configuring a Multiarea Adjacency for OSPFv3
IN THIS SECTION
Requirements | 79
Overview | 79
Configuration | 80
Verification | 87
This example shows how to configure a multiarea adjacency for OSPFv3.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
OSPFv3 intra-area paths are preferred over inter-area paths. In this example, Device R1 and Device R2
are area border routers (ABRs) with interfaces in both area 0 and in area 1. The link between Device R1
and R2 is in area 0 and is a high-speed link. The links in area 1 are lower speed.
If you want to forward some of area 1’s traffic between Device R1 and Device R2 over the high-speed
link, one method to accomplish this goal is to make the high-speed link a multiarea adjacency so that the
link is part of both area 0 and area 1.
If the high-speed link between Device R1 and Device R2 remains in area 1 only, Device R1 always routes
traffic to Device R4 and Device R5 through area 1 over the lower-speed links. Device R1 also uses the
intra-area area 1 path through Device R3 to get to area 1 destinations downstream of Device R2.
Clearly, this scenario results in suboptimal routing.

80
An OSPF virtual link cannot be used to resolve this issue without moving the link between Device R1
and Device R2 to area 1. You might not want to do this if the physical link belongs to the network's
backbone topology.
The OSPF/OSPFv3 protocol extension described in RFC 5185, OSPF Multi-Area Adjacency resolves the
issue, by allowing the link between Device R1 and Device R2 to be part of both the backbone area and
area 1.
To create a multiarea adjacency, you configure an interface to be in two areas, with ge-1/2/0 on Device
R1 configured in both area 0 and area 1, and ge-1/2/0 on Device R2 configured in both area 0 and area
1. On both Device R1 and Device R2, area 0 contains the primary interface and is the primary link
between the devices. Area 1 contains the secondary logical interface, which you configure by including
the secondary statement.
Figure 8: OSPFv3 Multiarea Adjacency
"CLI Quick Configuration" shows the configuration for all of the devices in Figure 8 on page 80. The
section "No Link Title" describes the steps on Device R1 and Device R2.
Configuration
IN THIS SECTION
Procedure | 81
81
Procedure
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 R1
set interfaces ge-1/2/0 unit 0 family inet6 address 2001:db8::1/64

set interfaces fe-1/2/1 unit 0 family inet6 address 2001:db8::2/64
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set interfaces lo0 unit 0 family inet6 address 1::1/128
set protocols ospf3 area 0.0.0.0 interface ge-1/2/0.0
set protocols ospf3 area 0.0.0.0 interface lo0.0 passive
set protocols ospf3 area 0.0.0.1 interface fe-1/2/1.0
set protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0 secondary
Device R2
set interfaces ge-1/2/0 unit 0 family inet6 address 9009:1::2/64

set interfaces fe-1/2/1 unit 0 family inet6 address 9009:4::1/64
set protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0 secondary
Device R3

82

Device R4

Device R5

Device R6

information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device R1:

83
1. Configure the interfaces.
[edit interfaces]
user@R1# set ge-1/2/0 unit 0 family inet6 address 9009:1::1/64
user@R1# set fe-1/2/1 unit 0 family inet6 address 9009:2::2/64
user@R1# set lo0 unit 0 family inet address 1.1.1.1/32
user@R1# set lo0 unit 0 family inet6 address 1::1/128
2. Enable OSPFv3 on the interfaces that are in area 0.
[edit protocols ospf3 area 0.0.0.0]

user@R1# set interface ge-1/2/0.0
user@R1# set interface lo0.0 passive
3. Enable OSPFv3 on the interface that is in area 1.

user@R1# set interface fe-1/2/1.0
user@R1# set interface ge-1/2/0.0 secondary
Guide.
[edit interfaces]
user@R2# set ge-1/2/0 unit 0 family inet6 address 9009:1::2/64
user@R2# set lo0 unit 0 family inet6 address 2::2/128
84


user@R2# set interface ge-1/2/0.0 secondary
Results
From configuration mode, confirm your configuration by entering the show interfaces and show
protocols commands. If the output does not display the intended configuration, repeat the instructions
in this example to correct the configuration.
Device R1

ge-1/2/0 {
unit 0 {
family inet6 {
address 9009:1::1/64;
}
}
}
fe-1/2/1 {
unit 0 {
family inet6 {
address 9009:2::2/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 1.1.1.1/32;
85
}
family inet6 {
address 1::1/128;
}
}
}
user@R1# show protocols

ospf3 {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
area 0.0.0.1 {
secondary;
}
}
}
Device R2

ge-1/2/0 {
unit 0 {
family inet6 {
address 9009:1::2/64;
}
}
}
fe-1/2/1 {
unit 0 {
family inet6 {
address 9009:4::1/64;
}
}
}
fe-1/2/2 {
86
unit 0 {
family inet6 {
address 9009:6::2/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 2.2.2.2/32;
}
family inet6 {
address 2::2/128;
}
}
}

ospf3 {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
area 0.0.0.1 {
secondary;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
87
Verification
IN THIS SECTION
Verifying the Flow of Traffic | 87
Verifying That the Traffic Flow Changes When You Remove the Multiarea Adjacency | 88
Verifying the Flow of Traffic
Purpose
Verify that traffic uses the high-speed link between Device R1 and Device R2 to reach destinations in
area 1.
Action
From operational mode on Device R1, use the traceroute command check the traffic flow to Device R5
and Device R6.
user@R1> traceroute 6::6

traceroute6 to 6::6 (6::6) from 9009:1::1, 64 hops max, 12 byte packets
1 9009:1::2 (9009:1::2) 1.361 ms 1.166 ms 1.117 ms
2 6::6 (6::6) 1.578 ms 1.484 ms 1.488 ms

1 9009:1::2 (9009:1::2) 1.312 ms 1.472 ms 1.132 ms
2 9009:4::1 (9009:4::1) 1.137 ms 1.174 ms 1.126 ms
3 5::5 (5::5) 1.591 ms 1.445 ms 1.441 ms
Meaning
The traceroute output shows that traffic uses the 9009:1:: link between Device R1 and Device R2.
88
Verifying That the Traffic Flow Changes When You Remove the Multiarea Adjacency
Purpose
Verify the results without the multiarea adjacency configured.
Action
1. Deactivate the backbone link interfaces in area 1.
user@R1# deactivate protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0

user@R1# commit
user@R2# deactivate protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0
user@R2# commit
2. From operational mode on Device R1, use the traceroute command check the traffic flow to Device
R5 and Device R6.

1 9009:2::1 (9009:2::1) 1.314 ms 8.523 ms 8.310 ms
2 9009:3::2 (9009:3::2) 1.166 ms 1.162 ms 1.172 ms
3 9009:4::1 (9009:4::1) 1.386 ms 1.182 ms 1.138 ms
4 6::6 (6::6) 1.605 ms 1.469 ms 1.438 ms

1 9009:2::1 (9009:2::1) 1.365 ms 1.174 ms 1.133 ms
2 9009:3::2 (9009:3::2) 1.157 ms 1.198 ms 1.138 ms
3 5::5 (5::5) 1.584 ms 1.461 ms 1.443 ms
Meaning
Without the multiarea adjacency, the output shows suboptimal routing with traffic taking the path
through the area 1 low-speed-links.
89
Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-

Stubby Areas
Figure 9 on page 89 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.
Figure 9: OSPF AS Network with Stub Areas and NSSAs
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 9 on page 89 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
90
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.
Similar to area 0.0.0.3 in Figure 9 on page 89, 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
IN THIS SECTION
Requirements | 90
Overview | 91
Configuration | 93
Verification | 95
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.
Requirements
Before you begin:
91
Overview
IN THIS SECTION
Topology | 92
The backbone area, which is 0 in Figure 10 on page 92, 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:
• 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.
92
• 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.
Figure 10: OSPF Network Topology with Stub Areas and NSSAs
Topology
93
Configuration
IN THIS SECTION
Procedure | 93
Results | 94
• 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 07 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 07 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
Procedure
To configure OSPF stub areas:
1. On all routing devices in the area, configure an OSPF stub area.

94
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. 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
[edit]
user@host# commit
Results
Configuration on all routing devices:

area 0.0.0.7 {
stub;
}
95
Configuration on the ABR (the output also includes the optional setting):

area 0.0.0.7 {
stub default-metric 10 no-summaries;
}
Verification
IN THIS SECTION
Verifying the Type of OSPF Area | 95
Purpose
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
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.
96
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
IN THIS SECTION
Requirements | 96
Overview | 96
Configuration | 98
Verification | 102
This example shows how to configure an OSPF not-so-stubby area (NSSA) to control the advertisement
of external routes into an area.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 98
97
The backbone area, which is 0 in Figure 11 on page 98, 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.
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
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
98
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.
Figure 11: OSPF Network Topology with Stub Areas and NSSAs
Topology
Configuration
IN THIS SECTION
Configuring Routing Devices to Participate in a Not-So-Stubby-Area | 99
Disabling the Export of Type 7 Link State Advertisements into Not-So-Stubby Areas | 101
99
Configuring Routing Devices to Participate in a Not-So-Stubby-Area
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
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
100
[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.

user@host# set default-lsa metric-type 1
5. (Optional) On the ABR, specify the flooding of Type 7 LSAs.

user@host# set default-lsa type-7
6. On the ABR, restrict summary LSAs from entering the area.

user@host# set no-summaries

user@host# commit
Results
Configuration on all routing devices in the area:

area 0.0.0.9 {
nssa;
}
101
Configuration on the ABR. The output also includes the optional metric-type and type-7 statements.

area 0.0.0.9 {
nssa {
default-lsa {
default-metric 10;
metric-type 1;
type-7;
}
no-summaries;
}
}
Disabling the Export of Type 7 Link State Advertisements into Not-So-Stubby Areas
To quickly disable exporting Type 7 LSAs into the NSSA, copy the following commands, paste them into
configuration mode. 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.

102
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# set protocols ospf no-nssa-abr
[edit]
user@host# commit
Results

no-nssa-abr;
Verification
IN THIS SECTION
Verifying the Type of OSPF Area | 103
Verifying the Type of LSAs | 103

103
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
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
104
Understanding OSPFv3 Stub and Totally Stubby Areas
Junos OS OSPFv3 configuration for IPv6 networks is identical to OSPFv2 configuration. You configure
the protocol with set ospf3 commands instead of set ospf commands and use show ospf3 commands
instead of show ospf commands to check the OSPF status. Also, make sure to set IPv6 addresses on the
interfaces running OSPFv3.
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:
• 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).
Example: Configuring OSPFv3 Stub and Totally Stubby Areas
IN THIS SECTION
Requirements | 104
Overview | 105
Configuration | 106
Verification | 116
This example shows how to configure an OSPFv3 stub area and a totally stubby area to control the
advertisement of external routes into an area.
Requirements
105
Overview
Figure 12 on page 105 shows the topology used in this example.
Figure 12: OSPFv3 Network Topology with Stub Areas
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
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
106
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.
section "No Link Title" describes the steps on Device 2, Device 6, Device 7, and Device 8.
Configuration
IN THIS SECTION
Procedure | 106
Procedure
Device 1

107

Device 2

set protocols ospf3 area 0.0.0.7 stub default-metric 10
set protocols ospf3 area 0.0.0.7 stub no-summaries
Device 3

Device 4

Device 5

108
Device 6

set protocols ospf3 area 0.0.0.7 stub
Device 7

set protocols ospf3 export static-to-ospf
set policy-options policy-statement static-to-ospf term 1 from protocol static
set policy-options policy-statement static-to-ospf term 1 then accept
set routing-options rib inet6.0 static route 1010::1/128 next-hop 9009:7::2
Device 8

Guide.
To configure Device 2:
109
[edit interfaces]
user@2# set fe-1/2/0 unit 0 family inet6 address 9009:2::2/64
user@2# set lo0 unit 0 family inet address 2.2.2.2/32

user@2# set interface fe-1/2/0.0
user@2# set interface lo0.0 passive

4. Specify area 7 as an OSPFv3 stub area.
The stub statement is required on all routing devices in the area.

user@2# set stub

user@2# set stub default-metric 10
6. (Optional) On the ABR, restrict summary LSAs from entering the area.
This step converts the stub area into a totally stubby area.

user@2# set stub no-summaries
110
Guide.
[edit interfaces]

3. Specify area 7 as an OSPFv3 stub area.
The stub statement is required on all routing devices in the area.

user@6# set stub
Guide.
[edit interfaces]
111


3. Configure static routes that enable connectivity to the customer routes.
[edit routing-options rib inet6.0 static]

user@7# set route 1010::1/128 next-hop 9009:7::2
4. Configure a routing policy to redistribute the static routes.
[edit policy-options policy-statement static-to-ospf term 1]

user@7# set from protocol static
user@7# set then accept
5. Apply the routing policy to the OSPFv3 instance.
[edit protocols ospf3]

user@7# set export static-to-ospf
Guide.
112
[edit interfaces]
2. Configure two loopback interface addresses to simulate customer routes.
[edit interfaces lo0 unit 0 family inet6]

user@8# set address 1010::1/128
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.
Device 2
user@2# show interfaces

fe-1/2/0 {
unit 0 {
family inet6 {
address 9009:2::2/64;
}
}
}
fe-1/2/1 {
unit 0 {
family inet6 {
address 9009:4::1/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 2.2.2.2/32;
}
113
}
}
user@2# show protocols

ospf3 {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
area 0.0.0.7 {
stub default-metric 10 no-summaries;
}
}
Device 6

fe-1/2/0 {
unit 0 {
family inet6 {
address 9009:4::2/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 6.6.6.6/32;
}
}
}

ospf3 {
area 0.0.0.7 {
stub;
114
interface lo0.0 {
passive;
}
}
}
Device 7

fe-1/2/0 {
unit 0 {
family inet6 {
address 9009:5::2/64;
}
}
}
fe-1/2/1 {
unit 0 {
family inet6 {
address 9009:7::1/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 7.7.7.7/32;
}
}
}

ospf3 {
export static-to-ospf;
area 0.0.0.9 {
interface lo0.0 {
passive;
}
115
}
}
user@7# show policy-options

policy-statement static-to-ospf {
term 1 {
from protocol static;
then accept;
}
}
user@7# show routing-options

rib inet6.0 {
static {
route 1010::1/128 next-hop 9009:7::2;
route 2020::1/128 next-hop 9009:7::2;
}
}
Device 8

fe-1/2/0 {
unit 0 {
family inet6 {
address 9009:7::2/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 8.8.8.8/32;
}
family inet6 {
address 1010::1/128;
address 2020::1/128;
}
116
}
}
Verification
IN THIS SECTION
Verifying the Type of OSPFv3 Area | 116
Verifying the Routes in the OSPFv3 Stub Area | 117
Verifying the Type of OSPFv3 Area
Purpose
Verify that the OSPFv3 area is a stub area. Confirm that the output displays Stub as the Stub type.
Action
From operational mode on Device 2 and on Device 6, enter the show ospf3 overview command.
user@2> show ospf3 overview

Instance: master
Router ID: 2.2.2.2
Route table index: 51
Area border router
LSA refresh time: 50 minutes
Area: 0.0.0.0
Stub type: Not Stub
Area border routers: 2, AS boundary routers: 0
Neighbors
Up (in full state): 1
Area: 0.0.0.7
Stub type: Stub, Stub cost: 10
117
Neighbors
Topology: default (ID 0)
Prefix export count: 0
Full SPF runs: 24
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
Backup SPF: Not Needed

Instance: master
Router ID: 6.6.6.6
Area: 0.0.0.7
Stub type: Stub
Neighbors
Full SPF runs: 17
Meaning
On Device 2, the stub type of area 0 is Not Stub. The stub type of area 7 is Stub. The stub default metric
is 10.
On Device 6, the stub type of area 7 is Stub.
Verifying the Routes in the OSPFv3 Stub Area
Purpose
Make sure that the expected routes are present in the routing tables.
118
Action
From operational mode on Device 6 and Device 2, enter the show route command.
user@6> show route

inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
6.6.6.6/32 *[Direct/0] 1d 01:57:12

> via lo0.0
inet6.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

::/0 *[OSPF3/10] 00:10:52, metric 11

> via fe-1/2/0.0
9009:4::/64 *[Direct/0] 1d 01:56:31
> via fe-1/2/0.0
[OSPF3/10] 1d 01:56:31, metric 1
> via fe-1/2/0.0
9009:4::2/128 *[Local/0] 1d 01:56:53
Local via fe-1/2/0.0
fe80::/64 *[Direct/0] 1d 01:56:31
> via fe-1/2/0.0
fe80::2a0:a514:0:a4c/128
*[Local/0] 1d 01:56:53
ff02::5/128 *[OSPF3/10] 1d 01:58:22, metric 1
MultiRecv
user@2> show route

2.2.2.2/32 *[Direct/0] 1d 02:16:13

> via lo0.0

1010::1/128 *[OSPF3/150] 00:30:15, metric 0, tag 0

119
> via fe-1/2/0.0

2020::1/128 *[OSPF3/150] 00:30:15, metric 0, tag 0
> via fe-1/2/0.0
9009:1::/64 *[OSPF3/10] 1d 02:15:54, metric 2
> via fe-1/2/0.0
9009:2::/64 *[Direct/0] 1d 02:15:54
> via fe-1/2/0.0
[OSPF3/10] 1d 02:15:54, metric 1
> via fe-1/2/0.0
9009:2::2/128 *[Local/0] 1d 02:15:54
9009:3::/64 *[OSPF3/10] 1d 02:15:54, metric 2
> via fe-1/2/0.0
9009:4::/64 *[Direct/0] 1d 02:15:54
> via fe-1/2/1.0
[OSPF3/10] 05:38:05, metric 1
> via fe-1/2/1.0
9009:4::1/128 *[Local/0] 1d 02:15:54
9009:5::/64 *[OSPF3/10] 1d 02:15:54, metric 3
> via fe-1/2/0.0
9009:6::/64 *[OSPF3/10] 1d 01:33:10, metric 3
> via fe-1/2/0.0
fe80::/64 *[Direct/0] 1d 02:15:54
> via fe-1/2/0.0
[Direct/0] 1d 02:15:54
> via fe-1/2/1.0
fe80::2a0:a514:0:64c/128
*[Local/0] 1d 02:15:54
fe80::2a0:a514:0:94c/128
*[Local/0] 1d 02:15:54
ff02::5/128 *[OSPF3/10] 1d 02:17:45, metric 1
MultiRecv
Meaning
On Device 6, the default route has been learned because of the default-metric statement on the ABR,
Device 2. Otherwise, the only OSPFv3 routes in Device 6’s routing table are the network address
9009:4::/64 and the OSPFv3 multicast address ff02::5/128 for all SPF link-state routers, also known as
AllSPFRouters.
120
On Device 2, all of the OSPFv3 routes have been learned, including the external customer routes,
1010::1/128 and 2020::1/128.
Understanding OSPFv3 Not-So-Stubby Areas
Like an OSPF stub area, an OSPFv3 stub area has no external routes, so you cannot redistribute routes
from another protocol into a stub area. Not-so-stubby-areas (NSSAs) allow external routes to be flooded
within the area. Routers in an NSSA do not receive external link-state advertisements (LSAs) from area
border routers (ABRs), but are allowed to send external routing information for redistribution. They use
type 7 LSAs to tell the ABRs about these external routes, which the ABR then translates to type 5
external LSAs and floods as normal to the rest of the OSPF network.
Example: Configuring OSPFv3 Not-So-Stubby Areas
IN THIS SECTION
Requirements | 120
Overview | 120
Configuration | 122
Verification | 133
This example shows how to configure an OSPFv3 not-so-stubby area (NSSA) to control the
advertisement of external routes into the area.
Requirements
Overview
In this example, Device 7 redistributes static Customer 1 routes into OSPFv3. Device 7 is in area 9,
which is configured as an NSSA. Device 3 is the ABR attached to the NSSA. An NSSA is a type of stub
area that can import autonomous system external routes and send them to other areas, but still cannot
receive AS-external routes from other areas. Because area 9 is defined as an NSSA, Device 7 uses type 7
121
LSAs to tell the ABR (Device 3) about these external routes. Device 3 then translates the type 7 routes
to type 5 external LSAs and floods them as normal to the rest of the OSPF network.
In area 3, Device 5 redistributes static Customer 2 routes into OSPFv3. These routes are learned on
Device 3, but not on Device 7 or 10. Device 3 injects a default static route into area 9 so that Device 7
and 10 can still reach the Customer 2 routes.
You configure each routing device in area 9 (area ID 0.0.0.9) with the following setting:
• nssa—Specifies an OSPFv3 NSSA. You must include the nssa statement on all routing devices in area
9.
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 summary 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
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 OSPFv3 exports route information from external ASs, it includes a cost,
or external metric, in the route. The difference between the two metrics is how OSPFv3
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, OSPFv3 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
122
into NSSAs for Junos OS release 5.0 and later. To support backward compatibility with earlier
Junos OS releases, include the type-7 statement.
Figure 13: OSPFv3 Network Topology with an NSSA
section "No Link Title" describes the steps on Device 3, Device 7, and Device 9.
Configuration
IN THIS SECTION
Procedure | 123
123
Procedure
Device 1

Device 3

set protocols ospf3 area 0.0.0.9 nssa default-lsa default-metric 10
set protocols ospf3 area 0.0.0.9 nssa default-lsa metric-type 1
set protocols ospf3 area 0.0.0.9 nssa default-lsa type-7
set protocols ospf3 area 0.0.0.9 nssa no-summaries
Device 4

124
Device 5

Device 7

set protocols ospf3 export static2-to-ospf
set protocols ospf3 area 0.0.0.9 nssa
set policy-options policy-statement static2-to-ospf term 1 from protocol static
set policy-options policy-statement static2-to-ospf term 1 then accept
Device 8

Device 9

125

Device 10

Guide.
[edit interfaces]


126
4. Configure an OSPFv3 NSSA.
The nssa statement is required on all routing devices in the area.

user@3# set nssa

user@3# set default-lsa default-metric 10

user@3# set nssa default-lsa metric-type 1

user@3# set nssa default-lsa type-7

user@3# set nssa no-summaries
Guide.
127
[edit interfaces]

3. Configure static routes that enable connectivity to the customer routes.

4. Configure a routing policy to redistribute the static routes.

5. Apply the routing policy to the OSPFv3 instance.

Guide.
128
[edit interfaces]


user@7# set nssa
Guide.
[edit interfaces]
129
2. Configure two loopback interface addresses to simulate customer routes.
[edit interfaces lo0 unit 0 family inet6]

Results
Device 3

fe-1/2/0 {
unit 0 {
family inet6 {
address 9009:3::2/64;
}
}
}
fe-1/2/1 {
unit 0 {
family inet6 {
address 9009:5::1/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 3.3.3.3/32;
}
}
130
}
}

ospf3 {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
area 0.0.0.9 {
nssa {
default-lsa {
default-metric 10;
metric-type 1;
type-7;
}
no-summaries;
}
}
}
Device 5

fe-1/2/0 {
unit 0 {
family inet6 {
address 9009:6::2/64;
}
}
}
fe-1/2/1 {
unit 0 {
family inet6 {
address 9009:7::1/64;
}
}
}
131
lo0 {
unit 0 {
family inet {
address 5.5.5.5/32;
}
}
}

ospf3 {
area 0.0.0.3 {
interface lo0.0 {
passive;
}
}
}

term 1 {
then accept;
}
}

rib inet6.0 {
static {
route 1010::1/128 next-hop 9009:7::2;
route 2020::1/128 next-hop 9009:7::2;
}
}
132
Device 7

fe-1/2/0 {
unit 0{
family inet6 {
address 9009:5::2/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 7.7.7.7/32;
}
}
}

ospf3 {
area 0.0.0.9 {
nssa;
interface lo0.0 {
passive;
}
}
}
Device 8

fe-1/2/0 {
unit 0 {
family inet6 {
address 9009:7::2/64;
}
}
}
lo0 {
133
unit 0 {
family inet {
address 8.8.8.8/32;
}
family inet6 {
address 1010::1/128;
address 2020::1/128;
}
}
}
Verification
IN THIS SECTION
Verifying the Type of OSPFv3 Area | 133
Verifying the Type of OSPFv3 Area
Purpose
Verify that the OSPFv3 area is an NSSA area. Confirm that the output displays Stub NSSA as the Stub
type.
Action
From operational mode on Device 3, Device 7, and Device 10 enter the show ospf3 overview command.

Instance: master
Router ID: 3.3.3.3
134
Area border router, AS boundary router, NSSA router

Area: 0.0.0.0
Stub type: Not Stub
Neighbors
Area: 0.0.0.9
Stub type: Stub NSSA, Stub cost: 10
Neighbors
Full SPF runs: 22

Instance: master
Router ID: 7.7.7.7
AS boundary router, NSSA router
Area: 0.0.0.9
Stub type: Stub NSSA
Neighbors
Full SPF runs: 11

Instance: master
Router ID: 10.10.10.10
NSSA router
135

Area: 0.0.0.9
Stub type: Stub NSSA
Neighbors
Full SPF runs: 6
Meaning
On Device 3, the stub type of area 0 is Not Stub. The stub type of area 9 is Stub NSSA. The stub default
metric is 10.
On Device 7 and Device 10, the stub type of area 9 is Stub NSSA.
Purpose
Action
user@7> show route

7.7.7.7/32 *[Direct/0] 3d 03:00:23

> via lo0.0

::/0 *[OSPF3/150] 01:01:31, metric 12, tag 0

> via fe-1/2/1.0
136
3030::1/128 *[Static/5] 01:01:43

> to 9009:8::2 via fe-1/2/0.0
4040::1/128 *[Static/5] 01:01:43
> to 9009:8::2 via fe-1/2/0.0
9009:5::/64 *[OSPF3/10] 01:01:33, metric 2
> via fe-1/2/1.0
9009:8::/64 *[Direct/0] 01:01:43
> via fe-1/2/0.0
9009:8::1/128 *[Local/0] 01:02:01
9009:9::/64 *[Direct/0] 01:01:45
> via fe-1/2/1.0
[OSPF3/10] 01:01:44, metric 1
> via fe-1/2/1.0
9009:9::1/128 *[Local/0] 01:02:01
fe80::/64 *[Direct/0] 01:01:45
> via fe-1/2/1.0
[Direct/0] 01:01:43
> via fe-1/2/0.0
fe80::2a0:a514:0:f4c/128
*[Local/0] 01:02:01
fe80::2a0:a514:0:114c/128
*[Local/0] 01:02:01
ff02::5/128 *[OSPF3/10] 3d 03:01:25, metric 1
MultiRecv
user@10> show route

10.10.10.10/32 *[Direct/0] 01:01:59

> via lo0.0

::/0 *[OSPF3/150] 01:01:35, metric 11, tag 0

> via fe-1/2/0.0
137
3030::1/128 *[OSPF3/150] 01:01:35, metric 0, tag 0

> via fe-1/2/1.0
4040::1/128 *[OSPF3/150] 01:01:35, metric 0, tag 0
> via fe-1/2/1.0
9009:5::/64 *[Direct/0] 01:01:50
> via fe-1/2/0.0
[OSPF3/10] 01:01:50, metric 1
> via fe-1/2/0.0
9009:5::2/128 *[Local/0] 01:01:50
9009:9::/64 *[Direct/0] 01:01:50
> via fe-1/2/1.0
[OSPF3/10] 01:01:40, metric 1
> via fe-1/2/1.0
9009:9::2/128 *[Local/0] 01:01:50
fe80::/64 *[Direct/0] 01:01:50
> via fe-1/2/0.0
[Direct/0] 01:01:50
> via fe-1/2/1.0
fe80::2a0:a514:0:c4c/128
*[Local/0] 01:01:50
fe80::2a0:a514:0:124c/128
*[Local/0] 01:01:50
ff02::5/128 *[OSPF3/10] 01:02:16, metric 1
MultiRecv
user@3> show route

3.3.3.3/32 *[Direct/0] 3d 03:03:10

> via lo0.0

1010::1/128 *[OSPF3/150] 01:04:21, metric 0, tag 0

> via fe-1/2/0.0
138
2020::1/128 *[OSPF3/150] 01:04:21, metric 0, tag 0

> via fe-1/2/0.0
3030::1/128 *[OSPF3/150] 01:03:57, metric 0, tag 0
> via fe-1/2/1.0
4040::1/128 *[OSPF3/150] 01:03:57, metric 0, tag 0
> via fe-1/2/1.0
9009:1::/64 *[OSPF3/10] 3d 03:02:06, metric 2
> via fe-1/2/0.0
9009:3::/64 *[Direct/0] 3d 03:02:55
> via fe-1/2/0.0
[OSPF3/10] 3d 03:02:54, metric 1
> via fe-1/2/0.0
9009:3::2/128 *[Local/0] 3d 03:02:55
9009:5::/64 *[Direct/0] 01:04:09
> via fe-1/2/1.0
[OSPF3/10] 01:04:09, metric 1
> via fe-1/2/1.0
9009:5::1/128 *[Local/0] 3d 03:02:54
9009:6::/64 *[OSPF3/10] 3d 02:19:14, metric 3
> via fe-1/2/0.0
9009:9::/64 *[OSPF3/10] 01:04:02, metric 2
> via fe-1/2/1.0
fe80::/64 *[Direct/0] 3d 03:02:55
> via fe-1/2/0.0
[Direct/0] 01:04:09
> via fe-1/2/1.0
fe80::2a0:a514:0:84c/128
*[Local/0] 3d 03:02:55
fe80::2a0:a514:0:b4c/128
*[Local/0] 3d 03:02:54
ff02::5/128 *[OSPF3/10] 3d 03:03:50, metric 1
MultiRecv
Meaning
On Device 7, the default route has been learned because of the default-metric statement on the ABR,
Device 3. Otherwise, the only OSPFv3 routes in Device 7’s routing table are those local to area 9 and
the OSPFv3 multicast address ff02::5/128 for all SPF link-state routers, also known as AllSPFRouters.
139
Device 10 has the default route injected by Device 3 and also the OSPF external routes injected by
Device 7.
Neither Device 7 nor Device 10 has the external customer routes that were injected into OSPFv3 by
Device 5.
On Device 3, all of the OSPFv3 routes have been learned, including the external customer routes,
1010::1/128 and 2020::1/128.
Purpose
Verify the type of LSAs that are in the area.
Action
From operational mode on Device 7, enter the show ospf3 database nssa detail command.
user@7> show ospf3 database nssa detail

Area 0.0.0.9
Type ID Adv Rtr Seq Age Cksum Len
NSSA 0.0.0.1 3.3.3.3 0x8000002a 1462 0xf406 28
Prefix ::/0
Prefix-options 0x0, Metric 10, Type 1,
NSSA *0.0.0.1 7.7.7.7 0x80000003 1625 0x88df 60
Prefix 3030::1/128
Fwd addr 9009:9::1,
NSSA *0.0.0.2 7.7.7.7 0x80000003 1025 0xef57 60
Prefix 4040::1/128
Fwd addr 9009:9::1,
Meaning
On Device 7, the NSSA LSAs are the type 1 external default route, learned from Device 3, and the type
2 external static routes to the Customer 1 network.
140
Understanding Not-So-Stubby Areas Filtering
You might have a situation when exporting Type 7 LSAs into a not-so-stubby area (NSSA) is
unnecessary. When an autonomous system boundary router (ASBR) is also an area border router (ABR)
with an NSSA attached, Type 7 LSAs are exported into the NSSA by default.
Also, when the ASBR (also an 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. Hence, to avoid the same route getting redistributed twice (from Type 5 LSAs and Type
7 LSAs), you can disable exporting Type 7 LSAs into the NSSA by including the no-nssa-abr statement
on the routing device.
Example: Configuring OSPFv3 Not-So-Stubby Areas with Filtering
IN THIS SECTION
Requirements | 140
Overview | 140
Configuration | 141
Verification | 148
This example shows how to configure an OSPFv3 not-so-stubby area (NSSA) when there is no need to
inject external routes into the NSSA as Type 7 link-state advertisements (LSAs).
Requirements
Overview
When an autonomous system border router (ASBR) is also an NSSA area border router (ABR), the
routing device generates Type 5 as well as Type 7 LSAs. You can prevent the router from creating Type 7
LSAs for the NSSA with the no-nssa-abr statement.
In this example, Device 5 and Device 3 are in customer networks. Device 4 and Device 2 are both
injecting the customer routes into OSPFv3. Area 1 is an NSSA. Because Device 4 is both an NSSA ABR
and an ASBR, it generates both type 7 and type 5 LSAs and injects type 7 LSAs into area 1 and type 5
141
LSAs into area 0. To stop type 7 LSAs from being injected into area 1, the no-nssa-abr statement in
included in the Device 4 configuration.
Figure 14: OSPFv3 Network Topology with an NSSA ABR That Is Also an ASBR
section "No Link Title" describes the steps on Device 4.
Configuration
IN THIS SECTION
Procedure | 142
142
Procedure
Device 1

Device 2

set protocols ospf3 export static2-to-ospf
set policy-options policy-statement static2-to-ospf term 1 from protocol static
set policy-options policy-statement static2-to-ospf term 1 then accept
Device 3

set routing-options rib inet6.0 static route ::/0 next-hop 9009:4::1
143
Device 4

set protocols ospf3 no-nssa-abr
set protocols ospf3 area 0.0.0.1 nssa default-lsa default-metric 10
set protocols ospf3 area 0.0.0.1 nssa default-lsa metric-type 1
set protocols ospf3 area 0.0.0.1 nssa default-lsa type-7
set protocols ospf3 area 0.0.0.1 nssa no-summaries
Device 5

set routing-options rib inet6.0 static route ::/0 next-hop 9009:1::2
Device 6

144
information about navigating the CLI, see “Using the CLI Editor in Configuration Mode” in the CLI User
Guide.
[edit interfaces]



user@4# set nssa

user@4# set nssa default-lsa default-metric 10
145

user@4# set nssa default-lsa metric-type 1

user@4# set nssa default-lsa type-7

user@4# set nssa no-summaries
9. Disable exporting Type 7 LSAs into the NSSA.
This setting is useful if you have an AS boundary router that is also an ABR with an NSSA area
attached.

user@4# set no-nssa-abr
10. Configure static routes to the customer network.

11. Configure a policy to inject the static routes into OSPFv3.

146
12. Apply the policy to OSPFv3.

Results
Device 4

fe-1/2/0 {
unit 0 {
family inet6 {
address 9009:1::2/64;
}
}
unit 0 {
family inet6 {
address 9009:6::1/64;
}
}
unit 0 {
family inet6 {
address 9009:3::1/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 4.4.4.4/32;
}
147
}
}

ospf3 {
no-nssa-abr;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
area 0.0.0.1 {
nssa {
default-lsa {
default-metric 10;
metric-type 1;
type-7;
}
no-summaries;
}
}
}

term 1 {
then accept;
}
}

rib inet6.0 {
static {
route 1010::1/128 next-hop 9009:1::1;
route 2020::1/128 next-hop 9009:1::1;
148
}
}
Verification
IN THIS SECTION
Purpose
Action
user@1> show route

1.1.1.1/32 *[Direct/0] 03:25:44

> via lo0.0

::/0 *[OSPF3/150] 01:52:58, metric 11, tag 0

> via fe-1/2/0.0
3030::1/128 *[OSPF3/150] 02:44:02, metric 0, tag 0
> via fe-1/2/1.0
149
4040::1/128 *[OSPF3/150] 02:44:02, metric 0, tag 0

> via fe-1/2/1.0
9009:5::/64 *[Direct/0] 03:25:34
> via fe-1/2/1.0
[OSPF3/10] 03:25:24, metric 1
> via fe-1/2/1.0
9009:5::1/128 *[Local/0] 03:25:34
9009:6::/64 *[Direct/0] 03:25:34
> via fe-1/2/0.0
[OSPF3/10] 03:25:34, metric 1
> via fe-1/2/0.0
9009:6::2/128 *[Local/0] 03:25:34
fe80::/64 *[Direct/0] 03:25:34
> via fe-1/2/0.0
[Direct/0] 03:25:34
> via fe-1/2/1.0
fe80::2a0:a514:0:44c/128
*[Local/0] 03:25:34
fe80::2a0:a514:0:74c/128
*[Local/0] 03:25:34
ff02::5/128 *[OSPF3/10] 03:27:00, metric 1
MultiRecv
user@6> show route

6.6.6.6/32 *[Direct/0] 03:26:57

> via lo0.0

1010::1/128 *[OSPF3/150] 03:16:59, metric 0, tag 0

> via fe-1/2/0.0
2020::1/128 *[OSPF3/150] 03:16:59, metric 0, tag 0
> via fe-1/2/0.0
150
3030::1/128 *[OSPF3/150] 02:44:34, metric 0, tag 0

> via fe-1/2/0.0
4040::1/128 *[OSPF3/150] 02:44:34, metric 0, tag 0
> via fe-1/2/0.0
9009:3::/64 *[Direct/0] 03:26:29
> via fe-1/2/0.0
[OSPF3/10] 03:26:29, metric 1
> via fe-1/2/0.0
9009:3::2/128 *[Local/0] 03:26:29
9009:5::/64 *[OSPF3/10] 02:44:34, metric 3
> via fe-1/2/0.0
9009:6::/64 *[OSPF3/10] 03:16:59, metric 2
> via fe-1/2/0.0
fe80::/64 *[Direct/0] 03:26:29
> via fe-1/2/0.0
fe80::2a0:a514:0:64c/128
*[Local/0] 03:26:29
ff02::5/128 *[OSPF3/10] 03:27:37, metric 1
MultiRecv
Meaning
On Device 1, the default route (::/0) has been learned because of the default-metric statement on the
ABR, Device 4. The customer routes 3030::1 and 4040::1 have been learned from Device 2. The 1010::1
and 2020::1 routes have been suppressed. They are not needed because the default route can be used
instead.
On Device 6 in area 0, all of the customer routes have been learned.
Purpose
Verify the type of LSAs that are in the area.

151
Action
From operational mode on Device 1, enter the show ospf3 database nssa detail command.
user@4> show ospf3 database nssa detail

Area 0.0.0.1
NSSA 0.0.0.1 2.2.2.2 0x80000004 2063 0xceaf 60
Prefix 3030::1/128
Fwd addr 9009:5::2,
NSSA 0.0.0.2 2.2.2.2 0x80000004 1463 0x3627 60
Prefix 4040::1/128
Fwd addr 9009:5::2,
NSSA *0.0.0.1 4.4.4.4 0x80000003 35 0x25f8 28
Prefix ::/0
Meaning
Device 4 is not sending Type 7 (NSSA) LSAs for customer routes 1010::1/128 and 2020::1/128. If you
were to delete or deactivate the no-nssa-abr statement and then rerun the show ospf3 database nssa
detail command, you would see that Device 4 is sending Type 7 LSAs for 1010::1/128 and 2020::1/128.
Understanding OSPF Virtual Links for Noncontiguous Areas
OSPF requires that all areas in an autonomous system (AS) must be physically connected to the
backbone area (area 0). 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 area border
routers (ABRs) to pass network traffic from one adjacent area to another. The transit area must have full
152
routing information and it cannot be a stub area. For example, Figure 15 on page 152 shows a virtual
link between a noncontiguous area and the backbone area through an area connected to both.
Figure 15: OSPF Topology with a Virtual Link
In the topology shown in Figure 15 on page 152, a virtual link is established between area 0.0.0.3 and
the backbone area through area 0.0.0.2. The virtual link transits 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 OSPF Virtual Links to Connect Noncontiguous

Areas
IN THIS SECTION
Requirements | 153
Overview | 153
Configuration | 154
Verification | 158
This example shows how to configure an OSPF virtual link to connect noncontiguous areas.
153
Requirements
Before you begin:
• Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices.
Overview
IN THIS SECTION
Topology | 154
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 16 on page 154. 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.0.2.5, and Device R2 has a router ID of 192.0.2.3.
154
• 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.
Figure 16: OSPF Virtual Link
Topology
Configuration
IN THIS SECTION
Procedure | 155
Results | 157
• To quickly configure an OSPF virtual link on the local routing device (Device R1), copy the following
155
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 protocols ospf area 0.0.0.0 virtual-link neighbor-id 192.0.2.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 protocols ospf area 0.0.0.0 virtual-link neighbor-id 192.0.2.5 transit-
area 0.0.0.2
Procedure
To configure an OSPF virtual link on the local routing device (Device R1):
1. Configure the router ID.
[edit]
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
156
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.

user@R1# set virtual-link neighbor-id 192.0.2.3 transit-area 0.0.0.2

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):
[edit]
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.
157
This routing device is not physically connected to the backbone.

user@R2# set virtual-link neighbor-id 192.0.2.5 transit-area 0.0.0.2

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.0.2.5;

area 0.0.0.0 {
virtual-link neighbor-id 192.0.2.3 transit-area 0.0.0.2;
}
Configuration on the remote ABR (Device R2):
user@R2#: show routing-options


area 0.0.0.0 {
}
158
Verification
IN THIS SECTION
Verifying Entries in the Link-State Database | 158
Verifying OSPF Interface Status and Configuration | 158
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
159
Example: Configuring OSPFv3 Virtual Links
IN THIS SECTION
Requirements | 159
Overview | 160
Configuration | 160
Verification | 174
This example shows how to configure OSPF version 3 (OSPFv3) with some areas that do not have a
direct adjacency to the backbone area (area 0). When an area lacks an adjacency with area 0, a virtual
link is required to connect to the backbone through a non-backbone area. The area through which you
configure the virtual link, known as a transit area, must have full routing information. The transit area
cannot be a stub area.
Requirements
160
Overview
Figure 17: OSPFv3 with Virtual Links
Device 0, Device 1, Device 2, and Device 3 are connected to the OSPFv3 backbone Area 0. Device 2,
Device 3, and Device 4 connect to each other across Area 1. and Area 2 is located between Device 4
and Device 5. Because Device 5 does not have a direct adjacency to Area 0, a virtual link is required
across Area 1 between Device 3 and Device 4. Similarly, because Device 0 and Device 1 have two
separate Area 0 backbone sections, you need to configure a second virtual link across Area 1 between
Device 2 and Device 3.
Configuration
IN THIS SECTION
Procedure | 161
161
Procedure
Device 0
set logical-systems 0 interfaces so-0/3/2 unit 0 family inet6 address 9009:1::1/64

set logical-systems 0 interfaces lo0 unit 0 family inet address 192.168.0.1/32
set logical-systems 0 interfaces lo0 unit 0 family inet6 address feee::10:255:71:4/128
set logical-systems 0 protocols ospf3 area 0.0.0.0 interface so-0/3/2.0
set logical-systems 0 protocols ospf3 area 0.0.0.0 interface lo0.0 passive
set logical-systems 0 routing-options router-id 192.168.0.1
Device 1
set logical-systems 1 interfaces at-2/0/0 atm-options vpi 0

set logical-systems 1 interfaces at-2/0/0 unit 0 family inet6 address 9009:2::1/64
set logical-systems 1 interfaces at-2/0/0 unit 0 vci 0.77
set logical-systems 1 protocols ospf3 area 0.0.0.0 interface at-2/0/0.0
Device 2

set logical-systems 2 interfaces fe-1/1/0 unit 0 family inet6 address 9009:4::1/64
set logical-systems 2 interfaces at-0/3/1 atm-options vpi 0 maximum-vcs 1200
set logical-systems 2 interfaces at-0/3/1 unit 0 family inet6 address 9009:2::2/64
set logical-systems 2 interfaces at-0/3/1 unit 0 vci 0.77
set logical-systems 2 protocols ospf3 area 0.0.0.0 virtual-link neighbor-id 192.168.3.1 transit-area 0.0.0.1
set logical-systems 2 protocols ospf3 area 0.0.0.0 interface at-0/3/1.0
162
set logical-systems 2 protocols ospf3 area 0.0.0.1 interface fe-1/1/0.0

Device 3

set logical-systems 3 interfaces t1-0/2/1 unit 0 family inet6 address 9009:5::1/64
set logical-systems 3 protocols ospf3 area 0.0.0.1 interface t1-0/2/1.0
Device 4
set logical-systems 4 interfaces t1-0/2/1 unit 0 family inet6 address 9009:5::2/64

set logical-systems 4 protocols ospf3 area 0.0.0.1 interface t1-0/2/1.0
Device 5

163

Guide.
[edit interfaces]
user@0# set so-0/3/2 unit 0 family inet6 address 9009:1::1/64
user@0# set lo0 unit 0 family inet6 address feee::10:255:71:4/128
2. Add the interfaces into Area 0 of the OSPFv3 process.

user@0# set interface so-0/3/2.0
[edit routing-options]
user@0# set router-id 192.168.0.1
Guide.
164
[edit interfaces]
user@1# set at-2/0/0 atm-options vpi 0
user@1# set at-2/0/0 unit 0 family inet6 address 9009:2::1/64
user@1# set at-2/0/0 unit 0 vci 0.77
2. Add the interfaces into Area 0 of the OSPFv3 process.

user@1# set interface at-2/0/0.0
Guide.
[edit interfaces]
user@2# set at-0/3/1 atm-options vpi 0 maximum-vcs 1200
user@2# set at-0/3/1 unit 0 family inet6 address 9009:2::2/64
user@2# set at-0/3/1 unit 0 vci 0.77
165
2. Add the interfaces connected to Device 1, Device 3, and Device 4 into the OSPFv3 process.

user@2# set interface at-0/3/1.0
3. Configure the virtual link to Device 3 through Area 1 so that Device 1 can access the discontiguous
portion of the OSPF backbone found on Device 0.

user@2# set virtual-link neighbor-id 192.168.3.1 transit-area 0.0.0.1
Guide.
[edit interfaces]
user@3# set t1-0/2/1 unit 0 family inet6 address 9009:5::1/64
166
2. For the OSPFv3 process on Device 3, configure the interfaces connected to Device 2 and Device 4
into Area 1 and the interface connected to Device 0 into Area 0.

user@3# set interface t1-0/2/1.0
3. Configure two virtual links through Area 1—one connecting to Device 2 and the second connecting
to Device 4.
The virtual links allow Device 5 to access the OSPF backbone, and connect the discontiguous
sections of Area 0 located at Device 0 and Device 1.

Guide.
[edit interfaces]
user@4# set t1-0/2/1 unit 0 family inet6 address 9009:5::2/64
167

2. On Device 4, add the connected interfaces into the OSPFv3 process.

user@4# set interface t1-0/2/1.0
3. Configure the virtual link to Device 3 through Area 1 so that Device 5 can access the OSPF
backbone.

Guide.
[edit interfaces]
168
2. Add the interfaces into the OSPFv3 process.

Results
and show routing-options commands. If the output does not display the intended configuration, repeat
the instructions in this example to correct the configuration.
Device 0

so-0/3/2 {
unit 0 {
family inet6 {
address 9009:1::1/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
family inet6 {
address feee::10:255:71:4/128;
}
}
}
ospf3 {
area 0.0.0.0 {
169
interface lo0.0 {
passive;
}
}
}
router-id 192.168.0.1;
Device 1

at-2/0/0 {
atm-options {
vpi 0;
}
unit 0 {
family inet6 {
address 9009:2::1/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
family inet6 {
address feee::10:255:71:1/128;
}
}
}
ospf3 {
area 0.0.0.0 {
interface at-2/0/0.0;
interface lo0.0 {
passive;
}
}
}
170

router-id 192.168.1.1;
Device 2

so-0/2/0 {
unit 0 {
family inet6 {
address 9009:3::1/64;
}
}
}
fe-1/1/0 {
unit 0 {
family inet6 {
address 9009:4::1/64;
}
}
}
at-0/3/1 {
atm-options {
vpi 0 {
maximum-vcs 1200;
}
}
unit 0 {
vci 0.77;
family inet6 {
address 9009:2::2/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
family inet6 {
address feee::10:255:71:11/128;
}
}
171
}
ospf3 {
area 0.0.0.0 {
interface at-0/3/1.0;
}
area 0.0.0.1 {
interface lo0.0 {
passive;
}
}
}
router-id 192.168.2.1;
Device 3

so-0/3/2 {
unit 0 {
family inet6 {
address 9009:1::2/64;
}
}
}
t1-0/2/1 {
unit 0 {
family inet6 {
address 9009:5::1/64;
}
}
}
so-0/3/0 {
unit 0 {
family inet6 {
address 9009:3::2/64;
}
}
}
172
lo0 {
unit 0 {
family inet {
address 192.168.3.1/32;
}
family inet6 {
address feee::10:255:71:3/128;
}
}
}
ospf3 {
area 0.0.0.1 {
interface t1-0/2/1.0;
interface lo0.0 {
passive;
}
}
area 0.0.0.0 {
}
}
router-id 192.168.3.1;
Device 4

t1-0/2/1 {
unit 0 {
family inet6 {
address 9009:5::2/64;
}
}
}
fe-0/0/0 {
unit 0 {
family inet6 {
address 9009:6::1/64;
173
}
}
}
fe-1/1/0 {
unit 0 {
family inet6 {
address 9009:4::2/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.4.1/32;
}
family inet6 {
address feee::10:255:71:5/128;
}
}
}
ospf3 {
area 0.0.0.1 {
interface t1-0/2/1.0;
interface lo0.0 {
passive;
}
}
area 0.0.0.2 {
}
area 0.0.0.0 {
}
}
router-id 192.168.4.1;
174
Device 5

fe-0/0/0 {
unit 0 {
family inet6 {
address 9009:6::2/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.5.1/32;
}
family inet6 {
address feee::10:255:71:6/128;
}
}
}
ospf3 {
area 0.0.0.2 {
interface lo0.0 {
passive;
}
}
}
router-id 192.168.5.1;
If you are done configuring the devices, enter commit from configuration mode.
Verification
IN THIS SECTION
Device 0 Status | 175

175
To verify proper operation of OSPFv3 for IPv6, use the following commands:
• show ospf3 interface
• show ospf3 neighbor
• show ospf3 database
• show ospf3 route
• show interfaces terse (to see the IPv6 link local address assigned to the lo0 interface)
NOTE: To view prefix information, you must use the extensive option with the show ospf3
database command.
Device 0 Status
Purpose
Verify that Device 0 has learned the expected routes and has established the expected neighbor
adjacencies.
In the show ospf3 database sample output, the stars indicate the “best” routes. These routes are the
routes that are installed in the routing table.
Action
user@0> show ospf3 database

Area 0.0.0.0
Router *0.0.0.0 192.168.0.1 0x8000008f 1858 0x6e21 40
176
Router 0.0.0.0 192.168.1.1 0x8000008f 1861 0x523d 40

Router 0.0.0.0 192.168.2.1 0x80000090 1918 0x9e62 56
Router 0.0.0.0 192.168.3.1 0x80000092 2104 0x46d 72
Router 0.0.0.0 192.168.4.1 0x8000008f 2012 0x7016 40
InterArPfx 0.0.0.1 192.168.2.1 0x80000093 231 0xfc5c 36
InterArPfx 0.0.0.2 192.168.2.1 0x80000093 43 0x156 36
InterArPfx 0.0.0.3 192.168.2.1 0x80000092 1731 0x31a4 44
InterArPfx 0.0.0.4 192.168.2.1 0x8000008f 2668 0xc51f 44
InterArPfx 0.0.0.5 192.168.2.1 0x80000091 2856 0xfa59 36
InterArPfx 0.0.0.6 192.168.2.1 0x80000090 2481 0xe3fb 44
InterArPfx 0.0.0.1 192.168.3.1 0x80000093 417 0xf562 36
InterArPfx 0.0.0.2 192.168.3.1 0x80000093 2854 0x84d 36
InterArPfx 0.0.0.3 192.168.3.1 0x80000092 1729 0xbc26 44
InterArPfx 0.0.0.4 192.168.3.1 0x8000008f 2667 0x2ca9 44
InterArPfx 0.0.0.5 192.168.3.1 0x80000091 229 0xe56e 36
InterArPfx 0.0.0.6 192.168.3.1 0x8000008f 2292 0xde01 44
InterArPfx 0.0.0.2 192.168.4.1 0x80000092 794 0xf461 36
InterArPfx 0.0.0.3 192.168.4.1 0x80000092 606 0xf85b 36
InterArPfx 0.0.0.4 192.168.4.1 0x80000091 419 0xfe54 36
InterArPfx 0.0.0.5 192.168.4.1 0x80000090 1825 0xd906 44
InterArPfx 0.0.0.6 192.168.4.1 0x8000008f 2669 0xf1eb 44
InterArPfx 0.0.0.7 192.168.4.1 0x80000091 981 0xbc95 36
InterArPfx 0.0.0.8 192.168.4.1 0x8000008f 2481 0x8f4f 44
InterArPfx 0.0.0.9 192.168.4.1 0x80000090 2294 0xf0dd 44
InterArPfx 0.0.0.10 192.168.4.1 0x8000008f 231 0xac5a 44
IntraArPfx *0.0.0.1 192.168.0.1 0x80000094 2858 0xbf9f 64
IntraArPfx 0.0.0.1 192.168.1.1 0x80000095 2861 0x87d6 64
IntraArPfx 0.0.0.1 192.168.2.1 0x80000096 793 0xc7bd 64
IntraArPfx 0.0.0.1 192.168.3.1 0x80000097 1167 0x93f0 64
interface so-0/3/2.0 Area 0.0.0.0

Link *0.0.0.2 192.168.0.1 0x80000091 858 0xc0c7 56
Link 0.0.0.8 192.168.3.1 0x80000091 1354 0x84f9 56
user@0> show ospf3 interface
Interface State Area DR ID BDR ID Nbrs
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
so-0/3/2.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
user@0> show ospf3 neighbor

ID Interface State Pri Dead
192.168.3.1 so-0/3/2.0 Full 128 33
177
Neighbor-address fe80::2a0:a514:0:24c
user@0> show ospf3 route

Prefix Path Route NH Metric
Type Type Type
192.168.1.1 Intra Router IP 3
NH-interface so-0/3/2.0
192.168.2.1 Intra Area BR IP 2
9009:1::/64 Intra Network IP 1
9009:1::2/128 Intra Network IP 1
9009:3::/64 Inter Network IP 2
9009:6::1/128 Inter Network IP 2
feee::10:255:71:1/128 Intra Network IP 3
feee::10:255:71:3/128 Inter Network IP 1
NH-interface lo0.0
178
user@0> show interfaces terse

Interface Admin Link Proto Local Remote
lt-1/2/0
so-0/3/2.0 up up inet6 9009:1::1/64
fe80::2a0:a514:0:14c/64
lo0
lo0.0 up up inet 192.168.0.1 --> 0/0
inet6 fe80::2a0:a50f:fc56:14c
feee::10:255:71:4
...
Device 1 Status
Purpose
adjacencies.
Action

lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
at-2/0/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
192.168.2.1 at-2/0/0.0 Full 128 37
Neighbor-address fe80::2a0:a514:0:c4c

Area 0.0.0.0
Router 0.0.0.0 192.168.0.1 0x8000008f 2334 0x6e21 40
Router *0.0.0.0 192.168.1.1 0x8000008f 2331 0x523d 40
Router 0.0.0.0 192.168.2.1 0x80000090 2390 0x9e62 56
Router 0.0.0.0 192.168.3.1 0x80000092 2578 0x46d 72
Router 0.0.0.0 192.168.4.1 0x8000008f 2486 0x7016 40
InterArPfx 0.0.0.2 192.168.2.1 0x80000093 515 0x156 36
InterArPfx 0.0.0.3 192.168.2.1 0x80000092 2203 0x31a4 44
179
InterArPfx 0.0.0.4 192.168.2.1 0x80000090 140 0xc320 44

InterArPfx 0.0.0.5 192.168.2.1 0x80000092 328 0xf85a 36
InterArPfx 0.0.0.6 192.168.2.1 0x80000090 2953 0xe3fb 44
InterArPfx 0.0.0.1 192.168.3.1 0x80000093 891 0xf562 36
InterArPfx 0.0.0.2 192.168.3.1 0x80000094 328 0x64e 36
InterArPfx 0.0.0.3 192.168.3.1 0x80000092 2203 0xbc26 44
InterArPfx 0.0.0.4 192.168.3.1 0x80000090 141 0x2aaa 44
InterArPfx 0.0.0.5 192.168.3.1 0x80000091 703 0xe56e 36
InterArPfx 0.0.0.6 192.168.3.1 0x8000008f 2766 0xde01 44
InterArPfx 0.0.0.2 192.168.4.1 0x80000092 1268 0xf461 36
InterArPfx 0.0.0.3 192.168.4.1 0x80000092 1080 0xf85b 36
InterArPfx 0.0.0.4 192.168.4.1 0x80000091 893 0xfe54 36
InterArPfx 0.0.0.5 192.168.4.1 0x80000090 2299 0xd906 44
InterArPfx 0.0.0.6 192.168.4.1 0x80000090 143 0xefec 44
InterArPfx 0.0.0.7 192.168.4.1 0x80000091 1455 0xbc95 36
InterArPfx 0.0.0.8 192.168.4.1 0x8000008f 2955 0x8f4f 44
InterArPfx 0.0.0.9 192.168.4.1 0x80000090 2768 0xf0dd 44
IntraArPfx 0.0.0.1 192.168.0.1 0x80000095 334 0xbda0 64
IntraArPfx *0.0.0.1 192.168.1.1 0x80000096 331 0x85d7 64
IntraArPfx 0.0.0.1 192.168.3.1 0x80000097 1641 0x93f0 64
interface at-2/0/0.0 Area 0.0.0.0

Link *0.0.0.2 192.168.1.1 0x80000091 1331 0xaecd 56
Link 0.0.0.8 192.168.2.1 0x80000091 1453 0x80f3 56

Type Type Type
NH-interface at-2/0/0.0
180

NH-interface lo0.0

lt-1/2/0
at-2/0/0.0 up up inet6 9009:2::1/64
fe80::2a0:a514:0:b4c/64
lo0
lo0.0 up up inet 192.168.1.1 --> 0/0
feee::10:255:71:1
...
181
Device 2 Status
Purpose
adjacencies.
Action

at-0/3/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
vl-192.168.3.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
lo0.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
so-0/2/0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
fe-1/1/0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1

192.168.1.1 at-0/3/1.0 Full 128 32
Neighbor-address fe80::2a0:a514:0:b4c
192.168.3.1 vl-192.168.3.1 Full 0 35
Neighbor-address 9009:3::2
192.168.3.1 so-0/2/0.0 Full 128 38
192.168.4.1 fe-1/1/0.0 Full 128 30
Neighbor-address fe80::2a0:a514:0:a4c

Area 0.0.0.0
Router 0.0.0.0 192.168.0.1 0x8000008f 2771 0x6e21 40
Router 0.0.0.0 192.168.1.1 0x8000008f 2770 0x523d 40
Router *0.0.0.0 192.168.2.1 0x80000090 2827 0x9e62 56
Router 0.0.0.0 192.168.3.1 0x80000093 15 0x26e 72
Router 0.0.0.0 192.168.4.1 0x8000008f 2923 0x7016 40
InterArPfx *0.0.0.1 192.168.2.1 0x80000093 1140 0xfc5c 36
InterArPfx *0.0.0.2 192.168.2.1 0x80000093 952 0x156 36
InterArPfx *0.0.0.3 192.168.2.1 0x80000092 2640 0x31a4 44
InterArPfx *0.0.0.4 192.168.2.1 0x80000090 577 0xc320 44
InterArPfx *0.0.0.5 192.168.2.1 0x80000092 765 0xf85a 36
182
InterArPfx *0.0.0.6 192.168.2.1 0x80000091 390 0xe1fc 44

InterArPfx 0.0.0.1 192.168.3.1 0x80000093 1328 0xf562 36
InterArPfx 0.0.0.2 192.168.3.1 0x80000094 765 0x64e 36
InterArPfx 0.0.0.3 192.168.3.1 0x80000092 2640 0xbc26 44
InterArPfx 0.0.0.5 192.168.3.1 0x80000091 1140 0xe56e 36
InterArPfx 0.0.0.6 192.168.3.1 0x80000090 203 0xdc02 44
InterArPfx 0.0.0.2 192.168.4.1 0x80000092 1705 0xf461 36
InterArPfx 0.0.0.3 192.168.4.1 0x80000092 1517 0xf85b 36
InterArPfx 0.0.0.4 192.168.4.1 0x80000091 1330 0xfe54 36
InterArPfx 0.0.0.5 192.168.4.1 0x80000090 2736 0xd906 44
InterArPfx 0.0.0.7 192.168.4.1 0x80000091 1892 0xbc95 36
InterArPfx 0.0.0.8 192.168.4.1 0x80000090 392 0x8d50 44
InterArPfx 0.0.0.9 192.168.4.1 0x80000091 205 0xeede 44
IntraArPfx 0.0.0.1 192.168.1.1 0x80000096 770 0x85d7 64
IntraArPfx *0.0.0.1 192.168.2.1 0x80000096 1702 0xc7bd 64
IntraArPfx 0.0.0.1 192.168.3.1 0x80000097 2078 0x93f0 64
Area 0.0.0.1
Router *0.0.0.0 192.168.2.1 0x80000093 15 0x8f62 56
Router 0.0.0.0 192.168.3.1 0x80000093 2828 0x39b7 56
Router 0.0.0.0 192.168.4.1 0x80000092 16 0x8768 56
InterArPfx *0.0.0.1 192.168.2.1 0x80000094 1515 0xec6c 36
InterArPfx *0.0.0.3 192.168.2.1 0x80000090 202 0x994d 44
InterArPfx *0.0.0.4 192.168.2.1 0x8000008f 1327 0xd839 44
InterArPfx 0.0.0.1 192.168.3.1 0x80000094 1703 0xd781 36
InterArPfx 0.0.0.3 192.168.3.1 0x80000090 390 0xe002 44
InterArPfx 0.0.0.4 192.168.3.1 0x8000008f 1515 0xc34e 44
InterArPfx 0.0.0.1 192.168.4.1 0x80000093 1422 0x193b 36
InterArPfx 0.0.0.3 192.168.4.1 0x80000090 672 0xed1 44
InterArPfx 0.0.0.4 192.168.4.1 0x8000008f 1235 0xe824 44
IntraArPfx *0.0.0.1 192.168.2.1 0x80000097 2265 0x6bf1 76
IntraArPfx 0.0.0.1 192.168.3.1 0x80000099 953 0xadb8 76
IntraArPfx 0.0.0.1 192.168.4.1 0x80000098 2079 0x3c26 76
interface at-0/3/1.0 Area 0.0.0.0

Link 0.0.0.2 192.168.1.1 0x80000091 1770 0xaecd 56
Link *0.0.0.8 192.168.2.1 0x80000091 1890 0x80f3 56
183

Link *0.0.0.6 192.168.2.1 0x80000092 2452 0x6018 56
Link 0.0.0.7 192.168.3.1 0x80000092 2453 0x3a3d 56
interface fe-1/1/0.0 Area 0.0.0.1

Link *0.0.0.7 192.168.2.1 0x80000092 2077 0x8de7 56
Link 0.0.0.8 192.168.4.1 0x80000091 2172 0x8ce5 56

Type Type Type
NH-interface (null), NH-addr feee::10:255:71:3
NH-interface fe-1/1/0.0
184

NH-interface lo0.0

lt-1/2/0
so-0/2/0.0 up up inet6 9009:3::1/64
fe80::2a0:a514:0:84c/64
fe-1/1/0.0 up up inet6 9009:4::1/64
fe80::2a0:a514:0:94c/64
at-0/3/1.0 up up inet6 9009:2::2/64
fe80::2a0:a514:0:c4c/64
lo0
lo0.0 up up inet 192.168.2.1 --> 0/0
feee::10:255:71:11
...
Device 3 Status
Purpose
adjacencies.
Action

so-0/3/2.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
vl-192.168.2.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
vl-192.168.4.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
lo0.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
185
t1-0/2/1.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1

so-0/3/0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1

192.168.0.1 so-0/3/2.0 Full 128 31
192.168.2.1 vl-192.168.2.1 Full 0 33
192.168.4.1 vl-192.168.4.1 Full 0 38
192.168.4.1 t1-0/2/1.0 Full 128 35
192.168.2.1 so-0/3/0.0 Full 128 37

Area 0.0.0.0
Router 0.0.0.0 192.168.0.1 0x80000090 11 0x6c22 40
Router 0.0.0.0 192.168.1.1 0x80000090 12 0x503e 40
Router 0.0.0.0 192.168.2.1 0x80000091 69 0x9c63 56
Router *0.0.0.0 192.168.3.1 0x80000093 255 0x26e 72
Router 0.0.0.0 192.168.4.1 0x80000090 163 0x6e17 40
InterArPfx 0.0.0.2 192.168.2.1 0x80000093 1194 0x156 36
InterArPfx 0.0.0.3 192.168.2.1 0x80000092 2882 0x31a4 44
InterArPfx 0.0.0.4 192.168.2.1 0x80000090 819 0xc320 44
InterArPfx 0.0.0.5 192.168.2.1 0x80000092 1007 0xf85a 36
InterArPfx 0.0.0.6 192.168.2.1 0x80000091 632 0xe1fc 44
InterArPfx *0.0.0.1 192.168.3.1 0x80000093 1568 0xf562 36
InterArPfx *0.0.0.2 192.168.3.1 0x80000094 1005 0x64e 36
InterArPfx *0.0.0.3 192.168.3.1 0x80000092 2880 0xbc26 44
InterArPfx *0.0.0.4 192.168.3.1 0x80000090 818 0x2aaa 44
InterArPfx *0.0.0.5 192.168.3.1 0x80000091 1380 0xe56e 36
InterArPfx *0.0.0.6 192.168.3.1 0x80000090 443 0xdc02 44
InterArPfx 0.0.0.2 192.168.4.1 0x80000092 1945 0xf461 36
InterArPfx 0.0.0.3 192.168.4.1 0x80000092 1757 0xf85b 36
InterArPfx 0.0.0.4 192.168.4.1 0x80000091 1570 0xfe54 36
InterArPfx 0.0.0.5 192.168.4.1 0x80000090 2976 0xd906 44
InterArPfx 0.0.0.7 192.168.4.1 0x80000091 2132 0xbc95 36
InterArPfx 0.0.0.8 192.168.4.1 0x80000090 632 0x8d50 44
186
InterArPfx 0.0.0.9 192.168.4.1 0x80000091 445 0xeede 44

IntraArPfx 0.0.0.1 192.168.1.1 0x80000096 1012 0x85d7 64
IntraArPfx *0.0.0.1 192.168.3.1 0x80000097 2318 0x93f0 64
Area 0.0.0.1
Router 0.0.0.0 192.168.2.1 0x80000093 257 0x8f62 56
Router *0.0.0.0 192.168.3.1 0x80000094 68 0x37b8 56
Router 0.0.0.0 192.168.4.1 0x80000092 257 0x8768 56
InterArPfx 0.0.0.1 192.168.2.1 0x80000094 1757 0xec6c 36
InterArPfx 0.0.0.3 192.168.2.1 0x80000090 444 0x994d 44
InterArPfx 0.0.0.4 192.168.2.1 0x8000008f 1569 0xd839 44
InterArPfx *0.0.0.1 192.168.3.1 0x80000094 1943 0xd781 36
InterArPfx *0.0.0.3 192.168.3.1 0x80000090 630 0xe002 44
InterArPfx *0.0.0.4 192.168.3.1 0x8000008f 1755 0xc34e 44
InterArPfx 0.0.0.1 192.168.4.1 0x80000093 1663 0x193b 36
InterArPfx 0.0.0.3 192.168.4.1 0x80000090 913 0xed1 44
InterArPfx 0.0.0.4 192.168.4.1 0x8000008f 1476 0xe824 44
IntraArPfx 0.0.0.1 192.168.2.1 0x80000097 2507 0x6bf1 76
IntraArPfx *0.0.0.1 192.168.3.1 0x80000099 1193 0xadb8 76
IntraArPfx 0.0.0.1 192.168.4.1 0x80000098 2320 0x3c26 76

Link 0.0.0.2 192.168.0.1 0x80000091 2011 0xc0c7 56
Link *0.0.0.8 192.168.3.1 0x80000091 2505 0x84f9 56
interface t1-0/2/1.0 Area 0.0.0.1

Link *0.0.0.9 192.168.3.1 0x80000092 2130 0x1661 56
Link 0.0.0.7 192.168.4.1 0x80000092 2507 0x383f 56

Link 0.0.0.6 192.168.2.1 0x80000092 2694 0x6018 56
Link *0.0.0.7 192.168.3.1 0x80000092 2693 0x3a3d 56

Type Type Type
187

NH-interface t1-0/2/1.0
NH-interface lo0.0

lt-1/2/0
188
so-0/3/2.0 up up inet6 9009:1::2/64

fe80::2a0:a514:0:24c/64
t1-0/2/1.0 up up inet6 9009:5::1/64
fe80::2a0:a514:0:34c/64
so-0/3/0.0 up up inet6 9009:3::2/64
fe80::2a0:a514:0:74c/64
lo0
lo0.0 up up inet 192.168.3.1 --> 0/0
feee::10:255:71:3
...
Device 4 Status
Purpose
adjacencies.
Action

lo0.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
fe-1/1/0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
t1-0/2/1.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
fe-0/0/0.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
vl-192.168.3.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1

192.168.2.1 fe-1/1/0.0 Full 128 35
192.168.3.1 t1-0/2/1.0 Full 128 34
192.168.5.1 fe-0/0/0.0 Full 128 39
192.168.3.1 vl-192.168.3.1 Full 0 33

189
Area 0.0.0.0
Router 0.0.0.0 192.168.0.1 0x80000090 270 0x6c22 40
Router 0.0.0.0 192.168.1.1 0x80000090 271 0x503e 40
Router 0.0.0.0 192.168.2.1 0x80000091 328 0x9c63 56
Router 0.0.0.0 192.168.3.1 0x80000093 514 0x26e 72
Router *0.0.0.0 192.168.4.1 0x80000090 420 0x6e17 40
InterArPfx 0.0.0.2 192.168.2.1 0x80000093 1453 0x156 36
InterArPfx 0.0.0.3 192.168.2.1 0x80000093 141 0x2fa5 44
InterArPfx 0.0.0.4 192.168.2.1 0x80000090 1078 0xc320 44
InterArPfx 0.0.0.5 192.168.2.1 0x80000092 1266 0xf85a 36
InterArPfx 0.0.0.6 192.168.2.1 0x80000091 891 0xe1fc 44
InterArPfx 0.0.0.1 192.168.3.1 0x80000093 1827 0xf562 36
InterArPfx 0.0.0.2 192.168.3.1 0x80000094 1264 0x64e 36
InterArPfx 0.0.0.3 192.168.3.1 0x80000093 139 0xba27 44
InterArPfx 0.0.0.5 192.168.3.1 0x80000091 1639 0xe56e 36
InterArPfx 0.0.0.6 192.168.3.1 0x80000090 702 0xdc02 44
InterArPfx *0.0.0.2 192.168.4.1 0x80000092 2202 0xf461 36
InterArPfx *0.0.0.3 192.168.4.1 0x80000092 2014 0xf85b 36
InterArPfx *0.0.0.4 192.168.4.1 0x80000091 1827 0xfe54 36
InterArPfx *0.0.0.5 192.168.4.1 0x80000091 233 0xd707 44
InterArPfx *0.0.0.6 192.168.4.1 0x80000090 1077 0xefec 44
InterArPfx *0.0.0.7 192.168.4.1 0x80000091 2389 0xbc95 36
InterArPfx *0.0.0.8 192.168.4.1 0x80000090 889 0x8d50 44
InterArPfx *0.0.0.9 192.168.4.1 0x80000091 702 0xeede 44
InterArPfx *0.0.0.10 192.168.4.1 0x8000008f 1639 0xac5a 44
IntraArPfx 0.0.0.1 192.168.1.1 0x80000096 1271 0x85d7 64
IntraArPfx 0.0.0.1 192.168.3.1 0x80000097 2577 0x93f0 64
Area 0.0.0.1
Router 0.0.0.0 192.168.2.1 0x80000093 515 0x8f62 56
Router 0.0.0.0 192.168.3.1 0x80000094 327 0x37b8 56
Router *0.0.0.0 192.168.4.1 0x80000092 514 0x8768 56
InterArPfx 0.0.0.1 192.168.2.1 0x80000094 2015 0xec6c 36
InterArPfx 0.0.0.3 192.168.2.1 0x80000090 702 0x994d 44
InterArPfx 0.0.0.4 192.168.2.1 0x8000008f 1827 0xd839 44
InterArPfx 0.0.0.1 192.168.3.1 0x80000094 2202 0xd781 36
InterArPfx 0.0.0.3 192.168.3.1 0x80000090 889 0xe002 44
190
InterArPfx 0.0.0.4 192.168.3.1 0x8000008f 2014 0xc34e 44

InterArPfx *0.0.0.1 192.168.4.1 0x80000093 1920 0x193b 36
InterArPfx *0.0.0.3 192.168.4.1 0x80000090 1170 0xed1 44
InterArPfx *0.0.0.4 192.168.4.1 0x8000008f 1733 0xe824 44
IntraArPfx 0.0.0.1 192.168.2.1 0x80000097 2765 0x6bf1 76
IntraArPfx 0.0.0.1 192.168.3.1 0x80000099 1452 0xadb8 76
IntraArPfx *0.0.0.1 192.168.4.1 0x80000098 2577 0x3c26 76
Area 0.0.0.2
Router *0.0.0.0 192.168.4.1 0x80000091 45 0x4741 40
Router 0.0.0.0 192.168.5.1 0x80000090 270 0x3a50 40
InterArPfx *0.0.0.1 192.168.4.1 0x80000094 2295 0xfa5a 36
InterArPfx *0.0.0.2 192.168.4.1 0x80000094 2108 0xfe54 36
InterArPfx *0.0.0.3 192.168.4.1 0x80000093 139 0xe7f6 44
InterArPfx *0.0.0.4 192.168.4.1 0x80000091 2483 0xda7a 36
InterArPfx *0.0.0.5 192.168.4.1 0x80000090 983 0xab35 44
InterArPfx *0.0.0.6 192.168.4.1 0x80000091 795 0xdc3 44
InterArPfx *0.0.0.7 192.168.4.1 0x80000090 1545 0xa2b2 36
InterArPfx *0.0.0.9 192.168.4.1 0x80000090 1358 0x9cb5 36
InterArPfx *0.0.0.11 192.168.4.1 0x80000090 608 0x8f49 44
InterArPfx *0.0.0.12 192.168.4.1 0x80000090 327 0x37a3 44
InterArPfx *0.0.0.13 192.168.4.1 0x8000008f 1452 0x689e 44
InterArPfx *0.0.0.14 192.168.4.1 0x8000008f 1264 0x6c98 44
IntraArPfx *0.0.0.1 192.168.4.1 0x80000098 2858 0x82f5 64
IntraArPfx 0.0.0.1 192.168.5.1 0x80000095 1270 0xf25a 64

Link 0.0.0.7 192.168.2.1 0x80000092 2577 0x8de7 56
Link *0.0.0.8 192.168.4.1 0x80000091 2670 0x8ce5 56
interface t1-0/2/1.0 Area 0.0.0.1

Link 0.0.0.9 192.168.3.1 0x80000092 2389 0x1661 56
Link *0.0.0.7 192.168.4.1 0x80000092 2764 0x383f 56

Link *0.0.0.6 192.168.4.1 0x80000092 2952 0x79fc 56
Link 0.0.0.2 192.168.5.1 0x80000091 2270 0xb1c7 56

191

Type Type Type
NH-interface lo0.0
192

lt-1/2/0
t1-0/2/1.0 up up inet6 9009:5::2/64
fe80::2a0:a514:0:44c/64
fe-0/0/0.0 up up inet6 9009:6::1/64
fe80::2a0:a514:0:54c/64
fe-1/1/0.0 up up inet6 9009:4::2/64
fe80::2a0:a514:0:a4c/64
lo0
lo0.0 up up inet 192.168.4.1 --> 0/0
feee::10:255:71:5
...
Device 5 Status
Purpose
adjacencies.
Action

lo0.0 DRother 0.0.0.2 0.0.0.0 0.0.0.0 0
fe-0/0/0.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
192.168.4.1 fe-0/0/0.0 Full 128 34

Area 0.0.0.2
Router 0.0.0.0 192.168.4.1 0x80000091 509 0x4741 40
Router *0.0.0.0 192.168.5.1 0x80000090 732 0x3a50 40
InterArPfx 0.0.0.1 192.168.4.1 0x80000094 2759 0xfa5a 36
InterArPfx 0.0.0.2 192.168.4.1 0x80000094 2572 0xfe54 36
193
InterArPfx 0.0.0.3 192.168.4.1 0x80000093 603 0xe7f6 44

InterArPfx 0.0.0.4 192.168.4.1 0x80000091 2947 0xda7a 36
InterArPfx 0.0.0.5 192.168.4.1 0x80000090 1447 0xab35 44
InterArPfx 0.0.0.6 192.168.4.1 0x80000091 1259 0xdc3 44
InterArPfx 0.0.0.7 192.168.4.1 0x80000090 2009 0xa2b2 36
InterArPfx 0.0.0.9 192.168.4.1 0x80000090 1822 0x9cb5 36
InterArPfx 0.0.0.11 192.168.4.1 0x80000090 1072 0x8f49 44
InterArPfx 0.0.0.12 192.168.4.1 0x80000090 791 0x37a3 44
InterArPfx 0.0.0.13 192.168.4.1 0x8000008f 1916 0x689e 44
InterArPfx 0.0.0.14 192.168.4.1 0x8000008f 1728 0x6c98 44
IntraArPfx 0.0.0.1 192.168.4.1 0x80000099 322 0x80f6 64
IntraArPfx *0.0.0.1 192.168.5.1 0x80000095 1732 0xf25a 64

Link 0.0.0.6 192.168.4.1 0x80000093 416 0x77fd 56
Link *0.0.0.2 192.168.5.1 0x80000091 2732 0xb1c7 56

lt-1/2/0
fe-0/0/0.0 up up inet6 9009:6::2/64
fe80::2a0:a514:0:64c/64
lo0
lo0.0 up up inet 192.168.5.1 --> 0/0
feee::10:255:71:6
...
RELATED DOCUMENTATION
OSPF Overview | 2
5 CHAPTER
Configure OSPF Route Control
Configuring OSPF Route Control | 195

195
Configuring OSPF Route Control
IN THIS SECTION
Understanding OSPF Route Summarization | 195
Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements Sent into the Backbone
Area | 196
Understanding OSPF Traffic Control | 208
Example: Controlling OSPF Route Preferences | 220
Understanding the SPF Algorithm Options for OSPF | 230
Understanding Synchronization Between LDP and IGPs | 237
Example: Configuring Synchronization Between LDP and OSPF | 237
OSPFv2 Compatibility with RFC 1583 Overview | 242
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.
196
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 Sent into the Backbone Area
IN THIS SECTION
Requirements | 196
Overview | 197
Configuration | 199
Verification | 204
This example shows how to summarize routes sent into the backbone area.
Requirements
Before you begin:
• Configure a static route. See Examples: Configuring Static Routes in the Junos OS Routing Protocols
Library for Routing Devices.
197
Overview
IN THIS SECTION
Topology | 198
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 18 on page 198 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/28. 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
198
10.0.4.0/28. Area 0.0.0.3 also contains external static route 3.0.0.8, which will be flooded throughout
the network.
Figure 18: Summarizing Ranges of Routes in OSPF
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.
• network/mask-length—Indicates the summarized IP address range and the number of significant bits
in the network mask.
Topology
199
Configuration
IN THIS SECTION
Procedure | 200
Results | 202
• 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 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 area-range 10.0.8.0/28
• 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]
200
set protocols ospf area 0.0.0.3 area-range 10.0.4.0/28

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
Procedure
To summarize routes sent to the backbone area:
NOTE: For OSPFv3, include IPv6 addresses.
[edit]
user@R5# set interfaces fe-0/0/1 unit 0 family inet address 10.0.8.3/30
[edit]
2. Configure the type of OSPF area.

201
[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


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/28
[edit]
user@R3# set protocols ospf area 0.0.0.3 area-range 10.0.4.0/28
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
202
[edit]
user@host# commit
Results

fe-0/0/0 {
unit 0 {
family inet {
address 10.0.2.3/32;
}
}
}
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;
}
203
}
}

area 0.0.0.0 {
}
area 0.0.0.4 {
stub;
area-range 10.0.8.0/28;
}

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;
}
}
}
fe-0/0/4 {
unit 0 {
204
family inet {
address 10.0.2.7/32;
}
}
}
user@R3t# show protocols ospf

area 0.0.0.0 {
}
area 0.0.0.3 {
nssa {
area-range 3.0.0.0/8 ;
}
area-range 10.0.4.0/28;
}
To confirm your OSPFv3 configuration, enter the show interfaces and show protocols ospf3 commands.
Verification
IN THIS SECTION
Verifying the Summarized Route | 204
Verifying the Summarized Route
Purpose
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.
205
Action
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
IN THIS SECTION
Requirements | 205
Overview | 205
Configuration | 206
Verification | 207
This example shows how to limit the number of prefixes exported to OSPF.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 206
206
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.
Topology
Configuration
IN THIS SECTION
Procedure | 207
Results | 207
To quickly limit the number of prefixes exported to OSPF, copy the following commands, paste them
[edit]
set protocols ospf prefix-export-limit 100000
207
Procedure
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
[edit]
user@host# commit
Results

prefix-export-limit 100000;
Verification
IN THIS SECTION
Verifying the Prefix Export Limit | 208

208
Verifying the Prefix Export Limit
Purpose
Verify the prefix export counter that displays the number or routes exported into OSPF.
Action
Understanding OSPF Traffic Control
IN THIS SECTION
Controlling the Cost of Individual OSPF Network Segments | 209
Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth | 209
Controlling OSPF Route Preferences | 210
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 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

209
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.
When there are multiple equal-cost routes to the same destination in a routing table, an equal-cost
multipath (ECMP) set is formed. If there is an ECMP set for the active route, the Junos OS software uses
a hash algorithm to choose one of the next-hop addresses in the ECMP set to install in the forwarding
table.
You can configure Junos OS so that multiple next-hop entries in an ECMP set are installed in the
forwarding table. Define a load-balancing routing policy by including one or more policy-statement
configuration statements at the [edit policy-options] hierarchy level, with the action load-balance per-
packet. Then apply the routing policy to routes exported from the routing table to the forwarding table.
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, 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
210
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.
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.
SEE ALSO
OSPF Overview
Example: Controlling OSPF Route Preferences
Example: Configuring ECMP Flow-Based Forwarding
Example: Controlling the Cost of Individual OSPF Network Segments
IN THIS SECTION
Requirements | 211
Overview | 211
Configuration | 213
211
Verification | 215
This example shows how to control the cost of individual OSPF network segments.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 212
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.
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.
212
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 19 on page 212 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 19: OSPF Metric Configuration
Topology
213
Configuration
IN THIS SECTION
Configuring the Reference Bandwidth | 213
Configuring a Metric for a Specific OSPF Interface | 214
Configuring the Reference Bandwidth
To quickly configure the reference bandwidth, copy the following commands, paste them into a text file,
mode.
[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.
214
[edit]
user@host# commit
NOTE: Repeat this entire configuration on all routing devices in a shared network.
Results

reference-bandwidth 10g;
Configuring a Metric for a Specific OSPF Interface
To quickly configure a metric for a specific OSPF interface, copy the following commands, paste them
[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:

215
[edit]
2. Configure the metric of the OSPF network segment.

user@host# set interface fe-1/0/1 metric 5

user@host# commit
Results

area 0.0.0.0 {
interface fe-1/0/1.0 {
metric 5;
}
}
Verification
IN THIS SECTION
Verifying the Configured Metric | 216

216
Verifying the Route | 216
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.
Action
Verifying the Route
Purpose
When choosing paths to a destination, OSPF uses the path with the lowest total cost. Confirm that
OSPF is using the appropriate path.
Action
From operational mode, enter the show route command.
SEE ALSO
Understanding OSPF Traffic Control

217
Example: Dynamically Adjusting OSPF Interface Metrics Based on

Bandwidth
IN THIS SECTION
Requirements | 219
Overview | 219
Verification | 220
This example shows how to dynamically adjust OSPF interface metrics based on bandwidth.
Configuration
To quickly configure bandwidth threshold values and associated metric values for an OSPF interface,
copy the following commands, paste them into a text file, remove any line breaks, change any details
necessary to match your network configuration, copy and paste the commands into the CLI at the [edit]
hierarchy level, and then enter commit from configuration mode.
[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:

218
[edit]
2. Configure the metric of the OSPF network segment.

user@host# set interface ae0 metric 5
3. Configure the bandwidth threshold values and associated metric values.

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

user@host# commit
Results

area 0.0.0.0 {
interface ae0.0 {
bandwidth-based-metrics {
bandwidth 1g metric 60;
bandwidth 10g metric 50;
}
metric 5;
219
}
}
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 219
You can specify a set of bandwidth threshold values and associated metric values for 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. 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.
Topology
220
Verification
IN THIS SECTION
Verifying the Configured Metric | 220
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.
Action
IN THIS SECTION
Requirements | 222
Overview | 222
Verification | 223
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.
221
Configuration
To quickly configure the OSPF route preference values, copy the following commands, paste them into a
configuration mode.
[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
[edit]
user@host# commit
Results

preference 168;
external-preference 169;
222
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.
Overview
IN THIS SECTION
Topology | 223
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:
• 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 OSPF routes
have a value of 10. The range is from 0 through 4,294967,295 (232 – 1).
223
• 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 (232 – 1).
Topology
Verification
IN THIS SECTION
Verifying the Route | 223
Verifying the Route
Purpose
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.
Action
Understanding OSPF Overload Function
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:
224
• 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.
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.
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.
In cases of incorrect configurations, the huge number of routes might enter OSPF, which can hamper the
network performance. To prevent this, prefix-export-limit should be configured which will purge
externals and prevent the network from the bad impact.
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.
By default, there is no limit to the number of prefixes (routes) that can be exported into OSPF. To
prevent this, prefix-export-limit should be configured which will purge externals and prevent the
network.
Starting from Junos OS Release 18.2 onward, the following functionalities are supported by Stub Router
in your OSPF network, when the OSPF is overloaded:
• Allow Route leaking—external prefixes are redistributed during OSPF overload and the prefixes are
originated with normal cost.
• Advertise stub network with max metric—stub networks are advertised with maximum metric during
OSPF overload.
• Advertise intra-area prefix with max metric—intra-area prefixes are advertised with maximum metric
during OSPF overload.
225
• Advertise external prefix with max possible metric—OSPF AS external prefixes are redistributed
during OSPF overload and the prefixes are advertised with maximum cost.
You can now configure the following when OSPF is overloaded:
• allow-route-leaking at the [edit protocols <ospf | ospf3> overload] hierarchy level to advertise the
external prefixes with normal cost.
• stub-network at the [edit protocols ospf overload] hierarchy level to advertise stub network with
maximum metric.
• intra-area-prefix at the [edit protocols ospf3 overload] hierarchy level to advertise intra-area prefix
with maximum metric.
• as-external at the [edit protocols <ospf | ospf3> overload] hierarchy level to advertise external prefix
with maximum metric.
To limit the number of prefixes exported to OSPF:
[edit]
set protocols ospf prefix-export-limit number
The prefix export limit number can be a value from 0 through 4,294,967,295.
SEE ALSO
overload
allow-route-leaking
stub-network
intra-area-prefix
as-external
Example: Configuring OSPF to Make Routing Devices Appear Overloaded
IN THIS SECTION
Requirements | 226
226
Overview | 226
Configuration | 227
Verification | 229
This example shows how to configure a routing device running OSPF to appear to be overloaded.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 227
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.
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
227
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.
Topology
Configuration
IN THIS SECTION
Procedure | 227
Procedure
To quickly configure a local routing device to appear as overloaded, copy the following commands, paste
[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
228
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.

user@host# set overload timeout 60
4. (Optional) Configure the limit on the number prefixes exported to OSPF, to minimise the load on the
routing device and prevent the device from entering the overload mode.

user@host# set prefix-export-limit 50

user@host# commit
Results
The output includes the optional timeout and prefix-export-limit statements.
prefix-export-limit 50;
overload timeout 60;
229
Verification
IN THIS SECTION
Verifying Traffic Has Moved Off Devices | 229
Verifying Transit Interface Metrics | 229
Verifying the Overload Configuration | 230
Verifying the Viable Next Hop | 230
Verifying Traffic Has Moved Off Devices
Purpose
Verify that the traffic has moved off the upstream devices.
Action
From operational mode, enter the show interfaces detail command.
Verifying Transit Interface Metrics
Purpose
Verify that the transit interface metrics are set to the maximum value of 65535 on the downstream
neighboring device.
Action
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.
230
Verifying the Overload Configuration
Purpose
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.
Action
From operational mode, enter the show ospf overview command for OSPFv2, and the show ospf3
Verifying the Viable Next Hop
Purpose
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.
Action
From operational mode, enter the show route address command.
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.
231
• 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. 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.
Example: Configuring SPF Algorithm Options for OSPF
IN THIS SECTION
Requirements | 231
Overview | 232
Configuration | 233
Verification | 234
This example shows how to configure the SPF algorithm options. The SPF options control the timers
that dictate when the SPF algorithm runs.
Requirements
Before you begin:
232
Overview
IN THIS SECTION
Topology | 232
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 10. 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.
Topology
233
Configuration
IN THIS SECTION
Procedure | 233
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
Procedure
To configure the SPF options:
[edit]
user@host# edit protocols ospf
2. Configure the SPF delay time.

user@host# set spf-options delay 210
234
3. Configure the maximum number of times that the SPF algorithm can run in succession.

user@host# set spf-options rapid-runs 4
4. Configure the SPF hold-down timer.

user@host# set spf-options holddown 5050

user@host# commit
Results

spf-options {
delay 210;
holddown 5050;
rapid-runs 4;
}
Verification
IN THIS SECTION
Verifying SPF Options | 235

235
Verifying SPF Options
Purpose
Verify that SPF is operating per your network requirements. Review the SPF delay field, the SPF
holddown field, and the SPF rapid runs fields.
Action
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 Networks 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
• OSPFv2 peer interfaces

236
• 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 {
flood-reduction;
}
interface lo0.0;
}
}
NOTE: Beginning with Junos OS Release 12.2, you can configure a global default link-state
advertisement (LSA) flooding interval in OSPF for self-generated LSAs by including the lsa-
refresh-interval minutes statement at the [edit protocols (ospf | ospf3)] hierarchy level. The
Juniper Networks implementation refreshes LSAs every 50 minutes. The range is 25 through
50 minutes. By default, any LSA that is not refreshed expires after 60 minutes.
If you have both the global LSA refresh interval configured for OSPF and OSPF flooding
reduction configured for a specific interface in an OSPF area, the OSPF flood reduction
configuration takes precedence for that specific interface.
237
Understanding Synchronization Between LDP and IGPs
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.
SEE ALSO
Example: Configuring Synchronization Between LDP and OSPF

Junos OS MPLS Applications User Guide
Example: Configuring Synchronization Between LDP and OSPF
IN THIS SECTION
Requirements | 237
Overview | 238
Configuration | 238
Verification | 242
This example shows how to configure synchronization between LDP and OSPFv2.
Requirements
Before you begin:
238
Overview
IN THIS SECTION
Topology | 238
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.
Topology
Configuration
IN THIS SECTION
Enabling Synchronization Between LDP and OSPFv2 | 239

239
Disabling Synchronization Between LDP and OSPFv2 | 241
Enabling Synchronization Between LDP and OSPFv2
information about navigating the CLI, see Modifying the Junos OS Configuration in CLI User Guide.
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
240
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
[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
user@host# show protocols ldp


area 0.0.0.0 {
ldp-synchronization {
hold-time 10;
}
}
}
241
Disabling Synchronization Between LDP and OSPFv2
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
[edit]
user@host# commit
Results

area 0.0.0.0 {
disable;
}
}
}
242
Verification
IN THIS SECTION
Verifying the LDP Synchronization State of the Interface | 242
Verifying the LDP Synchronization State of the Interface
Purpose
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.
Action
From operational mode, enter the show ospf interface extensive command.
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.
SEE ALSO

243
IN THIS SECTION
Requirements | 243
Overview | 243
Configuration | 244
Verification | 245
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
IN THIS SECTION
Topology | 243
By default, the Junos OS implementation of OSPF is compatible with RFC 1583. 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 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. Being able to use multiple available paths to calculate an AS
external route can prevent routing loops. To minimize the potential for routing loops, configure the same
RFC compatibility on all OSPF devices in an OSPF domain.
Topology
244
Configuration
IN THIS SECTION
Procedure | 244
Results | 245
Procedure
To quickly disable OSPFv2 compatibility with RFC 1583, copy the following commands, paste them into
configuration mode. You configure this setting on all devices that are part of the OSPF domain.
[edit]
set protocols ospf no-rfc-1583
To disable OSPFv2 compatibility with RFC 1583:
1. Disable RFC 1583.
[edit]
user@host# set protocols ospf no-rfc-1583
[edit]
user@host# commit
245
NOTE: Repeat this configuration on each routing device that participates in an OSPF routing
domain.
Results

no-rfc-1583;
Verification
IN THIS SECTION
Verifying the OSPF Routes | 245
Verifying the OSPF Routes
Purpose
Verify that the OSPF routing table maintains the intra-AS paths with the largest metric, which the router
uses to calculate AS external routes.
Action
From operational mode, enter the show ospf route detail command.
OSPF Overview | 2
6 CHAPTER
Configure OSPF Authentication
Configuring OSPF Authentication | 247

247
Configuring OSPF Authentication
IN THIS SECTION
Understanding IPsec Authentication for OSPF Packets on EX Series Switches | 247
Using IPsec to Secure OSPFv3 Networks (CLI Procedure) | 265
Example: Configuring IPsec Authentication for an OSPF Interface | 267
Understanding IPsec Authentication for OSPF Packets on EX Series

Switches
IN THIS SECTION
Authentication Algorithms | 248
Encryption Algorithms | 248
IPsec Protocols | 249
Security Associations | 249
IPsec Modes | 249
IP Security (IPsec) provides a secure way to authenticate senders and encrypt IP version 4 (IPv4) traffic
between network devices. IPsec offers network administrators for Juniper Networks EX Series Ethernet
Switches and their users the benefits of data confidentiality, data integrity, sender authentication, and
anti-replay services.
248
IPsec is a framework for ensuring secure private communication over IP networks and is based on
standards developed by the International Engineering Task Force (IETF). IPsec provides security services
at the network layer of the Open Systems Interconnection (OSI) model by enabling a system to select
required security protocols, determine the algorithms to use for the security services, and implement
any cryptographic keys required to provide the requested services. You can use IPsec to protect one or
more paths between a pair of hosts, between a pair of security gateways (such as switches), or between
a security gateway and a host.
OSPF version 3 (OSPFv3), unlike OSPF version 2 (OSPFv2), does not have a built-in authentication
method and relies on IPsec to provide this functionality. You can secure specific OSPFv3 interfaces and
protect OSPFv3 virtual links.
Authentication Algorithms
Authentication is the process of verifying the identity of the sender. Authentication algorithms use a
shared key to verify the authenticity of the IPsec devices. The Juniper Networks Junos operating system
(Junos OS) uses the following authentication algorithms:
• Message Digest 5 (MD5) uses a one-way hash function to convert a message of arbitrary length to a
fixed-length message digest of 128 bits. Because of the conversion process, it is mathematically
infeasible to calculate the original message by computing it backwards from the resulting message
digest. Likewise, a change to a single character in the message will cause it to generate a very
different message digest number.
To verify that the message has not been tampered with, Junos OS compares the calculated message
digest against a message digest that is decrypted with a shared key. Junos OS uses the MD5 hashed
message authentication code (HMAC) variant that provides an additional level of hashing. MD5 can
be used with an authentication header (AH) and Encapsulating Security Payload (ESP).
• Secure Hash Algorithm 1 (SHA-1) uses a stronger algorithm than MD5. SHA-1 takes a message of
less than 264 bits in length and produces a 160-bit message digest. The large message digest ensures
that the data has not been changed and that it originates from the correct source. Junos OS uses the
SHA-1 HMAC variant that provides an additional level of hashing. SHA-1 can be used with AH, ESP,
and Internet Key Exchange (IKE).
Encryption Algorithms
Encryption encodes data into a secure format so that it cannot be deciphered by unauthorized users. As
with authentication algorithms, a shared key is used with encryption algorithms to verify the
authenticity of IPsec devices. Junos OS uses the following encryption algorithms:
• Data Encryption Standard cipher-block chaining (DES-CBC) is a symmetric secret-key block

algorithm. DES uses a key size of 64 bits, where 8 bits are used for error detection and the remaining
56 bits provide encryption. DES performs a series of simple logical operations on the shared key,
249
including permutations and substitutions. CBC takes the first block of 64 bits of output from DES,
combines this block with the second block, feeds this back into the DES algorithm, and repeats this
process for all subsequent blocks.
• Triple DES-CBC (3DES-CBC) is an encryption algorithm that is similar to DES-CBC but provides a
much stronger encryption result because it uses three keys for 168-bit (3 x 56-bit) encryption. 3DES
works by using the first key to encrypt the blocks, the second key to decrypt the blocks, and the third
key to reencrypt the blocks.
IPsec Protocols
IPsec protocols determine the type of authentication and encryption applied to packets that are secured
by the switch. Junos OS supports the following IPsec protocols:
• AH—Defined in RFC 2402, AH provides connectionless integrity and data origin authentication for
IPv4. It also provides protection against replays. AH authenticates as much of the IP header as
possible, as well as the upper-level protocol data. However, some IP header fields might change in
transit. Because the value of these fields might not be predictable by the sender, they cannot be
protected by AH. In an IP header, AH can be identified with a value of 51 in the Protocol field of an
IPv4 packet.
• ESP—Defined in RFC 2406, ESP can provide encryption and limited traffic flow confidentiality or
connectionless integrity, data origin authentication, and an anti-replay service. In an IP header, ESP
can be identified with a value of 50 in the Protocol field of an IPv4 packet.
Security Associations
An IPsec consideration is the type of security association (SA) that you wish to implement. An SA is a set
of IPsec specifications that are negotiated between devices that are establishing an IPsec relationship.
These specifications include preferences for the type of authentication, encryption, and IPsec protocol
to be used when establishing the IPsec connection. An SA can be either unidirectional or bidirectional,
depending on the choices made by the network administrator. An SA is uniquely identified by a Security
Parameter Index (SPI), an IPv4 or IPv6 destination address, and a security protocol (AH or ESP) identifier.
IPsec Modes
Junos OS supports the following IPsec modes:
• Tunnel mode is supported for both AH and ESP in Junos OS. In tunnel mode, the SA and associated
protocols are applied to tunneled IPv4 or IPv6 packets. For a tunnel mode SA, an outer IP header
specifies the IPsec processing destination and an inner IP header specifies the ultimate destination
for the packet. The security protocol header appears after the outer IP header and before the inner
250
IP header. In addition, there are slight differences for tunnel mode when you implement it with AH
and ESP:
• For AH, portions of the outer IP header are protected, as well as the entire tunneled IP packet.
• For ESP, only the tunneled packet is protected, not the outer header.
When one side of an SA is a security gateway (such as a switch), the SA must use tunnel mode.
However, when traffic (for example, SNMP commands or BGP sessions) is destined for a switch, the
system acts as a host. Transport mode is allowed in this case because the system does not act as a
security gateway and does not send or receive transit traffic.
NOTE: Tunnel mode is not supported for OSPF v3 control packet authentication.
• Transport mode provides an SA between two hosts. In transport mode, the protocols provide
protection primarily for upper-layer protocols. A transport mode security protocol header appears
immediately after the IP header and any options and before any higher-layer protocols (for example,
TCP or UDP). There are slight differences for transport mode when you implement it with AH and
ESP:
• For AH, selected portions of the IP header are protected, as well as selected portions of the
extension headers and selected options within the IPv4 header.
• For ESP, only the higher-layer protocols are protected, not the IP header or any extension headers
preceding the ESP header.
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:
• 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.
251
• 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 Internet Key Exchange (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.
252
SEE ALSO
Overview of IPsec
OSPFv3 does not have a built-in authentication method and relies on the IP Security (IPsec) suite to
provide this functionality. IPsec provides such functionality as authentication of origin, data integrity,
confidentiality, replay protection, and nonrepudiation of source. You can use IPsec to secure specific
OSPFv3 interfaces and protect OSPFv3 virtual links.
NOTE:
You configure the actual IPsec authentication separately from your OSPFv3 configuration and
then apply IPsec to the OSPFv3 interfaces or OSPFv3 virtual links.
OSPFv3 uses the IP authentication header (AH) and the IP Encapsulating Security Payload (ESP)
portions of the IPsec Protocol to authenticate routing information between peers. AH can provide
connectionless integrity and data origin authentication. It also provides protection against replays. AH
authenticates as much of the IP header as possible, as well as the upper-level protocol data. However,
some IP header fields might change in transit. Because the value of these fields might not be predictable
by the sender, they cannot be protected by AH. ESP can provide encryption and limited traffic flow
confidentiality or connectionless integrity, data origin authentication, and an anti-replay service.
IPsec is based on security associations (SAs). An SA is a set of IPsec specifications that are negotiated
between devices that are establishing an IPsec relationship. This simplex connection provides security
services to the packets carried by the SA. These specifications include preferences for the type of
authentication, encryption, and IPsec protocol to be used when establishing the IPsec connection. An
SA is used to encrypt and authenticate a particular flow in one direction. Therefore, in normal
bidirectional traffic, the flows are secured by a pair of SAs. An SA to be used with OSPFv3 must be
configured manually and use transport mode. Static values must be configured on both ends of the SA.
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 (SPI) values,
algorithms, and keys to be used and require matching configurations on both end points (OSPFv3 peers).
As a result, each peer must have the same configured options for communication to take place.
The actual choice of encryption and authentication algorithms is left to your IPsec administrator;
however, we have the following recommendations:
• Use ESP with NULL encryption to provide authentication to the OSPFv3 protocol headers only. With
NULL encryption, you are choosing not to provide encryption on OSPFv3 headers. This can be useful
253
for troubleshooting and debugging purposes. For more information about NULL encryption, see RFC
2410, The NULL Encryption Algorithm and Its Use With IPsec.
• Use ESP with non-NULL encryption for full confidentiality. With non-NULL encryption, you are
choosing to provide encryption. For more information about NULL encryption, see RFC 2410, The
NULL Encryption Algorithm and Its Use With IPsec.
• Use AH to provide authentication to the OSPFv3 protocol headers, portions of the IPv6 header, and
portions of the extension headers.
The following restrictions apply to IPsec authentication for OSPFv3:
• Dynamic Internet Key Exchange (IKE) security associations (SAs) are not supported.
• Only IPsec transport mode is supported. In transport mode, only the payload (the data you transfer)
of the IP packet is encrypted and/or authenticated. 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.
SEE ALSO
Overview of IPsec
Example: Configuring Simple Authentication for OSPFv2 Exchanges
IN THIS SECTION
Requirements | 254
Overview | 254
Configuration | 254
Verification | 256
This example shows how to enable simple authentication for OSPFv2 exchanges.
254
Requirements
Before you begin:
• Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices or
the Junos OS Interfaces Configuration Guide for Security Devices.
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 (“ “).
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.
Configuration
IN THIS SECTION
Procedure | 255
Results | 256
255
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
Procedure
To enable simple authentication for OSPFv2 exchanges:
[edit]
2. Specify the interface.

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

user@host# commit
256
NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices in the area.
Results
NOTE: After you configure the password, you do not see the password itself. The output displays
the encrypted form of the password you configured.

area 0.0.0.0 {
authentication {
simple-password "$9$-3dY4ZUHm5FevX-db2g"; ## SECRET-DATA
}
}
}
Verification
IN THIS SECTION
Verifying the Configured Authentication Method | 256
Verifying the Configured Authentication Method
Purpose
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.
257
Action
From operational mode, enter the show ospf interface and the show ospf overview commands.
Example: Configuring MD5 Authentication for OSPFv2 Exchanges
IN THIS SECTION
Requirements | 257
Overview | 257
Configuration | 258
Verification | 260
This example shows how to enable MD5 authentication for OSPFv2 exchanges.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 258
258
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.
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.
Topology
Configuration
IN THIS SECTION
Procedure | 258
Results | 259
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
Procedure
To enable MD5 authentication for OSPFv2 exchanges:

259
[edit]

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
[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

area 0.0.0.0 {
authentication {
260
md5 5 key "$9$pXXhuIhreWx-wQF9puBEh"; ## SECRET-DATA

}
}
}
Verification
IN THIS SECTION
Purpose
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.
Action
Example: Configuring a Transition of MD5 Keys on an OSPFv2 Interface
IN THIS SECTION
Requirements | 261
Overview | 261
Configuration | 262
261
Verification | 265
This example shows how to configure a transition of MD5 keys on an OSPFv2 interface.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 262
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.
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.
262
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.
Topology
Configuration
IN THIS SECTION
Procedure | 263
Results | 264
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
263
NeWpsswdFEB start-time 2011-02-01.00:01

NeWpsswdMAR start-time 2011-03-01.00:01
NeWpsswdAPR start-time 2011-04-01.00:01
Procedure
To configure multiple MD5 keys on an OSPFv2 interface:
[edit]

user@host# edit interface fe-0/1/0
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:

user@host# set authentication md5 2 key NeWpsswdFEB start-time 2011-02-01.00:01
264
b. For the month of March, enter the following:

user@host# set authentication md5 3 key NeWpsswdMAR start-time 2011-03-01.00:01
c. For the month of April, enter the following:

user@host# set authentication md5 4 key NeWpsswdAPR start-time 2011-04-01.00:01

user@host# commit
NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices.
Results

area 0.0.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
md5 4 key "$9$fQn90OReML1Rds4oiHBIEhSevMLXNVqm" start-time
265
"2011-4-1.00:01:00 -0700"; ## SECRET-DATA

}
}
}
Verification
IN THIS SECTION
Purpose
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.
Action
Using IPsec to Secure OSPFv3 Networks (CLI Procedure)
IN THIS SECTION
Securing OPSFv3 Networks | 267

266
OSPF version 3 (OSPFv3) does not have a built-in authentication method and relies on IP Security
(IPsec) to provide this functionality. You can use IPsec to secure OSPFv3 interfaces on EX Series
switches.
This topic includes:
Configuring Security Associations

When you configure a security association (SA), include your choices for authentication, encryption,
direction, mode, protocol, and security parameter index (SPI).
To configure a security association:
1. Specify a name for the security association:
[edit security ipsec]

user@switch# set security-association sa-name
2. Specify the mode of the security association:
[edit security ipsec security-association sa-name]

user@switch# set mode transport
3. Specify the type of security association:

user@switch# set type manual
4. Specify the direction of the security association:

user@switch# set direction bidirectional
5. Specify the value of the security parameter index:

user@switch# set spi spi-value
267
6. Specify the type of authentication to be used:

user@switch# set authentication algorithm type
7. Specify the encryption algorithm and key:

user@switch# set encryption algorithm algorithm key type
Securing OPSFv3 Networks

You can secure the OSPFv3 network by applying the SA to the OSPFv3 configuration.
To secure the OSPFv3 network:
[edit protocols ospf3 area area-number interface interface-name]

user@switch# set ipsec-sa sa-name
Example: Configuring IPsec Authentication for an OSPF Interface
IN THIS SECTION
Requirements | 267
Overview | 268
Configuration | 270
Verification | 275
This example shows how to enable IP Security (IPsec) authentication for an OSPF interface.
Requirements
Before you begin:
268
Overview
IN THIS SECTION
Topology | 270
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;

269
• 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 Library for Routing Devices.
• 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;
• 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.
270
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.
Topology
Configuration
IN THIS SECTION
Enabling IPsec Authentication for an OSPF Interface | 273

271
Configuring Security Associations
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
protocol ah
set security ipsec security-association sa1 manual direction bidirectional spi
256
authentication algorithm hmac-md5-96 key ascii-text 123456789012abcd
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.

user@host# set manual direction bidirectional
272
4. Configure the IPsec protocol to use.

user@host# set manual direction bidirectional protocol ah
5. Configure the value of the SPI.

user@host# set manual direction bidirectional spi 256
6. Configure the authentication algorithm and key.

user@host# set manual direction bidirectional authentication algorithm hmac-md5-96 key ascii-text
123456789012abcd

user@host# commit
NOTE: Repeat this entire configuration on all peer OSPF routing devices.
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;
273
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
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:
[edit]
274

3. Apply the IPsec manual SA.

user@host# set ipsec-sa sa1

user@host# commit
NOTE: Repeat this entire configuration on all peer OSPF routing devices.
Results

area 0.0.0.0 {
ipsec-sa sa1;
}
}
275
Verification
IN THIS SECTION
Verifying the IPsec Security Association Settings | 275
Verifying the IPsec Security Association on the OSPF Interface | 275
Verifying the IPsec Security Association Settings
Purpose
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.
Action
From operational mode, enter the show ipsec security-associations command.
Verifying the IPsec Security Association on the OSPF Interface
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
276
SEE ALSO
Junos OS Administration Library for Routing Devices

Junos OS Services Interfaces Library for Routing Devices
7 CHAPTER
Configure OSPF Routing Instances
Configuring OSPF Routing Instances | 278

278
Configuring OSPF Routing Instances
IN THIS SECTION
Understanding OSPF Routing Instances | 278
Installing Routes from OSPF Routing Instances into the OSPF Routing Table Group | 280
Understanding OSPF Routing Instances
IN THIS SECTION
Minimum Routing-Instance Configuration for OSPFv2 | 279
Minimum Routing-Instance Configuration for OSPFv3 | 279
Multiple Routing Instances of OSPF | 280
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, primary, refers to the main inet.0 routing table. The primary
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.

279
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 {
ospf {
... ospf-configuration ...
}
}
}
}
NOTE: You can configure a logical interface under only one routing instance.
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 {
280
instance-type (no-forwarding | virtual-router | vrf);

vrf-import [ policy-names ];
vrf-export [ policy-names ];
protocols {
ospf3 {
... ospf3-configuration ...
}
}
}
}
NOTE: You can configure a logical interface under only one routing instance.
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)]
Installing Routes from OSPF Routing Instances into the OSPF Routing
Table Group
To install routes learned from OSPF routing instances into routing tables in the OSPF routing table
group, include the rib-group statement:
rib-group group-name;
For a list of hierarchy levels at which you can include this statement, see the statement summary section
for this statement.
281
Example: Configuring Multiple Routing Instances of OSPF
IN THIS SECTION
Requirements | 281
Overview | 281
Configuration | 284
Verification | 290
This example shows how to configure multiple routing instances of OSPF.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 283
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.

282
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 Routing Policies, Firewall Filters, and Traffic Policers
User Guide.
Figure 20 on page 283 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.
283
Topology
Figure 20: Configuration for Multiple Routing Instances
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:
• 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.
• 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.
284
Configuration
IN THIS SECTION
Procedure | 284
Procedure
To quickly configure multiple routing instances of OSPF, copy the following commands, paste them into
configuration mode.
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
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
so-4/2/2
285
[edit]
set routing-instances voice-policy interface so-3/2/2
set routing-instances voice-policy protocols ospf rib-group voice-to-inet area
set routing-instances other-policy interface so-5/2/2
set routing-instances other-policy protocols ospf rib-group other-to-inet area
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 ]
so-3/2/2
so-5/2/2
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
286
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 ]
287
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.
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit routing-instances
protocols] hierarchy level.
[edit]
user@D1# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-2/2/2
[edit]
[edit]
user@host# commit
Results
Confirm your configuration by entering the show routing-instances, show routing-options, and show
288
user@D1# show routing-instances

voice-policy {
protocols {
ospf {
rib-group voice-to-inet;
area 0.0.0.0 {
}
}
}
}
other-policy {
protocols {
ospf {
rib-group other-to-inet;
area 0.0.0.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 ];
289
}
}
user@D1# show protocols ospf

rib-group inet-to-voice-and-other;
area 0.0.0.0 {
}
user@D3# show routing-instances

voice-policy {
protocols {
ospf {
rib-group voice-to-inet;
area 0.0.0.0 {
}
}
}
}
other-policy {
protocols {
ospf {
rib-group other-to-inet;
area 0.0.0.0 {
}
}
}
}
user@D3# show routing-options

rib-groups {
inet-to-voice-and-other {
290
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 {
}
To confirm your OSPFv3 configuration, enter the show routing-instances, show routing-options, and
show protocols ospf3 commands.
Verification
IN THIS SECTION
Verifying the Routing Instances | 290
Verifying the Routing Instances
Purpose
Verify the configured routing instance settings.
Action
From operational mode, enter the show route instance detail command.
291
SEE ALSO
rib-group (Protocols OSPF)
Routing Instances Overview

8 CHAPTER
Configure OSPF Timers
Configuring OSPF Timers | 293

293
Configuring OSPF Timers
IN THIS SECTION
OSPF Timers Overview | 293
Example: Configuring OSPF Timers | 294
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.
• 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
294
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.
SEE ALSO
Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network
Example: Configuring OSPF Timers
IN THIS SECTION
Requirements | 294
Overview | 295
Configuration | 296
Verification | 302
This example shows how to configure the OSPF timers.
Requirements
Before you begin:
295
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
296
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.
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
IN THIS SECTION
Configuring the Hello Interval and the Dead Interval | 297
Controlling the LSA Retransmission Interval | 299
Specifying the Transit Delay | 300

297
Configuring the Hello Interval and the Dead Interval
To quickly configure the hello and dead intervals, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration, copy and paste the commands into
the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
[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:
[edit]
2. Specify the interfaces.

user@host# set interface fe-0/0/1
3. Configure the hello interval.

user@host# set interface fe-0/0/1 hello-interval 2
user@host# set interface fe-1/0/1 hello-interval 2
298
4. Configure the dead interval.

user@host# set interface fe-0/0/1 dead-interval 8
user@host# set interface fe-1/0/1 dead-interval 8

user@host# commit
NOTE: Repeat this entire configuration on all routing devices in a shared network.
Results

area 0.0.0.0 {
hello-interval 2;
dead-interval 8;
}
hello-interval 2;
dead-interval 8;
}
}
299
Controlling the LSA Retransmission Interval
To quickly configure the LSA retransmission interval, copy the following commands, paste them into a
configuration mode.
[edit]
set protocols ospf area 0.0.0.1 interface fe-0/0/1 retransmit-interval 8
To configure the LSA retransmission interval:
[edit]

3. Configure the LSA retransmission interval.

user@host# set interface fe-0/0/1 retransmit-interval 8
300

user@host# commit
Results

area 0.0.0.1 {
retransmit-interval 8;
}
}
Specifying the Transit Delay
To quickly configure the transit delay, copy the following commands, paste them into a text file, remove
any line breaks, change any details necessary to match your network configuration, copy and paste the
[edit]
set protocols ospf area 0.0.0.1 interface fe-1/0/1 transit-delay 2
To configure the transit delay:

301
[edit]

3. Configure the transit delay.

user@host# set interface fe-1/0/1 transit-delay 2

user@host# commit
Results

area 0.0.0.1 {
transit-delay 2;
}
}
302
Verification
IN THIS SECTION
Verifying the Timer Configuration | 302
Verifying the Timer Configuration
Purpose
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.
Action
From operational mode, enter the show ospf interface detail for OSPFv2, and enter the show ospf3
interface detail command for OSPFv3.

9 CHAPTER
Configure OSPF Fault Detection using

BFD
Configuring OSPF Fault Detection using BFD | 304

304
Configuring OSPF Fault Detection using BFD
IN THIS SECTION
Understanding BFD Authentication for OSPF | 313
Configuring BFD Authentication for OSPF | 315
Understanding BFD for OSPF
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 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, so they provide
faster detection.
The BFD failure detection timers are adaptive and can be adjusted to be faster or slower. The lower the
BFD failure detection timer value, the faster the failure detection and vice versa. For example, the
timers can adapt to a higher value if the adjacency fails (that is, the timer detects failures more slowly).
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. 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 routing device.
NOTE: QFX5000 Series switches and EX4600 switches do not support minimum interval values
of less than 1 second.
305
NOTE: BFD is supported for OSPFv3 in Junos OS Release 9.3 and later.
NOTE: For branch SRX Series devices, we recommend 1000 ms as the minimum keepalive time
interval for BFD packets.
You can configure the following BFD protocol settings:
• detection-time threshold—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—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 after which the local routing device transmits hello packets and
the minimum interval after 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 using the transmit-interval minimum-interval
and minimum-receive-interval statements.
NOTE: BFD is an intensive protocol that consumes system resources. Specifying a minimum
interval for BFD of 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 no less than 500 ms. An interval of 1000 ms is recommended to avoid
any instability issues.
• For very large-scale network deployments with a large number of BFD sessions, 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. Without NSR, Routing Engine-based sessions can have a minimum
306
interval of 100 ms. In OSPFv3, BFD is always based in the Routing Engine, meaning that
BFD is not distributed. For distributed BFD sessions with NSR configured, the minimum
interval recommendations are unchanged and depend only on your network deployment.
• On a single QFX5100 switch, when you add a QFX-EM-4Q expansion module, specify a
minimum interval higher than 1000 ms.
• minimum-receive-interval—Minimum receive interval for failure detection. This setting configures

the minimum receive interval, in milliseconds, after which the routing device expects to receive a
hello packet from a neighbor with which it has established a BFD session. You can also specify the
minimum receive interval using the minimum-interval statement.
• 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 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. You can also specify the
minimum transmit interval using the minimum-interval statement.
• transmit-interval threshold—Threshold for the adaptation of the BFD session transmit interval.
When the 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 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.

307
Example: Configuring BFD for OSPF
IN THIS SECTION
Requirements | 307
Overview | 307
Configuration | 309
Verification | 312
This example shows how to configure the Bidirectional Forwarding Detection (BFD) protocol for OSPF.
Requirements
Before you begin:
Election.
Overview
IN THIS SECTION
Topology | 309
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
308
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.
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, after which the local routing
device transmits hello packets as well as the minimum interval after 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 using the transmit-interval minimum-interval and minimum-
receive-interval statements.
NOTE: BFD is an intensive protocol that consumes system resources. Specifying a minimum
interval for BFD of 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 no less than 500 ms. An interval of 1000 ms is recommended to avoid
any instability issues.
NOTE:
309
• For the bfdd process, the detection time interval set is lower than 300 ms. If
there is a high priority process such as ppmd running on the system, the CPU
might spend time on the ppmd process rather than the bfdd process.
• For branch SRX Series devices, we recommend 1000 ms as the minimum

keepalive time interval for BFD packets.
• For very large-scale network deployments with a large number of BFD sessions, 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.
• 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.
Topology
Configuration
IN THIS SECTION
Procedure | 309
Procedure
To quickly configure the BFD protocol for OSPF, copy the following commands, paste them into a text
310
configuration mode.
[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:
[edit]

3. Specify the minimum transmit and receive intervals.

user@host# set interface fe-0/0/1 bfd-liveness-detection minimum-interval 300
311
4. Configure the number of missed hello packets that cause the originating interface to be declared
down.

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.

user@host# set interface fe-0/0/1 bfd-liveness-detection full-neighbors-only

user@host# commit
NOTE: Repeat this entire configuration on the other neighboring interface.
Results

area 0.0.0.0 {
bfd-liveness-detection {
minimum-interval 300;
multiplier 4;
full-neighbors-only;
}
}
}
312
Verification
IN THIS SECTION
Verifying the BFD Sessions | 312
Verifying the BFD Sessions
Purpose
Verify that the OSPF interfaces have active BFD sessions, and that session components have been
configured correctly.
Action
From operational mode, enter the show bfd session detail command.
Meaning
The output displays information about the 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.

313
Understanding BFD Authentication for OSPF
IN THIS SECTION
BFD Authentication Algorithms | 313
Security Authentication Keychains | 314
Strict Versus Loose Authentication | 315
Bidirectional Forwarding Detection (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 OSPFv2.
BFD authentication is not supported on MPLS OAM sessions. 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.
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
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 can 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.
314
• 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 might 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 might take additional time to
authenticate the session.
NOTE: Nonstop active routing (NSR) is not supported with the meticulous-keyed-md5 and
meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms might
go down after a switchover.
NOTE: QFX5000 Series switches and EX4600 switches do not support minimum interval values
of less than 1 second.
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.
315
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
IN THIS SECTION
Configuring BFD Authentication Parameters | 315
Viewing Authentication Information for BFD Sessions | 317
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]
user@host# set protocols ospf area 0.0.0.1 interface if2-ospf bfd-liveness-detection authentication
algorithm keyed-sha-1
316
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.
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
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 keychain name as specified in Step "2".
• At least one key, a unique integer between 0 and 63. Creating multiple keys enables 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, in the format yyyy-mm-dd.hh:mm:ss.
[edit security]
user@host# authentication-key-chains key-chain bfd-ospf key 53 secret $ABC123$ABC123 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 ospf interface if2-ospf bfd-liveness-detection authentication loose-check
317
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.
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 “$ABC123$ABC123” and a start time of June
1, 2009, at 9:46:02 AM PST. Key 2 contains the secret data “$ABC123$ABC123” and a start time of
June 1, 2009, at 3:29:20 PM PST.

area 0.0.0.1 {
interface if2-ospf {
authentication {
algorithm keyed-sha-1;
key-chain bfd-ospf;
}
}
}
}
[edit security]
authentication key-chains {
key-chain bfd-ospf {
key 1 {
secret “$ABC123$ABC123”; ## SECRET-DATA
start-time “2009-6-1.09:46:02 -0700”;
}
key 2 {
secret “$ABC123$ABC123”;
start-time “2009-6-1.15:29:20 -0700”; ## SECRET-DATA
}
318
}
}
If you commit these updates to your configuration, you see output similar to the following. In the output
for the show bfd session detail command, Authenticate is displayed to indicate that BFD authentication
is configured.
show bfd session 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
1 sessions, 1 clients
Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps
For more information about the configuration, use the show bfd session 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 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

Replicated
Min async interval 0.200, min slow interval 1.000
319
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

Junos OS Administration Library for Routing Devices
CLI Explorer
Example: Configuring BFD Authentication for OSPF
10 CHAPTER
Configure Graceful Restart for OSPF
Configuring Graceful Restart for OSPF | 321

321
Configuring Graceful Restart for OSPF
IN THIS SECTION
Graceful Restart for OSPF Overview | 321
Graceful Restart for OSPF Overview
IN THIS SECTION
Helper Mode for Graceful Restart | 322
Planned and Unplanned Graceful Restart | 323
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 ), the restarting device can quickly resume full operation without
recalculating algorithms.
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.
322
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 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.
323
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
IN THIS SECTION
Requirements | 323
Overview | 324
Configuration | 325
Verification | 329
This example shows how to configure graceful restart specifically for OSPF.
Requirements
Before you begin:
Election.
324
Overview
IN THIS SECTION
Topology | 324
Graceful restart enables 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] 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 statement configures how long (in seconds) the routing device notifies helper
routers that it has completed graceful restart by sending purged grace link-state advertisements (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 statement 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.
Topology
325
Configuration
IN THIS SECTION
Enabling Graceful Restart for OSPF | 325
Disabling Graceful Restart for OSPF | 327
Enabling Graceful Restart for OSPF
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 routing-options graceful-restart
set protocols ospf graceful-restart restart-duration 190
set protocols ospf graceful-restart notify-duration 40
To enable graceful restart for OSPF:
NOTE: For OSPFv3, use IPv6 addresses.
[edit]
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4
2. Configure OSPF on the interfaces.

326
[edit]
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/1
3. Configure graceful restart globally
[edit]
user@host#edit routing-options graceful-restart
4. Configure OSPF graceful restart.
[edit]
user@host# edit protocols ospf graceful-restart
5. (Optional) Configure the restart duration time.
[edit protocols ospf graceful-restart]

user@host# set restart-duration 190
6. (Optional) Configure the notify duration time.

user@host# set notify-duration 40

user@host# commit
327
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.

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;
}
}
}
graceful-restart {
restart-duration 190;
notify-duration 40;
}
area 0.0.0.0 {
}
To confirm an OSPFv3 configuration, enter the show interfaces and the show protocols ospf3
commands.
Disabling Graceful Restart for OSPF
To quickly disable graceful restart for OSPF, copy the following commands, paste them into a text file,
328
mode.
[edit]
user@host# set protocols ospf graceful-restart disable
To disable graceful restart for OSPF:
1. Disable graceful restart for the OSPF protocol only.
This command does not affect the global graceful restart configuration setting.
[edit]
user@host# set protocols ospf graceful-restart disable
[edit]
user@host# commit
Results

graceful-restart disable;
To confirm an OSPFv3 configuration, enter the show protocols ospf3 command.

329
Verification
IN THIS SECTION
Verifying the OSPF Graceful Restart Configuration | 329
Verifying Graceful Restart Status | 329
Verifying the OSPF Graceful Restart Configuration
Purpose
Verify information about your OSPF graceful restart configuration.
Action
From operational mode, enter the show ospf overview command for OSPFv2. Enter the show ospf3
Meaning
The Restart field displays the status of graceful restart as either enabled or disabled. The Restart
duration field displays how much time the restarted routing device requires to complete reacquisition of
OSPF neighbors. The Restart grace period field displays how much time the neighbors should consider
the restarted routing device as part of the topology.
Verifying Graceful Restart Status
Purpose
Verify the status of graceful restart.
Action
330
Meaning
The Restart State field displays Pending if the restart has not been 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 or have not yet completed graceful restart for the specified routing table.
Example: Configuring the Helper Capability Mode for OSPFv2 Graceful

Restart
IN THIS SECTION
Requirements | 330
Overview | 331
Configuration | 331
Verification | 335
This example shows how to disable and reenable the helper mode capability for OSPFv2 graceful
restart.
Requirements
Before you begin:
331
Overview
IN THIS SECTION
Topology | 331
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.
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.
Topology
Configuration
IN THIS SECTION
Disabling Helper Mode for OSPFv2 | 332

332
Reenabling Helper Mode for OSPFv2 | 334
Disabling Helper Mode for OSPFv2
To quickly enable graceful restart for OSPFv2 with helper mode disabled, copy the following commands
and paste them into the CLI.
[edit]
set protocols ospf graceful-restart helper-disable standard
To enable graceful restart for OSPFv2 with helper mode disabled:
[edit]
2. Configure OSPFv2 on the interfaces
[edit]
3. Disable the OSPFv2 graceful restart helper capability.

333
If you disable the OSPFv2 graceful restart helper capability, you cannot disable strict LSA checking.
[edit]
user@host# set protocols ospf graceful-restart helper-disable standard
[edit]
user@host# commit
Results

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;
}
}
}
graceful-restart {
helper-disable {
standard;
}
}
area 0.0.0.0 {
334
}
Reenabling Helper Mode for OSPFv2
To quickly reenable standard helper-mode for OSPFv2, copy the following commands, paste them into a
configuration mode.
[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. Delete the standard helper-mode statement from the OSPFv2 configuration.
[edit]
user@host# delete protocols ospf graceful-restart helper-disable standard
[edit]
user@host# commit
Results
After you reenable standard helper mode, the show protocols ospf command no longer displays the
graceful restart configuration.
335
Verification
IN THIS SECTION
Verifying the OSPFv2 Graceful Restart Configuration | 335
Verifying the OSPFv2 Graceful Restart Configuration
Purpose
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.
Action
From operational mode, enter the show ospf overview command.
Purpose
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.
Action
336
Example: Configuring the Helper Capability Mode for OSPFv3 Graceful

Restart
IN THIS SECTION
Requirements | 336
Overview | 336
Configuration | 337
Verification | 340
This example shows how to disable and reenable the helper mode capability for OSPFv3 graceful
restart.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 337
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
337
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.
Topology
Configuration
IN THIS SECTION
Disabling Helper Mode for OSPFv3 | 337
Reenabling Helper Mode for OSPFv3 | 339
Disabling Helper Mode for OSPFv3
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 2001:0a00:0004::
set interfaces fe-1/1/2 unit 0 family inet6 address 2001:0a00:0005::
set protocols ospf3 graceful-restart helper-disable
338
To enable graceful restart for OSPFv3 with helper mode disabled:
[edit]
user@host# set interfaces fe-1/1/1 unit 0 family inet6 address 2001:0a00:0004::
user@host# set interfaces fe-1/1/1 unit 0 family inet address 2001: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
[edit]
user@host# commit
Results
Confirm your configuration by entering the show interfaces and the show protocols ospf3 commands. If

fe-1/1/1 {
unit 0 {
339
family inet6 {
address 2001:0a00:0004::/128;
}
}
}
fe-1/1/2 {
unit 0 {
family inet6 {
address 2001:0a00:0005::/128;
}
}
}
user@host# show protocols ospf3
graceful-restart {
helper-disable;
}
area 0.0.0.0 {
}
Reenabling Helper Mode for OSPFv3
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
340
[edit]
user@host# commit
Results
After you reenable standard helper mode, the show protocols ospfs command no longer displays the
graceful restart configuration.
Verification
IN THIS SECTION
Verifying the OSPFv3 Graceful Restart Configuration | 340
Verifying the OSPFv3 Graceful Restart Configuration
Purpose
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.
Action
From operational mode, enter the show ospf3 overview command.
Purpose
341
Action
Example: Disabling Strict LSA Checking for OSPF Graceful Restart
IN THIS SECTION
Requirements | 341
Overview | 342
Configuration | 342
Verification | 345
This example shows how to disable strict link-state advertisement (LSA) checking for OSPF graceful
restart.
Requirements
Before you begin:
342
Overview
IN THIS SECTION
Topology | 342
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.

Topology
Configuration
IN THIS SECTION
Procedure | 343
343
Procedure
To quickly enable graceful restart for OSPF with strict LSA checking disabled, copy the following
[edit]
set protocols ospf graceful-restart no-strict-lsa-checking
To enable graceful restart for OSPF with strict LSA checking disabled:
[edit]
2. Configure OSPF on the interfaces
[edit]
3. Disable strict LSA checking.

344
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
[edit ]
user@host# commit
Results

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;
}
}
}
graceful-restart {
no-strict-lsa-checking;
}
area 0.0.0.0 {
345
}
To confirm your OSPFv3 configuration, enter the show interfaces and the show protocols ospf3
commands.
Verification
IN THIS SECTION
Verifying the OSPF Graceful Restart Configuration | 345
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.
Action
Purpose
346
Action
Graceful Restart Concepts

11 CHAPTER
Configure Loop-Free Alternate Routes

for OSPF
Configuring Loop-Free Alternate Routes for OSPF | 348

348
Configuring Loop-Free Alternate Routes for OSPF
IN THIS SECTION
Per Prefix Loop Free Alternates for OSPF | 348
Configuring Per-Prefix LFA for OSPF | 349
Loop-Free Alternate Routes for OSPF Overview | 350
Configuring Node-Link Protection for OSPF | 352
Configuring Node to Link Protection Fallback for OSPF | 353
Excluding an OSPF Interface as a Backup for a Protected Interface | 354
Configuring RSVP Label-Switched Paths as Backup Paths for OSPF | 357
Example: Configuring Loop-Free Alternate Routes for OSPF | 358
Remote LFA over LDP Tunnels in OSPF Networks Overview | 386
Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network | 388
Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks | 389
Per Prefix Loop Free Alternates for OSPF
In certain topologies and usage scenarios, when multiple destinations originate the same prefix and
there is no viable LFA to the best prefix originator, whilst a non-best prefix originator has one. Per-prefix
LFA is a technology by which, the LFA to a non-best prefix originator can be used in lieu of the LFA to
the best prefix originator to provide local repair. This can be used to increase the local repair coverage
for the OSPF protocol also.
Per-Prefix Loop Free Alternates (LFA)—Loop Free Alternates (LFA) is a technology by which a neighbor
can be used as a backup next hop to provide a local repair path for the traffic to flow temporarily in case
of failures in the primary next hop (node or link). For this, the basic requirement is that the selected
backup neighbor provides a loop free path with respect to primary next hop towards a destination,
originating a set of interior gateway protocol (IGP) prefixes.
349
The following topology explains the deployment case where per prefix LFA feature is applicable.
Figure 21: Per-Prefix LFA Usage Scenario
ABR1 and ABR2 are area boundary routers (ABRs), dual homed to an IPv6 core network, which
advertises the summary LSA for the prefix 10.0.1.0/24 with a metric of 10. Also, from PE router’s
perspective, ABR1 is the best prefix originator for 10.0.1.0/24. In this case, P2 is not a valid LFA for
ABR1 because of the equal cost multi paths (ECMP) {P2, PE, P1, ABR1} and {P2, ABR2, ABR1} causing
some of the traffic to be looped back through the router PE (no valid LFA). However for ABR2, which is
also a prefix originator for 10.0.1.0/24, P2 is a valid LFA because the only path is {P2, ABR2}.
Configuring Per-Prefix LFA for OSPF
Per prefix LFA is a mechanism by which LFA to a non-best prefix originator can be used in lieu of the
LFA to the best prefix originator to provide local repair. In such cases, per prefix LFA can be used to
increase the local repair coverage for the OSPF protocol.
Loop Free Alternates (LFA) is a mechanism by which a neighbor can be used as a backup next hop to
provide a local repair path for the traffic to flow temporarily in case of failures in the primary next hop
(node or link). For this the basic requirement is that the selected backup neighbor provides a loop free
350
path with respect to primary next hop towards a destination originating a set of IGP prefixes. In certain
topologies and usage scenarios, it may be possible that multiple destinations are originating the same
prefix and there is no viable LFA to the best prefix originator, whilst a non-best prefix originator has one.
Per prefix LFA is a mechanism by which LFA to a non-best prefix originator can be used in lieu of the
LFA to the best prefix originator to provide local repair. In such cases, per prefix LFA can be used to
increase the local repair coverage for the OSPF protocol.
To configure per prefix LFA for an OSPF interface:
• Configure the per-prefix-calculation configuration statement at the [edit protocols (ospf | ospf3)
backup-spf-options] hierarchy level.
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 three mechanisms for route redundancy for OSPF through alternate loop-free routes:
351
• 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.
• Per-prefix loop-free alternates (LFAs)—It is a technology by which a neighbor can be used as a

backup next hop to provide a local repair path for the traffic to flow temporarily in case of failures in
the primary next hop (node or link). For this, the basic requirement is that the selected backup
neighbor provides a loop-free path with respect to a primary next hop towards a destination,
originating a set of interior gateway protocol (IGP) prefixes.
In certain topologies and usage scenarios, it may be possible that multiple destinations are originating
the same prefix and there is no viable LFA to the best prefix originator, while a non-best prefix
originator has a viable LFA. Per-prefix LFA is a mechanism by which LFA to a non-best prefix
originator can be used in lieu of the LFA to the best prefix originator to provide local repair. In such
cases, per prefix LFA can be used to increase the local repair coverage for the OSPF protocol.
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:

352
• 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 {
link-protection;
}
}
}
}
SEE ALSO
link-protection
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:

353
• 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
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
[edit]
protocols {
ospf {
area 0.0.0.0 {
node-link-protection;
}
}
}
}
Configuring Node to Link Protection Fallback 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.
354
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
In certain topologies it may be desirable to have local repair protection to node failures in the primary
next hop, which may not be available. In that case, to ensure that some level of local repair capabilities
exist, a fallback mechanism is required. Since the link protection is less stringent than node protection, it
may be possible that link protection exists and provide the same to those destination (and hence the
prefixes originated by it).
To configure node to link protection fallback for an OSPF interface:
• Include the node-link-degradation statement at the [edit protocols (ospf | ospf3) backup-spf-
options] hierarchy level.
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
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 {
no-eligible-backup;
}
}
355
}
}
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.
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.
356
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 {
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.
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 {
downstream-paths-only;
357
}
}
}
}
SEE ALSO
backup-spf-options
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;
358
}
}
}
Example: Configuring Loop-Free Alternate Routes for OSPF
IN THIS SECTION
Requirements | 358
Overview | 358
Configuration | 359
Verification | 371
This example demonstrates the use of link protection for interfaces that have OSPF 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.
Requirements
Overview
IN THIS SECTION
Topology | 359
In this example, six OSPF neighbors are configured with link protection. This causes Junos OS to create
an alternate path to the primary next hop for all destination routes that traverse each protected
interface. Link protection is used here because even if a link becomes unavailable, the neighboring node
would still be available through another interface.
359
The example shows two topologies. One is the default topology, and the other is the voice topology. For
more information about multitopology routing, see the Multitopology Routing User Guide.
The example also includes RSVP LSPs configured as backup LSPs for protected OSPF interfaces.
Topology
Figure 22 on page 359 shows the sample network.
Figure 22: OSPF Link Protection
"CLI Quick Configuration" shows the configuration for all of the devices in Figure 22 on page 359.
The section "No Link Title" describes the steps on Device R1.
Configuration
IN THIS SECTION
Procedure | 366
360
Device R1
set interfaces so-0/2/2 unit 0 description to-R2

set interfaces so-0/2/2 unit 0 family mpls
set interfaces t1-0/1/2 unit 0 description to-R2
set interfaces t1-0/1/2 unit 0 family inet address 192.168.241.1/30
set interfaces t1-0/1/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.164.1/32 primary
set protocols rsvp interface all link-protection
set protocols rsvp interface fxp0.0 disable
set protocols mpls label-switched-path path1 backup
set protocols mpls label-switched-path path1 to 10.255.164.3
set protocols mpls label-switched-path path2 backup
set protocols mpls label-switched-path path2 to 10.255.164.3
set protocols mpls interface all
set protocols mpls interface fxp0.0 disable
set protocols ospf topology voice topology-id 32
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface so-0/2/0.0 link-protection
set protocols ospf area 0.0.0.0 interface so-0/2/0.0 metric 10
set protocols ospf area 0.0.0.0 interface t1-0/1/0.0 link-protection
set protocols ospf area 0.0.0.0 interface t1-0/1/0.0 metric 10
361
set protocols ldp interface all

set protocols ldp interface fxp0.0 disable
set policy-options policy-statement pplb then load-balance per-packet
set routing-options forwarding-table export pplb
set routing-options topologies family inet topology voice
set routing-options forwarding-table indirect-next-hop-change-acknowledgements
Device R2

362

Device R3

set protocols ospf traceoptions file ospf
set protocols ospf traceoptions file size 5m
set protocols ospf traceoptions file world-readable
set protocols ospf traceoptions flag error
set routing-options static route 11.3.1.0/24 discard
363

Device R4

364
Device R5

set interfaces s0-0/2/0 unit 0 description to-R2
set interfaces s0-0/2/0 unit 0 family inet address 192.168.242.22/30
set interfaces s0-0/2/0 unit 0 family mpls
set protocols ospf area 0.0.0.0 interface s0-0/2/0.0 link-protection
set protocols ospf area 0.0.0.0 interface s0-0/2/0.0 metric 10
365

Device R6

366
Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For
Guide.
[edit interfaces]
user@R1# set so-0/2/2 unit 0 description to-R2
user@R1# set so-0/2/2 unit 0 family inet address 192.168.242.1/30
user@R1# set so-0/2/2 unit 0 family mpls
user@R1# set t1-0/1/2 unit 0 description to-R2
user@R1# set t1-0/1/2 unit 0 family inet address 192.168.241.1/30
user@R1# set t1-0/1/2 unit 0 family mpls
user@R1# set t1-0/1/0 unit 0 description to-R4
user@R1# set t1-0/1/0 unit 0 family inet address 192.168.241.17/30
user@R1# set t1-0/1/0 unit 0 family mpls
user@R1# set so-0/2/0 unit 0 description to-R4
user@R1# set so-0/2/0 unit 0 family inet address 192.168.242.17/30
user@R1# set so-0/2/0 unit 0 family mpls
user@R1# set lo0 unit 0 family inet address 10.255.164.1/32 primary
2. Extend backup coverage to include RSVP LSP paths.
[edit protocols rsvp]

user@R1# set interface all link-protection
user@R1# set interface fxp0.0 disable
3. Enable MPLS on the interfaces, and configure backup LSPs to Device R3.
[edit protocols mpls]

user@R1# set interface all
user@R1# set label-switched-path path1 backup
user@R1# set label-switched-path path1 to 10.255.164.3
367
user@R1# set label-switched-path path2 backup

user@R1# set label-switched-path path2 to 10.255.164.3
4. Configure OSPF connections, link metrics, and link protection.

user@R1# set traffic-engineering
user@R1# set interface so-0/2/0.0 link-protection
user@R1# set interface so-0/2/0.0 metric 10
user@R1# set interface so-0/2/2.0 link-protection
user@R1# set interface so-0/2/2.0 metric 10
user@R1# set interface t1-0/1/0.0 link-protection
user@R1# set interface t1-0/1/0.0 metric 10
user@R1# set interface t1-0/1/2.0 link-protection
user@R1# set interface t1-0/1/2.0 metric 10
5. (Optional) Configure a specific OSPF topology for voice traffic.

user@R1# set topology voice topology-id 32
[edit routing-options topologies family inet]
user@R1# set topology voice
6. Enable LDP on the interfaces.
[edit protocols ldp]

7. (Optional) Configure per-packet load balancing.
[edit policy-options policy-statement pplb]

user@R1# set then load-balance per-packet
368
[edit routing-options forwarding-table]

user@R1# set export pplb
8. Configure the routing protocol process (rpd) to request an acknowledgement when creating a new
forwarding next hop.
We recommend that the indirect-next-hop-change-acknowledgements statement be configured

when protection mechanisms are being used. This includes MPLS RSVP protection such as fast
reroute (FRR) as well as interior gateway protocol (IGP) loop-free alternate (LFA) link or node
protection.
[edit routing-options forwarding-table]

user@R1# set indirect-next-hop-change-acknowledgements
Results

so-0/2/2 {
unit 0 {
description to-R2;
family inet {
address 192.168.242.1/30;
}
family mpls;
}
}
t1-0/1/2 {
unit 0 {
description to-R2;
family inet {
address 192.168.241.1/30;
}
family mpls;
}
}
t1-0/1/0 {
369
unit 05 {
description to-R4;
family inet {
address 192.168.241.17/30;
}
family mpls;
}
}
so-0/2/0 {
unit 0 {
description to-R4;
family inet {
address 192.168.242.17/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.164.1/32 {
primary;
}
}
}
}

rsvp {
interface all {
link-protection;
}
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path path1 {
backup;
to 10.255.164.3;
}
370
label-switched-path path2 {
backup;
to 10.255.164.3;
}
interface all;
interface fxp0.0 {
disable;
}
}
ospf {
topology voice topology-id 32;
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
link-protection;
metric 10;
}
link-protection;
metric 10;
}
interface t1-0/1/0.0 {
link-protection;
metric 10;
}
interface t1-0/1/2.0 {
link-protection;
metric 10;
}
}
}
ldp {
interface all;
interface fxp0.0 {
disable;
371
}
}
user@R1# show policy-options

policy-statement pplb {
then {
load-balance per-packet;
}
}

forwarding-table {
export pplb;
indirect-next-hop-change-acknowledgements;
}
topologies {
family inet {
topology voice;
}
}
Verification
IN THIS SECTION
Verifying the Routes on Device R1 | 372
Checking the Backup Coverage | 375
Checking the Backup LSPs | 376
Checking the Backup Neighbors | 376
Checking the SPF Calculations | 378

372
Verifying the Routes on Device R1
Purpose
On Device R1, check the OSPF routes in the routing table.
Action
user@R1> show route protocol ospf

10.255.164.2/32 *[OSPF/10] 1d 23:34:00, metric 10

> to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
10.255.164.3/32 *[OSPF/10] 1d 23:34:00, metric 20
> to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
10.255.164.4/32 *[OSPF/10] 1d 23:34:00, metric 10
> to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
10.255.164.5/32 *[OSPF/10] 1d 23:34:00, metric 20
to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
> to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
10.255.164.6/32 *[OSPF/10] 1d 23:34:00, metric 25
to 192.168.242.2 via so-0/2/2.0
> to 192.168.241.2 via t1-0/1/2.0
to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
192.168.241.8/30 *[OSPF/10] 1d 23:34:00, metric 20
> to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
192.168.241.12/30 *[OSPF/10] 1d 23:34:00, metric 30
to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
to 192.168.242.18 via so-0/2/0.0
> to 192.168.241.18 via t1-0/1/0.0
192.168.241.24/30 *[OSPF/10] 1d 23:34:00, metric 30
to 192.168.242.2 via so-0/2/2.0
373
> to 192.168.241.2 via t1-0/1/2.0

192.168.242.4/30 *[OSPF/10] 1d 23:34:00, metric 20
to 192.168.242.2 via so-0/2/2.0
> to 192.168.241.2 via t1-0/1/2.0
192.168.242.8/30 *[OSPF/10] 1d 23:34:00, metric 20
> to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
192.168.242.12/30 *[OSPF/10] 1d 23:34:00, metric 25
to 192.168.242.2 via so-0/2/2.0
> to 192.168.241.2 via t1-0/1/2.0
to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
192.168.242.20/30 *[OSPF/10] 1d 23:34:00, metric 20
> to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
192.168.242.24/30 *[OSPF/10] 1d 23:34:00, metric 25
to 192.168.242.2 via so-0/2/2.0
> to 192.168.241.2 via t1-0/1/2.0
224.0.0.5/32 *[OSPF/10] 1w1d 02:46:58, metric 1
MultiRecv
:voice.inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)

10.255.164.2/32 *[OSPF/10] 1d 23:34:00, metric 10

> to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
10.255.164.3/32 *[OSPF/10] 1d 23:34:00, metric 20
> to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
10.255.164.4/32 *[OSPF/10] 1d 23:34:00, metric 10
to 192.168.242.18 via so-0/2/0.0
> to 192.168.241.18 via t1-0/1/0.0
10.255.164.5/32 *[OSPF/10] 1d 23:34:00, metric 20
to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
> to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
10.255.164.6/32 *[OSPF/10] 1d 23:34:00, metric 25
to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
374
> to 192.168.242.18 via so-0/2/0.0

to 192.168.241.18 via t1-0/1/0.0
192.168.241.8/30 *[OSPF/10] 1d 23:34:00, metric 20
> to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
192.168.241.12/30 *[OSPF/10] 1d 23:34:00, metric 30
> to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
192.168.241.24/30 *[OSPF/10] 1d 23:34:00, metric 30
to 192.168.242.2 via so-0/2/2.0
> to 192.168.241.2 via t1-0/1/2.0
192.168.242.4/30 *[OSPF/10] 1d 23:34:00, metric 20
to 192.168.242.2 via so-0/2/2.0
> to 192.168.241.2 via t1-0/1/2.0
192.168.242.8/30 *[OSPF/10] 1d 23:34:00, metric 20
to 192.168.242.18 via so-0/2/0.0
> to 192.168.241.18 via t1-0/1/0.0
192.168.242.12/30 *[OSPF/10] 1d 23:34:00, metric 25
to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
> to 192.168.242.18 via so-0/2/0.0
to 192.168.241.18 via t1-0/1/0.0
192.168.242.20/30 *[OSPF/10] 1d 23:34:00, metric 20
to 192.168.242.2 via so-0/2/2.0
> to 192.168.241.2 via t1-0/1/2.0
192.168.242.24/30 *[OSPF/10] 1d 23:34:00, metric 25
> to 192.168.242.2 via so-0/2/2.0
to 192.168.241.2 via t1-0/1/2.0
mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Meaning
As expected, Device R1 has multiple potential routes to each destination.

375
Checking the Backup Coverage
Purpose
On Device R1, use the show (ospf | ospf3) backup coverage command to check the level of backup
coverage available for all the nodes and prefixes in the network.
Action
user@R1> show ospf backup coverage
Topology default coverage:
Node Coverage:
Area Covered Total Percent

Nodes Nodes Covered
0.0.0.0 5 5 100.00%
Route Coverage:
Path Type Covered Total Percent

Routes Routes Covered
Intra 17 18 94.44%
Inter 0 0 100.00%
Ext1 0 0 100.00%
Ext2 0 0 100.00%
All 17 18 94.44%
Topology voice coverage:
Node Coverage:

Nodes Nodes Covered
0.0.0.0 5 5 100.00%
Route Coverage:

376
Intra 17 18 94.44%
Inter 0 0 100.00%
Ext1 0 0 100.00%
Ext2 0 0 100.00%
All 17 18 94.44%
Checking the Backup LSPs
Purpose
On Device R1, use the show (ospf | ospf3) backup lsp command to check LSPs designated as backup
routes for OSPF routes.
Action
user@R1> show ospf backup lsp
path1
Egress: 10.255.164.3, Status: up, Last change: 01:13:48
TE-metric: 19, Metric: 0
path2
Checking the Backup Neighbors
Purpose
On Device R1, use the show (ospf | ospf3) backup neighbor command to check the neighbors through
which direct next hops for the backup paths are available.
Action
user@R1> show ospf backup neighbor
Topology default backup neighbors:
Area 0.0.0.0 backup neighbors:

377
10.255.164.4
Neighbor to Self Metric: 10
Self to Neighbor Metric: 10
Direct next-hop: so-0/2/0.0 via 192.168.242.18
Direct next-hop: t1-0/1/0.0 via 192.168.241.18
10.255.164.2
10.255.164.3 (LSP endpoint)

Direct next-hop: path1
Topology voice backup neighbors:
10.255.164.4
10.255.164.2
10.255.164.3 (LSP endpoint)

378
Checking the SPF Calculations
Purpose
On Device R1, use the show (ospf | ospf3) backup spf detail command to check OSPF shortest-path-
first (SPF) calculations for backup paths. To limit the output, the voice topology is specified in the
command.
Action
user@R1> show ospf backup spf detail topology voice
Topology voice results:
Area 0.0.0.0 results:
192.168.241.2
Self to Destination Metric: 10
Parent Node: 10.255.164.1
Primary next-hop: t1-0/1/2.0
Backup next-hop: path1
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Track Item: 10.255.164.2
Eligible, Reason: Contributes backup next-hop
Backup Neighbor: 10.255.164.2
Not evaluated, Reason: Interface is already covered
Track Item: 10.255.164.1
192.168.241.18
Primary next-hop: t1-0/1/0.0
Backup next-hop: so-0/2/0.0 via 192.168.242.18
379

Track Item: 10.255.164.1
Track Item: 10.255.164.2
Track Item: 10.255.164.4
Not eligible, Reason: Path loops
Track Item: 10.255.164.1
192.168.242.2
Primary next-hop: so-0/2/2.0
Backup next-hop: path2
Track Item: 10.255.164.2
Track Item: 10.255.164.1
192.168.242.18
Primary next-hop: so-0/2/0.0
Backup next-hop: t1-0/1/0.0 via 192.168.241.18
380

Track Item: 10.255.164.1
Track Item: 10.255.164.2
Track Item: 10.255.164.4
Track Item: 10.255.164.1
10.255.164.2
Parent Node: 192.168.241.2
Parent Node: 192.168.242.2
Primary next-hop: so-0/2/2.0 via 192.168.242.2
Primary next-hop: t1-0/1/2.0 via 192.168.241.2
Track Item: 10.255.164.2
Not evaluated, Reason: Primary next-hop multipath
Track Item: 10.255.164.1
Track Item: 10.255.164.2
10.255.164.4
Parent Node: 192.168.241.18
Parent Node: 192.168.242.18
381

Track Item: 10.255.164.4
Track Item: 10.255.164.1
Track Item: 10.255.164.4
192.168.241.10
192.168.242.6
382

Track Item: 10.255.164.1
Track Item: 10.255.164.2
192.168.242.10
192.168.242.22
Track Item: 10.255.164.2
383

10.255.164.3
Parent Node: 192.168.242.6
10.255.164.5
Parent Node: 192.168.241.10
Parent Node: 192.168.242.10
Parent Node: 192.168.242.22
384
192.168.242.14
192.168.242.26
10.255.164.6
Parent Node: 192.168.242.14
385
Parent Node: 192.168.242.26

192.168.241.14
192.168.241.26
386

SEE ALSO
Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data
Traffic
Remote LFA over LDP Tunnels in OSPF Networks Overview
In an OSPF network, a loop free alternate (LFA) is a directly connected neighbor that provides
precomputed backup paths to the destinations reachable through the protected link on the point of
local repair (PLR). A remote LFA is not directly connected to the PLR and provides precomputed backup
paths using dynamically created LDP tunnels to the remote LFA node. The PLR uses this remote LFA
backup path when the primary link fails. The primary goal of the remote LFA is to increase backup
coverage for the OSPF networks and provide protection for Layer 1 metro-rings.
LFAs do not provide full backup coverage for OSPF networks. This is a major setback for metro Ethernet
networks that are often shaped as ring topologies. To overcome this setback, Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) backup tunnels are commonly used to extend the backup
coverage. However, a majority of network providers have already implemented LDP as the MPLS tunnel
setup protocol and do not want to implement the RSVP-TE protocol merely for backup coverage. LDP
automatically brings up transport tunnels to all potential destinations in an OSPF network and hence is
the preferred protocol. The existing LDP implemented for the MPLS tunnel setup can be reused for
protection of OSPF networks and subsequent LDP destinations, thereby eliminating the need for RSVP-
TE backup tunnels for backup coverage.
To calculate the remote LFA backup path, the OSPF protocol determines the remote LFA node in the
following manner:
387
1. Calculates the reverse shortest path first from the adjacent router across the protected link of a PLR.
The reverse shortest path first uses the incoming link metric instead of the outgoing link metric to
reach a neighboring node.
The result is a set of links and nodes, which is the shortest path from each leaf node to the root node.
2. Calculates the shortest path first (SPF) on the remaining adjacent routers to find the list of nodes that
can be reached without traversing the link being protected.
The result is another set of links and nodes on the shortest path from the root node to all leaf nodes.
3. Determines the common nodes from the above results. These nodes are the remote LFAs.
OSPF listens to the advertised labels for the LDP routes. For each advertised LDP route, OSPF checks
whether it contains an LDP supplied next hop. If the corresponding OSPF route does have a backup
next hop, then OSPF runs the backup policy and adds an additional tracking route with the
corresponding LDP label-switched path next hop as the backup next hop. If there are no backup next
hops, LDP builds a dynamic LDP tunnel to the remote LFA, and LDP establishes a targeted adjacency
between the remote LFA node and the PLR node. This backup route has two LDP labels. The top label is
the OSPF route, which denotes the backup path from the PLR to the remote LFA route. The bottom
label is the LDP MPLS label-switched path that denotes the route for reaching the ultimate destination
from the remote LFA. When an LDP session goes down and a remote tunnel is no longer available, OSPF
changes all the routes that have been using this backup LDP tunnel.
NOTE: Currently, Junos OS supports only IPv4 transport LSPs. If you need to reuse IPv4
transport LSPs for IPv6 IGP networks, add an IPv6 explicit NULL label to the label stack of the
tracking route. The system automatically converts the IPv4 LSP to an IPv6 LSP.
LDP might be vulnerable by an automatically targeted adjacency, and these threats can be mitigated
using all or some of the following mechanisms:
• Remote LFAs that are several hops away use extended hello messages to indicate willingness to
establish a targeted LDP session. A remote LFA can reduce the threat of spoofed extended hello
messages by filtering them and accepting only those originating at sources permitted by an access or
filter list.
• There is a need to authenticate with TCP-MD5 all auto-targeted LDP sessions in the given IGP/LDP
domain using apply groups or LDP global-level authentication.
• As an added security measure, the repair or remote tunnel endpoint routers should be assigned from
a set of addresses that are not reachable from outside of the routing domain.
388
SEE ALSO
auto-targeted-session
Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network
The primary goal of a remote loop free alternate (LFA) is to increase backup coverage for OSPF routes
and provide protection especially for Layer 1 metro-rings. The existing LDP implemented for the MPLS
tunnel setup can be reused for protection of OSPF networks and subsequent LDP destinations. The
OSPF protocol creates a dynamic LDP tunnel to reach the remote LFA node from the point of local
repair (PLR). The PLR uses this remote LFA backup path when the primary link fails.
Before you configure remote LFA over LDP tunnels in an OSPF network, you must do the following:
1. Enable LDP on the loopback interface.
Configure a loopback interface because an LDP targeted adjacency cannot be formed without a
loopback interface. LDP targeted adjacency is essential for determining remote LFA backup paths.
2. Make sure that remote LFA allows asymmetric remote neighbor discovery—that is, it must send
periodic targeted hello messages to the router that initiated the remote neighbor for LDP auto-
targeted adjacency.
3. Configure link protection or node-link protection on the PLR.
To configure remote LFA backup over LDP tunnels in an OSPF network:
1. Enable remote LFA backup to determine the backup next hop using dynamic LDP label-switched
path.
[edit protocols ospf backup-spf-options]

user@host# set remote-backup-calculation
2. Enable automatically targeted LDP sessions using the loopback addresses between the PLR and the
remote LFA node.

user@host# set auto-targeted-session
389
3. Specify a time interval for which the targeted LDP sessions are kept up even after the remote LFA
node goes down.
[edit protocols ldp auto-targeted-session]

user@host# set teardown-delay seconds
For example, to set a teardown delay value of 60 seconds:

user@host# set teardown-delay 60
4. Specify the maximum number of automatically targeted LDP sessions to optimize memory usage.

user@host# set maximum-sessions number of sessions
For example, to set a maximum sessions allowed to 20:

user@host# set maximum-sessions 20
SEE ALSO
backup-spf-options
Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks
IN THIS SECTION
Requirements | 390
Overview | 390
Configuration | 391
390
Verification | 402
In an OSPF network, a loop free alternate(LFA) is a directly connected neighbor that provides
precomputed backup paths to the destinations reachable via the protected link on the point of local
repair (PLR). A remote LFA is not directly connected to the PLR and provides precomputed backup paths
using dynamically created LDP tunnels to the remote LFA node. The PLR uses this remote LFA backup
path when the primary link fails. The primary goal of the remote LFA is to increase backup coverage for
the OSPF networks and provide protection for Layer 1 metro-rings. This example shows how to
configure remote LFA for LDP tunnels in an OSPF network for extending backup protection.
Requirements
This example uses the following hardware and software components:
• Nine MX Series routers with OSPF protocol and LDP enabled on the connected interfaces.
• Junos OS Release 15.1 or later running on all devices.
Before you configure remote LFA over LDP tunnels in an OSPF networks, make sure of the following:
• LDP is enabled on the loopback interface. Without a loopback interface, LDP targeted adjacency
cannot be formed. Remote LFA cannot be configured without LDP targeted adjacency.
• Remote LFA must allow asymmetric remote neighbor discovery, that is, it must send periodic
targeted hellos to the router that initiated the remote neighbor for LDP auto targeted adjacency.
• Link protection or node-link protection must be configured on the point of local repair (PLR).
Overview
IN THIS SECTION
Topology | 391
The example includes nine routers in a ring topology. Configure the OSPF protocol on the directly
connected interfaces. Device R6 is the PLR. This example verifies that Junos OS updates the routing
table of Device R6 with LDP next-hop routes as the backup route.
391
Topology
In the topology Figure 23 on page 391 shows the remote LFA over LDP tunnels in OSPF networks is
configured on Device R6.
Figure 23: Example Remote LFA over LDP Tunnels
Configuration
IN THIS SECTION
Configuring Device R6 | 398
Results | 400
392
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24

set interfaces ge-0/0/0 unit 0 family mpls
set interfaces lo0 unit 0 family mpls
set routing-options forwarding-table export per-packet
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface lo0.0
set protocols ospf backup-spf-options remote-backup-calculation
set protocols ospf export static
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ldp auto-targeted-session teardown-delay 20
set protocols ldp auto-targeted-session maximum-sessions 60
set protocols ldp egress-policy static
set protocols ldp interface ge-0/0/0.0
set protocols ldp interface lo0.0
set policy-options policy-statement per-packet then load-balance per-packet
set policy-options policy-statement per-packet then accept
set policy-options policy-statement static from protocol static
set policy-options policy-statement static then accept
393
R1

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 link-protection
R2

394

set protocols ospf area 0.0.0.0 interface all
R3

R4

395

R5

396
R6

set protocols ospf topology default backup-spf-options remote-backup-calculation
R7

397

R8

398
Configuring Device R6
Guide.
[edit interfaces]
user@R6# set ge-0/0/0 unit 0 family inet address 60.1.1.2/24
user@R6# set ge-0/0/0 unit 0 family mpls
2. Assign the loopback addresses to the device.
[edit lo0 unit 0 family]

user@R6# set address 7.7.7.7/32
user@R6# set mpls
3. Configure the router ID. Apply the policy to the forwarding table of the local router with the export
statement.
user@R6# set router-id 7.7.7.7
user@R6# set forwarding-table export per-packet
399
4. Enable remote LFA backup which calculates the backup next hop using dynamic LDP label-switched
path.

user@R6# set topology default backup-spf-options remote-backup-calculation
user@R6# set backup-spf-options remote-backup-calculation
5. Configure the traffic engineering and the link protection for the interfaces in the OSPF area.

user@R6# set traffic-engineering
user@R6# set area 0.0.0.0 interface ge-0/0/0.0 link-protection
user@R6# set area 0.0.0.0 interface lo0.0
6. Specify a time interval for which the targeted LDP sessions are kept up when the remote LFA goes
down, and specify a maximum number of automatically, targeted LDP sessions to optimize the use of
memory.

user@R6# set auto-targeted-session teardown-delay 20
user@R6# set auto-targeted-session maximum-sessions 60
7. Configure the LDP protocols on the interfaces.

user@R6# set interface lo0.0
8. Configure the policy options to load balance the per-packet of the policy-statement routing policy.
[edit policy-options policy-statement]

user@R6# set per-packet then load-balance per-packet
user@R6# set per-packet then accept
400
Results

ge-0/0/0 {
unit 0 {
family inet {
address 60.1.1.2/24;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 70.1.1.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 80.1.1.2/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 7.7.7.7/32;
}
family mpls;
401
}
}

ospf {
topology default {
remote-backup-calculation;
}
}
inactive: per-prefix-calculation all;
}
area 0.0.0.0 {
link-protection;
}
link-protection;
}
link-protection;
}
interface lo0.0;
}
}
ldp {
auto-targeted-session {
teardown-delay 20;
maximum-sessions 60;
}
402
interface lo0.0;
}

policy-statement per-packet {
then {
accept;
}
}

router-id 7.7.7.7;
forwarding-table {
export per-packet;
}
If you are done configuring the device, enter commit from the configuration mode.
Verification
IN THIS SECTION
Verifying the Routes | 402
Verifying the LDP Routes | 405
Verifying the OSPF Routes | 406
Verifying the Designated Backup Path Node | 408
Verifying the Backup Neighbors | 409
Verifying the Routes
Purpose
Verify that the expected routes are learned.

403
Action
On Device R6, from operational mode, run the show route 6.6.6.6/24 command to display the routes in
the routing table.
user@R6> show route 6.6.6.6/24

6.6.6.6/32 *[OSPF/10] 02:21:07, metric 1

> to 60.1.1.1 via ge-0/0/0.0
to 80.1.1.1 via ge-0/0/2.0, Push 299872

6.6.6.6/32 *[LDP/9] 02:21:07, metric 1

> to 60.1.1.1 via ge-0/0/0.0
to 80.1.1.1 via ge-0/0/2.0, Push 299792, Push 299872(top)

6.6.6.6/32 (1 entry, 1 announced)
State: <FlashAll>
*OSPF Preference: 10
Next hop type: Router, Next hop index: 1048585
Address: 0x9df2690
Next-hop reference count: 10
Next hop: 60.1.1.1 via ge-0/0/0.0 weight 0x1, selected
Session Id: 0x141
Next hop: 80.1.1.1 via ge-0/0/2.0 weight 0x101 uflags Remote
neighbor path
Label operation: Push 299872
Label TTL action: prop-ttl
Load balance label: Label 299872: None;
Label element ptr: 0x9dc27a0
Label parent element ptr: 0x0
Label element references: 6
Label element child references: 4
Label element lsp id: 0
404
Session Id: 0x142

State: <Active Int>
Age: 2:22:40 Metric: 1
Validation State: unverified
Area: 0.0.0.0
Task: OSPF
Announcement bits (2): 0-KRT 4-LDP
AS path: I
6.6.6.6/32 (1 entry, 1 announced)

State: <FlashAll>
*LDP Preference: 9
Address: 0x9df2a90
Label element ptr: 0x9dc0dc0
Label parent element ptr: 0x0
Session Id: 0x0
Next hop: 80.1.1.1 via ge-0/0/2.0 weight 0x101 uflags Remote
neighbor path
Label operation: Push 299792, Push 299872(top)
Label TTL action: prop-ttl, prop-ttl(top)
Load balance label: Label 299792: None; Label 299872: None;
Label element ptr: 0x9dc1ba0
Label parent element ptr: 0x9dc27a0
Session Id: 0x0
State: <Active Int>
Age: 2:22:40 Metric: 1
Task: LDP
Announcement bits (1): 0-Resolve tree 1
AS path: I
405
Meaning
The output shows all the routes in the routing table of Device R6.
Verifying the LDP Routes
Purpose
Verify the automatically targeted LDP routes.
Action
From operational mode, enter the show ldp session auto-targeted detail command.
user@R6>show ldp session auto-targeted detail
Address: 4.4.4.4, State: Operational, Connection: Open, Hold time: 28

Session ID: 7.7.7.7:0--4.4.4.4:0
Next keepalive in 8 seconds
Active, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Neighbor types: auto-targeted
Keepalive interval: 10, Connect retry interval: 1
Local address: 7.7.7.7, Remote address: 4.4.4.4
Up for 02:28:28
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
4.4.4.4
30.1.1.2
406
40.1.1.1
128.92.25.37
Verifying the OSPF Routes
Purpose
Display all the LDP backup routes in the OSPF routing table of Device R6.
Action
On Device R6, from operational mode, run the show ospf route command to display the routes in the
OSPF routing table.
user@R6> show ospf route

Topology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop

Type Type Type Interface Address/LSP
1.1.1.1 Intra AS BR IP 2 ge-0/0/2.0 80.1.1.1
Bkup LSP LDP->4.4.4.4
2.2.2.2 Intra Router IP 1 ge-0/0/2.0 80.1.1.1
ge-0/0/2.0 80.1.1.1
1.1.1.1/32 Intra Network IP 2 ge-0/0/2.0 80.1.1.1
407
ge-0/0/2.0 80.1.1.1
7.7.7.7/32 Intra Network IP 0 lo0.0
Bkup IP ge-0/0/0.0 60.1.1.1
Bkup IP ge-0/0/2.0 80.1.1.1
60.1.1.0/24 Intra Network IP 1 ge-0/0/0.0
88.88.88.88/32 Ext2 Network IP 0 ge-0/0/2.0 80.1.1.1
ge-0/0/2.0 80.1.1.1
408

Meaning
The output shows all the LDP backup routes in the OSPF routing table of Device R6.
Verifying the Designated Backup Path Node
Purpose
Display the remote LFA next hop determined for a given destination.
Action
From operational mode, enter the show ospf backup spf results command.
user@R6> show ospf backup spf results
Topology default results:
6.6.6.6
Primary next-hop: ge-0/0/0.0 via 60.1.1.1
Backup next-hop: LDP->4.4.4.4 via ge-0/0/2.0
Backup Neighbor: 6.6.6.6 via: Direct
Not eligible, Reason: Primary next-hop link fate sharing
409
Backup Neighbor: 4.4.4.4 via: LDP (LSP endpoint)

Meaning
The output indicates whether a specific interface or node has been designated as a remote backup path
and why.
Verifying the Backup Neighbors
Purpose
Display the backup neighbors for the Device R6
Action
From operational mode, enter the show ospf backup neighbor command.
user@R6>show ospf backup neighbor
6.6.6.6 via: Direct

Direct next-hop: ge-0/0/0.0 via 60.1.1.1
8.8.8.8 via: Direct

2.2.2.2 via: Direct

410
4.4.4.4 via: LDP (LSP endpoint)

Direct next-hop: LDP->4.4.4.4 via ge-0/0/2.0
Direct next-hop: LDP->4.4.4.4 via ge-0/0/0.0
Neighbors Protected: 2
Meaning
The output displays the backup neighbors available for area 0.0.0.0.
SEE ALSO
12 CHAPTER
Configure OSPF Support for Traffic

Engineering
Configuring OSPF Support for Traffic Engineering | 412
How to Configure Flexible Algorithms in OSPF for Segment Routing Traffic

Engineering | 457
412
Configuring OSPF Support for Traffic Engineering
IN THIS SECTION
OSPF Support for Traffic Engineering | 412
Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface | 423
OSPF Passive Traffic Engineering Mode | 426
Advertising Label-Switched Paths into OSPFv2 | 429
Static Adjacency Segment Identifier for OSPF | 450
Understanding Source Packet Routing in Networking (SPRING) | 453
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:
413
• 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 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
414
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 is used for information injected
into the traffic engineering database. Its value does not affect normal OSPF forwarding.
Example: Enabling OSPF Traffic Engineering Support
IN THIS SECTION
Requirements | 414
Overview | 415
Configuration | 415
Verification | 421
This example shows how to enable OSPF traffic engineering support to advertise the label-switched
path (LSP) metric in summary link-state advertisements (LSAs).
Requirements
Before you begin:
• Configure BGP per your network requirements. See the BGP User Guide
• Configure MPLS per your network requirements. See the MPLS Applications User Guide.
415
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.
Configuration
IN THIS SECTION
Procedure | 415
information about navigating the CLI, see Modifying the Junos OS Configuration in theCLI User Guide.
Procedure
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.
416
Configuration on R1:
[edit]
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
[edit]
[edit]
[edit]
To enable OSPF traffic engineering support to advertise LSP metrics in summary LSAs:
417
[edit]
[edit]
[edit]
[edit]
2. Configure the OSPF area and add the interfaces.

418
[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]
[edit]
[edit]
419
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]
[edit]
4. On Device R1, configure MPLS traffic engineering.
[edit ]
user@R1# set protocols mpls traffic-engineering bgp-igp
user@R1# set protocols mpls label-switched-path R1-to-R4 to 10.0.0.4
[edit]
user@host# commit
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
420
Output for R1:
user@host# show routing-options

router-id 10.0.0.1;

traffic-engineering {
shortcuts lsp-metric-into-summary;
}
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:

router-id 10.0.0.2;

area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
421
Output for R3:

router-id 10.0.0.3;

area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
Output for R4:

router-id 10.0.0.4;

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.
Verification
IN THIS SECTION
Verifying the Traffic Engineering Capability for OSPF | 422

422
Verifying OSPF Entries in the Traffic Engineering Database | 422
Verifying That the Traffic Engineering Database Is Learning Node Information from OSPF | 422
Verifying the Traffic Engineering Capability for OSPF
Purpose
Verify that traffic engineering has been enabled for OSPF. By default, traffic engineering is disabled.
Action
overview for OSPFv3.
Verifying OSPF Entries in the Traffic Engineering Database
Purpose
Verify the OSPF information in the traffic engineering database. The Protocol field displays OSPF and
the area from which the information was learned.
Action
From operational mode, enter the show ted database command.
Verifying That the Traffic Engineering Database Is Learning Node Information from OSPF
Purpose
Verify that OSPF is reporting node information. The Protocol name field displays OSPF and the area
from which the information was learned.
Action
From operational mode, enter the show ted protocol command.

423
Example: Configuring the Traffic Engineering Metric for a Specific OSPF

Interface
IN THIS SECTION
Requirements | 423
Overview | 423
Configuration | 423
Verification | 425
This example shows how to configure the OSPF metric value used for traffic engineering.
Requirements
Before you begin:
• Configure OSPF for traffic engineering. See Example: Enabling OSPF Traffic Engineering Support
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.
Configuration
IN THIS SECTION
Procedure | 424
424
To quickly configure the OSPF traffic engineering metric for a specific interface, copy the following
commands, paste them into a text file, remove any line breaks, change any details necessary to match
your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and
then enter commit from configuration mode.
[edit]
set protocols ospf area 0.0.0.0 interface fe-0/1/1 te-metric 10
Procedure
To configure an OSPF traffic engineering metric for a specific interface used only for traffic engineering:
[edit]
2. Configure the traffic engineering metric of the OSPF network segments.

user@host set interface fe-0/1/1 te-metric 10

user@host# commit
425
Results

area 0.0.0.0 {
te-metric 10;
}
}
Verification
IN THIS SECTION
Verifying the Configured Traffic Engineering Metric | 425
Verifying the Configured Traffic Engineering Metric
Purpose
Verify the traffic engineering metric value. Confirm that Metric field displays the configured traffic
engineering metric.
Action
From operational mode, enter the show ted database extensive command.
426
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
IN THIS SECTION
Requirements | 426
Overview | 427
Configuration | 427
Verification | 429
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.
Requirements
Before you begin:
• Configure BGP per your network requirements. See the BGP User Guide.
• Configure the LSP per your network requirements. See the MPLS Applications User Guide.
427
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
IN THIS SECTION
Procedure | 428
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
428
Procedure
To configure OSPF passive traffic engineering mode:
[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.

user@host# set interface so-1/1/0 passive traffic-engineering remote-node-id 192.168.207.2

user@host# commit
Results

area 0.0.0.1 {
passive {
remote-node-id 192.168.207.2;
}
}
429
}
}
Verification
IN THIS SECTION
Verifying the Status of OSPF Interfaces | 429
Verifying the Status of OSPF Interfaces
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
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.
430
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
IN THIS SECTION
Requirements | 430
Overview | 430
Configuration | 432
Verification | 449
This example shows how to advertise LSPs into OSPFv2.
Requirements
Before you begin, configure the device interfaces. See the Junos OS Network Interfaces Library for
Routing Devices.
Overview
IN THIS SECTION
Topology | 431
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 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:
431
• 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.
Topology
Figure 24 on page 432 shows a sample network topology that consists of the following:
• 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.
432
• 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 24: Advertising an LSP into OSPFv2
Configuration
IN THIS SECTION
Configuring BGP | 433
Configuring MPLS | 436
Configuring RSVP | 441
Configuring OSPF | 443
Configuring the LSP | 447
Advertising the LSP into OSPFv2 | 448

433
The following examples require you to navigate various levels in the configuration hierarchy. For
To configure the devices to advertise an LSP into OSPFv2, perform the following tasks:
Configuring BGP
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
set protocols bgp group internal-peers peer-as 65000
[edit]
[edit]
434

To configure BGP:
1. On each routing device, configure the local AS number.
[edit]
user@R1# set routing-options autonomous-system 65000
[edit]
[edit]
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 peer-as 65000
[edit]
435

[edit]
[edit]
user@host# commit
Results
Confirm your configuration by entering the show routing-options and show protocols bgp commands. If

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;
}
436


type internal;
peer-as 65000;
neighbor 10.0.0.1;
neighbor 10.0.0.6;
}


type internal;
peer-as 65000;
neighbor 10.0.0.1;
neighbor 10.0.0.3;
}
Configuring MPLS
To quickly configure MPLS on all of the routing devices in AS 65000, copy the following commands and
paste them into the CLI.
437
[edit]
[edit]
[edit]
To configure MPLS:
438
1. Configure the transit interfaces for MPLS.
[edit ]
user@R1# set interfaces so-0/0/2 unit 0 family mpls
[edit ]
[edit ]
2. Enable MPLS.
[edit ]
user@R1# set protocols mpls interface all
[edit ]
[edit ]
439
3. Disable MPLS on the management interface (fxp0.0).
[edit ]
user@R1# set protocols mpls interface fxp0.0 disable
[edit ]
[edit ]
[edit]
user@host# commit
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.

so-0/0/2 {
unit 0 {
family mpls;
}
}
user@R1# show protocols mpls

interface all;
interface fxp0.0 {
440
disable;
}

so-0/0/2 {
unit 0 {
family mpls;
}
}
so-0/0/3 {
unit 0 {
family mpls;
}
}

interface all;
interface fxp0.0 {
disable;
}

so-0/0/3 {
unit 0 {
family mpls;
}
}

interface all;
interface fxp0.0 {
disable;
}
441
Configuring RSVP
To quickly configure RSVP on all of the routing devices in AS 65000, copy the following commands and
[edit]
set protocols rsvp interface so-0/0/2
[edit]
[edit]
To configure RSVP:
442
1. Enable RSVP.
[edit ]
user@R1# set protocols rsvp interface so-0/0/2
[edit ]
[edit ]
2. Disable RSVP on the management interface (fxp0.0).
[edit ]
user@R1# set protocols rsvp interface fxp0.0 disable
[edit ]
[edit ]
[edit]
user@host# commit
Results
Confirm your configuration by entering the show protocols rsvp command. If the output does not
443
user@R1# show protocols rsvp

interface fxp0.0 {
disable;
}

interface fxp0.0 {
disable;
}

interface fxp0.0 {
disable;
}
Configuring OSPF
To quickly configure OSPF, copy the following commands and paste them into the CLI.
[edit]
444
[edit]
[edit]
To configure OSPF:
[edit]
[edit]
[edit]
445
2. Configure the OSPF area and the interfaces.
[edit]
[edit]
[edit]
3. Disable OSPF on the management interface (fxp0.0).
[edit]
[edit]
[edit]
[edit ]
user@host# commit
Results
446

router-id 10.0.0.1;

area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}

router-id 10.0.0.3;

area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}

router-id 10.0.0.6;

area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
447
}
}
Configuring the LSP
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.

user@R1# set label-switched-path R1-to-R6 to 10.0.0.6
[edit ]
user@R1# commit
448
Results
Confirm your configuration by entering the show protocols mpls command. If the output does not

to 10.0.0.6;
}
Advertising the LSP into OSPFv2
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:
[edit]
user@R1# edit protocols ospf
2. Include the label-switched-path statement, and specify the LSP R1-to-R6 that you created.

user@R1# set area 0.0.0.0 label-switched-path R1-to-R6
449
3. (Optional) Specify a metric for the LSP.

user@R1# set protocols ospf area 0.0.0.0 label-switched-path R1-to-R6 metric 2
[edit]
user@R1# commit
Results

area 0.0.0.0 {
metric 2;
}
}
Verification
IN THIS SECTION
Verifying the OSPF Neighbor | 450

450
Verifying the OSPF Neighbor
Purpose
Verify that another neighbor is listed and is reachable over the LSP. The interface field indicates the
name of the LSP.
Action
From operational mode, enter the show ospf neighbor command.
Static Adjacency Segment Identifier for OSPF
Adjacency segment is a strict forwarded single-hop tunnel that carries packets over a specific link
between two nodes, irrespective of the link cost. You can configure static adjacency segment identifier
(SID) labels for an interface.
Configuring a static adjacency SID on an interface causes the existing dynamically allocated adjacency
SID to be removed along with the transit route for the same.
For static adjacency SIDs, the labels are picked from either a static reserved label pool or from an OSPF
segment routing global block (SRGB).
You can reserve a label range to be used for static allocation of labels using the following configuration:
user@host# set protocols mpls label-range static-label-range start-value end-value
The static pool can be used by any protocol to allocate a label in this range. You need to ensure that no
two protocols use the same static label. OSPF adjacency SIDs can be allocated from this label block
through the configuration using keyword label. The label value for the specific adjacency SIDs need to
be explicitly configured. The following is a sample configuration:
user@host# set protocols mpls label-range static-label-range 700000 799999;

user@host# set protocols ospf source-packet-routing srgb start-label 800000 index-range 4000;
user@host# set protocols ospf area0 interface ge-0/0/0.1 ipv4-adjacency-segment unprotected label
700001;
451
NOTE: When you use ipv4-adjacency-segment command, the underlying interface must be
point-to-point.
SRGB is a global label space that is allocated for the protocol based on configuration. The labels in the
entire SRGB is available for OSPF to use and are not allocated to other applications/protocols. Prefix
SIDs (and Node SIDs) are indexed from this SRGB.
OSPF Adj-SIDs can be allocated from OSPF SRGB using keyword ‘index’ in the configuration. In such
cases, it should be ensured that the Adj-SID index does not conflict with any other prefix SID in the
domain. Like Prefix-SIDs, Adj-SIDs will also be configured by mentioning the index with respect to the
SRGB. However, the Adj-SID subtlv will still have the SID as a value and the L and V flags are set. The
following is a sample configuration:
user@host# set protocols ospf area0 interface ge-0/0/0.1 ipv4-adjacency-segment unprotected index 1;
Static adjacency SIDs can be configured per area and also based on whether the protection is required
or not. Adjacency SIDs should be configured per interface at the [edit protocols ospf area area interface
• Protected—Ensures adjacency SID is eligible to have a backup path and a B-flag is set in an adjacency
SID advertisement.
• Unprotected—Ensures no backup path is calculated for a specific adjacency SID and a B-flag is not
set in an adjacency SID advertisement.
The following is a sample configuration:
user@host# set protocols ospf area0 interface ge-0/0/0.1 ipv4-adjacency-segment unprotected index 1;
user@host# set protocols ospf area0 interface ge-0/0/1.1 ipv4-adjacency-segment protected index 2;
When segment routing is used in LAN subnetworks, each router in the LAN may advertise the adjacency
SID of each of its neighbors. To configure adjacency SID for a LAN interface to a specific neighbor, you
should configure the adjacency SIDs under the lan-neighbor configuration at the [edit protocols ospf
area0 interface interface_name lan-neighbor neighbor-routerid] hierarchy level. The following is a
sample configuration:
user@host# set protocols mpls label-range static-label-range 700000 799999;

452
user@host# set protocols ospf area0 interface ge-1/0/0.1 lan-neighbor 11.12.1.2 ipv4-adjacency-segment
unprotected label 700001;
Use the following CLI hierarchy for configuring adjacency SID:
[edit ]
protocols {
ospf {
area0 {
interface <interface_name> {
ipv4-adjacency-segment {
protected {
dynamic;
label <value>
index <index>
}
unprotected {
dynamic;
label <value>
index <index>
}
}
}
interface <interface_name> {
lan-neighbor <neighbor-routerid>{
ipv4-adjacency-segment {
protected {
dynamic;
label <value>
index <index>
}
unprotected {
dynamic;
label <value>
index <index>
}
}
}
}
}
453
}
}
Use the following operational CLI commands to verify the configuration:
show ospf neighbor detail
The following sample output displays the details of configured and dynamic adjacency SID.
user@host> show ospf neighbor detail

Address Interface State ID Pri Dead
11.12.1.2 ge-1/0/0.0 Full 12.1.1.1 128 34
Area 0.0.0.0, opt 0x52, DR 0.0.0.0, BDR 0.0.0.0
Up 00:06:27, adjacent 00:06:27
SPRING Adjacency Labels:
Label Flags Adj-Sid-Type
90010 BVLP Protected
1212 VLP UnProtected

[email protected]# run show route label 90010

90010 *[L-OSPF/10/5] 00:00:21, metric 0

> to 11.12.1.2 via ge-1/0/0.0, Pop
to 11.12.2.2 via ge-1/0/2.0, Swap 16021
to 11.12.3.2 via ge-1/0/3.0, Swap 16021
Understanding Source Packet Routing in Networking (SPRING)
Source packet routing or segment routing is a control-plane architecture that enables an ingress router
to steer a packet through a specific set of nodes and links in the network without relying on the
intermediate nodes in the network to determine the actual path it should take. In this context, the
term ’source’ means ’the point at which the explicit route is imposed’. Starting with Junos OS Release
17.2R1, segment routing for IS-IS and OSPFv2 is supported on QFX5100 and QFX10000 switches.
454
Starting with Junos OS Release 17.3R1, segment routing for IS-IS and OSPFv2 is supported on
QFX5110 and QFX5200 switches.
Starting in Junos OS Release 20.3R1, Segment routing support for OSPF and IS-IS protocols to provide
basic functionality with Source Packet Routing in Networking (SPRING).
Essentially segment routing engages IGPs like IS-IS and OSPF for advertising two types of network
segments or tunnels:
• First, a strict forwarded single-hop tunnel that carries packets over a specific link between two
nodes, irrespective of the link cost, referred to as adjacency segments.
• Second, a multihop tunnel using shortest path links between two specific nodes, referred to as node
segments.
Ingress routers can steer a packet through a desired set of nodes and links by pre-appending the packet
with an appropriate combination of tunnels.
Segment routing leverages the source routing paradigm. A node steers a packet through an ordered list
of instructions, called segments. A segment can represent any instruction, topological or service-based.
A segment can have a local semantic to a segment routing node or to a global node within a segment
routing domain. Segment routing enforces a flow through any topological path and service chain while
maintaining per-flow state only at the ingress node to the segment routing domain. Segment routing can
be directly applied to the MPLS architecture with no change on the forwarding plane. A segment is
encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to
process is on the top of the stack. Upon completion of a segment, the related label is popped from the
stack. Segment routing can be applied to the IPv6 architecture, with a new type of routing extension
header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered
list of IPv6 addresses in the routing extension header. The segment to process is indicated by a pointer
in the routing extension header. Upon completion of a segment, the pointer is incremented.
Traffic engineering shortcuts are enabled for labeled IS-IS segment routes, when you configure shortcuts
at the following hierarchy levels:
• [edit protocols is-is traffic-engineering family inet] for IPv4 traffic.
• [edit protocols is-is traffic-engineering family inet6] for IPv6 traffic.
When source packet routing is deployed in the network, the data center, backbone, and peering devices,
switch MPLS packets with a label stack built by the source of the traffic; for example, data center
servers. In Junos OS Release 17.4R1, the source-routed traffic co-exists with traffic taking RSVP
signaled paths, and source routing is implemented as regular label switching through mpls.0 table using
the label operations – pop, swap (to the same label value), and swap-push (for interface protection). In all
the cases, traffic can be load balanced between multiple Layer 3 interfaces, or within an aggregate
interface. Starting in Junos OS Release 17.4R1, the traffic statistics in a segment routing network can be
recorded in an OpenConfig compliant format for the Layer 3 interfaces. The statistics is recorded for the
455
Source Packet Routing in Networking (SPRING) traffic only, excluding RSVP and LDP-signaled traffic,
and the family MPLS statistics per interface is accounted for separately. The SR statistics also includes
SPRING traffic statistics per link aggregation group (LAG) member, and per segment identifier (SID). To
enable recording of segment routing statistics, include sensor-based-stats statement at the [edit
protocol isis source-packet-routing] hierarchy level.
Prior to Junos OS Release 19.1R1, sensors were available for collecting segment routing statistics for
MPLS transit traffic only, which is MPLS-to-MPLS in nature. Starting in Junos OS Release 19.1R1, on MX
Series routers with MPC and MIC interfaces and PTX Series routers, additional sensors are introduced to
collect segment routing statistics for MPLS ingress traffic, which is IP-to-MPLS in nature. With this
feature, you can enable sensors for label IS-IS segment routing traffic only, and stream the statistics to a
gRPC client.
You can enable the segment routing statistics for MPLS ingress traffic using the egress option under the
per-sid configuration statement. The resource name for the per-sid egress functionality is:
/junos/services/segment-routing/sid/egress/usage/
You can view the label IS-IS route association with the sensors using the show isis spring sensor info
command output. This command does not display counter values of the actual sensors.
The segment routing statistics records are exported to a server. You can view segment routing statistics
data from the following the OpenConfig paths:
• /mpls/signalling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-counter[ip-
addr='L-ISIS-1.1.1.1']/state/counters[name='oc-xxx']/out-pkts
• /mpls/signalling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-counter[ip-
addr='L-ISIS-1.1.1.1']/state/counters[name='oc-xxx']/out-pkts
NOTE:
• Graceful Routing Engine switchover (GRES) is not supported for segment routing statistics.
Nonstop active routing (NSR) is not supported for label IS-IS. During a Routing Engine
switchover, a new sensor is created in the new primary Routing Engine, replacing the sensor
created by the previous primary Routing Engine. As a result, at the time of a Routing Engine
switchover, the segment routing statistics counter start from zero.
• Graceful restart is not support for label IS-IS.
In case of graceful restart, the existing sensor is deleted and a new sensor is created during
IS-IS initialization. The segment routing statistics counter restarts from zero.
456
• In-service software upgrade (ISSU) and nonstop software upgrade (NSSU) are not supported.
In such cases, the segment routing statistics counter is restarted.
• Zero-statistics segment routing data is suppresses and does not get streamed to the gRPC
clients.
SEE ALSO
IS-IS Extensions to Support Traffic Engineering

Understanding Forwarding Adjacencies
Understanding LDP-IGP Synchronization
no-advertise-adjacency-segment (Protocols OSPF)
no-source-packet-routing (Protocols OSPF)
sensor-based-stats
sensor (Junos Telemetry Interface)
sensor-based-stats (Junos Telemetry Interface)
show (ospf | ospf3) overview
show (ospf | ospf3) neighbor
show ospf database
show (ospf | ospf3) route
show route table
level (Global IS-IS)
show isis database
show isis overview
show isis route
show isis adjacency
source-packet-routing (Protocols IS-IS)
no-advertise-adjacency-segment (Protocols IS-IS)
Release History Table
Release Description
20.3R1 Starting in Junos OS Release 20.3R1, Segment routing support for OSPF and IS-IS protocols to provide
basic functionality with Source Packet Routing in Networking (SPRING).
457
19.1R1 Starting in Junos OS Release 19.1R1, on MX Series routers with MPC and MIC interfaces and PTX Series
routers, additional sensors are introduced to collect segment routing statistics for MPLS ingress traffic,
which is IP-to-MPLS in nature. With this feature, you can enable sensors for label IS-IS segment routing
traffic only, and stream the statistics to a gRPC client.
17.4R1 Starting in Junos OS Release 17.4R1, the traffic statistics in a segment routing network can be recorded
in an OpenConfig compliant format for the Layer 3 interfaces.
17.3R1 Starting with Junos OS Release 17.3R1, segment routing for IS-IS and OSPFv2 is supported on
17.2R1 Starting with Junos OS Release 17.2R1, segment routing for IS-IS and OSPFv2 is supported on
MPLS Applications User Guide
How to Configure Flexible Algorithms in OSPF for

Segment Routing Traffic Engineering
SUMMARY IN THIS SECTION
A flexible algorithm allows IGPs alone to compute Understanding OSPF Flexible Algorithm for
constraint based paths over the network thereby Segment Routing | 458
providing simple traffic engineering without using a Example: OSPF Flexible Algorithm | 467
network controller. This is a light weight solution for
networks that have not implemented a controller | 497
with full fledged segment routing but still want to | 497
reap the benefits of segment routing in their
network. | 497
WHAT'S NEXT
For more information on configuring flexible algorithms, see the OSPF User Guide
458
Understanding OSPF Flexible Algorithm for Segment Routing
IN THIS SECTION
Benefits of Configuring Flexible Algorithm | 458
What is Flexible Algorithm Definition (FAD)? | 459
Participation in a Flexible Algorithm | 460
Network Topology Configured with Flexible Algorithm Definitions | 460
Flexible Algorithm RIBs | 465
BGP Community and Flexible Algorithms | 465
Supported and Unsupported Features | 466
Starting in Junos OS Release 21.1R1, you can thin slice a network by defining flexible algorithms that
compute paths using different parameters and link constraints based on your requirements. For example,
you can define a flexible algorithm that computes a path to minimize IGP metric and define another
flexible algorithm to compute a path based on traffic engineering metric to divide the network into
separate planes. This feature allows networks without a controller to configure traffic engineering using
segment routing without actually implementing a network controller. You can use the prefix SIDs to
steer packets along the constraint-based paths. You can configure the prefix SIDs for flexible algorithm
through policy configurations.
IGP protocols use a link metric to calculate a best path. However, the best IGP path might not always be
the best path for certain types of traffic. Therefore, the IGP computed best path based on the shortest
IGP metric is often replaced with traffic engineered path due to the traffic requirements that are not
reflected by the IGP metric. Typically RSVP-TE or SR TE is used for computing the path based on
additional metrics and constraints to overcome this limitation. Junos installs such paths in the
forwarding tables in addition to or as a replacement for the original path computed by the IGPs.
Benefits of Configuring Flexible Algorithm
• A lightweight version of segment routing traffic engineering that can be used in the core of the
network.
• Allows you to configure traffic engineering using segment routing even without installing a network
controller.
• Utilize equal-cost multipath (ECMP) and TI-LFA per-slice without configuring BGP-LS or static path.
459
• Compute TI-LFA backup path using the same flexible algorithm definition and constraints
computation.
• Take advantage of segment routing traffic engineering using only OSPFv2 without configuring RSVP
or LDP.
• Ability to provision constrained primary path based on a single label.
What is Flexible Algorithm Definition (FAD)?
A flexible algorithm allows IGP to calculate additional best paths based on specified constraints thereby
providing simple traffic engineering without using a network controller. This is a lightweight solution for
networks that have not implemented a controller with full fledged segment routing but still want to reap
the benefits of segment routing in their network. Every operator can define separate constraints or
colors depending on their requirements.
To define a flexible algorithm, include flex-algorithm id statement at the [edit routing-options] hierarchy
level. The flexible algorithm definition (FAD) is assigned with an identifier ranging from 128 through 255.
This flexible algorithm can be defined on one or more routers in a network. A flexible algorithm
computes a best path based on the following parameters:
• Calculation type—SPF or strict SPF are the two available calculation type options. You can specify
one of these calculation types in your FAD. Select the SPF calculation type if you want to influence
the SPF computation on your device based on a certain local policy such as traffic engineering
shortcuts. If you select strict SPF then the local policy cannot influence the SPF path selection.
• Metric type- IGP metric or TE metric are the available metric type options. You can specify one of
these metric types in your FAD depending on your network requirement. If you do not want to use
the IGP metric for a specific link you can configure a TE metric that OSPFv2 can use for calculating
the route.
• Priority- You can assign a priority to your FADs as per your requirement and OSPFv2 prioritizes a
particular FAD advertisement over another FAD based on your assigned priority.
• Set of Link constraints- You can configure admin-groups for many protocols at the [edit protocols
mpls admin-groups] hierarchy level to color an individual link. These admin-groups can then be
defined as include any, include-all or exclude at the [edit routing-options flex-algorithm definition
admin-groups] hierarchy level.
We recommend configuring flexible algorithm on only a few routers to provide redundancy and to avoid
conflicts. Flexible algorithm definition is advertised in IGP as FAD sub-TLVs. In very large networks, we
do not recommend configuring more than 8 flexible algorithm definitions as each flexible algorithm will
compute its own path and might cause performance issues beyond that.
The default FAD has the following parameters:

460
• calculation type: spf
• metric type: igp-metric
• priority: 0
• Link constraints: none
NOTE: Modifying the flexible algorithm definition in a live network or on the fly could cause
traffic disruptions until all the nodes converge on the new paths.
Participation in a Flexible Algorithm
You can configure specific routers to participate in a particular flexible algorithm as per your
requirement. Paths computed based on a flexible algorithm definition is used by various applications
each potentially using its own specific data plane for forwarding the data over such paths. The
participating device must explicitly advertise its participation in a particular flexible algorithm to every
application in the segment routing flexible algorithm sub TLV for OSPFv2. You can configure a node to
participate in a certain flexible algorithm provided it can support the constraints specified in that FAD.
To configure participation in a flexible algorithm include the flex-algorithm statement at the [edit
protocols isis source-packet- routing] hierarchy level. The same device can advertise a FAD and also
participate in a flexible algorithm.
Network Topology Configured with Flexible Algorithm Definitions
Figure 25 on page 461 shows the sample topology, there are 8 routers R0, R1, R2, R3, R4, R5, R6, and
R7. Four flexible algorithms, 128, 129, 130, and 135 are defined and configured with admin-groups as
listed in the following table:
Flex Algorithm Definition (FAD) Color
128 Include any Red
129 Include any Green
130 Include any Green and Blue

461
(Continued)
Flex Algorithm Definition (FAD) Color
135 Exclude Red
Figure 25: Flexible Algorithm Topology

462
Figure 26 on page 462 shows how FAD 128 routes traffic on any interface that is configured with admin
group red.
Figure 26: Traffic Flow for Flexible Algorithm Definition 128

463
group green.

464
group green and blue.
Figure 28: Traffic flow for Flexible Algorithm Definition 130

465
Figure 29 on page 465 shows how FAD 135 routes traffic on any interface that is not configured with
admin group red.
Flexible Algorithm RIBs
For every flexible algorithm that a router participates in the corresponding flexible algorithm routes are
installed in the corresponding flexible algorithm RIB groups also known as routing tables. By default,
labeled OSPFv2 flexible algorithm routes are installed in the inet.color, inet(6)color.0 and mpls.0 RIBs.
BGP Community and Flexible Algorithms
A flexible algorithm can have an associated BGP color community to resolve routes of other services
such as VPN service. By default, the associated BGP color community is the same as the flexible
algorithm ID. The flexible algorithm ingress routes that are installed in the inet(6)color.0 tables will have
this color community in the route. However, you can configure a different BGP color community at the
[edit routing-options flex-algorithm id color desired color community value] hierarchy level.
466
NOTE: Changing the BGP color community for a flexible algorithm might result in traffic
disruption. If you modify a BGP color community for a flexible algorithm then all routes
pertaining to that flexible algorithm are removed from the RIB and added again with new colors.
Supported and Unsupported Features
Junos OS supports flexible algorithms in the following scenarios:
• Support for configuring and advertising prefix SIDs for different flexible algorithms.
• Partially supports Internet Draft draft-ietf-lsr-flex-algo-05.txt IGP Flexible Algorithm
• The current implementation for flexible algorithms is supported for only OSPFv2 only as only
OSPFv2 supports segment routing.
Junos OS does not support the following features in conjunction with flexible algorithms:
• Link delay metric is not supported.
• Flexible algorithm is applicable only for default unicast topology, OSPFv2 multi-topology is not
supported.
• OSPFv2 shortcuts and other OSPFv2 traffic engineering configuration options are not applicable for
flexible algorithm computation. .
• The current implementation for flexible algorithms is not supported for OSPFv3.
• Inter-area (OSPFv2) leaking of flexible algorithm prefix SIDs is not supported.
• Prefix and SID conflict resolution is not supported.
• Remote loop free alternate functionality is not supported because TI-LFA is the preferred FRR
computation.
• Advertising flexible algorithm definition in the absence of flexible algorithm participation is not
supported.
• Advertisement of link attributes for flex algorithm using the Application-Specific Link attribute
(ASLA) advertisements is not supported.
• Transport class RIB is not supported.

467
SEE ALSO

show ospf flex-algorithm | 0
Example: OSPF Flexible Algorithm
IN THIS SECTION
Overview | 467
Requirements | 468
Configuration | 468
Verification | 489
Overview
IN THIS SECTION
Topology | 468
This example shows how to configure flexible algorithm in an OSPFv2 network. The flexible algorithm
allows networks without a controller to configure traffic engineering using segment routing without
actually implementing a network controller.
Starting in Junos OS Release 21.1R1, you can thin-slice a network by defining flexible algorithms that
compute paths using different parameters and link constraints based on your requirements. The set
consisting of calculation-type, metric-type, and a set of constraints is referred to as a flexible algorithm
definition (FAD). You can define FADs and advertise the same in an OSPFv2 network. A device can also
be configured to participate in a certain flexible algorithm provided it supports the constraints for that
specific FAD.
468
Topology
Figure 6 shows a flexible algorithm topology in which there are 6 devices R0, R1, R2, R3, R4, and R5.
Two flexible algorithms 128 and 129 are defined on each of these devices. The admin-groups red, blue,
and green are configured on the devices. The FADs with different parameters such as metric-types,
calculation-types, and link constraints are defined on each of the devices.
Figure 30: Flexible Algorithm Topology
Requirements
• Six MX Series routers.
• Junos OS Release 21.1R1 or later running on all devices.
Configuration
IN THIS SECTION

469
Results | 485
Device R0
set interfaces ge-0/0/0 description R0_to_R1_1

set policy-options policy-statement ex-bgp term 1 from route-filter 10.1.1.0/24 exact
set policy-options policy-statement ex-bgp term 1 then community add blue
set policy-options policy-statement ex-bgp term 1 then accept
set policy-options policy-statement ex-bgp term 0 from route-filter 10.1.0.0/24 exact
set policy-options policy-statement ex-bgp term 0 then community add red
set policy-options policy-statement ex-bgp term 0 then accept
set policy-options policy-statement prefix-sid term 1001 from route-filter 192.168.255.10/32 exact
set policy-options policy-statement prefix-sid term 1001 then prefix-segment algorithm 128 index 1280
set policy-options policy-statement prefix-sid term 1001 then prefix-segment algorithm 128 node-segment
set policy-options policy-statement prefix-sid term 1001 then prefix-segment index 1000
470
set policy-options policy-statement prefix-sid term 1001 then prefix-segment node-segment

set policy-options policy-statement prefix-sid term 1001 then accept
set policy-options community blue members color:1:129
set policy-options community red members color:0:128
set protocols bgp group to-R5 type internal
set protocols bgp group to-R5 family inet segment-routing-te
set protocols bgp group to-R5 family inet unicast extended-nexthop-color
set protocols bgp group to-R5 export ex-bgp
set protocols bgp group to-R5 local-as 65000
set protocols bgp group to-R5 neighbor 192.168.255.15
set protocols mpls admin-groups RED 0
set protocols mpls admin-groups BLUE 1
set protocols mpls admin-groups GREEN 2
set protocols mpls label-range static-label-range 1000 8000
set protocols mpls interface ge-0/0/0.0 admin-group RED
set protocols mpls interface ge-0/0/1.0 admin-group GREEN
set protocols mpls interface ge-0/0/1.0 admin-group BLUE
set protocols ospf backup-spf-options use-post-convergence-lfa maximum-labels 5
set protocols ospf backup-spf-options use-source-packet-routing
set protocols ospf traffic-engineering advertisement always
set protocols ospf source-packet-routing prefix-segment prefix-sid
set protocols ospf source-packet-routing srgb start-label 80000
set protocols ospf source-packet-routing srgb index-range 5000
set protocols ospf source-packet-routing flex-algorithm 128
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 post-convergence-lfa node-protection
set routing-options flex-algorithm 128 definition metric-type igp-metric
set routing-options flex-algorithm 128 definition spf
set routing-options flex-algorithm 128 definition admin-group include-any RED
set routing-options flex-algorithm 129 definition metric-type igp-metric
set routing-options flex-algorithm 129 definition spf
set routing-options flex-algorithm 129 definition admin-group include-all BLUE
471

set routing-options static route 10.1.1.0/24 receive
set routing-options static route 10.1.0.0/24 receive
Device R1

set interfaces ge-0/0/4 description R1_to_R3
472

Device R2

473

474

Device R3

475

Device R4

476

477

Device R5
set chassis network-services enhanced-ip

set protocols bgp group to-R1 type internal
478
set protocols bgp group to-R1 family inet segment-routing-te

set protocols bgp group to-R1 family inet unicast extended-nexthop-color
set protocols bgp group to-R1 local-as 65000
set protocols bgp group to-R1 neighbor 192.168.255.10
set routing-options static route 10.1.15.0/24 reject
To configure flexible algorithm for OSPFv2, perform the following steps on the device R0:
479
1. Configure the device interfaces to enable IP transport.
[edit]
user@R0set interfaces ge-0/0/0 description R0_to_R1_1
user@R0set interfaces ge-0/0/0 unit 0 family inet address 10.10.1.1/30
user@R0set interfaces ge-0/0/0 unit 0 family mpls
2. Configure the loopback interface (lo0) address that is used as router ID for OSPF sessions.
[edit]
user@R0set interfaces lo0 unit 0 family inet address 192.168.255.10/32
3. Configure the router ID and autonomous system (AS) number to propagate routing information
within a set of routing devices that belong to the same AS.
[edit]
user@R0set routing-options router-id 192.168.255.10
user@R0set routing-options autonomous-system 65000
4. Define a policy to load balance packets and apply the per-packet policy to enable load balancing of
traffic.
[edit]
480
user@R0set policy-options policy-statement pplb then load-balance per-packet

user@R0set routing-options forwarding-table export pplb
5. Configure the route filter for the routing policy term that enables the Device R0 to reach the
192.168.255.10/32 network.
[edit]
user@R0set policy-options policy-statement prefix-sid term 1001 from route-filter 192.168.255.10/32
exact
6. Advertise prefix segments through policy configuration.
[edit]
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment algorithm 128
index 1280
node-segment
index 1290
node-segment
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment index 1000
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment node-segment
user@R0set policy-options policy-statement prefix-sid term 1001 then accept
7. Configure BGP between R0 and R5 that advertises routes 10.1.0.0/24 and 10.1.1.0/24 to use the
algorithms. 10.1.0.0/24 uses algorithm 128 and 10.1.1.0/24 uses algorithm 129.
[edit]
user@R0set policy-options policy-statement ex-bgp term 1 from route-filter 10.1.1.0/24 exact
user@R0set policy-options policy-statement ex-bgp term 1 then community add blue
user@R0set policy-options policy-statement ex-bgp term 1 then accept
user@R0set policy-options policy-statement ex-bgp term 0 from route-filter 10.1.0.0/24 exact
user@R0set policy-options policy-statement ex-bgp term 0 then community add red
user@R0set policy-options policy-statement ex-bgp term 0 then accept
481
8. Configure the policy action to attach color communities when exporting prefixes from inet-unicast
address families.
user@R0set policy-options community blue members color:1:129

user@R0set policy-options community red members color:0:128
9. Configure the BGP group to enable connection to R5 using the IPv4 unicast address family. Enable
segment routing for the BGP group.
[edit]
user@R0set protocols bgp group to-R5 type internal
user@R0set protocols bgp group to-R5 family inet segment-routing-te
user@R0set protocols bgp group to-R5 family inet unicast extended-nexthop-color
user@R0set protocols bgp group to-R5 export ex-bgp
user@R0set protocols bgp group to-R5 local-as 65000
user@R0set protocols bgp group to-R5 neighbor 192.168.255.15
10. Configure MPLS on all interfaces excluding the management interface.
[edit]
user@R0set protocols mpls interface all
user@R0set protocols mpls interface fxp0.0 disable
11. Configure the MPLS label range to assign static labels for the links.
[edit]
user@R0set protocols mpls label-range static-label-range 1000 8000
482
12. Configure TI-LFA to enable protection against link and node failures. SR using TI-LFA provides
faster restoration of network connectivity by routing the traffic instantly to a backup or an
alternate path if the primary path fails or becomes unavailable.
[edit]
user@R0set protocols ospf backup-spf-options use-source-packet-routing
13. Configure the maximum number of labels for segment routing routed paths for protection of
backup shortest-path-first attributes.
[edit]
user@R0set protocols ospf backup-spf-options use-post-convergence-lfa maximum-labels 5
14. Configure prefix segment attributes, the start label and the index range for segment routing global
blocks (SRGBs) in SPRING for the OSPF protocol.
[edit]
user@R0set protocols ospf source-packet-routing prefix-segment prefix-sid
user@R0set protocols ospf source-packet-routing srgb start-label 80000
user@R0set protocols ospf source-packet-routing srgb index-range 5000
15. Enable node-link protection on the OSPF interfaces that follow post-convergence path.
[edit]
user@R0set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 post-convergence-lfa node-protection
483
16. Configure the loopback interface as passive to ensure the protocols do not run over the loopback
interface and that the loopback interface is advertised correctly throughout the network.
[edit]
user@R0set protocols ospf area 0.0.0.0 interface lo0.0 passive
17. Define flexible algorithms on the device R0. Assign a name for each of the FADs ranging from 128
through 255.
[edit]
user@R0set routing-options flex-algorithm 128
user@R0set routing-options flex-algorithm 129
Specify the parameters of the definition. OSPFv2 calculates the path based on these specified
parameters of the FAD.
a. Specify the calculation type based on which the OSPFv2 protocol calculates the path.
[edit]
user@R0set routing-options flex-algorithm 128 definition spf
user@R0set routing-options flex-algorithm 128 definition spf
b. Specify the metric type based on which OSPFv2 calculates the path.
[edit]
user@R0set routing-options flex-algorithm 128 definition metric-type igp-metric
user@R0set routing-options flex-algorithm 129 definition metric-type igp-metric
c. If you have enabled RSVP traffic engineering, you can configure admin-groups for many
protocols to color an individual link.
[edit]
user@R0set protocols mpls admin-groups RED 0
484
user@R0set protocols mpls admin-groups BLUE 1

user@R0set protocols mpls admin-groups GREEN 2
d. Assign the configured admin-groups policies to the device R0 interfaces.
[edit]
user@R0set protocols mpls interface ge-0/0/0.0 admin-group RED
user@R0set protocols mpls interface ge-0/0/1.0 admin-group GREEN
user@R0set protocols mpls interface ge-0/0/2.0 admin-group RED
user@R0set protocols mpls interface ge-0/0/3.0 admin-group GREEN
e. Define the admin-groups as per your requirement.
[edit]
user@R0set routing-options flex-algorithm 128 definition admin-group include-any RED
user@R0set routing-options flex-algorithm 129 definition admin-group include-all BLUE
NOTE: For FADs with link-constraints to work, all relevant links should advertise the
admin-colors in OSPFv2. You must either enable RSVP on the interfaces or if you have
not configured RSVP for traffic engineering, make sure you configure set traffic-
engineering advertise always at the [edit protocols ospf] hierarchy level.
[edit]
user@R0set protocols ospf traffic-engineering advertisement always
18. Configure the flexible algorithm participation on the device R0. The same device can advertise a
FAD and also participate in a flexible algorithm.
[edit]
user@R0set protocols ospf source-packet-routing flex-algorithm 128
user@R0set protocols ospf source-packet-routing flex-algorithm 129
485
19. Configure static route on R0.
[edit]
user@R0set routing-options static route 10.1.1.0/24 receive
user@R0set routing-options static route 10.1.0.0/24 receive
Results
Check the results of the configuration:
From configuration mode, confirm your configuration by entering the, show interfaces, show routing-
options, show protocols, and show policy-options commands. If the output does not display the
intended configuration, repeat the instructions in this example to correct the configuration.
interfaces {
ge-0/0/0 {
description R0_to_R1_1;
unit 0 {
family inet {
address 10.10.1.1/30;
}
family mpls;
}
}
ge-0/0/1 {
description R0_to_R1_2
unit 0 {
family inet {
address 10.10.1.5/30;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 10.10.3.1/30;
}
family mpls;
486
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 10.10.3.5/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.255.10/32;
}
}
}
}
policy-options {
policy-statement pplb {
then {
}
}
policy-statement prefix-sid {
term 1001 {
from {
route-filter 192.168.255.10/32 exact;
}
then {
prefix-segment {
algorithm 128 index 1280 node-segment;
index 1000;
node-segment;
487
}
accept;
}
}
}
}
protocols {
mpls {
admin-groups {
RED 0;
BLUE 1;
GREEN 2;
}
label-range {
static-label-range 1000 8000;
}
interface all;
interface fxp0.0 {
disable;
}
admin-group RED;
}
admin-group GREEN;
}
admin-group RED;
}
admin-group GREEN;
}
}
ospf {
use-post-convergence-lfa maximum-labels 5;
use-source-packet-routing;
}
advertisement always;
}
source-packet-routing {
prefix-segment prefix-sid;
488
srgb start-label 80000 index-range 5000;

flex-algorithm [ 128 129 ];
}
area 0.0.0.0 {
interface lo0.0 {
passive;
}
post-convergence-lfa {
node-protection;
}
}
node-protection;
}
}
node-protection;
}
}
node-protection;
}
}
}
}
}
routing-options {
flex-algorithm 128 {
definition {
metric-type igp-metric;
spf;
admin-group include-any RED;
}
}
flex-algorithm 129 {
definition {
metric-type te-metric;
spf;
admin-group include-all [ GREEN BLUE ];
489
}
}
router-id 192.168.255.10;
forwarding-table {
export pplb;
}
}
Verification
IN THIS SECTION
Verifying the OSPF Database | 489
Action | 489
Verifying the Flexible Algorithm Details | 491
Action | 491
Verifying Flex Colored routes | 492
Action | 492
Verifying OSPF Logs | 493
Action | 493
To confirm that the configuration is working properly, perform the following tasks:
Verifying the OSPF Database
Purpose
Verifying that the flexible algorithm signaling is displayed in the OSPF database.
Action
From operational mode, run the show ospf database opaque-area extensive command.
490
On R0
user@R0>show ospf database opaque-area extensive
OpaqArea 4.0.0.0 192.168.255.10 0x800000ad 503 0x22 0xb85d 76

Opaque LSA
SR-Algorithm (8), length 3:
Algo (1), length 1:
0
Algo (2), length 1:
128
Algo (3), length 1:
129
SID/Label Range (9), length 12:
Range Size (1), length 3:
5000
SID/Label (1), length 3:
Label (1), length 3:
80000
Flex-Algorithm Definition (16), length 12:
Flex-Algo (1), length 1:
128
Metric-Type (2), length 1:
0
Calc-Type (3), length 1:
0
Priority (4), length 1:
0
FAD AG Include Any (2), length 4:
Include Any AG (1), length 4:
0x1
Flex-Algorithm Definition (16), length 12:
Flex-Algo (1), length 1:
129
Metric-Type (2), length 1:
2
Calc-Type (3), length 1:
0
Priority (4), length 1:
0
FAD AG Include All (3), length 4:
Include All AG (1), length 4:
491
0x6
Aging timer 00:51:37
Installed 00:08:20 ago, expires in 00:51:37, sent 00:08:18 ago
Last changed 5d 13:35:52 ago, Change count:
Meaning
This output on R0 illustrates that:
Three segment-routing algorithms (including two flexible algorithms) are advertised by this device.
Two FADs are advertised by this device.
Verifying the Flexible Algorithm Details
Purpose
Verifying that the flexible algorithm details are displayed.
Action
From operational mode, run the show ospf spring flex-algorithm <flex-algorithm-id> command.
On R0
user@R0>show ospf spring flex-algorithm 128

Flex Algo: 128, Area: 0.0.0.0
Color: 128, Participating, FAD supported
Winner: 192.168.255.10, Metric: 0, Calc: 0, Prio: 0, inc-any: 0x1, FAD
supported
Include-Any: 0x1 RED
SPF Version: 296
Participation toggles: 1
Topo refresh count: 0
Full SPFs: 296, Partial SPFs: 0
user@R0>show ospf spring flex-algorithm 129

Flex Algo: 129, Area: 0.0.0.0
Color: 129, Participating, FAD supported
Winner: 192.168.255.10, Metric: 0, Calc: 0, Prio: 0, inc-all: 0x2, FAD
supported
492
Include-All: 0x2 BLUE

SPF Version: 181
Participation toggles: 1
Topo refresh count: 12
Full SPFs: 181, Partial SPFs: 0
Meaning
The flexible algorithm details that are configured on R0 are displayed.
Verifying Flex Colored routes
Purpose
Verifying that the fexible algorithm specific OSPF internal routes are displayed.
Action
From operational mode, run the show route protocol ospf table command.
On R0
user@R0>show route protocol ospf table inetcolor.0

inetcolor.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
192.168.255.11-128<c>/64
*[L-OSPF/10/5] 00:20:30, metric 1
> to 10.10.1.2 via ge-0/0/0.0
192.168.255.11-129<c>/64
*[L-OSPF/10/5] 21:19:07, metric 1
> to 10.10.1.6 via ge-0/0/1.0
192.168.255.12-128<c>/64
*[L-OSPF/10/5] 00:20:30, metric 2
to 10.10.1.2 via ge-0/0/0.0, Push 81282
> to 10.10.3.2 via ge-0/0/2.0, Push 81282
192.168.255.12-129<c>/64
*[L-OSPF/10/5] 00:20:30, metric 4
> to 10.10.1.6 via ge-0/0/1.0, Push 81292
192.168.255.13-128<c>/64
493
*[L-OSPF/10/5] 00:20:30, metric 1

> to 10.10.3.2 via ge-0/0/2.0
192.168.255.13-129<c>/64
*[L-OSPF/10/5] 01:00:52, metric 2
> to 10.10.1.6 via ge-0/0/1.0, Push 81293
192.168.255.14-128<c>/64
*[L-OSPF/10/5] 00:16:11, metric 2
> to 10.10.3.2 via ge-0/0/2.0, Push 81284
192.168.255.14-129<c>/64
*[L-OSPF/10/5] 00:16:11, metric 3
> to 10.10.1.6 via ge-0/0/1.0, Push 81294
192.168.255.15-128<c>/64
*[L-OSPF/10/5] 00:12:41, metric 3
to 10.10.1.2 via ge-0/0/0.0, Push 81285
> to 10.10.3.2 via ge-0/0/2.0, Push 81285
192.168.255.15-129<c>/64
*[L-OSPF/10/5] 00:12:41, metric 5
> to 10.10.1.6 via ge-0/0/1.0, Push 81295
Meaning
The output displays all the colored flex routes programmed in inetcolor.0 table in the following format:
prefix_address-flex-algo-id<c>/64
Verifying OSPF Logs
Purpose
Verifying that the OSPF logs displays the flexible algorithm keyword.
Action
From operational mode, run the show ospf log command.
On R0
user@R0>show ospf log

Topology default SPF log:
494
Last instance of each event type

When Type Elapsed
1w2d 13:59:18 SPF 0.000316
1w2d 13:59:18 Stub 0.000233
1w2d 13:59:18 Interarea 0.000002
1w2d 13:59:18 External 0.000004
1w2d 13:59:18 NSSA 0.000001
1w2d 13:59:18 Cleanup 0.000551
Maximum length of each event type

When Type Elapsed
1w2d 14:34:27 SPF 0.000997
1w2d 15:59:35 Stub 0.000675
1w3d 07:08:27 Interarea 0.000010
1w3d 07:29:07 External 0.000013
1w3d 07:15:21 NSSA 0.000008
1w3d 08:38:05 Cleanup 0.001044
Last 100 events

When Type Elapsed
1w2d 14:08:36 FlexAlgo SPF 0.000680

1w2d 14:08:36 SPF 0.000204
1w2d 14:08:36 Stub 0.000025
1w2d 14:08:36 Interarea 0.000003
1w2d 14:08:36 External 0.000002
1w2d 14:08:36 NSSA 0.000001
1w2d 14:08:36 Prefix SID 0.000222
1w2d 14:08:36 Adj SID 0.000074
1w2d 14:08:36 Cleanup 0.000607
1w2d 14:08:36 Total 0.001209
1w2d 14:08:31 SPF 0.000188
1w2d 14:08:31 Stub 0.000054
1w2d 14:08:31 Interarea 0.000002
1w2d 14:08:31 External 0.000001
1w2d 14:08:31 NSSA 0.000001
1w2d 14:08:31 Prefix SID 0.000181
1w2d 14:08:31 Adj SID 0.000178
1w2d 14:08:31 Cleanup 0.000413
1w2d 14:08:31 Total 0.001656
1w2d 14:06:54 FlexAlgo SPF 0.001914
1w2d 14:06:54 FlexAlgo SPF 0.000081
1w2d 14:06:54 SPF 0.000215
495
1w2d 14:06:54 Stub 0.000030

1w2d 14:06:54 Interarea 0.000003
1w2d 14:06:54 External 0.000001
1w2d 14:06:54 NSSA 0.000001
1w2d 14:06:54 Prefix SID 0.000227
1w2d 14:06:54 Adj SID 0.000075
1w2d 14:06:54 Cleanup 0.000233
1w2d 14:06:54 Total 0.000859
1w2d 14:06:49 SPF 0.000234
1w2d 14:06:49 Stub 0.000072
1w2d 14:06:49 Interarea 0.000003
1w2d 14:06:49 External 0.000002
1w2d 14:06:49 NSSA 0
1w2d 14:06:49 Prefix SID 0.000262
1w2d 14:06:49 Adj SID 0.000254
1w2d 14:06:49 Cleanup 0.000495
1w2d 14:06:49 Total 0.001936
1w2d 14:06:30 FlexAlgo SPF 0.001356
1w2d 14:06:30 FlexAlgo SPF 0.000061
1w2d 14:06:30 SPF 0.000207
1w2d 14:06:30 Stub 0.000023
1w2d 14:06:30 Interarea 0.000003
1w2d 14:06:30 External 0.000002
1w2d 14:06:30 NSSA 0.000001
1w2d 14:06:30 Prefix SID 0.000237
1w2d 14:06:30 Adj SID 0.000087
1w2d 14:06:30 Cleanup 0.000430
1w2d 14:06:30 Total 0.001060
1w2d 14:06:25 SPF 0.000207
1w2d 14:06:25 Stub 0.000077
1w2d 14:06:25 Interarea 0.000002
1w2d 14:06:25 External 0.000002
1w2d 14:06:25 NSSA 0.000001
1w2d 14:06:25 Prefix SID 0.000250
1w2d 14:06:25 Adj SID 0.000245
1w2d 14:06:25 Cleanup 0.000399
1w2d 14:06:25 Total 0.001840
1w2d 14:05:56 FlexAlgo SPF 0.001781
1w2d 14:05:56 FlexAlgo SPF 0.000080
1w2d 14:05:55 SPF 0.000215
1w2d 14:05:55 Stub 0.000025
1w2d 14:05:55 Interarea 0.000002
1w2d 14:05:55 External 0.000001
496
1w2d 14:05:55 NSSA 0.000001

1w2d 14:05:55 Prefix SID 0.000240
1w2d 14:05:55 Adj SID 0.000073
1w2d 14:05:55 Cleanup 0.000422
1w2d 14:05:55 Total 0.001055
1w2d 14:05:50 SPF 0.000212
1w2d 14:05:50 Stub 0.000082
1w2d 14:05:50 Interarea 0.000003
1w2d 14:05:50 External 0.000001
1w2d 14:05:50 NSSA 0.000001
1w2d 14:05:50 Prefix SID 0.000264
1w2d 14:05:50 Adj SID 0.000239
1w2d 14:05:50 Cleanup 0.000458
1w2d 14:05:50 Total 0.002053
1w2d 13:59:23 FlexAlgo SPF 0.001603
1w2d 13:59:23 FlexAlgo SPF 0.000062
1w2d 13:59:23 SPF 0.000224
1w2d 13:59:23 Stub 0.000021
1w2d 13:59:23 Interarea 0.000002
1w2d 13:59:23 External 0.000001
1w2d 13:59:23 NSSA 0.000001
1w2d 13:59:23 Prefix SID 0.000222
1w2d 13:59:23 Adj SID 0.000087
1w2d 13:59:23 Cleanup 0.000413
1w2d 13:59:23 Total 0.001228
1w2d 13:59:18 SPF 0.000316
1w2d 13:59:18 Stub 0.000233
1w2d 13:59:18 Interarea 0.000002
1w2d 13:59:18 External 0.000004
1w2d 13:59:18 NSSA 0.000001
1w2d 13:59:18 Prefix SID 0.000324
1w2d 13:59:18 Adj SID 0.000318
1w2d 13:59:18 Cleanup 0.000551
1w2d 13:59:18 Total 0.002751
Meaning
The output displays the FlexAlgo keyword added for the SPF logs.
497
13 CHAPTER
Configure OSPF Database Protection

499
Configuring OSPF Database Protection
IN THIS SECTION
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 state, it must remain there until you issue
a command to clear database protection before it can return to normal operations.
500
• 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.
SEE ALSO
database-protection
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.
501
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.
• 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.
14 CHAPTER
Configure OSPF Routing Policy
Configuring OSPF Routing Policy | 503

503
Configuring OSPF Routing Policy
IN THIS SECTION
Understanding Routing Policies | 503
Example: Injecting OSPF Routes into the BGP Routing Table | 557
Example: Redistributing Static Routes into OSPF | 562
Example: Configuring an OSPF Import Policy | 567
Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through OSPF | 573
Example: Redistributing OSPF Routes into IS-IS | 605
Understanding Routing Policies
IN THIS SECTION
Importing and Exporting Routes | 504
Active and Inactive Routes | 506
Explicitly Configured Routes | 506
Dynamic Database | 506

504
For some routing platform vendors, the flow of routes occurs between various protocols. If, for example,
you want to configure redistribution from RIP to OSPF, the RIP process tells the OSPF process that it
has routes that might be included for redistribution. In Junos OS, there is not much direct interaction
between the routing protocols. Instead, there are central gathering points where all protocols install
their routing information. These are the main unicast routing tables inet.0 and inet6.0.
From these tables, the routing protocols calculate the best route to each destination and place these
routes in a forwarding table. These routes are then used to forward routing protocol traffic toward a
destination, and they can be advertised to neighbors.
Importing and Exporting Routes
Two terms—import and export—explain how routes move between the routing protocols and the routing
table.
• When the Routing Engine places the routes of a routing protocol into the routing table, it is importing
routes into the routing table.
• When the Routing Engine uses active routes from the routing table to send a protocol advertisement,
it is exporting routes from the routing table.
NOTE: The process of moving routes between a routing protocol and the routing table is
described always from the point of view of the routing table. That is, routes are imported into
a routing table from a routing protocol and they are exported from a routing table to a routing
protocol. Remember this distinction when working with routing policies.
505
As shown in Figure 31 on page 505, you use import routing policies to control which routes are placed
in the routing table, and export routing policies to control which routes are advertised from the routing
table to neighbors.
Figure 31: Importing and Exporting Routes
In general, the routing protocols place all their routes in the routing table and advertise a limited set of
routes from the routing table. The general rules for handling the routing information between the
routing protocols and the routing table are known as the routing policy framework.
The routing policy framework is composed of default rules for each routing protocol that determine
which routes the protocol places in the routing table and advertises from the routing table. The default
rules for each routing protocol are known as default routing policies.
You can create routing policies to preempt the default policies, which are always present. A routing
policy allows you to modify the routing policy framework to suit your needs. You can create and
implement your own routing policies to do the following:
• Control which routes a routing protocol places in the routing table.
• Control which active routes a routing protocol advertises from the routing table. An active route is a
route that is chosen from all routes in the routing table to reach a destination.
• Manipulate the route characteristics as a routing protocol places the route in the routing table or
advertises the route from the routing table.
You can manipulate the route characteristics to control which route is selected as the active route to
reach a destination. The active route is placed in the forwarding table and is used to forward traffic
toward the route’s destination. In general, the active route is also advertised to a router’s neighbors.
506
Active and Inactive Routes
When multiple routes for a destination exist in the routing table, the protocol selects an active route and
that route is placed in the appropriate routing table. For equal-cost routes, the Junos OS places multiple
next hops in the appropriate routing table.
When a protocol is exporting routes from the routing table, it exports active routes only. This applies to
actions specified by both default and user-defined export policies.
When evaluating routes for export, the Routing Engine uses only active routes from the routing table.
For example, if a routing table contains multiple routes to the same destination and one route has a
preferable metric, only that route is evaluated. In other words, an export policy does not evaluate all
routes; it evaluates only those routes that a routing protocol is allowed to advertise to a neighbor.
NOTE: By default, BGP advertises active routes. However, you can configure BGP to advertise
inactive routes, which go to the same destination as other routes but have less preferable
metrics.
Explicitly Configured Routes
An explicitly configured route is a route that you have configured. Direct routes are not explicitly
configured. They are created as a result of IP addresses being configured on an interface. Explicitly
configured routes include aggregate, generated, local, and static routes. (An aggregate route is a route
that distills groups of routes with common addresses into one route. A generated route is a route used
when the routing table has no information about how to reach a particular destination. A local route is
an IP address assigned to a router interface. A static route is an unchanging route to a destination.)
The policy framework software treats direct and explicitly configured routes as if they are learned
through routing protocols; therefore, they can be imported into the routing table. Routes cannot be
exported from the routing table to the pseudoprotocol, because this protocol is not a real routing
protocol. However, aggregate, direct, generated, and static routes can be exported from the routing
table to routing protocols, whereas local routes cannot.
Dynamic Database
In Junos OS Release 9.5 and later, you can configure routing policies and certain routing policy objects in
a dynamic database that is not subject to the same verification required by the standard configuration
database. As a result, you can quickly commit these routing policies and policy objects, which can be
referenced and applied in the standard configuration as needed. BGP is the only protocol to which you
can apply routing policies that reference policies configured in the dynamic database. After a routing
policy based on the dynamic database is configured and committed in the standard configuration, you
can quickly make changes to existing routing policies by modifying policy objects in the dynamic
507
database. Because Junos OS does not validate configuration changes to the dynamic database, when
you use this feature, you should test and verify all configuration changes before committing them.
SEE ALSO
Example: Configuring Dynamic Routing Policies
Understanding OSPF Routing Policy
IN THIS SECTION
Routing Policy Terms | 508
Routing Policy Match Conditions | 508
Routing Policy Actions | 509
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.
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.

508
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.
• 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.
509
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 Terms.
Understanding Backup Selection Policy for OSPF Protocol
Support for OSPF loop-free alternate (LFA) routes essentially adds IP fast-reroute capability for OSPF.
Junos OS precomputes multiple loop-free backup routes for all OSPF routes. These backup routes are
pre-installed 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. The selection of
LFA is done randomly by selecting any matching LFA to progress to the given destination. This does not
ensure best backup coverage available for the network. In order to choose the best LFA, Junos OS
allows you to configure network-wide backup selection policies for each destination (IPv4 and IPv6) and
a primary next-hop interface. These policies are evaluated based on admin-group, srlg, bandwidth,
protection-type, metric, and node information.
During backup shortest-path-first (SPF) computation, each node and link attribute of the backup path is
accumulated by IGP and is associated with every node (router) in the topology. The next hop in the best
backup path is selected as the backup next hop in the routing table. In general, backup evaluation policy
rules are categorized into the following types:
510
• Pruning — Rules configured to select the eligible backup path.
• Ordering — Rules configured to select the best among the eligible backup paths.
The backup selection policies can be configured with both pruning and ordering rules. While evaluating
the backup policies, each backup path is assigned a score, an integer value that signifies the total weight
of the evaluated criteria. The backup path with the highest score is selected.
To enforce LFA selection, configure various rules for the following attributes:
• admin-group– Administrative groups, also known as link coloring or resource class, are manually
assigned attributes that describe the “color” of links, such that links with the same color conceptually
belong to the same class. These configured administrative groups are defined under protocol MPLS.
You can use administrative groups to implement a variety of backup selection policies using exclude,
include-all, include-any, or preference.
• srlg— A shared risk link group (SRLG) is a set of links sharing a common resource, which affects all
links in the set if the common resource fails. These links share the same risk of failure and are
therefore considered to belong to the same SRLG. For example, links sharing a common fiber are said
to be in the same SRLG because a fault with the fiber might cause all links in the group to fail. An
SRLG is represented by a 32-bit number unique within an IGP (OSPF) domain. A link might belong to
multiple SRLGs. You can define the backup selection to either allow or reject the common SRLGs
between the primary and the backup path. This rejection of common SRLGs are based on the non-
existence of link having common SRLGs in the primary next-hop and the backup SPF.
NOTE: Administrative groups and SRLGs can be created only for default topologies.
• bandwidth—The bandwidth specifies the bandwidth constraints between the primary and the backup
path. The backup next-hop link can be used only if the bandwidth of the backup next-hop interface is
greater than or equal to the bandwidth of the primary next hop.
• protection-type— The protection-type protects the destination from node failure of the primary
node or link failure of the primary link. You can configure node, link, or node-link to protect the
destination. If link-node is configured , then the node-protecting LFA is preferred over link-protection
LFA.
• node- The node is per-node policy information. Here, node can be a directly connected router,
remote router like RSVP backup LSP tail-end, or any other router in the backup SPF path. The nodes
are identified through the route-id advertised by a node in the LSP. You can list the nodes to either
prefer or exclude them in the backup path.
• metric— Metric decides how the LFAs should be preferred. In backup selection path, root metric and
dest-metric are the two types of metrics. root-metric indicates the metric to the one-hop neighbor or
a remote router such as an RSVP backup LSP tail-end router. The dest-metric indicates the metric
511
from a one-hop neighbor or remote router such as an RSVP backup LSP tail-end router to the final
destination. The metric evaluation is done either in ascending or descending order. By default, the
first preference is given to backup paths with lowest destination evaluation and then to backup paths
with lowest root metrics.
The evaluation-order allows you to control the order and criteria of evaluating these attributes in the
backup path. You can explicitly configure the evaluation order. Only the configured attributes influence
the backup path selection. The default order of evaluation of these attributes for the LFA is [ admin-
group srlg bandwidth protection-type node metric ] .
NOTE: TE attributes are not supported in OSPFv3 and cannot be used for backup selection
policy evaluation for IPv6 prefixes.
SEE ALSO
backup-selection (Protocols IS-IS)
Configuring Backup Selection Policy for the OSPF Protocol
Support for OSPF loop-free alternate (LFA) routes essentially adds IP fast-reroute capability for OSPF.
Junos OS precomputes multiple loop-free backup routes for all OSPF routes. These backup routes are
pre-installed 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. The selection of
LFA is done randomly by selecting any matching LFA to progress to the given destination. This does not
ensure best backup coverage available for the network. In order to choose the best LFA, Junos OS
allows you to configure network-wide backup selection policies for each destination (IPv4 and IPv6) and
a primary next-hop interface. These policies are evaluated based on admin-group, srlg, bandwidth,
protection-type, metric, and node information.
Before you begin to configure the backup selection policy for the OSPF protocol:
• Configure the router interfaces. See the Junos OS Network Management Administration Guide for
Routing Devices.
• Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Library
for Routing Devices.
To configure the backup selection policy for the OSPF protocol:

512
1. Configure per-packet load balancing.
[edit policy-options]
user@host# set policy-statement ecmp term 1 then load-balance per-packet
2. Enable RSVP on all the interfaces.
[edit protocols]
user@host# set rsvp interface all
3. Configure administrative groups.

user@host# set admin-groups group-name
4. Configure srlg values.
user@host# set srlg srlg-name srlg-value srlg-value
5. Enable MPLS on all the interfaces.

user@host# set interface all
6. Apply MPLS to an interface configured with an administrative group.

user@host# set interface interface-name admin-group group-name
7. Configure the ID of the router.
user@host# set router-id router-id
513
8. Apply the routing policy to all equal cost multipaths exported from the routing table to the
forwarding table.
user@host# set forwarding-table export ecmp
9. Enable link protection and configure metric values on all the interfaces for an area.

user@host# set area area-id interface interface-name link-protection
user@host# set area area-id interface interface-name metric metric
10. Configure the administrative group of the backup selection policy for an IP address.
You can choose to exclude, include all, include any, or prefer the administrative groups from the
backup path.
user@host# set backup-selection destination ip-address interface interface-name admin-group
• Specify the administrative group to be excluded.
[edit routing-options backup-selection destination ip-address interface

interface-name admin-group]
user@host# set exclude group-name
The backup path is not selected as the loop-free alternate (LFA) or backup nexthop if any of the
links in the path have any one of the listed administrative groups.
For example, to exclude the group c1 from the administrative group:
[edit routing-options backup-selection destination 0.0.0.0/0 interface

all admin-group]
user@host# set exclude c1
514
• Configure all the administrative groups if each link in the backup path requires all the listed
administrative groups in order to accept the path.

user@host# set include-all group-name
For example, to set all the administrative groups if each link requires all the listed administrative
groups in order to accept the path:

all admin-group]
user@host# set include-all c2
• Configure any administrative group if each link in the backup path requires at least one of the
listed administrative groups in order to select the path.

user@host# set include-any group-name
For example, to set any administrative group if each link in the backup path requires at least one
of the listed administrative groups in order to select the path:

all admin-group]
user@host# set include-any c3
• Define an ordered set of an administrative group that specifies the preference of the backup
path.
The leftmost element in the set is given the highest preference.

user@host# set preference group-name
515
For example, to set an ordered set of an administrative group that specifies the preference of
the backup path:

all admin-group]
user@host# set preference c4
11. Configure the backup path to allow the selection of the backup next hop only if the bandwidth is
greater than or equal to the bandwidth of the primary next hop.
user@host# set backup-selection destination ip-address interface interface-name bandwidth-greater-
equal-primary
12. Configure the backup path to specify the metric from the one-hop neighbor or from the remote
router such as an RSVP backup label-switched-path (LSP) tail-end router to the final destination.
The destination metric can be either highest or lowest.
• Configure the backup path that has the highest destination metric.
user@host# set backup-selection destination ip-address interface interface-name dest-metric
highest
• Configure the backup path that has the lowest destination metric.
user@host# set backup-selection destination ip-address interface interface-name dest-metric
lowest
13. Configure the backup path that is a downstream path to the destination.
user@host# set backup-selection destination ip-address interface interface-name downstream-paths-
only
14. Set the order of preference of the root and the destination metric during backup path selection.
The preference order can be :
516
• [root dest] — Backup path selection or preference is first based on the root-metric criteria. If the
criteria of all the root-metric is the same, then the selection or preference is based on the dest-
metric.
• [dest root] — Backup path selection or preference is first based on the dest-metric criteria. If the
criteria of all the dest-metric is the same, then the selection is based on the root-metric.
user@host# set backup-selection destination ip-address interface interface-name metric-order dest
user@host# set backup-selection destination ip-address interface interface-name metric-order root
15. Configure the backup path to define a list of loop-back IP addresses of the adjacent neighbors to
either exclude or prefer in the backup path selection.
The neighbor can be a local (adjacent router) neighbor, remote neighbor, or any other router in the
backup path.
user@host# set backup-selection destination ip-address interface interface-name node
• Configure the list of neighbors to be excluded.

interface-name node]
user@host# set exclude node-address
The backup path that has a router from the list is not selected as the loop-free alternative or
backup next hop.
• Configure an ordered set of neighbors to be preferred.

interface-name node]
user@host# set preference node-address
The backup path having the leftmost neighbor is selected.

16. Configure the backup path to specify the required protection type of the backup path to be link,
node, or node-link.
517
• Select the backup path that provides link protection.
user@host# set backup-selection destination ip-address interface interface-name protection-type
link
• Select the backup path that provides node protection.
node
• Select the backup path that allows either node or link protection LFA where node-protection
LFA is preferred over link-protection LFA.
node-link
17. Specify the metric to the one-hop neighbor or to the remote router such as an RSVP backup label-
switched-path (LSP) tail-end router.
• Select the path with highest root metric.
user@host# set backup-selection destination ip-address interface all root-metric highest
• Select the path with lowest root metric.
user@host# set backup-selection destination ip-address interface all root-metric lowest
18. Configure the backup selection path to either allow or reject the common shared risk link groups
(SRLGs) between the primary link and each link in the backup path.
518
• Configure the backup path to allow common srlgs between the primary link and each link in the
backup path.
user@host# set backup-selection destination ip-address interface all srlg loose
A backup path with a fewer number of srlg collisions is preferred.
• Configure the backup path to reject the backup path that has common srlgs between the
primary next-hop link and each link in the backup path.
user@host# set backup-selection destination ip-address interface all srlg strict
19. Configure the backup path to control the order and the criteria of evaluating the backup path based
on the administrative group, srlg, bandwidth, protection type, node, and metric.
The default order of evaluation is admin-group, srlg, bandwidth, protection-type, node, and metric.
user@host# set backup-selection destination ip-address interface all evaluation-order admin-group
user@host# set backup-selection destination ip-address interface all evaluation-order srlg
user@host# set backup-selection destination ip-address interface all evaluation-order bandwidth
SEE ALSO
Topology-Independent Loop-Free Alternate with Segment Routing for

OSPF
IN THIS SECTION
Understanding Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 519
Configuring Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 521
519
Understanding Topology-Independent Loop-Free Alternate with Segment Routing for

OSPF
IN THIS SECTION
Benefits of Using Topology-Independent Loop-Free Alternate with Segment Routing | 520
Segment routing enables a router to send a packet along a specific path in the network by imposing a
label stack that describes the path. The forwarding actions described by a segment routing label stack
do not need to be established on a per-path basis. Therefore, an ingress router can instantiate an
arbitrary path using a segment routing label stack and use it immediately without any signaling.
In segment routing, each node advertises mappings between incoming labels and forwarding actions. A
specific forwarding action is referred to as a segment and the label that identifies that segment is
referred to as a segment identifier (SID). The backup paths created by TI-LFA use the following types of
segments:
• Node segment—A node segment forwards packets along the shortest path or paths to a destination
node. The label representing the node segment (the node SID) is swapped until the destination node
is reached.
• Adjacency segment—An adjacency segment forwards packets across a specific interface on the node
that advertised the adjacency segment. The label representing an adjacency segment (the adjacency
SID) is popped by the node that advertised it.
A router can send a packet along a specific path by creating a label stack that uses a combination of
node SIDs and adjacency SIDs. Typically, node SIDs are used to represent parts of the path that
correspond to the shortest path between two nodes. An adjacency SID is used wherever a node SID
cannot be used to accurately represent the desired path.
When used with OSPF, TI-LFA provides protection against link failure, node failure., fate-sharing failures,
and shared risk link group failures. In link failure mode, the destination is protected if the link fails. In
node protection mode, the destination is protected if the neighbor connected to the primary link fails.
To determine the node-protecting post-convergence path, the cost of all the links leaving the neighbor is
assumed to increase by a configurable amount.
Starting in Junos OS Release 20.3R1, you can configure fate-sharing protection in TI-LFA networks for
segment routing to choose a fast reroute path that does not include fate-sharing groups in the topology-
independent loop-free alternate (TI-LFA) backup paths to avoid fate-sharing failures. With fate-sharing
protection, a list of fate-sharing groups are configured on each PLR with the links in each fate-sharing
group identified by their respective IP addresses. The PLR associates a cost with each fate-sharing
520
group. The fate-sharing-aware post-convergence path is computed by assuming that the cost of each
link in the same fate-sharing group as the failed link has increased the cost associated with that group.
Starting in Junos OS Release 20.3R1, you can configure Shared Risk Link Group (SRLG) protection in TI-
LFA networks for segment routing to choose a fast reroute path that does not include SRLG links in the
topology-independent loop-free alternate (TI-LFA) backup paths. SRLGs share a common fibre and they
also share the risks of a broken link. When one link in an SRLG fails, other links in the group might also
fail. Therefore, you need to avoid links that share the same risk as the protected link in the backup path.
Configuring SRLG protection prevents TI-LFA from selecting backup paths that include a shared risk link.
If you have configured SRLG protection then OSPFv2 computes the fast reroute path that is aligned
with the post convergence path and excludes the links that belong to the SRLG of the protected link. All
local and remote links that are from the same SRLG as the protected link are excluded from the TI-LFA
back up path. The point of local repair (PLR) sets up the label stack for the fast reroute path with a
different outgoing interface. Currently you cannot enable SRLG protection in IPv6 networks and in
networks with multitopology.
In order to construct a backup path that follows the post-convergence path, TI-LFA can use several
labels in the label stack that define the backup path. If the number of labels required to construct a
particular post-convergence backup path exceeds a certain amount, it is useful in some circumstances to
not install that backup path. You can configure the maximum number of labels that a backup path can
have in order to be installed. The default value is 3, with a range of 2 through 5.
It is often the case that the post-convergence path for a given failure is actually a set of equal-cost
paths. TI-LFA attempts to construct the backup paths to a given destination using multiple equal-cost
paths in the post-failure topology. Depending on the topology, TI-LFA might need to use different label
stacks to accurately construct those equal-cost backup paths. By default, TI-LFA only installs one
backup path for a given destination. However, you can configure the value in the range from 1 through
8.
Benefits of Using Topology-Independent Loop-Free Alternate with Segment Routing
• Loop-free alternate (LFA) and remote LFA (RLFA) have been used to provide fast-reroute protection
for several years. With LFA, a point of local repair (PLR) determines whether or not a packet sent to
one of its direct neighbors reaches its destination without looping back through the PLR. In a typical
network topology, approximately 40 to 60 percent of the destinations can be protected by LFA.
Remote LFA expands on the concept of LFA by allowing the PLR to impose a single label to tunnel
the packet to a repair tunnel endpoint from which the packet can reach its destination without
looping back through the PLR. Using remote LFA, more destinations can be protected by the PLR
compared to LFA. However, depending on the network topology, the percentage of destinations
protected by remote LFA is usually less than 100 percent.
• Topology-independent LFA (TI-LFA) extends the concept of LFA and remote LFA by allowing the PLR
to use deeper label stacks to construct backup paths. In addition, TI-LFA imposes the constraint that
the backup path used by the PLR be the same path that a packet takes once the interior gateway
521
protocol (IGP) has converged for a given failure scenario. This path is referred to as the post-
convergence path.
• Using the post-convergence path as the backup path has some desirable characteristics. For some
topologies, a network operator only needs to make sure that the network has enough capacity to
carry the traffic along the post-convergence path after a failure. In these cases, a network operator
does not need to allocate additional capacity to deal with the traffic pattern immediately after the
failure while the backup path is active, because the backup path follows the post-convergence path.
• When used with OSPF, TI-LFA provides protection against link failure and node failure.
Configuring Topology-Independent Loop-Free Alternate with Segment Routing for

OSPF
Before you configure TI-LFA for OSPF, be sure you configure SPRING or segment routing.
Starting in Junos OS Release 19.3R1, Junos supports creation of OSPF topology-independent TI-LFA
backup paths where the prefix SID is learned from a segment routing mapping server advertisement
when the PLR and mapping server are both in the same OSPF area.
To configure TI-LFA using SPRING for OSPF, you must do the following:
1. Enable TI-LFA for OSPF protocol.
[edit protocols ospf backup-spf-options]

user@R1# set use-post-convergence-lfa
2. (Optional) Configure backup shortest path first (SPF) attributes such as maximum equal-cost
multipath (ECMP) backup paths and maximum labels for TI-LFA for the OSPF protocol.
[edit protocols ospf backup-spf-options use-post-convergence-lfa]

user@R1# set maximum-backup-paths maximum-backup-paths
user@R1# set maximum-labels maximum-labels
3. Configure the computation and installation of a backup path that follows the post-convergence path
on the given area and interfacefor the OSPF protocol.
[edit protocols ospf area area-id interface interface-name

user@R1# set post-convergence-lfa
522
4. (Optional) Enable node protection for a given area and interface.
[edit protocols ospf area area-id interfaceinterface-name post-convergence-

lfa]
user@R1# set node-protection
5. (Optional) Enable fate-sharing protection for a given area and interface.

lfa]
user@R1# set fate-sharing-protection
6. (Optional) Enable SRLG protection for a given area and interface.

lfa]
user@R1# set srlg-protection
source-packet-routing
use-post-convergence-lfa
post-convergence-lfa
Example: Configuring Backup Selection Policy for the OSPF or OSPF3

Protocol
IN THIS SECTION
Requirements | 523
Overview | 523
Configuration | 524
Verification | 550
523
This example shows how to configure the backup selection policy for the OSPF or OSPF3 protocol,
which enables you to select a loop-free alternate (LFA) in the network.
When you enable backup selection policies, Junos OS allows selection of LFA based on the policy rules
and attributes of the links and nodes in the network. These attributes are admin-group, srlg, bandwidth,
protection-type, metric, and node.
Requirements
• Eight routers that can be a combination of M Series Multiservice Edge Routers, MX Series 5G
Universal Routing Platforms, PTX Series Packet Transport Routers, and T Series Core Routers
• Junos OS Release 15.1 or later running on all devices
Before you begin:
2. Configure OSPF.
Overview
IN THIS SECTION
Topology | 524
In Junos OS, the default loop-free alternative (LFA) selection algorithm or criteria can be overridden with
an LFA policy. These policies are configured for each destination (IPv4 and IPv6) and a primary next-hop
interface . These backup policies enforce LFA selection based on admin-group, srlg, bandwidth,
protection-type, metric, and node attributes of the backup path. During backup shortest-path-first (SPF)
computation, each attribute (both node and link) of the backup path, stored per backup next-hop, is
accumulated by IGP. For the routes created internally by IGP, the attribute set of every backup path is
evaluated against the policy configured for each destination (IPv4 and IPv6) and a primary next-hop
interface. The first or the best backup path is selected and installed as the backup next hop in the
routing table. To configure the backup selection policy, include the backup-selection configuration
statement at the [edit routing-options] hierarchy level. The show backup-selection command displays
the configured policies for a given interface and destination. The display can be filtered against a
particular destination, prefix, interface, or logical systems.
524
Topology
In this topology shown in Figure 32 on page 524, the backup selection policy is configured on Device
R3.
Figure 32: Example Backup Selection Policy for OSPF or OPSF3
Configuration
IN THIS SECTION

525
Results | 544
R0

set interfaces ge-0/0/0 unit 0 family inet6 address 2001:db8:10:1:1::1/64
set interfaces xe-0/2/0 unit 0 family inet address 172.16.20.1/30
set interfaces xe-0/2/0 unit 0 family inet6 address 2001:db8:20:1:1::1/64
set interfaces xe-0/2/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet6 address 2001:db8::10:10:10:10/128 primary
set routing-options srlg srlg1 srlg-value 1001
526

set protocols rsvp interface all
set protocols mpls admin-groups c0 0
527
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 10

set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 51
set protocols ospf3 area 0.0.0.0 interface ge-0/0/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 51
R1

528

set protocols mpls interface ge-0/0/0.0 srlg srlg9
529

R2

530

531

set protocols ospf3 area 0.0.0.0 interface ge-0/1/0.0 link-protection
R3

532

set routing-options forwarding-table export ecmp
set routing-options backup-selection destination 10.1.1.0/30 interface xe-1/3/0.0 admin-group include-all c2
set routing-options backup-selection destination 10.1.1.0/30 interface all admin-group exclude c3
set routing-options backup-selection destination 10.1.1.0/30 interface all srlg strict
set routing-options backup-selection destination 10.1.1.0/30 interface all protection-type node
set routing-options backup-selection destination 10.1.1.0/30 interface all bandwidth-greater-equal-primary
set routing-options backup-selection destination 10.1.1.0/30 interface all neighbor preference 172.16.7.7
set routing-options backup-selection destination 10.1.1.0/30 interface all root-metric lowest
set routing-options backup-selection destination 10.1.1.0/30 interface all metric-order root
set routing-options backup-selection destination 172.16.30.0/30 interface all bandwidth-greater-equal-
primary
set routing-options backup-selection destination 172.16.45.0/30 interface all bandwidth-greater-equal-
primary
533

set protocols mpls interface ge-0/0/5.0 admin-group c0
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 link-protection
set protocols ospf3 area 0.0.0.0 interface ge-0/0/5.0 link-protection
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 link-protection
534

set policy-options policy-statement ecmp term 1 then load-balance per-packet
R4

535

R5

536

537

R6

538

R7

539

set protocols mpls interface xe-0/3/0.0 srlg srlg8
540
Guide.
[edit interfaces]
user@R3# set ge-0/0/5 unit 0 family inet6 address 2001:db8:50:1:1::2/64
user@R3# set xe-0/3/1 unit 0 family inet address 172.16.75.1/30
user@R3# set xe-0/3/1 unit 0 family inet6 address 2001:db8:75:1:1::1/64
user@R3# set xe-0/3/1 unit 0 family mpls
user@R3# set xe-1/3/0 unit 0 family inet address 172.16.90.1/30
user@R3# set xe-1/3/0 unit 0 family inet6 address 2001:db8:90:1:1::1/64
user@R3# set xe-1/3/0 unit 0 family mpls
user@R3# set lo0 unit 0 family inet address 172.16.3.3/32 primary
user@R3# set lo0 unit 0 family inet6 address 2001:db8::3:3:3:3/128 primary
user@R3# set lo0 unit 0 family mpls
2. Configure srlg values.
user@R3# set srlg srlg1 srlg-value 1001
541

3. Configure the ID of the router.
user@R3# set router-id 172.16.3.3
4. Apply the routing policy to all equal-cost multipaths exported from the routing table to the
forwarding table.
user@R3# set forwarding-table export ecmp
5. Configure attributes of the backup selection policy.
[edit routing-options backup-selection]

user@R3# set destination 10.1.1.0/30 interface xe-1/3/0.0 admin-group include-all c2
user@R3# set destination 10.1.1.0/30 interface all admin-group exclude c3
user@R3# set destination 10.1.1.0/30 interface all srlg strict
user@R3# set destination 10.1.1.0/30 interface all protection-type node
user@R3# set destination 10.1.1.0/30 interface all bandwidth-greater-equal-primary
user@R3# set destination 10.1.1.0/30 interface all neighbor preference 172.16.7.7
user@R3# set destination 10.1.1.0/30 interface all root-metric lowest
user@R3# set destination 10.1.1.0/30 interface all metric-order root
542

6. Enable RSVP on all the interfaces.
[edit protocols]
user@R3# set rsvp interface all
7. Configure administrative groups.

user@R3# set admin-groups c0 0
543

8. Enable MPLS on all the interfaces and configure administrative group for an interface.

user@R3# set interface ge-0/0/5.0 admin-group c0
9. Enable link protection and configure metric values on all the interfaces for an OSPF area.

user@R3# set area 0.0.0.0 interface ge-0/0/5.0 metric 10
user@R3# set area 0.0.0.0 interface xe-0/3/1.0 metric 21
user@R3# set area 0.0.0.0 interface xe-1/3/0.0 link-protection
10. Enable link protection and configure metric values on all the interfaces for an OSPF3 area.

user@R3# set area 0.0.0.0 interface xe-1/3/0.0 link-protection
544
11. Configure the routing policy.
[edit policy-options]
user@R3# set policy-statement ecmp term 1 then load-balance per-packet
Results

ge-0/0/5 {
unit 0 {
family inet {
address 192.168.50.2/30;
}
family inet6 {
address 2001:db8:50:1:1::2/64;
}
family mpls;
}
}
xe-0/3/1 {
unit 0 {
family inet {
address 192.168.75.1/30;
}
family inet6 {
address 2001:db8:75:1:1::1/64;
}
family mpls;
}
}
ge-1/0/0 {
unit 0 {
family inet {
address 192.168.80.1/30;
}
family inet6 {
address 2001:db8:80:1:1::1/64;
545
}
family mpls;
}
}
ge-1/0/5 {
unit 0 {
family inet {
address 172.16.200.1/24;
}
family inet6 {
address 2001:db8:200:1:1::1/64;
}
}
}
ge-1/0/6 {
unit 0 {
family inet {
address 192.168.85.1/30;
}
family inet6 {
address 2001:db8:85:1:1::1/64;
}
family mpls;
}
}
xe-1/3/0 {
unit 0 {
family inet {
address 192.168.90.1/30;
}
family inet6 {
address 2001:db8:90:1:1::1/64;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 172.16.3.3/32 {
primary;
}
}
546
family inet6 {
address 2001:db8:3:3:3:3/128 {
primary;
}
}
family mpls;
}
}

rsvp {
interface all;
}
mpls {
admin-groups {
c0 0;
c1 1;
c2 2;
c3 3;
c4 4;
c5 5;
c6 6;
c7 7;
c8 8;
c9 9;
c10 10;
c11 11;
c12 12;
c13 13;
c14 14;
c15 15;
c16 16;
c17 17;
c18 18;
c19 19;
c20 20;
c21 21;
c22 22;
c23 23;
c24 24;
c25 25;
547
c26 26;
c27 27;
c28 28;
c29 29;
c30 30;
c31 31;
}
interface all;
admin-group c0;
}
}
ospf {
area 0.0.0.0 {
link-protection;
metric 10;
}
interface xe-0/3/1.0 {
metric 21;
}
metric 13;
}
metric 15;
}
link-protection;
metric 22;
}
}
}
ospf3 {
area 0.0.0.0 {
link-protection;
metric 10;
}
metric 21;
}
548
metric 13;
}
metric 15;
}
link-protection;
metric 22;
}
}
}

srlg {
srlg1 srlg-value 1001;
}
router-id 172.16.3.3;
forwarding-table {
export ecmp;
}
backup-selection {
destination 10.1.1.0/30 {
admin-group {
include-all c2;
}
}
interface all {
admin-group {
exclude c3;
549
}
srlg strict;
protection-type node;
bandwidth-greater-equal-primary;
node {
preference 172.16.7.7;
}
root-metric lowest;
metric-order root;
}
}
destination 172.16.30.0/30 {
interface all {
admin-group {
exclude c5;
}
srlg strict;
node {
}
root-metric lowest;
metric-order root;
}
}
destination 192.168.45.0/30 {
interface all {
admin-group {
exclude c5;
}
srlg strict;
node {
}
root-metric lowest;
metric-order root;
}
}
}
550
Verification
IN THIS SECTION
Verifying the Routes | 550
Verifying the OSPF Route | 554
Verifying the OSPF3 Route | 554
Verifying the Backup Selection Policy for Device R3 | 555
Verifying the Routes
Purpose
Verify that the expected routes are learned.
Action
From operational mode, run the show route command for the routing table.
user@R3> show route

172.16.3.3/32 *[Direct/0] 02:22:27

> via lo0.0
10.4.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.5.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.6.128.0/17 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.9.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.10.0.0/16 *[Static/5] 02:22:57
551
> to 10.92.31.254 via fxp0.0

10.13.4.0/23 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.13.10.0/23 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.82.0.0/15 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.84.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.85.12.0/22 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.92.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.92.16.0/20 *[Direct/0] 02:22:57
> via fxp0.0
10.92.24.195/32 *[Local/0] 02:22:57
Local via fxp0.0
10.94.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.99.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.102.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.150.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.155.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.157.64.0/19 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.160.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.204.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.205.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.206.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.207.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.209.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.212.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
552
10.213.0.0/16 *[Static/5] 02:22:57

> to 10.92.31.254 via fxp0.0
10.214.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.215.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.216.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.13.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.14.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.16.0/20 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.32.0/20 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.227.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
172.16.50.0/30 *[Direct/0] 02:19:55
> via ge-0/0/5.0
172.16.50.2/32 *[Local/0] 02:19:58
Local via ge-0/0/5.0
172.16.75.0/30 *[Direct/0] 02:19:55
> via xe-0/3/1.0
172.16.75.1/32 *[Local/0] 02:19:57
Local via xe-0/3/1.0
172.16.24.195/32 *[Direct/0] 02:22:57
> via lo0.0
172.16.0.0/12 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.102.0/23 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.136.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.136.192/32 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.137.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.233.5/32 *[OSPF/10] 00:16:55, metric 1
MultiRecv
553
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

47.0005.80ff.f800.0000.0108.0001.1280.9202.4195/152
*[Direct/0] 02:22:57
> via lo0.0

0 *[MPLS/0] 00:16:55, metric 1

Receive
1 *[MPLS/0] 00:16:55, metric 1
Receive
2 *[MPLS/0] 00:16:55, metric 1
Receive
13 *[MPLS/0] 00:16:55, metric 1
Receive

2001:db8:50:1:1::/64 *[Direct/0] 02:19:44

> via ge-0/0/5.0
2001:db8:50:1:1::2/128 *[Local/0] 02:19:58
2001:db8:75:1:1::/64 *[Direct/0] 02:19:44
> via xe-0/3/1.0
2001:db8:75:1:1::1/128 *[Local/0] 02:19:57
2001:db8::3:3:3:3/128 *[Direct/0] 02:22:27
> via lo0.0
2001:db8::128:92:24:195/128
*[Direct/0] 02:22:57
> via lo0.0
fe80::/64 *[Direct/0] 02:19:44
> via ge-0/0/5.0
[Direct/0] 02:19:43
> via xe-0/3/1.0
fe80::205:86ff:fe00:ed05/128
*[Local/0] 02:19:58
fe80::205:86ff:fe00:ed3d/128
554
*[Local/0] 02:19:57
fe80::5668:a50f:fcc1:3ca2/128
*[Direct/0] 02:22:57
> via lo0.0
Meaning
The output shows all Device R3 routes.
Verifying the OSPF Route
Purpose
Verify the routing table of OSPF.
Action
From operational mode, run the show ospf route detail command for Device R3.
user@R3> show ospf route detail


area 0.0.0.0, origin 172.16.3.3, priority low
172.16.75.0/30 Intra Network IP 21 xe-0/3/1.0
area 0.0.0.0, origin 172.16.3.3, priority low
Meaning
The output displays the routing table of OSPF routers.
Verifying the OSPF3 Route
Purpose
Verify the routing table of OSPF3.

555
Action
From operational mode, run the show ospf3 route detail command for Device R3.
user@R3> show ospf3 route detail

Type Type Type
2001:db8:50:1:1::/64 Intra Network IP 10
NH-interface ge-0/0/5.0
Area 0.0.0.0, Origin 172.16.3.3, Priority low
2001:db8:75:1:1::/64 Intra Network IP 21
NH-interface xe-0/3/1.0
Area 0.0.0.0, Origin 172.16.3.3, Priority low
Meaning
The output displays the routing table of OSPF3 routers.
Verifying the Backup Selection Policy for Device R3
Purpose
Verify the backup selection policy for Device R3.
Action
From operational mode, run the show backup-selection command for Device R3.
user@R3> show backup-selection

Prefix: 10.1.1.0/30
Interface: all
Admin-group exclude: c3
Neighbor preference: 172.16.7.7
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >=
Primary: Enabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Root-metric, Dest-metric
Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node,
Metric
Interface: xe-1/3/0.0
556
Admin-group include-all: c2
Protection Type: Link, Downstream Paths Only: Disabled, SRLG: Loose, B/w >=
Primary: Disabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Dest-metric, Root-metric
Metric Prefix: 172.16.30.0/30
Interface: all
Metric
Prefix: 172.16.45.0/30
Interface: all
Metric
Meaning
The output displays the configured policies per prefix per primary next-hop interface.
SEE ALSO

557
Example: Injecting OSPF Routes into the BGP Routing Table
IN THIS SECTION
Requirements | 557
Overview | 557
Configuration | 558
Verification | 561
Troubleshooting | 562
This example shows how to create a policy that injects OSPF routes into the BGP routing table.
Requirements
Before you begin:
• Configure network interfaces.
• Configure external peer sessions. See Example: Configuring External BGP Point-to-Point Peer
Sessions.
• Configure interior gateway protocol (IGP) sessions between peers.
Overview
IN THIS SECTION
Topology | 557
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.
Topology
558
Configuration
IN THIS SECTION
Configuring the Routing Policy | 558
Configuring Tracing for the Routing Policy | 560
Configuring the Routing Policy
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
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
559
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.

user@host# set from area 0.0.0.1
4. Specify that the route is to be accepted if the previous conditions are matched.

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
user@host# show policy-options

policy-statement injectpolicy1 {
term injectterm1 {
from {
protocol ospf;
area 0.0.0.1;
}
then accept;
560
}
}
user@host# show protocols bgp

export injectpolicy1;
Configuring Tracing for the Routing Policy
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
Guide.
1. Include a trace action in the policy.

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
561
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

policy-statement injectpolicy1 {
term injectterm1 {
then {
trace;
}
}
}

traceoptions {
file ospf-bgp-policy-log size 5m files 5;
flag policy;
}
Verification
IN THIS SECTION
Verifying That the Expected BGP Routes Are Present | 562

562
Verifying That the Expected BGP Routes Are Present
Purpose
Verify the effect of the export policy.
Action
Troubleshooting
IN THIS SECTION
Using the show log Command to Examine the Actions of the Routing Policy | 562
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
IN THIS SECTION
Requirements | 563
Overview | 563
563
Configuration | 564
Verification | 566
This example shows how to create a policy that redistributes static routes into OSPF.
Requirements
Before you begin:
Overview
IN THIS SECTION
Topology | 563
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.
Topology
564
Configuration
IN THIS SECTION
Procedure | 564
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
Procedure
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
565
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.
[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
[edit]
user@host# commit
Results
Confirm your configuration by entering the show policy-options and show protocols ospf commands. If

policy-statement exportstatic1 {
term exportstatic1 {
then accept;
566
}
}

export exportstatic1;
To confirm your OSPFv3 configuration, enter the show policy-options and the show protocols ospf3
commands.
Verification
IN THIS SECTION
Verifying That the Expected Static Routes Are Present | 566
Verifying That AS External LSAs Are Added to the Routing Table | 566
Verifying That the Expected Static Routes Are Present
Purpose
Verify the effect of the export policy.
Action
Verifying That AS External LSAs Are Added to the Routing Table
Purpose
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.
567
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
IN THIS SECTION
Requirements | 567
Overview | 567
Configuration | 568
Verification | 572
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).
Requirements
Before you begin:
Election.
• Configure a single-area OSPF network. See Example: Configuring a Single-Area OSPF Network .
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.
568
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.
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.
Configuration
IN THIS SECTION
Procedure | 569
To quickly configure an OSPF import policy, paste them into a text file, remove any line breaks, change
any details necessary to match your network configuration, copy and paste the commands into the CLI
at the [edit] hierarchy level, and then enter commit from configuration mode.
569
[edit]
set protocols ospf export export_static
set policy-options policy-statement export_static from protocol static
set policy-options policy-statement export_static then accept
[edit]
set protocols ospf import filter_routes
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
Procedure
To configure an OSPF import policy:
[edit]
[edit]
2. Enable OSPF on the interfaces.

570
[edit]
[edit]
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
[edit]
user@host# commit
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.
571
Output for R1:

so-0/2/0 {
unit 0 {
family inet {
address 10.0.2.1/30;
}
}
}

policy-statement export_static {
then accept;
}

export export_static;
area 0.0.0.0 {
}
Output for R2:

so-0/2/0 {
unit 0 {
family inet {
address 10.0.2.2/30;
}
572
}
}

policy-statement filter_routes {
from {
}
then reject;
}

import filter_routes;
area 0.0.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.
Verification
IN THIS SECTION
Verifying the Routing Table | 573
Purpose
Verify that OSPF is advertising the static route in the OSPF database.
573
Action
From operational mode, enter the show ospf database for OSPFv2, and enter the show ospf3 database
command for OSPFv3.
Verifying the Routing Table
Purpose
Verify the entries in the routing table.
Action
Example: Configuring a Route Filter Policy to Specify Priority for Prefixes

Learned Through OSPF
IN THIS SECTION
Requirements | 573
Overview | 574
Configuration | 575
Verification | 579
This example shows how to create an OSPF import policy that prioritizes specific prefixes learned
through OSPF.
Requirements
Before you begin:
574
• Control OSPF designated router election See Example: Controlling OSPF Designated Router Election
• Configure a single-area OSPF network. See Example: Configuring a Single-Area OSPF Network .
Overview
IN THIS SECTION
Topology | 575
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.
• 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 192.0.2.0/24 orlonger are installed
first because they have a priority of high. Routes matching 198.51.100.0/24 orlonger are installed next
575
because they have a priority of medium. Routes matching 203.0.113.0/24 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.
Topology
Configuration
IN THIS SECTION
Procedure | 576
To quickly configure an OSPF import policy that prioritizes specific prefixes learned through OSPF, copy
the following commands, paste them into a text file, remove any line breaks, change any details
necessary to match your network configuration, copy and paste the commands into the CLI at the [edit]
hierarchy level, and then enter commit from configuration mode.
[edit]
set policy-options policy-statement ospf-import term t1 from route-filter 203.0.113.0/24 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 then priority medium
set policy-options policy-statement ospf-import term t3 then priority high
set protocols ospf import ospf-import
576

Procedure
To configure an OSPF import policy that prioritizes specific prefixes:
[edit]
[edit]
3. 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 203.0.113.0/24
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
orlonger
user@host# set policy-options policy-statement ospf-import term t2 then priority medium
577

orlonger
user@host# set policy-options policy-statement ospf-import term t3 then priority high
4. Apply the policy to OSPF.
[edit]
user@host# set protocols ospf import ospf-import
[edit]
user@host# commit
Results
Confirm your configuration by entering the show interfaces, show policy-options, and the show

fe-0/1/0 {
unit 0 {
family inet {
address 192.168.8.4/30;
}
}
}
fe-0/2/0 {
unit 0 {
family inet {
address 192.168.8.5/30;
}
578
}
}

import ospf-import;
area 0.0.0.0 {
}

policy-statement ospf-import {
term t1 {
from {
route-filter 203.0.113.0/24 orlonger;
}
then {
priority low;
accept;
}
}
term t2 {
from {
}
then {
priority medium;
accept;
}
}
term t3 {
from {
}
then {
priority high;
accept;
}
579
}
}

import ospf-import;
area 0.0.0.0 {
}
To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show
protocols ospf3 commands.
Verification
IN THIS SECTION
Verifying the Prefix Priority in the OSPF Routing Table | 579
Verifying the Prefix Priority in the OSPF Routing Table
Purpose
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.
580
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
IN THIS SECTION
Requirements | 580
Overview | 581
Configuration | 583
Verification | 592
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.
Requirements
Before you begin:
581
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.
582
Figure 33 on page 582 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 33: Sample Topology Used for an OSPF Export Network Summary Policy
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.1 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.1/30 and connects to R4.
583
10.0.2.4/30 and connects to R3. Interface fe-1/1/0 has an IP address of 10.0.8.6/30 and connects to
R5. Interface fe-1/0/0 has an IP address of 10.0.8.9/30 and connects to R6.
connects to R4.

and connects to R4.
Configuration
IN THIS SECTION
Procedure | 585
To quickly configure an OSPF export policy for network summaries, copy the following commands, paste
[edit]
[edit]
584

[edit]
[edit]
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.4 network-summary-export export-policy
[edit]
[edit]
585
Procedure
To configure an configure an OSPF export policy for network summaries:
[edit]
[edit]
[edit]
user@R3#set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
[edit]
586

[edit]
[edit]
[edit]
[edit]
[edit]
[edit]
587

[edit]
[edit]
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
[edit]
user@host# commit
Results
588
Output for R1:

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;
}
}
}

area 0.0.0.3 {
}
Output for R2:

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;
}
589
}
}

area 0.0.0.3 {
}
Output for R3:

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;
}
}
}

area 0.0.0.0 {
}
area 0.0.0.3 {
590
}
Output for R4:

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;
}
}
}

area 0.0.0.0 {
}
area 0.0.0.4 {
network-summary-export export-policy;
591
}

policy-statement export-policy {
term term1 {
from {
route-filter 10.0.4.4/30 prefix-length-range /30-/30;
}
then accept;
}
}
Output for R5:

fe-1/1/0 {
unit 0 {
family inet {
address 10.0.8.5/30;
}
}
}

area 0.0.0.4 {
}
Output for R6:

fe-1/0/0 {
unit 0 {
family inet {
address 10.0.8.7/30;
}
592
}
}

area 0.0.0.4 {
}
protocols ospf3 commands on the appropriate device.
Verification
IN THIS SECTION
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 inter-area-prefix area 0.0.0.4 command for OSPFv3.
593
Purpose
Verify that the routes corresponding to the rejected network summaries are no longer present in R4’s,
R5’s, or R6’s routing table.
Action
From operational mode, enter the show route protocol ospf command for both OSPFv2 and OSPFv3.
Example: Configuring an OSPF Import Policy for Network Summaries
IN THIS SECTION
Requirements | 593
Overview | 593
Configuration | 595
Verification | 604
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.
Requirements
Before you begin:
Election.
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
594
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:
• 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 34 on page 594 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 34: Sample Topology Used for an OSPF Import Network Summary Policy
595
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:

and connects to R3. Interface fe-0/0/1 has an IP address of 10.0.4.5/30 and connects to R2.
connects to R1. Interface fe-1/0/0 has an IP address of 10.0.4.1/30 and connects to R3.
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.1/30 and connects to R4.
10.0.2.1/30 and connects to R3. Interface fe-1/1/0 has an IP address of 10.0.8.6/30 and connects to
R5. Interface fe-1/0/0 has an IP address of 10.0.8.9/30 and connects to R6.
connects to R4.

and connects to R4.
Configuration
IN THIS SECTION
Procedure | 596
596
Procedure
To quickly configure an OSPF import policy for network summaries, copy the following commands, paste
[edit]
[edit]
[edit]
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 network-summary-import import-policy
597
[edit]
[edit]
[edit]
To configure an configure an OSPF import policy for network summaries:

598
[edit]
[edit]
[edit]
user@R3#set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
[edit]
[edit]
[edit]

599
[edit]
[edit]
[edit]
[edit]
[edit]
[edit]
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
600
prefix-length-range /30-/30
user@R3# set policy-options policy-statement import-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.3 network-summary-import import-policy
[edit]
user@host# commit
Results
Output for R1:

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;
}
601
}
}

area 0.0.0.3 {
}
Output for R2:

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.1/30;
}
}
}

area 0.0.0.3 {
}
Output for R3:

fe-0/0/1 {
unit 0 {
602
family inet {
address 10.0.2.1/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;
}
}
}

area 0.0.0.0 {
}
area 0.0.0.3 {
network-summary-import import policy;
}

policy-statement import-policy {
term term1 {
from {
route-filter 10.0.4.12/30 prefix-length-range /30-/30;
}
then accept;
}
}
603
Output for R4:

fe-0/0/1 {
unit 0 {
family inet {
address 10.0.2.1/30;
}
}
}
fe-1/0/0 {
unit 0 {
family inet {
address 10.0.8.9/30;
}
}
}
fe-1/1/0 {
unit 0 {
family inet {
address 10.0.8.6/30;
}
}
}

area 0.0.0.0 {
}
area 0.0.0.4 {
}
Output for R5:

fe-1/1/0 {
unit 0 {
family inet {
604
address 10.0.8.5/30;
}
}
}

area 0.0.0.4 {
}
Output for R6:

fe-1/0/0 {
unit 0 {
family inet {
address 10.0.8.10/30;
}
}
}

area 0.0.0.4 {
}
protocols ospf3 commands on the appropriate device.
Verification
IN THIS SECTION

605
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 inter-area-prefix area 0.0.0.4 command for OSPFv3.
Purpose
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.
Action
From operational mode, enter the show route protocol ospf command for both OSPFv2 and OSPFv3.
Example: Redistributing OSPF Routes into IS-IS
IN THIS SECTION
Requirements | 606
Overview | 606
Configuration | 607
Verification | 615
606
This example shows how to redistribute OSPF routes into an IS-IS network.
Requirements
Overview
IN THIS SECTION
Topology | 607
Export policy can be applied to IS-IS to facilitate route redistribution.
Junos OS does not support the application of import policy for link-state routing protocols like IS-IS
because such policies can lead to inconsistent link-state database (LSDB) entries, which in turn can
result in routing inconstancies.
In this example, OSPF routes 192.168.0/24 through 192.168.3/24 are redistributed into IS-IS area
49.0002 from Device R2.
In addition, policies are configured to ensure that Device R1 can reach destinations on the 10.0.0.44/30
network, and that Device R3 can reach destinations on the 10.0.0.36/30 network. This enables end-to-
end reachability.
607
Figure 35: IS-IS Route Redistribution Topology
section "No Link Title" describes the steps on Device R2. "No Link Title" describes the steps on Device
R3.
Topology
Configuration
IN THIS SECTION
Procedure | 608
608
Procedure
Device R1
set interfaces fe-1/2/0 unit 0 description to-R7

set interfaces fe-1/2/0 unit 0 family iso
set interfaces lo0 unit 0 family iso address 49.0002.0172.0016.0305.00
set protocols isis interface fe-1/2/0.0
set protocols isis interface lo0.0
Device R2
set interfaces fe-1/2/1 unit 0 description to-R5

set interfaces fe-1/2/1 unit 0 family iso
set interfaces fe-1/2/0 unit 0 description to-OSPF-network
set interfaces lo0 unit 0 family iso address 49.0002.0172.0016.0907.00
set protocols isis export ospf-isis
set protocols isis export send-direct-to-isis-neighbors
set protocols isis interface fe-1/2/1.0
set protocols isis interface lo0.0
set protocols ospf export send-direct-to-ospf-neighbors
set protocols ospf area 0.0.0.1 interface fe-1/2/0.0
set policy-options policy-statement ospf-isis term 1 from protocol ospf
set policy-options policy-statement ospf-isis term 1 from route-filter 192.168.0.0/22 longer
set policy-options policy-statement ospf-isis term 1 then accept
set policy-options policy-statement send-direct-to-isis-neighbors from protocol direct
set policy-options policy-statement send-direct-to-isis-neighbors from route-filter 10.0.0.44/30 exact
set policy-options policy-statement send-direct-to-isis-neighbors then accept
609
set policy-options policy-statement send-direct-to-ospf-neighbors from protocol direct

set policy-options policy-statement send-direct-to-ospf-neighbors from route-filter 10.0.0.36/30 exact
set policy-options policy-statement send-direct-to-ospf-neighbors then accept
Device R3

set protocols ospf export ospf
set policy-options policy-statement ospf term 1 from protocol static
set policy-options policy-statement ospf term 1 then accept
1. Configure the network interfaces.
[edit interfaces]
user@R2# set fe-1/2/1 unit 0 description to-R5
user@R2# set fe-1/2/1 unit 0 family inet address 10.0.0.37/30
user@R2# set fe-1/2/1 unit 0 family iso
user@R2# set fe-1/2/0 unit 0 description to-OSPF-network
user@R2# set lo0 unit 0 family iso address 49.0002.0172.0016.0907.00
610
2. Configure IS-IS on the interface facing Device R1 and the loopback interface.
[edit protocols isis]

user@R2# set interface lo0.0
3. Configure the policy that enables Device R1 to reach the 10.0.0.44/30 network.
[edit policy-options policy-statement send-direct-to-isis-neighbors]

user@R2# set from protocol direct
user@R2# set from route-filter 10.0.0.44/30 exact
user@R2# set then accept
4. Apply the policy that enables Device R1 to reach the 10.0.0.44/30 network.

user@R2# set export send-direct-to-isis-neighbors

user@R2# set area 0.0.0.1 interface fe-1/2/0.0
user@R2# set area 0.0.0.1 interface lo0.0 passive
6. Configure the OSPF route redistribution policy.
[edit policy-options policy-statement ospf-isis term 1]

user@R2# set from protocol ospf
user@R2# set from route-filter 192.168.0.0/22 longer
7. Apply the OSPF route redistribution policy to the IS-IS instance.

user@R2# set export ospf-isis
611
8. Configure the policy that enables Device R3 to reach the 10.0.0.36/30 network.
[edit policy-options policy-statement send-direct-to-ospf-neighbors]

user@R2# set from protocol direct
user@R2# set from route-filter 10.0.0.36/30 exact
9. Apply the policy that enables Device R3 to reach the 10.0.0.36/30 network.

user@R2# set export send-direct-to-ospf-neighbors
Guide.
To configure multi-level IS-IS:
1. Configure the network interfaces.
Multiple addresses are configured on the loopback interface to simulate multiple route destinations.
[edit interfaces]
2. Configure static routes to the loopback interface addresses.
These are the routes that are redistributed into IS-IS.
[edit routing-options static]

user@R3# set route 192.168.0.0/24 discard
612


4. Configure the OSPF policy to export the static routes.
[edit policy-options policy-statement ospf term 1]

user@R3# set from protocol static
5. Apply the OSPF export policy.

user@R3# set export ospf
Results
Device R2

fe-1/2/1 {
unit 0 {
description to-R5;
family inet {
address 10.0.0.37/30;
}
family iso;
}
}
613
fe-1/2/0 {
unit 0 {
description to-OSPF-network;
family inet {
address 10.0.0.45/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 172.16.9.7/32;
}
family iso {
address 49.0002.0172.0016.0907.00;
}
}
}

isis {
export [ ospf-isis send-direct-to-isis-neighbors ];
interface lo0.0;
}
ospf {
export send-direct-to-ospf-neighbors;
area 0.0.0.1 {
interface lo0.0 {
passive;
}
}
}

policy-statement ospf-isis {
term 1 {
from {
protocol ospf;
614
route-filter 192.168.0.0/22 longer;

}
then accept;
}
}
policy-statement send-direct-to-isis-neighbors {
from {
protocol direct;
}
then accept;
}
policy-statement send-direct-to-ospf-neighbors {
from {
protocol direct;
}
then accept;
}
Device R3

fe-1/2/0 {
unit 0 {
family inet {
address 10.0.0.46/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
address 192.168.2.1/32;
address 192.168.3.1/32;
address 192.168.0.1/32;
}
615
}
}

ospf {
export ospf;
area 0.0.0.1 {
interface lo0.0 {
passive;
}
}
}

policy-statement ospf {
term 1 {
then accept;
}
}

static {
route 192.168.0.0/24 discard;
}
Verification
IN THIS SECTION
Verifying OSPF Route Advertisement | 616

616
Verifying Route Redistribution | 617
Verifying Connectivity | 618
Verifying OSPF Route Advertisement
Purpose
Make sure that the expected routes are advertised by OSPF.
Action
From operational mode on Device R2, enter the show route protocol ospf command.
user@R2> show route protocol ospf

192.168.0.0/24 *[OSPF/150] 03:54:21, metric 0, tag 0

> to 10.0.0.46 via fe-1/2/0.0
192.168.0.1/32 *[OSPF/10] 03:54:21, metric 1
> to 10.0.0.46 via fe-1/2/0.0
192.168.1.0/24 *[OSPF/150] 03:54:21, metric 0, tag 0
> to 10.0.0.46 via fe-1/2/0.0
192.168.1.1/32 *[OSPF/10] 03:54:21, metric 1
> to 10.0.0.46 via fe-1/2/0.0
192.168.2.0/24 *[OSPF/150] 03:54:21, metric 0, tag 0
> to 10.0.0.46 via fe-1/2/0.0
192.168.2.1/32 *[OSPF/10] 03:54:21, metric 1
> to 10.0.0.46 via fe-1/2/0.0
192.168.3.0/24 *[OSPF/150] 03:54:21, metric 0, tag 0
> to 10.0.0.46 via fe-1/2/0.0
192.168.3.1/32 *[OSPF/10] 03:54:21, metric 1
> to 10.0.0.46 via fe-1/2/0.0
224.0.0.5/32 *[OSPF/10] 03:56:03, metric 1
617
MultiRecv
Meaning
The 192.168/16 routes are advertised by OSPF.
Verifying Route Redistribution
Purpose
Make sure that the expected routes are redistributed from OSPF into IS-IS.
Action
From operational mode on Device R1, enter the show route protocol isis command.
user@R1> show route protocol isis

10.0.0.44/30 *[IS-IS/160] 03:45:24, metric 20

> to 10.0.0.37 via fe-1/2/0.0
172.16.9.7/32 *[IS-IS/15] 03:49:46, metric 10
> to 10.0.0.37 via fe-1/2/0.0
192.168.0.0/24 *[IS-IS/160] 03:49:46, metric 10
> to 10.0.0.37 via fe-1/2/0.0
192.168.0.1/32 *[IS-IS/160] 03:49:46, metric 11, tag2 1
> to 10.0.0.37 via fe-1/2/0.0
192.168.1.0/24 *[IS-IS/160] 03:49:46, metric 10
> to 10.0.0.37 via fe-1/2/0.0
192.168.1.1/32 *[IS-IS/160] 03:49:46, metric 11, tag2 1
> to 10.0.0.37 via fe-1/2/0.0
192.168.2.0/24 *[IS-IS/160] 03:49:46, metric 10
> to 10.0.0.37 via fe-1/2/0.0
192.168.2.1/32 *[IS-IS/160] 03:49:46, metric 11, tag2 1
> to 10.0.0.37 via fe-1/2/0.0
192.168.3.0/24 *[IS-IS/160] 03:49:46, metric 10
618
> to 10.0.0.37 via fe-1/2/0.0

192.168.3.1/32 *[IS-IS/160] 03:49:46, metric 11, tag2 1
> to 10.0.0.37 via fe-1/2/0.0
Meaning
The 192.168/16 routes are redistributed into IS-IS.
Verifying Connectivity
Purpose
Check that Device R1 can reach the destinations on Device R3.
Action
From operational mode, enter the ping command.
user@R1> ping 192.168.1.1

PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=63 time=2.089 ms
Meaning
These results confirm that Device R1 can reach the destinations in the OSPF network.
Release History Table

Release Description
20.3R1 Starting in Junos OS Release 20.3R1, you can configure fate-sharing protection in TI-LFA networks for
segment routing to choose a fast reroute path that does not include fate-sharing groups in the topology-
independent loop-free alternate (TI-LFA) backup paths to avoid fate-sharing failures.
20.3R1 Starting in Junos OS Release 20.3R1, you can configure Shared Risk Link Group (SRLG) protection in TI-
LFA networks for segment routing to choose a fast reroute path that does not include SRLG links in the
topology-independent loop-free alternate (TI-LFA) backup paths.
619
19.3R1 Starting in Junos OS Release 19.3R1, Junos supports creation of OSPF topology-independent TI-LFA
backup paths where the prefix SID is learned from a segment routing mapping server advertisement
when the PLR and mapping server are both in the same OSPF area.
OSPF Routing Policy Overview

Understanding Route Filters for Use in Routing Policy Match Conditions
15 CHAPTER
Configure OSPFv2 Sham Links
Configuring OSPFv2 Sham Links | 621

621
Configuring OSPFv2 Sham Links
IN THIS SECTION
OSPFv2 Sham Links Overview | 621
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. A back-door link is a backup link that connects
customer edge (CE) devices in case the VPN backbone is unavailable. When such a backup link is
available and the CE devices are in the same OSPF area, the default behavior is to prefer this backup link
over the VPN backbone. This is because the backup link is considered an intra-area link, while the VPN
backbone is always considered an interarea link. Intra-area links are always preferred over interarea links.
The sham link is an unnumbered point-to-point intra-area link between PE devices. When the VPN
backbone has a sham intra-area link, this sham link can be preferred over the backup link if the sham link
has a lower OSPF metric than the backup link.
The sham link 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 36 on page 622 shows an OSPFv2 sham link. Router CE1 and Router CE2 are located
in the same OSPFv2 area. These customer edge (CE) routing devices are linked together by a Layer 3
622
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 36: 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.
623
NOTE: In Junos OS Release 16.1 and later, OSPF sham-links are supported on default instances.
The cost of the sham-link is dynamically set to the aigp-metric of the BGP route if no metric is
configured on the sham-link by the user. If the aigp-metric is not present in the BGP route then
the sham-link cost defaults to 1.
Example: Configuring OSPFv2 Sham Links
IN THIS SECTION
Requirements | 623
Overview | 623
Configuration | 625
Verification | 633
This example shows how to enable OSPFv2 sham links on a PE routing device.
Requirements
Overview
IN THIS SECTION
Topology | 624
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
624
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 an extra loopback interface 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 red.
Figure 37 on page 624 shows an OSPFv2 sham link.
Topology
Figure 37: 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.

625
section "No Link Title"describes the steps on Device PE1.
Configuration
IN THIS SECTION
Procedure | 625
Procedure
CE1

set interfaces fe-1/2/0 unit 0 family mpls
set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 metric 100
set policy-options policy-statement send-direct from protocol direct
set policy-options policy-statement send-direct then accept
PE1

626

set protocols mpls interface fe-1/2/1.0
set protocols bgp group toR4 type internal
set protocols bgp group toR4 local-address 192.0.2.2
set protocols bgp group toR4 family inet-vpn unicast
set protocols bgp group toR4 neighbor 192.0.2.4
set protocols ldp interface fe-1/2/1.0
set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp
set policy-options policy-statement bgp-to-ospf term 1 then accept
set policy-options policy-statement bgp-to-ospf term 2 then reject
set routing-instances red instance-type vrf
set routing-instances red interface fe-1/2/0.0
set routing-instances red interface lo0.1
set routing-instances red route-distinguisher 2:1
set routing-instances red vrf-target target:2:1
set routing-instances red protocols ospf export bgp-to-ospf
set routing-instances red protocols ospf sham-link local 198.51.100.2
set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10
set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/0.0
set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1

627
PE2

set protocols mpls interface fe-1/2/0.0
set protocols bgp group toR2 type internal
set protocols bgp group toR2 local-address 192.0.2.4
set protocols bgp group toR2 family inet-vpn unicast
set protocols bgp group toR2 neighbor 192.0.2.2
set protocols ldp interface fe-1/2/0.0
set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp
set policy-options policy-statement bgp-to-ospf term 1 then accept
set policy-options policy-statement bgp-to-ospf term 2 then reject
set routing-instances red instance-type vrf
set routing-instances red interface fe-1/2/1.0
set routing-instances red interface lo0.1
set routing-instances red route-distinguisher 2:1
set routing-instances red vrf-target target:2:1
set routing-instances red protocols ospf export bgp-to-ospf
set routing-instances red protocols ospf sham-link local 198.51.100.4
set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.2 metric 10
set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/1.0
set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1
CE2

628

set policy-options policy-statement send-direct from protocol direct
set policy-options policy-statement send-direct then accept
To configure OSPFv2 sham links on each PE device:
1. Configure the interfaces, including two loopback interfaces.
[edit interfaces]
user@PE1# set fe-1/2/0 unit 0 family inet address 10.1.1.2/30
user@PE1# set fe-1/2/0 unit 0 family mpls
user@PE1# set fe-1/2/1 unit 0 family inet address 10.1.1.5/30
user@PE1# set fe-1/2/1 unit 0 family mpls
user@PE1# set lo0 unit 0 family inet address 192.0.2.2/24
user@PE1# set lo0 unit 1 family inet address 198.51.100.2/24
2. Configure MPLS on the core-facing interface.

user@PE1# set interface fe-1/2/1.0
3. Configure internal BGP (IBGP).
[edit ]
user@PE1# set protocols bgp group toR4 type internal
user@PE1# set protocols bgp group toR4 local-address 192.0.2.2
user@PE1# set protocols bgp group toR4 family inet-vpn unicast
user@PE1# set protocols bgp group toR4 neighbor 192.0.2.4
629
4. Configure OSPF on the core-facing interface and on the loopback interface that is being used in the
main instance.

user@PE1# set interface lo0.0 passive
5. Configure LDP or RSVP on the core-facing interface and on the loopback interface that is being
used in the main instance.

user@PE1# set interface lo0.0
6. Configure a routing policy for use in the routing instance.
[edit policy-options policy-statement bgp-to-ospf]

user@PE1# set term 1 from protocol bgp
user@PE1# set term 1 then accept
user@PE1# set term 2 then reject
7. Configure the routing instance.
[edit routing-instances red]

user@PE1# set instance-type vrf
user@PE1# set route-distinguisher 2:1
user@PE1# set vrf-target target:2:1
user@PE1# set protocols ospf export bgp-to-ospf
user@PE1# set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
8. Configure the OSPFv2 sham link.
Include the extra loopback interface in the routing instance and also in the OSPF configuration.
630
Notice that the metric on the sham-link interface is set to 10. On Device CE1’s backup OSPF link,
the metric is set to 100. This causes the sham link to be the preferred link.
[edit routing-instances red]

user@PE1# set interface lo0.1
user@PE1# set protocols ospf sham-link local 198.51.100.2
user@PE1# set protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10
user@PE1# set protocols ospf area 0.0.0.0 interface lo0.1
9. Configure the autonomous system (AS) number and the router ID.
user@PE1# set router-id 192.0.2.2
user@PE1# set autonomous-system 2
[edit]
user@R1# 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
Output for PE1:
user@PE1# show interfaces

fe-1/2/0 {
unit 0{
family inet {
address 10.1.1.2/30;
}
family mpls;
}
}
fe-1/2/1 {
631
unit 0 {
family inet {
address 10.1.1.5/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.2/24;
}
}
unit 1 {
family inet {
address 198.51.100.2/24;
}
}
}
user@PE1# show protocols

mpls {
}
bgp {
group toR4 {
type internal;
family inet-vpn {
unicast;
}
neighbor 192.0.2.4;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
632
}
ldp {
interface lo0.0;
}
user@PE1# show policy-options

policy-statement bgp-to-ospf {
term 1 {
from protocol bgp;
then accept;
}
term 2 {
then reject;
}
}
user@PE1# show routing-instances

red {
instance-type vrf;
interface lo0.1;
route-distinguisher 2:1;
vrf-target target:2:1;
protocols {
ospf {
export bgp-to-ospf;
sham-link local 198.51.100.2;
area 0.0.0.0 {
sham-link-remote 198.51.100.4 metric 10;
interface lo0.1;
}
}
633
}
}
user@PE1# show routing-options

Verification
IN THIS SECTION
Verifying the Sham Link Interfaces | 633
Verifying the Local and Remote End Points of the Sham Link | 634
Verifying the Sham Link Adjacencies | 634
Verifying the Link-State Advertisement | 635
Verifying the Path Selection | 635
Verifying the Sham Link Interfaces
Purpose
Verify the sham link interface. The sham link is treated as an interface in OSPFv2, with the named
displayed as shamlink.<unique identifier>, where the unique identifier is a number. For example,
shamlink.0. The sham link appears as a point-to-point interface.
Action
From operational mode, enter the show ospf interface instance instance-name command.
user@PE1> show ospf interface instance red

lo0.1 DR 0.0.0.0 198.51.100.2
0.0.0.0 0
634
fe-1/2/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1

shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Verifying the Local and Remote End Points of the Sham Link
Purpose
Verify the local and remote end points of the sham link. The MTU for the sham link interface is always
zero.
Action
From operational mode, enter the show ospf interface instance instance-name detail command.
user@PE1> show ospf interface shamlink.0 instance red

shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 0.0.0.0, Mask: 0.0.0.0, MTU: 0, Cost: 10
Local: 198.51.100.2, Remote: 198.51.100.4
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None, No eligible backup
Topology default (ID 0) -> Cost: 10
Verifying the Sham Link Adjacencies
Purpose
Verify the adjacencies between the configured sham links.
Action
From operational mode, enter the show ospf neighbor instance instance-name command.
user@PE1> show ospf neighbor instance red

10.1.1.1 fe-1/2/0.0 Full 192.0.2.1 128 35
635
198.51.100.4 shamlink.0 Full 198.51.100.4

0 31
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.
user@PE1> show ospf database instance red
OSPF database, Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len
Router 192.0.2.1 192.0.2.1 0x80000009 1803 0x22 0x6ec7 72
Router 192.0.2.5 192.0.2.5 0x80000007 70 0x22 0x2746 72
Router *198.51.100.2 198.51.100.2 0x80000006 55 0x22
0xda6b 60
Router 198.51.100.4 198.51.100.4 0x80000005 63 0x22
0xb19 60
Network 10.0.0.18 192.0.2.5 0x80000002 70 0x22 0x9a71 32
OSPF AS SCOPE link state database
Extern 198.51.100.2 198.51.100.4 0x80000002 72 0xa2
0x343 36
Extern *198.51.100.4 198.51.100.2 0x80000002 71 0xa2
0xe263 36
Verifying the Path Selection
Purpose
Verify that the Layer 3 VPN path is used instead of the backup path.
636
Action
From operational mode, enter the traceroute command from Device CE1 to Device CE2.
user@CE1> traceroute 192.0.2.5
traceroute to 192.0.2.5 (192.0.2.5), 30 hops max, 40 byte packets

1 10.1.1.2 (10.1.1.2) 1.930 ms 1.664 ms 1.643 ms
2 * * *
3 10.1.1.10 (10.1.1.10) 2.485 ms 1.435 ms 1.422 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 192.0.2.5 (192.0.2.5) 1.347 ms 1.362 ms 1.329 ms
Meaning
The traceroute operation shows that the Layer 3 VPN is the preferred path. If you were to remove the
sham link or if you were to modify the OSPF metric to prefer that backup path, the traceroute would
show that the backup path is preferred.
Day One: Advanced OSPF in the Enterprise

16 CHAPTER
Configure OSPF on Logical Systems
Configuring OSPF on Logical Systems | 638

638
Configuring OSPF on Logical Systems
IN THIS SECTION
OSPF Support for Logical Systems | 638
Example: Configuring OSPF on Logical Systems Within the Same Router | 639
OSPF Support for Logical Systems
IN THIS SECTION
Introduction to Logical Systems | 638
OSPF and Logical Systems | 638
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)]

639
• [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)]
Example: Configuring OSPF on Logical Systems Within the Same Router
IN THIS SECTION
Requirements | 639
Overview | 639
Configuration | 641
Verification | 646
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 Device Using Logical Tunnel Interfaces on MX Series Routers and EX
Series Switches.
Overview
IN THIS SECTION
Topology | 640
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
640
all logical system interfaces that participate in the OSPF domain and specifies the area that the
interfaces are in.
Topology
Figure 38 on page 640 shows the sample network.
Figure 38: OSPF on Logical Systems

641
Configuration
IN THIS SECTION
Procedure | 642
Results | 644
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 protocols ospf area 0.0.0.0 interface lt-1/2/0.0
642
Procedure
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
[edit]
[edit]
643

[edit]
[edit]
[edit]
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
644
[edit]
user@host# commit
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 {
peer-unit 1;
family inet {
address 10.0.0.1/30;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lt-1/2/0.0;
}
}
}
}
LS2 {
645
interfaces {
lt-1/2/0 {
unit 1 {
peer-unit 2;
family inet {
address 10.0.0.2/30;
}
}
unit 4 {
peer-unit 3;
family inet {
address 10.0.2.2/30;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
}
}
}
}
LS3 {
interfaces {
lt-1/2/0 {
unit 3 {
peer-unit 4;
family inet {
address 10.0.2.1/30;
}
}
unit 5 {
646
peer-unit 0;
family inet {
address 10.0.1.1/30;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
}
}
}
}
Verification
IN THIS SECTION
Verifying That the Logical Systems Are Up | 646
Verifying Connectivity Between the Logical Systems | 647
Verifying That the Logical Systems Are Up
Purpose
Make sure that the interfaces are properly configured.
Action
user@host> show interfaces terse

...
lt-1/2/0 up up
647
lt-1/2/0.0 up up inet 10.0.1.2/30

lt-1/2/0.1 up up inet 10.0.0.2/30
lt-1/2/0.2 up up inet 10.0.0.1/30
lt-1/2/0.3 up up inet 10.0.2.1/30
lt-1/2/0.4 up up inet 10.0.2.2/30
lt-1/2/0.5 up up inet 10.0.1.1/30
...
Verifying Connectivity Between the Logical Systems
Purpose
Make sure that the OSPF adjacencies are established by checking the OSPF neighbor tables, checking
the routing tables, and pinging the logical systems.
Action
user@host> show ospf neighbor logical-system LS1

10.0.1.1 lt-1/2/0.0 Full 10.0.1.1 128 37
10.0.0.2 lt-1/2/0.2 Full 10.0.0.2 128 33

10.0.0.1 lt-1/2/0.1 Full 10.0.0.1 128 32
10.0.2.1 lt-1/2/0.4 Full 10.0.1.1 128 36

10.0.2.2 lt-1/2/0.3 Full 10.0.0.2 128 36
10.0.1.2 lt-1/2/0.5 Full 10.0.0.1 128 37
user@host> show route logical-system LS1

10.0.0.0/30 *[Direct/0] 00:28:00

648
> via lt-1/2/0.2

10.0.0.1/32 *[Local/0] 00:28:00
Local via lt-1/2/0.2
10.0.1.0/30 *[Direct/0] 00:28:00
> via lt-1/2/0.0
10.0.1.2/32 *[Local/0] 00:28:00
10.0.2.0/30 *[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
224.0.0.5/32 *[OSPF/10] 00:28:03, metric 1
MultiRecv

10.0.0.0/30 *[Direct/0] 00:28:31

> via lt-1/2/0.1
10.0.0.2/32 *[Local/0] 00:28:32
10.0.1.0/30 *[OSPF/10] 00:27:38, metric 2
> to 10.0.0.1 via lt-1/2/0.1
to 10.0.2.1 via lt-1/2/0.4
10.0.2.0/30 *[Direct/0] 00:28:32
> via lt-1/2/0.4
10.0.2.2/32 *[Local/0] 00:28:32
224.0.0.5/32 *[OSPF/10] 00:28:34, metric 1
MultiRecv

10.0.0.0/30 *[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
10.0.1.0/30 *[Direct/0] 00:29:13
> via lt-1/2/0.5
649
10.0.1.1/32 *[Local/0] 00:29:15

10.0.2.0/30 *[Direct/0] 00:29:14
> via lt-1/2/0.3
10.0.2.1/32 *[Local/0] 00:29:15
224.0.0.5/32 *[OSPF/10] 00:29:16, metric 1
MultiRecv
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
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
Logical Systems and Tenant Systems User Guide for Security Devices
Example: Creating an Interface on a Logical System
Example: Connecting Logical Systems Within the Same Device Using Logical Tunnel Interfaces on MX
Series Routers and EX Series Switches
Example: Configuring a Conditional OSPF Default Route Policy on Logical Systems
650
Example: Configuring an OSPF Default Route Policy on Logical Systems

Example: Configuring an OSPF Import Policy on Logical Systems
17 CHAPTER
Troubleshooting Network Issues
Troubleshooting Network Issues | 652

652
Troubleshooting Network Issues
IN THIS SECTION
Working with Problems on Your Network | 652
Isolating a Broken Network Connection | 653
Identifying the Symptoms of a Broken Network Connection | 655
Isolating the Causes of a Network Problem | 657
Taking Appropriate Action for Resolving the Network Problem | 658
Evaluating the Solution to Check Whether the Network Problem Is Resolved | 660
Checklist for Tracking Error Conditions | 662
Configure Routing Protocol Process Tracing | 664
Configure Routing Protocol Tracing for a Specific Routing Protocol | 668
Monitor Trace File Messages Written in Near-Real Time | 671
Stop Trace File Monitoring | 672
Working with Problems on Your Network
IN THIS SECTION
Problem | 652
Solution | 653
Problem
Description
This checklist provides links to troubleshooting basics, an example network, and includes a summary of
the commands you might use to diagnose problems with the router and network.
653
Solution
Table 2: Checklist for Working with Problems on Your Network
Tasks Command or Action
Isolating a Broken Network Connection
1. Identifying the Symptoms of a Broken Network ping (ip-address | hostname) show route (ip-
Connection address | hostname) traceroute (ip-address |
hostname)
1. Isolating the Causes of a Network Problem show < configuration | interfaces | protocols |
route >
1. Taking Appropriate Action for Resolving the [edit] delete routing options static route
Network Problem destination-prefix commit and-quit show
route destination-prefix
1. Evaluating the Solution to Check Whether the show route (ip-address | hostname) ping (ip-
Network Problem Is Resolved address | hostname) count 3 traceroute (ip-
address | hostname)
Isolating a Broken Network Connection
By applying the standard four-step process illustrated in Figure 39 on page 653, you can isolate a failed
node in the network. Note that the functionality described in this section is not supported in versions
15.1X49, 15.1X49-D30, or 15.1X49-D40.
Figure 39: Process for Diagnosing Problems in Your Network

654
Before you embark on the four-step process, however, it is important that you are prepared for the
inevitable problems that occur on all networks. While you might find a solution to a problem by simply
trying a variety of actions, you can reach an appropriate solution more quickly if you are systematic in
your approach to the maintenance and monitoring of your network. To prepare for problems on your
network, understand how the network functions under normal conditions, have records of baseline
network activity, and carefully observe the behavior of your network during a problem situation.
Figure 40 on page 654 shows the network topology used in this topic to illustrate the process of
diagnosing problems in a network.
Figure 40: Network with a Problem
The network in Figure 40 on page 654 consists of two autonomous systems (ASs). AS 65001 includes
two routers, and AS 65002 includes three routers. The border router (R1) in AS 65001 announces
aggregated prefixes 100.100/24 to the AS 65002 network. The problem in this network is that R6 does
not have access to R5 because of a loop between R2 and R6.
To isolate a failed connection in your network, follow the steps in these topics:
• Isolating the Causes of a Network Problem

655
• Taking Appropriate Action for Resolving the Network Problem
• Taking Appropriate Action for Resolving the Network Problem
• Evaluating the Solution to Check Whether the Network Problem Is Resolved
Identifying the Symptoms of a Broken Network Connection
IN THIS SECTION
Problem | 655
Solution | 655
Problem
Description
The symptoms of a problem in your network are usually quite obvious, such as the failure to reach a
remote host.
Solution
To identify the symptoms of a problem on your network, start at one end of your network and follow
the routes to the other end, entering all or one of the following Junos OS command-line interfaces (CLI)
operational mode commands:
user@host> ping (ip-address | host-name)

user@host> show route (ip-address | host-name)
user@host> traceroute (ip-address | host-name)
Sample Output
user@R6> ping 10.0.0.5

PING 10.0.0.5 (10.0.0.5): 56 data bytes
36 bytes from 10.1.26.1: Time to live exceeded
656
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst

4 5 00 0054 e2db 0 0000 01 01 a8c6 10.1.26.2 10.0.0.5

4 5 00 0054 e2de 0 0000 01 01 a8c3 10.1.26.2 10.0.0.5

4 5 00 0054 e2e2 0 0000 01 01 a8bf 10.1.26.2 10.0.0.5
^C
--- 10.0.0.5 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
user@R6> show route 10.0.0.5

10.0.0.5/32 *[IS-IS/165] 00:02:39, metric 10

> to 10.1.26.1 via so-0/0/2.0
user@R6> traceroute 10.0.0.5

1 10.1.26.1 (10.1.26.1) 0.649 ms 0.521 ms 0.490 ms
2 10.1.26.2 (10.1.26.2) 0.521 ms 0.537 ms 0.507 ms
3 10.1.26.1 (10.1.26.1) 0.523 ms 0.536 ms 0.514 ms
4 10.1.26.2 (10.1.26.2) 0.528 ms 0.551 ms 0.523 ms
5 10.1.26.1 (10.1.26.1) 0.531 ms 0.550 ms 0.524 ms
Meaning
The sample output shows an unsuccessful ping command in which the packets are being rejected
because the time to live is exceeded. The output for the show route command shows the interface
(10.1.26.1) that you can examine further for possible problems. The traceroute command shows the
loop between 10.1.26.1 (R2) and 10.1.26.2 (R6), as indicated by the continuous repetition of the two
interface addresses.
657
Isolating the Causes of a Network Problem
IN THIS SECTION
Problem | 657
Solution | 657
Problem
Description
A particular symptom can be the result of one or more causes. Narrow down the focus of your search to
find each individual cause of the unwanted behavior.
Solution
To isolate the cause of a particular problem, enter one or all of the following Junos OS CLI operational
mode command:
user@host> show < configuration | bgp | interfaces | isis | ospf | route >
Your particular problem may require the use of more than just the commands listed above. See the
appropriate command reference for a more exhaustive list of commonly used operational mode
commands.
Sample Output
user@R6> show interfaces terse

so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.56.2/30
iso
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.26.2/30
iso
so-0/0/3 up up
so-0/0/3.0 up up inet 10.1.36.2/30
658
iso
[...Output truncated...]
The following sample output is from R2:

10.0.0.5/32 *[Static/5] 00:16:21

> to 10.1.26.2 via so-0/0/2.0
[BGP/170] 3d 20:23:35, MED 5, localpref 100
AS path: 65001 I
> to 10.1.12.1 via so-0/0/0.0
Meaning
The sample output shows that all interfaces on R6 are up. The output from R2 shows that a static route
[Static/5] configured on R2 points to R6 (10.1.26.2) and is the preferred route to R5 because of its low
preference value. However, the route is looping from R2 to R6, as indicated by the missing reference to
R5 (10.1.15.2).
Taking Appropriate Action for Resolving the Network Problem
IN THIS SECTION
Problem | 659
Solution | 659
659
Problem
Description
The appropriate action depends on the type of problem you have isolated. In this example, a static route
configured on R2 is deleted from the [routing-options] hierarchy level. Other appropriate actions might
include the following:
Solution
• Check the local router’s configuration and edit it if appropriate.
• Troubleshoot the intermediate router.
• Check the remote host configuration and edit it if appropriate.
• Troubleshoot routing protocols.
• Identify additional possible causes.
To resolve the problem in this example, enter the following Junos OS CLI commands:
[edit]
user@R2# delete routing-options static route destination-
prefix
user@R2# commit and-quit
user@R2# show route destination-prefix
Sample Output
[edit]
user@R2# delete routing-options static route 10.0.0.5/32
[edit]
user@R2# commit and-quit
commit complete
Exiting configuration mode

660
10.0.0.5/32 *[BGP/170] 3d 20:26:17, MED 5, localpref 100

AS path: 65001 I
> to 10.1.12.1 via so-0/0/0.0
Meaning
The sample output shows the static route deleted from the [routing-options] hierarchy and the new
configuration committed. The output for the show route command now shows the BGP route as the
preferred route, as indicated by the asterisk (*).
Evaluating the Solution to Check Whether the Network Problem Is

Resolved
IN THIS SECTION
Problem | 660
Solution | 661
Problem
Description
If the problem is solved, you are finished. If the problem remains or a new problem is identified, start the
process over again.
You can address possible causes in any order. In relation to the network in Isolating a Broken Network
Connection, we chose to work from the local router toward the remote router, but you might start at a
different point, particularly if you have reason to believe that the problem is related to a known issue,
such as a recent change in configuration.
661
Solution
To evaluate the solution, enter the following Junos OS CLI commands:
user@host> show route (ip-address |host-

name)
user@host> ping (ip-address | host-name)
user@host> traceroute (ip-address | host-name)
Sample Output

10.0.0.5/32 *[BGP/170] 00:01:35, MED 5, localpref 100, from 10.0.0.2

AS path: 65001 I
> to 10.1.26.1 via so-0/0/2.0
user@R6> ping 10.0.0.5

PING 10.0.0.5 (10.0.0.5): 56 data bytes
^C
--- 10.0.0.5 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.796/0.833/0.866/0.029 ms
user@R6> traceroute 10.0.0.5

1 10.1.26.1 (10.1.26.1) 0.629 ms 0.538 ms 0.497 ms
2 10.1.12.1 (10.1.12.1) 0.534 ms 0.538 ms 0.510 ms
3 10.0.0.5 (10.0.0.5) 0.776 ms 0.705 ms 0.672 ms
Meaning
The sample output shows that there is now a connection between R6 and R5. The show route
command shows that the BGP route to R5 is preferred, as indicated by the asterisk (*). The ping
662
command is successful and the traceroute command shows that the path from R6 to R5 is through R2
(10.1.26.1), and then through R1 (10.1.12.1).
Checklist for Tracking Error Conditions
IN THIS SECTION
Problem | 662
Solution | 662
Problem
Description
Table 3 on page 662 provides links and commands for configuring routing protocol daemon tracing,
Border Gateway Protocol (BGP), Intermediate System-to-Intermediate System (IS-IS) protocol, and Open
Shortest Path First (OSPF) protocol tracing to diagnose error conditions.
Solution
Table 3: Checklist for Tracking Error Conditions
Configure Routing Protocol Process Tracing
1. Configure Routing Protocol Process Tracing [edit] edit routing-options traceoptio

filename size size files number show
show log filename
1. Configure Routing Protocol Tracing for a Specific Routing Protocol [edit] edit protocol protocol-name tr
set file filename size size files numbe
commit run show log filename
663
Table 3: Checklist for Tracking Error Conditions (Continued)
1. Monitor Trace File Messages Written in Near-Real Time monitor start filename
1. Stop Trace File Monitoring monitor stop filename
Configure BGP-Specific Options
1. Display Detailed BGP Protocol Information [edit] edit protocol bgp traceoptions
update detail show commit run show
1. Display Sent or Received BGP Packets [edit] edit protocol bgp traceoptions
update (send | receive) show commit
filename
1. Diagnose BGP Session Establishment Problems [edit] edit protocol bgp set traceopti
detail show commit run show log file
Configure IS-IS-Specific Options
1. Displaying Detailed IS-IS Protocol Information [edit] edit protocol isis traceoptions
1. Displaying Sent or Received IS-IS Protocol Packets [edit] edit protocols isis traceoptions
(send | receive) show commit run sho
filename
1. Analyzing IS-IS Link-State PDUs in Detail [edit] edit protocols isis traceoptions
Configure OSPF-Specific Options
1. Diagnose OSPF Session Establishment Problems [edit] edit protocols ospf traceoption
hello detail show commit run show l
664
Table 3: Checklist for Tracking Error Conditions (Continued)
1. Analyze OSPF Link-State Advertisement Packets in Detail [edit] edit protocols ospf traceoption
update detail show commit run show
Configure Routing Protocol Process Tracing
IN THIS SECTION
Action | 664
Meaning | 666
Action
To configure routing protocol process (rpd) tracing, follow these steps:
1. In configuration mode, go to the following hierarchy level:
[edit]
user@host# edit routing-options traceoptions
2. Configure the file, file size, number, and flags:

user@host# set file filename size size file number
user@host# set flag flag
665
For example:

user@host# set file daemonlog size 10240 files 10
user@host# set flag general
3. Verify the configuration:
user@host# show
For example:

user@host# show
file daemonlog size 10k files 10;
flag general;
4. Commit the configuration:
user@host# commit
NOTE: Some traceoptions flags generate an extensive amount of information. Tracing can also
slow down the operation of routing protocols. Delete the traceoptions configuration if you no
longer require it.
1. View the contents of the file containing the detailed messages:
user@host# run show log filename
For example:

user@pro4-a# run show log daemonlog
Sep 17 14:17:31 trace_on: Tracing to "/var/log/daemonlog" started
666
Sep 17 14:17:31 Tracing flags enabled: general

Sep 17 14:17:31 inet_routerid_notify: Router ID: 10.255.245.44
Sep 17 14:17:31 inet_routerid_notify: No Router ID assigned
Sep 17 14:17:31 Initializing LSI globals
Sep 17 14:17:31 LSI initialization complete
Sep 17 14:17:31 Initializing OSPF instances
Sep 17 14:17:31 Reinitializing OSPFv2 instance master
Sep 17 14:17:31 OSPFv2 instance master running
Meaning
Table 4 on page 666 lists tracing flags and example output for Junos-supported routing protocol
daemon tracing.
Table 4: Routing Protocol Daemon Tracing Flags
Tracing Description Example Output

Flag
all All operations Not available.
general Normal Not available.

operations
and routing
table change
normal Normal Not available.

operations
policy Policy Nov 29 22:19:58 export: Dest 10.0.0.0 proto Static Nov 29 22:19:58
operations policy_match_qual_or: Qualifier proto Sense: 0 Nov 29 22:19:58
and actions policy_match_qual_or: Qualifier proto Sense: 0 Nov 29 22:19:58 export: Dest
10.10.10.0 proto IS-IS
667
Table 4: Routing Protocol Daemon Tracing Flags (Continued)

Flag
route Routing table Nov 29 22:23:59 Nov 29 22:23:59 rtlist_walker_job: rt_list walk for RIB inet.0
changes started with 42 entries Nov 29 22:23:59 rt_flash_update_callback: flash KRT
(inet.0) start Nov 29 22:23:59 rt_flash_update_callback: flash KRT (inet.0) done
Nov 29 22:23:59 rtlist_walker_job: rt_list walk for inet.0 ended with 42 entries
Nov 29 22:23:59 Nov 29 22:23:59 KRT Request: send len 68 v14 seq 0
CHANGE route/user af 2 addr 172.16.0.0 nhop-type unicast nhop 10.10.10.33
Nov 29 22:23:59 KRT Request: send len 68 v14 seq 0 ADD route/user af 2
addr 172.17.0.0 nhop-type unicast nhop 10.10.10.33 Nov 29 22:23:59 KRT
Request: send len 68 v14 seq 0 ADD route/user af 2 addr 10.149.3.0 nhop-
type unicast nhop 10.10.10.33 Nov 29 22:24:19 trace_on: Tracing to "/var/log/
rpdlog" started Nov 29 22:24:19 KRT Request: send len 68 v14 seq 0 DELETE
route/user af 2 addr 10.10.218.0 nhop-type unicast nhop 10.10.10.29 Nov 29
22:24:19 RELEASE 10.10.218.0 255.255.255.0 gw 10.10.10.29,10.10.10.33
BGP pref 170/-101 metric so-1/1/0.0,so-1/1/1.0 <Release Delete Int Ext> as
65401 Nov 29 22:24:19 KRT Request: send len 68 v14 seq 0 DELETE route/
user af 2 addr 172.18.0.0 nhop-type unicast nhop 10.10.10.33
state State Not available.

transitions
task Interface Nov 29 22:50:04 foreground dispatch running job task_collect for task
transactions Scheduler Nov 29 22:50:04 task_collect_job: freeing task MGMT_Listen
and (DELETED) Nov 29 22:50:04 foreground dispatch completed job task_collect
processing for task Scheduler Nov 29 22:50:04 background dispatch running job
rt_static_update for task RT Nov 29 22:50:04 task_job_delete: delete
background job rt_static_update for task RT Nov 29 22:50:04 background
dispatch completed job rt_static_update for task RT Nov 29 22:50:04
background dispatch running job Flash update for task RT Nov 29 22:50:04
background dispatch returned job Flash update for task RT Nov 29 22:50:04
background dispatch running job Flash update for task RT Nov 29 22:50:04
task_job_delete: delete background job Flash update for task RT Nov 29
22:50:04 background dispatch completed job Flash update for task RT Nov 29
22:50:04 background dispatch running job Flash update for task RT Nov 29
22:50:04 task_job_delete: delete background job Flash update for task RT
668
Table 4: Routing Protocol Daemon Tracing Flags (Continued)

Flag
timer Timer usage Nov 29 22:52:07 task_timer_hiprio_dispatch: ran 1 timer Nov 29 22:52:07
main: running normal priority timer queue Nov 29 22:52:07 main: ran 1 timer
Nov 29 22:52:07 task_timer_hiprio_dispatch: running high priority timer queue
Nov 29 22:52:07 task_timer_hiprio_dispatch: ran 1 timer Nov 29 22:52:07
main: running normal priority timer queue Nov 29 22:52:07 main: ran 1 timer
Nov 29 22:52:07 main: running normal priority timer queue Nov 29 22:52:07
main: ran 2 timers
Configure Routing Protocol Tracing for a Specific Routing Protocol
IN THIS SECTION
Action | 668
Meaning | 670
Action
To configure routing protocol tracing for a specific routing protocol, follow these steps:
1. In configuration mode, go to the following hierarchy level:
[edit]
user@host# edit protocol protocol-name traceoptions
669
2. Configure the file, file size, number, and flags:
[edit protocols protocol name traceoptions]

user@host# set file filename size size files
number
[edit protocols protocol name traceoptions]
user@host# set flag flag
For example:
[edit protocols ospf traceoptions]

user@host# set file ospflog size 10240 files 10
user@host# set flag general
3. Verify the configuration:
user@host# show
For example:

user@host# show
file ospflog size 10k files 10;
flag general;
4. Commit the configuration:
user@host# commit
5. View the contents of the file containing the detailed messages:
user@host# run show log filename

670
For example:

user@pro4-a# run show log ospflog
Sep 17 14:23:10 trace_on: Tracing to "/var/log/ospflog" started
Sep 17 14:23:10 rt_flash_update_callback: flash OSPF (inet.0) start
Sep 17 14:23:10 OSPF: multicast address 224.0.0.5/32, route ignored
Sep 17 14:23:10 rt_flash_update_callback: flash OSPF (inet.0) done
Sep 17 14:23:10 CHANGE 10.255.245.46/32 gw 10.10.208.67 OSPF pref
10/0 metric 1/0 fe-0/0/0.0 <Delete Int>
10/0 metric 1/0 fe-0/0/0.0 <Active Int>
Sep 17 14:23:10 ADD 10.255.245.46/32 gw 10.10.208.67 OSPF pref
10/0 metric 1/0 fe-0/0/0.0 <Delete Int>
Sep 17 14:23:10 ADD 10.255.245.48/32 gw 10.10.208.69 OSPF pref
Sep 17 14:23:10 rt_close: 4/4 routes proto OSPF
Meaning
Table 5 on page 670 lists standard tracing options that are available globally or that can be applied to
specific protocols. You can also configure tracing for a specific BGP peer or peer group. For more
information, see the Junos System Basics Configuration Guide.
Table 5: Standard Trace Options for Routing Protocols
Tracing Flag Description
all All operations
general Normal operations and routing table changes
normal Normal operations

671
Table 5: Standard Trace Options for Routing Protocols (Continued)
Tracing Flag Description
policy Policy operations and actions
route Routing table changes
state State transitions
task Interface transactions and processing
timer Timer usage
Monitor Trace File Messages Written in Near-Real Time
IN THIS SECTION
Purpose | 671
Action | 671
Purpose
To monitor messages in near-real time as they are being written to a trace file.
Action
To monitor messages in near-real time as they are being written to a trace file, use the following Junos
OS command-line interface (CLI) operational mode command:
user@host> monitor start filename

672
Sample Output
command-name
user@host> monitor start isis

user@host>
*** isis ***
Sep 15 18:32:21 Updating LSP isis5.02-00 in database
Sep 15 18:32:21 Updating L2 LSP isis5.02-00 in TED
Sep 15 18:32:21 Adding a half link from isis5.02 to isis6.00
Sep 15 18:32:21 Scheduling L2 LSP isis5.02-00 sequence 0xd87 on interface fxp2.3
Sep 15 18:32:21 Sending L2 LSP isis5.02-00 on interface fxp2.3
Sep 15 18:32:21 sequence 0xd87, checksum 0xc1c8, lifetime 1200
Stop Trace File Monitoring
IN THIS SECTION
Action | 672
Sample Output | 673
Action
To stop monitoring a trace file in near-real time, use the following Junos OS CLI operational mode
command after you have started monitoring:
user@host monitor stop filename

673
Sample Output
user@host> monitor start isis

user@host>
*** isis ***
Sep 15 18:32:21 Scheduling L2 LSP isis5.02-00 sequence 0xd87 on interface fxp2.3
Sep 15 18:32:21 Sending L2 LSP isis5.02-00 on interface fxp2.3
Sep 15 18:32:21 sequence 0xd87, checksum 0xc1c8, lifetime 1200
monitor stop isis
user@host>
18 CHAPTER
Verifying and Monitoring OSPF
Verifying and Monitoring OSPF Configuration | 675

675
Verifying and Monitoring OSPF Configuration
IN THIS SECTION
Verifying an OSPF Configuration | 675
Tracing OSPF Protocol Traffic | 681
Verifying an OSPF Configuration
IN THIS SECTION
Verifying OSPF-Enabled Interfaces | 675
Verifying OSPF Neighbors | 677
Verifying the Number of OSPF Routes | 678
Verifying Reachability of All Hosts in an OSPF Network | 680
To verify an OSPF configuration, perform these tasks:
Verifying OSPF-Enabled Interfaces
IN THIS SECTION
Purpose | 676
Action | 676
Meaning | 676
676
Purpose
Verify that OSPF is running on a particular interface and that the interface is in the desired area.
Action
From the CLI, enter the show ospf interface command.
Sample Output
command-name
user@host> show ospf interface

Intf State Area DR ID BDR ID Nbrs
at-5/1/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-2/3/0.0 DR 0.0.0.0 192.168.4.16 192.168.4.15 1
lo0.0 DR 0.0.0.0 192.168.4.16 0.0.0.0 0
so-0/0/0.0 Down 0.0.0.0 0.0.0.0 0.0.0.0 0
so-6/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
so-6/0/2.0 Down 0.0.0.0 0.0.0.0 0.0.0.0 0
so-6/0/3.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Meaning
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.

677
Verifying OSPF Neighbors
IN THIS SECTION
Purpose | 677
Action | 677
Meaning | 677
Purpose
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.
Action
From the CLI, enter the show ospf neighbor command.
Sample Output
command-name
user@host> show ospf neighbor

Address Intf State ID Pri Dead
192.168.254.225 fxp3.0 2Way 10.250.240.32 128 36
192.168.254.230 fxp3.0 Full 10.250.240.8 128 38
192.168.254.229 fxp3.0 Full 10.250.240.35 128 33
10.1.1.129 fxp2.0 Full 10.250.240.12 128 37
10.1.1.131 fxp2.0 Full 10.250.240.11 128 38
10.1.2.1 fxp1.0 Full 10.250.240.9 128 32
10.1.2.81 fxp0.0 Full 10.250.240.10 128 33
Meaning
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:
678
• 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 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
IN THIS SECTION
Purpose | 678
Action | 679
Meaning | 680
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

679
For example, Figure 1 shows a sample network with an OSPF topology.
Figure 41: 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
command-name
user@host> show ospf route

Type Type Type Interface addr/label
680

192.168.5.2 Intra Router IP 1 lo0
Meaning
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 1, 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
IN THIS SECTION
Purpose | 680
Action | 680
Meaning | 681
Purpose
By using the traceroute tool on each loopback address in the network, verify that all hosts in the
network are reachable from each device.
Action
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.
681
3. Click Start. Output appears on a separate page.
Sample Output
command-name
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
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
682
• 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—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:
• detail—Detailed trace information
• receive—Packets being received
• send—Packets being transmitted
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:
• all—All tracing operations

683
• general—All normal operations and routing table changes (a combination of the normal and route
trace operations)
• normal—Normal events
• policy—Policy processing
• route—Routing information
• state—State transitions
• task—Routing protocol task processing
• timer—Routing protocol timer processing
NOTE: Use the trace flag all with caution as it might cause the CPU to become very busy.
Example: Tracing OSPF Protocol Traffic
IN THIS SECTION
Requirements | 683
Overview | 683
Configuration | 685
Verification | 690
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
684
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.
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.
685
Configuration
IN THIS SECTION
Configuring Global Tracing Operations and Tracing OSPF Packet Information | 685
Tracing SPF Calculations | 688
Tracing Link-State Advertisements | 689
Configuring Global Tracing Operations and Tracing OSPF Packet Information
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
To configure global routing tracing operations and tracing operations for OSPF packets:
686
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.

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.

user@host# set file files 5
5. Configure the maximum size of each trace file.

user@host# set file size 10k
6. Configure tracing flags.

user@host# set flag lsa-ack
user@host# set flag database-description
user@host# set flag hello
687
user@host# set flag lsa-update

user@host# set flag lsa-request

user@host# commit
Results

traceoptions {
file routing-log;
}

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.
688
Tracing SPF Calculations
To quickly trace SPF calculations, copy the following commands and paste them into the CLI.
[edit]
set protocols ospf traceoptions flag spf
To configure SPF tracing operations for OSPF:
[edit]
2. Configure the SPF tracing flag.

user@host# set flag spf

user@host# commit
689
Results

traceoptions {
file ospf-log ;
flag spf;
}
Tracing Link-State Advertisements
To quickly trace the creation, receipt, and retransmission of all LSAs, copy the following commands and
[edit]
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:
[edit]
690
2. Configure the link-state advertisement tracing flags.

user@host# set flag lsa-request
user@host# set flag lsa-update
user@host# set flag lsa-ack

user@host# commit
Results

traceoptions {
file ospf-log;
flag lsa-request;
flag lsa-update;
flag lsa-ack;
}
Verification
IN THIS SECTION
Verifying Trace Operations | 691

691
Verifying Trace Operations
Purpose
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.
Action
From operational mode, enter the show ospf overview extensive command for OSPFv2, and enter the
show ospf3 overview extensive command for OSPFv3.

Tracing and Logging Junos OS Operations
Example: Tracing Global Routing Protocol Operations
19 CHAPTER
Configuration Statements
admin-group | 695
area | 699
area-range | 702
as-external | 704
authentication | 706
backup-selection (Protocols OSPF) | 708
backup-spf-options (Protocols OSPF) | 711
bandwidth-based-metrics | 714
context-identifier (Protocols OSPF) | 721
default-lsa | 725
export | 732
graceful-restart (Protocols OSPF) | 734
import | 737
interface (Protocols OSPF) | 743
interface (Backup Selection OSPF) | 750
interface-type (Protocols OSPF) | 754
label-switched-path (Protocols OSPF) | 759
ldp-stitching (Protocols OSPF) | 761
link-protection (Protocols OSPF) | 762
lsa-refresh-interval | 764
mtu | 767
no-advertise-adjacency-segment (Protocols OSPF) | 775
no-domain-vpn-tag | 776
no-neighbor-down-notification | 778
no-nssa-abr | 779
no-rfc-1583 | 781
no-source-packet-routing (Protocols OSPF) | 783
node-segment (Protocols OSPF) | 785
nssa | 787
ospf | 789
ospf3 | 792
overload (Protocols OSPF) | 794
passive (Protocols OSPF) | 797
peer-interface (Protocols OSPF) | 799
prefix-export-limit (Protocols OSPF) | 803
protocols | 805
realm | 809
reference-bandwidth (Protocols OSPF) | 811
rib-group (Protocols OSPF) | 813
routing-instances (Multiple Routing Entities) | 815
sham-link | 817
shortcuts (Protocols OSPF) | 822

source-packet-routing (Protocols OSPF) | 824
spf-options (Protocols OSPF) | 827
stub | 830
stub-network | 832
topology (OSPF) | 833
topology (OSPF Interface) | 836
traceoptions (Protocols OSPF) | 838
traffic-engineering (OSPF) | 843
traffic-engineering (Passive TE Mode) | 846
virtual-link | 851
695
admin-group
IN THIS SECTION
Syntax | 695
Hierarchy Level | 695
Description | 696
Options | 696
Required Privilege Level | 697
Release Information | 697
Syntax
admin-group {
exclude [ group-name ];
include-all [ group-name ];
include-any [ group-name ];
preference [ group-name ];
}
Hierarchy Level
[edit logical-systems logical-system-name routing-options backup-selection

destination prefix interface interface name],
[edit logical-systems logical-system-name routing-instances instance-name
routing-options backup-selection destination prefix interface interface-name],
[edit routing-instances instance-name routing-options backup-selection
destination prefix interface interface-name],
[edit routing-options backup-selection destination prefix interface interface
name]
696
Description
Define the administrative groups criteria for the selection of the backup path.
NOTE: Configure group names of admin-group under the [edit protocols mpls] hierarchy level.
Options
exclude [ group- Specify the administrative groups to be excluded. The backup path is not selected
name ] as the loop-free alternate (LFA) or backup next hop if any of the links in the path
have any one of the listed administrative groups.
group-name Name of one or more admin-group defined under the [edit

protocols mpls] hierarchy level.
include-all [ group- Require each link in the backup path to have all the listed administrative groups
name ] in order to accept the path.

include-any [ group- Require each link in the backup path to have at least one of the listed
name ] administrative groups in order to select the path.

preference [ group- Define an ordered set of administrative groups that specifies the preference of
name ] the backup path. The leftmost element in the set is given the highest preference.

697
Required Privilege Level
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
Release Information
Statement introduced in Junos OS Release 14.1.
Understanding Backup Selection Policy for IS-IS Protocol

Configuring Backup Selection Policy for IS-IS Protocol
allow-route-leaking
IN THIS SECTION
Syntax | 698
Description | 698

698
Syntax
allow-route-leaking;
Hierarchy Level
[edit logical-systems name protocols ospf overload],

[edit logical-systems name routing-instances name protocols ospf overload],
[edit protocols ospf overload],
[edit routing-instances name protocols ospf overload],
[edit protocols ospf3 overload]
Description
Allow routes to be leaked when OSPF overload is configured and advertise the external prefixes with
maximum cost.
Release Information

699
stub-network | 832
as-external | 704
area
IN THIS SECTION
Syntax | 699
Description | 700
Options | 701
Syntax
area area-id {
interface interface-name {
no-eligible-remote-backup;
passive;
topology (ipv4-multicast | name) {
disable;
}
}
virtual-link neighbor-id router-id transit-area area-id {
disable;
}
}
}
700
Hierarchy Level
[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)],
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)]
Description
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.
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, OSPF must be
configured on an interface in order for direct interface addresses to be advertised as interior routes.
701
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.
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.
Release Information
Statement introduced before Junos OS Release 7.4.
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-eligible-remote-backup statement introduced in Junos OS Release 15.1.

virtual-link | 851
702
area-range
IN THIS SECTION
Syntax | 702
Description | 703
Default | 703
Options | 703
Syntax
area-range network/mask-length <exact> <override-metric metric> <restrict>;
Hierarchy Level
[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],
name protocols (ospf | ospf3) area area-id],
name protocols (ospf | ospf3) area area-id nssa],
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],
703
[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],
id nssa],
[edit routing-instances routing-instance-name realm (ipv4-unicast | ipv4-
multicast | ipv6-multicast) area area-id]
Description
(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
By default, area border routing devices do not summarize routes being sent from one area to other
areas, but rather send all routes explicitly.
Options
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.
704
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
Release Information
Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements
as-external
IN THIS SECTION
Syntax | 705
Description | 705

705
Syntax
as-external;
Hierarchy Level

[edit routing-instances name protocols ospf overload],
Description
Advertise OSPF AS external prefixes with maximum usable metric.
Release Information

706
stub-network | 832
authentication
IN THIS SECTION
Syntax | 706
Description | 707
Options | 707
Syntax
authentication {
md5 key-identifier {
key key-value;
start-time YYYY-MM-DD.hh:mm;
}
simple-password key;
}
Hierarchy Level
[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],
707

name protocols ospf area area-id interface interface-name],
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],
virtual-link]
Description
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. See CLI Explorer.
Options
simple- Configures a simple authentication password string, defined by key.

password
key
md5 Configure an MD5 password.
• key-identifier—MD5 key identifier. Range is from 0 through 255. Default is 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 date and time, in the format YYYY-MM-DD.hh:mm.

708
Release Information

backup-selection (Protocols OSPF)
IN THIS SECTION
Syntax | 709
Description | 710
Options | 710

709
Syntax
backup-selection {
destination prefix {
interface (interface-name| all){
admin-group {
}
dest-metric (highest | lowest);
metric-order [ root dest ];
node {
exclude [ node-address ];
preference [ node-address ];
}
protection-type (link | node | node-link);
root-metric (highest | lowest);
srlg (loose | strict);
evaluation-order [ admin-group srlg bandwidth protection-type node
metric ] ;
}
}
}
Hierarchy Level
[edit logical-systems logical-system-name routing-options],

routing-options],
[edit routing-instances instance-name routing-options],
710
Description
Define backup selection policies, per prefix per primary next-hop interface, to enforce loop-free
alternate (LFA) selection based on admin-group, srlg, bandwidth, protection-type, node, and metric
attributes of the backup path.
Options
destination Define the backup selection policy for a particular destination prefix or for all the
prefix prefixes. The value prefix defines the destination prefix name and prefix length. You
can specify 0/0 for the IPv4 least-specific prefix or 0::0/0 for the IPv6 least-specific
prefix.
node Define a list of loop-back IP addresses of the adjacent nodes to either prefer or
exclude in the backup path selection. The node can be a local (adjacent router) node,
remote node, or any other router in the backup path.
NOTE: The nodes are identified through the route-id advertised by a node in
the LSP.
exclude [ node- Specify one or more nodes to be excluded. The backup path that has a router from
address ] the list is not selected as the loop-free alternative or backup next hop.
preference Define an ordered set of one or more nodes to be preferred. The backup path having
[ node-address ] the leftmost node is selected.

711
Release Information
backup-spf-options (Protocols OSPF)
IN THIS SECTION
Syntax | 711
Description | 712
Options | 712
Syntax
disable;
no-install;
node-link-degradation;
per-prefix-calculation {
all;
externals;
712
stubs;
summary;
}
}
Hierarchy Level

[edit logical-systems logical-system-name protocols ospf topology (default |
name)],
name protocols ospf topology (default | name)];
[edit protocols ospf topology (default | name)],
[edit routing-instances routing-instance-name protocols ospf topology (default |
name)]
Description
Configure options for running the shortest-path-first (SPF) algorithm for backup next hops for protected
interfaces. Use these options to override the default behavior of having Junos OS calculate backup
paths for all the topologies in an instance when at least one 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 instance or topology.
713
downstream- Calculate and install only downstream paths as defined in RFC 5286, Basic
paths-only Specification for IP Fast Reroute: Loop-Free Alternates for the specified instance or
topology.
no-install Do not install the backup next hops for the specified instance or topology.
node-link- Degrade an interface from node-link to link protection in case no node protection
degradation LFA route is found for a given destination node. A link protecting loop-free alternate
(LFA) is used when node-link protecting LFA is not available in the topology for any
of the protected links.
per-prefix- Calculate backup next hops for non-best prefix originators.

calculation
• all—Calculate per-prefix loop free alternate (LFA) for all.
• externals—Calculate per-prefix LFA for not-so-stubby and externals only.
• stubs—Calculate per-prefix LFA for stubs only.
• summary—Calculate per-prefix LFA for summary originators only.
remote-backup- Determine the remote LFA backup paths from the point of local repair (PLR) in an
calculation OSPF network. For every protected link on the PLR, Junos OS creates a dynamic
LDP label-switched path to reach the remote LFA node. When the primary link fails,
the PLR uses these remote LFA backup paths to reach all the destinations reachable
through the primary-link.
routing-control-level—To add this statement to the configuration.
Release Information
node-link-degradation, per-prefix-calculation, and remote-backup-calculation options introduced in

Junos OS Release 15.1.
714
Support for remote-backup-calculation option introduced in Junos OS Release 18.2R1 for QFX5100,
QFX5110, and QFX5200 switches.
bandwidth-based-metrics
IN THIS SECTION
Syntax | 714
Description | 715
Options | 715
Syntax
bandwidth-based-metrics {
bandwidth value;
metric number;
}
Hierarchy Level

715

interface-name topology topology-name],
ipv4-multicast | ipv6-multicast) area area-id interface interface-name],
name protocols (ospf | ospf3) area area-id interface interface-name],
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],
interface interface-name topology topology-name],
unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name]
Description
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.
Options
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

716
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.
Release Information

bfd-liveness-detection (Protocols OSPF)
IN THIS SECTION
Syntax | 717
Description | 718
Options | 718

717
Syntax
authentication {
algorithm algorithm-name;
key-chain key-chain-name;
loose-check;
}
detection-time {
threshold milliseconds;
}
full-neighbors-only
holddown-interval holddown-interval;
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
multiplier number;
no-adaptation;
transmit-interval {
}
version (1 | automatic);
}
Hierarchy Level

718

name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area
area-id interface interface-name],
Description
Configure bidirectional failure detection timers and authentication for OSPF.
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 for the adaptation of the BFD session
detection time. When the 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.
holddown-interval holddown-interval—Time to hold the session-UP notification to the client.
• Range: 0 through 255000 milliseconds

719
minimum-interval milliseconds—Configure the minimum interval after 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. Optionally, instead of using this statement, you can configure the minimum
transmit and receive intervals separately using the transmit-interval minimum-interval and minimum-
receive-interval statements.
• Range: 1 through 255,000 milliseconds
minimum-receive-interval milliseconds—Configure the minimum interval after which the routing device
expects to receive a reply from a neighbor with which it has established a BFD session. Optionally,
instead of using this statement, you can configure the minimum receive interval using the minimum-
interval statement.
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 the threshold for the adaptation of the BFD session
transmit interval. When the 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.
• Range: 0 through 4,294,967,295 (232 – 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. Optionally,
instead of using this statement, you can configure the minimum transmit interval using the minimum-
interval statement.
version—Configure the BFD version to detect: 1 (BFD version 1) or automatic (autodetect the BFD
version).
• Default: automatic
720
Release Information
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 option introduced in Junos OS Release 9.0.
no-adaptation option 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 option introduced in Junos OS Release 9.5.
full-neighbors-only option introduced in Junos OS Release 9.5 for EX Series switches.
holddown-interval option introduced in Junos OS Release 19.4 for MX Series routers.
authentication algorithm, authentication key-chain, and authentication loose-check options introduced

in Junos OS Release 9.6.

Example: Configuring BFD Authentication for OSPF
721
context-identifier (Protocols OSPF)
IN THIS SECTION
Syntax | 721
Description | 721
Options | 722
Syntax
context-identifer identifier
Hierarchy Level
[edit logical-systems logical-system-name protocols (ospf |ospf3) area area-id],

[edit protocols (ospf | ospf3) area area-id ]
Description
Configure OSPF context-identifier information.

722
Options
identifer IPv4 address that defines a protection pair. The context identifier is manually configured on
both the primary and protector provider edge (PE) devices.
Release Information
database-protection
IN THIS SECTION
Syntax | 723
Description | 723
Default | 723
Options | 724

723
Syntax
database-protection {
ignore-count number;
ignore-time seconds;
maximum-lsa number;
reset-time seconds;
warning-only;
warning-threshold percent;
}
Hierarchy Level

unicast | ipv4-multicast | ipv6-unicast | ipv6-multicast)]
Description
Configure the maximum number of link-state advertisements (LSAs) that are not generated by the router
or switch in a given OSPF instance.
Default
By default, OSPF database protection is not enabled.

724
Options
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.
• 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
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

725
Release Information

default-lsa
IN THIS SECTION
Syntax | 725
Description | 726
Options | 726
Syntax
default-lsa {
default-metric metric;
metric-type type;
type-7;
}
726
Hierarchy Level

nssa],
ipv4-multicast | ipv6-multicast) area area-id nssa],
name protocols (ospf | ospf3) area area-id nssa],
area-id nssa],
[edit protocols (ospf | ospf3) area area-id nssa],
area area-id nssa],
id nssa],
unicast | ipv4-multicast | ipv6-multicast) area area-id nssa]
Description
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.
Options
default- Metric value, ranging from 1 through 16,777,215.

metric
metric
metric- Metric type 1 or 2. The configured metric determines the method used to compute the cost
type type to a destination:
727
• 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.
type-7 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.
Release Information

nssa | 787
stub | 830
728
definition (Protocols OSPF)
IN THIS SECTION
Syntax | 728
Description | 729
Options | 729
Syntax
definition {
(spf | strict-spf);
metric-type (igp-metric | te-metric);
priority priority;
}
Hierarchy Level
[edit logical-systems name routing-instances name routing-options flex-

algorithm],
[edit logical-systems name routing-options flex-algorithm],
[edit logical-systems name tenants name routing-instances name routing-options
flex-algorithm],
[edit routing-instances name routing-options flex-algorithm],
[edit routing-options flex-algorithm],
[edit tenants name routing-instances name routing-options flex-algorithm]
729
Description
Configure the flex-algorithm definition (FAD) and specify the parameters of the definition. OSPFv2
calculates the path based on these specified parameters of the FAD. We recommend configuring flexible
algorithm on only a couple of routers to provide redundancy and to avoid conflicts.
Options
spf Normal SPF of type 0
strict-spf Strict SPF
metric-type Specify the metric type that you would like to use in your network.
• Values:
• igp-metric— Specify this option to use the IGP route metric instead of the traffic
engineering metric.
• te-metric— Specify this option to use the configured traffic engineering metric
instead of the IGP metric if you have enabled traffic engineering on the device.
priority Specify a priority to the flexible algorithm advertisement. OSPFv2 prioritizes a particular
FAD advertisement over another FAD based on your assigned priority.
routing
Release Information
Statement introduced in Junos OS Release 21.1R1.

730

flex-algorithm (Protocols OSPF)
IN THIS SECTION
Syntax | 730
Description | 731
Options | 731
Syntax
flex-algorithm name {
color color;
definition;
}
Hierarchy Level
[edit logical-systems name routing-instances name routing-options],

[edit logical-systems name routing-options],
[edit logical-systems name tenants name routing-instances name routing-options],
731
[edit routing-instances name routing-options],

[edit routing-options],
[edit tenants name routing-instances name routing-options]
[edit logical-systems name routing-instances
name protocols ospf source-packet-routing
(Protocols OSPF)],
[[edit logical-systems name protocols
ospf source-packet-routing],edit logical-systems name tenants name
routing-instances name protocols ospf
source-packet-routing (Protocols OSPF)],
[edit protocols ospf source-packet-routing (Protocols
OSPF)],
[edit routing-instances name protocols
ospf source-packet-routing (Protocols OSPF)],
[edit tenants name routing-instances name protocols
ospf source-packet-routing (Protocols OSPF)]
Description
Define a flexible algorithm for OSPFv2 to compute a path based on specified parameters to thin slice a
network. We recommend configuring flexible algorithms on only a couple of routers to provide
redundancy and to avoid conflicts.
Configure participation of routers in a specific flexible algorithm in a network at the [edit protocols]
hierarchy level.
NOTE: Modifying the flexible algorithm definition could cause traffic disruptions until all the
nodes converge on the new paths.
Options
name Specify a flexible algorithm id to identify a flexible algorithm definition.
color Specify a color to be associated with this flexible algorithm.

732
routing
Release Information
Statement introduced in Junos OS Release 21.1R1.

show ospf flex-algorithm | 0
export
IN THIS SECTION
Syntax | 733
Description | 733
Options | 733

733
Syntax
export [ policy-names ];
Hierarchy Level

Description
Apply one or more policies to routes being exported from the routing table into OSPF.
Options
policy-names—Name of one or more policies.

734
Release Information

import
import
graceful-restart (Protocols OSPF)
IN THIS SECTION
Syntax | 735
Description | 735
Options | 735

735
Syntax
graceful-restart {
disable;
helper-disable (standard | restart-signaling | both);
no-strict-lsa-checking;
notify-duration seconds;
restart-duration seconds;
}
Hierarchy Level

[edit routing-instances routing-instance-name protocols ospf]
Description
Configure graceful restart for OSPF.
Graceful restart allows a routing device to restart with minimal effects to the network, and is enabled for
all routing protocols at the [edit routing-options] hierarchy level.
Options
disable Disable graceful restart for OSPF.
helper-disable Disable helper mode for graceful restart. When helper mode is disabled, a device
(standard | cannot help a neighboring device that is attempting to restart. Beginning with Junos OS
restart-
signaling| Release 11.4, you can configure restart signaling-based helper mode for OSPFv2
both)
736
graceful restart configurations. The last committed statement takes precedence over
the previously configured statement.
• standard disables helper mode for standard graceful restart (based on RFC 3623).
• restart-signaling disables helper mode for restart signaling-based graceful restart

(based on RFC 4811, RFC 4812, and RFC 4813).
• both disables helper mode for both standard and restart signaling-based graceful
restart.
Helper mode is enabled by default. For OSPFv2, both standard and restart-signaling
based helper modes are enabled by default.
no-strict-lsa- Disable strict OSPF link-state advertisement (LSA) checking to prevent the termination
checking 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.
notify- Estimated time needed to send out purged grace LSAs over all the interfaces. Range is 1
duration through 3600 seconds, and the default is 30 seconds.
seconds
restart- Estimated time needed to reacquire a full OSPF neighbor from each area. Range is 1
duration through 3600 seconds, and the default is 180 seconds.
seconds
Release Information
Support for the no-strict-lsa-checking statement introduced in Junos OS Release 8.5.

737
Support for the helper mode standard, restart-signaling, and both options introduced in Junos OS
Release 11.4.

import
IN THIS SECTION
Syntax | 737
Description | 738
Options | 738
Syntax
import [ policy-names ];
738
Hierarchy Level

Description
Filter OSPF routes from being added to the routing table.
Options
policy-names—Name of one or more policies.
Release Information

739

export
export
inter-area-prefix-export
IN THIS SECTION
Syntax | 739
Description | 740
Options | 740
Syntax
inter-area-prefix-export [ policy-names ];
740
Hierarchy Level
[edit logical-systems logical-system-name protocols ospf3 area area-id],

name protocols ospf3 area area-id],
name protocols ospf3 realm (ip4-unicast | ipv4-multicast | ipv6-multicast) area
area-id],
[edit protocols ospf3 area area-id],
area area-id],
[edit routing-instances routing-instance-name protocols ospf3 area area-id],
unicast | ipv4-muticast | ipv6-multicast) area area-id]
Description
Apply an export policy for OSPFv3 to specify which interarea prefix link-state advertisements (LSAs) are
flooded into an area.
Options
policy-name—Name of a policy configured at the [edit policy-options policy-statement policy-name

term term-name] hierarchy level.

741
Release Information

Routing Policies, Firewall Filters, and Traffic Policers User Guide
inter-area-prefix-import
IN THIS SECTION
Syntax | 741
Description | 742
Options | 742
Syntax
inter-area-prefix-import [ policy-names ];
742
Hierarchy Level
[edit logical-systems logical-system-name protocols ospf3 area area-id],

ipv4-multicast | ipv6-multicast) area area-id],
name protocols ospf3 area area-id],
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],
unicast | ipv4-multicast | ipv6-multicast) area area-id]
Description
Apply an import policy for OSPFv3 to specify which routes learned from an area are used to generate
interarea prefixes into other areas.
Options


743
Release Information

interface (Protocols OSPF)
IN THIS SECTION
Syntax | 743
Description | 745
Options | 745
Syntax
interface interface-name {
disable;
authentication key <key-id identifier>;
authentication {
744
algorithm algorithm-name;
key-chain key-chain-name;
loose-check;
}
detection-time {
}
minimum-receive-interval milliseconds;
transmit-interval {
}
multiplier number;
}
dead-interval seconds;
demand-circuit;
hello-interval seconds;
flood-reduction;
ipsec-sa name;
interface-type type;
disable;
hold-time seconds;
}
metric metric;
neighbor address <eligible>;
no-eligible-backup;
no-interface-state-traps;
passive;
poll-interval seconds;
priority number;
retransmit-interval seconds;
te-metric metric;
secondary;
metric metric;
}
transit-delay seconds;
}
745
Hierarchy Level

ipv4-multicast | ipv6-multicast) area area-id],
area-id],
area area-id],
id],
unicast | ipv4-multicast | ipv6-multicast) area area-id]
Description
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 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.
746
NOTE: For nonbroadcast interfaces, specify the IP address of the

nonbroadcast interface as interface-name.
disable Disable OSPF, an OSPF interface, or an OSPF virtual link. 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.
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.
dead-interval Specify how long OSPF waits before declaring that a neighboring routing device is
seconds unavailable. This is an interval during which the routing device receives no hello
packets from the neighbor. The interval to wait is in seconds, and can range from 1
through 65,535 seconds. The default is four times the hello interval—40 seconds
(broadcast and point-to-point networks); 120 seconds (nonbroadcast multiple
access (NBMA) networks).
demand-circuit Configure an interface as a demand circuit.
flood-reduction 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.
hello-interval Specify how often, in seconds, the routing device sends hello packets out the
seconds interface. The hello interval must be the same for all routing devices on a shared
logical IP network. The valid range is 1 through 255 seconds. The default is
10 seconds (broadcast and point-to-point networks); 30 seconds (non-broadcast
multiple access [NBMA] networks)
ipsec-sa name Apply the named IPsec authentication to the OSPF interface or virtual link or to an
OSPFv2 remote sham link.
747
ldp- Enable synchronization by advertising the maximum cost metric until LDP is
synchronization operational on the link. LDP distributes labels in non-traffic-engineered
applications. Labels are distributed along the best path determined by OSPF. If the
synchronization between LDP and OSPF is lost, the label-switched path (LSP) goes
down. Therefore, OSPF and LDP synchronization is beneficial. When LDP
synchronization is configured and when LDP is not fully operational on a given link
(a session is not established and labels are not exchanged), OSPF 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 OSPF. 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.
disable Disable LDP synchronization for IS-IS.
hold-time The time period to advertise the maximum cost metric for a link that
seconds is not fully operational. The range is 1 through 65,535 seconds. The
default is infinity.
NOTE: When an interface has been in the holddown state for

more than 3 minutes, a system log message with a warning
level is sent. This message appears in both the messages file
and the trace file.
metric metric 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. Range is 1 through 65,535. 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.
neighbor address For non-broadcast interfaces only, specify neighboring routers. On a non-broadcast
<eligible> 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.

748
• eligible—(Optional) Allow the neighbor to become a designated router. If you

omit this option, the neighbor is not considered eligible to become a designated
router.
no-eligible- Exclude the specified interface as a backup interface for OSPF interfaces on which
backup link protection or node-link protection is enabled.
no-interface- Disable the OSPF traps for interface state changes. This statement is particularly
state-traps useful for OSPF interfaces in passive mode.
NOTE: The no-interface-state-traps statement is supported only for

OSPFv2.
node-link- Enable node-link protection on the specified OSPF interface. Junos OS creates an
protection 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.
poll-interval For non-broadcast interfaces only, specify how often, in seconds, the router sends
seconds hello packets out of the interface before it establishes adjacency with a neighbor.
The valid range is from 1 to 255 seconds, and the default is 120 seconds.
priority number 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.
The value number is the 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. The range is 0 through 255, and the default is 128.
749
retransmit- Specify how long the routing device waits to receive a link-state acknowledgment
interval seconds packet before retransmitting link-state advertisements (LSAs) to an interface’s
neighbors. The range is from 1 through 65,535 seconds, and the default is
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.
secondary 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.
strict-bfd Enable strict bidirectional forwarding detection over an interface for OSPF.
te-metric metric 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. Valid metric values can range from 1 through 65,535. The
default is the IGP metric value.
transit-delay Set the estimated time required to transmit a link-state update on the interface.
seconds When calculating this time, make sure to account for transmission and propagation
delays. The valid range is 1 through 65,535 seconds, with a default of 1 second.
NOTE: You should never have to modify the transit delay time.
NOTE: You cannot run both OSPF and ethernet-tcc encapsulation between two Juniper
Networks routing devices.

750
Release Information
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 no-interface-state-traps statement introduced in Junos OS Release 10.3. This statement
is supported only for OSPFv2.

interface (Backup Selection OSPF)
IN THIS SECTION
Syntax | 751
Description | 752
Options | 752

751
Syntax
interface (interface-name | all) {

admin-group {
}
dest-metric (highest | lowest);
downstream-paths-only ;
evaluation-order [ admin-group srlg bandwidth protection-type node metric ];
metric-order [ root dest ];
node {
exclude [ node-address ];
preference [ node-address ];
}
protection-type (link | node| node-link);
root-metric (highest | lowest);
srlg (loose |strict);
}
Hierarchy Level
[edit logical-systems logical-system-name routing-options backup-selection

destination prefix],
routing-options backup-selection destination prefix],
[edit routing-instances instance-name routing-options backup-selection prefix],
[edit routing-options backup-selection destination prefix]
752
Description
Define the backup selection policy for a specific primary next hop.
Options
interface-name Name of the primary next-hop interface.
all All the interfaces.
bandwidth- Allow the selection of the backup next hop only if the bandwidth is greater than or
greater-equal- equal to the bandwidth of the primary next hop.
primary
dest-metric Specifiy the metric from the one-hop neighbor or from the remote router such as
(highest lowest) an RSVP backup label-switched-path (LSP) tail-end router to the final destination.
highest Select the backup path that has the highest destination metric.
lowest Select the backup path that has the lowest destination metric.
downstream- Select the backup path that is a downstream path to the destination.
paths-only
evaluation-order Control the order and the criteria of evaluating the backup path. The default order
[ admin-group srlg of evaluation is admin-group, srlg, bandwidth, protection-type, node and metric.
bandwidth
protection-type
node metric ]
NOTE: For the explicitly configured evaluation order, only the listed
attributes influence the selection of the backup path.
metric-order [ root Specify the order of preference of the root and the destination metric during the
dest ] backup path selection. The preference order can be:
• [root dest] — Backup path selection or preference is first based on the root-
metric criteria. If the criteria of all the root-metric is the same, then the
selection or preference is based on the dest-metric.
• [dest root] — Backup path selection or preference is first based on the dest-
metric criteria. If the criteria of all the dest-metric is the same, then the
selection is based on the root-metric.
753
NOTE: Backup path selection or preference is first based on the dest-

metric criteria. If the criteria of all the dest-metric is the same, then the
selection is based on the root-metric. By default, backup paths with lower
destination metric criteria are selected or preferred. If the criteria is the
same, then the lowest root metric criteria is preferred or selected.
root The metric to a one-hop neighbor or a remote router.
dest The metric from a one-hop neighbor or remote router to the final
destination.
protection-type Specify the required protection type of the backup path.

(link | node | node-
link)
NOTE: If no protection-type is configured, then by default the first best
path that matches all the other criteria is executed.
link Select the backup path that provides link protection.
node Select the backup path that provides node protection.
node-link Allow either node or link protection LFA where node-protection LFA is
preferred over link-protection LFA.
root-metric Specify the metric to the one-hop neighbor or to the remote router such as an
(highest lowest) RSVP backup label-switched-path (LSP) tail-end router.
highest Select the highest root metric.
lowest Select the lowest root metric.
srlg (loose | strict) Define the backup selection to either allow or reject the common shared risk link
groups (SRLGs) between the primary link and any link in the backup path.
loose Allow the backup path that has common srlgs between the primary link
and any link in the backup path. A backup path with a fewer number of srlg
collisions is preferred.
strict Reject the backup path that has common srlgs between the primary next-
hop link and each link in the backup path.
754
Release Information
interface-type (Protocols OSPF)
IN THIS SECTION
Syntax | 755
Description | 756
Default | 757
Options | 757

755
Syntax
interface-type (nbma | p2mp | p2mp-over-lan | p2p) {

ipsec-sa;
(disable | enable);
hold-time;
}
metric;
mtu;
neighbor address {
eligible;
}
no-advertise-adjacency-segment;
no-eligible-backup;
no-eligible-remote-backup;
no-interface-state-traps;
no-neighbor-down-notification;
passive {
remote-node-id;
remote-node-router-id;
}
}
poll-interval;
priority;
retransmit-interval;
secondary;
te-metric;
topology (default | ipv4-multicast | name);
transit-delay;
bandwidth-based-metrics;
bfd-liveness-detection;
dead-interval;
demand-circuit;
disable;
dynamic-neighbors;
flood-reduction;
hello-interval;
link-protection;
756
own-router-lsa;
}
Hierarchy Level

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-multicast
| ipv4-unicast | ipv6-multicast) area area-id interface interface-name],
name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area
[edit protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)
multicast | ipv4-unicast | ipv6-multicast) area area-id interface interface-name]
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.
757
Default
The software chooses the correct interface type based on the type of physical interface.
Options
nbma (OSPFv2 only) Nonbroadcast multiaccess (NBMA) interface
p2mp Point-to-multipoint interface
p2mp-over-lan Point-to-multipoint over LAN mode
p2p Point-to-point interface
Release Information
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 p2mp is introduced in Junos OS Release 18.1R1.
Support for OSPFv3 for interface type p2p only introduced in Junos OS Release 9.4 for EX Series
switches.

758
intra-area-prefix
IN THIS SECTION
Syntax | 758
Description | 758
Syntax
intra-area-prefix;
Hierarchy Level
[edit logical-systems name protocols ospf3 overload],

Description
Advertise intra-area Prefix with maximum metric.

759
Release Information

stub-network | 832
as-external | 704
label-switched-path (Protocols OSPF)
IN THIS SECTION
Syntax | 760
Description | 760
Options | 760

760
Syntax
label-switched-path name metric metric;
Hierarchy Level
[edit logical-systems logical-system-name protocols ospf area area-id],

name protocols ospf area area-id],
[edit protocols ospf area area-id],
[edit routing-instances routing-instance-name protocols ospf area area-id]
Description
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.
• Default: 1

761
Release Information
ldp-stitching (Protocols OSPF)
IN THIS SECTION
Syntax | 761
Description | 762
Syntax
ldp-stitching;
762
Hierarchy Level
[edit protocols ospf source-packet-routing],

[edit routing-instances name protocols ospf source-packet-routing]
Description
Enable segment routing to LDP stitching.
Release Information
LDP Mapping Server for Interoperability of Segment Routing with LDP Overview
link-protection (Protocols OSPF)
IN THIS SECTION
Syntax | 763
763
Description | 764
Syntax
link-protection;
Hierarchy Level
[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],
name interface interface-name],
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)],
interface-name topology (default | name)],
interface interface-name topology (default | name)]
764
Description
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.
Release Information
lsa-refresh-interval
IN THIS SECTION
Syntax | 765
Description | 765
765
Options | 766
Syntax
lsa-refresh-interval minutes;
Hierarchy Level

Description
Configure the refresh interval for all self-generated link-state advertisement (LSAs). The OSPF standard
requires that every LSA be refreshed every 30 minutes. The Juniper Networks implementation refreshes
LSAs every 50 minutes. By default, any LSA that is not refreshed expires after 60 minutes. By using this
configuration, you can specify when self-originated LSAs are refreshed.
766
You can override the default behavior by globally configuring the OSPF LSA refresh interval at the [edit
protocols ospf | ospf3] hierarchy level. However, if you also have OSPF flood reduction configured for a
specific interface in an OSPF area at the [edit protocols ospf | ospf3 area area-id interface interface-
name] hierarchy level, the flood reduction configuration takes precedence for that specific interface.
Options
minutes—Time between an LSA refresh, in minutes.
• Range: 25 through 50 minutes (1,500 through 3,000 seconds)
• Default: 50 minutes
Release Information

767
mtu
IN THIS SECTION
Syntax | 767
Description | 768
Options | 770
Syntax
mtu bytes;
Hierarchy Level
[edit interfaces interface-name],

[edit interfaces interface-name unit logical-unit-number family family],
[edit interfaces interface-range name],
[edit logical-systems logical-system-name interfaces interface-name unit logical-
unit-number family family],
[edit logical-systems logical-system-name protocols l2circuit local-switching
interface interface-name backup-neighbor address],
[edit logical-systems logical-system-name protocols l2circuit neighbor address
[edit logical-systems logical-system-name protocols l2circuit neighbor address
interface interface-name backup-neighbor address],
name protocols l2vpn interface interface-name],
768
name protocols vpls],

[edit protocols l2circuit local-switching interface interface-name backup-
neighbor address],
[edit protocols l2circuit neighbor address interface interface-name]
[edit protocols l2circuit neighbor address interface interface-name backup-
neighbor address],
[edit routing-instances routing-instance-name protocols l2vpn interface
interface-name],
[edit routing-instances routing-instance-name protocols vpls],
[edit logical-systems name protocols ospf area name
interface ],
[edit logical-systems name routing-instances
name protocols ospf area name interface],
[edit protocols ospf area name interface ],
[edit routing-instances name protocols ospf area name interface]
Description
Specify the maximum transmission unit (MTU) size for the media or protocol. The default MTU size
depends on the device type. Changing the media MTU or protocol MTU causes an interface to be
deleted and added again.
To route jumbo data packets on an integrated routing and bridging (IRB) interface or routed VLAN
interface (RVI) on EX Series switches, you must configure the jumbo MTU size on the member physical
interfaces of the VLAN that you have associated with the IRB interface or RVI, as well as on the IRB
interface or RVI itself (the interface named irb or vlan, respectively).
CAUTION: For EX Series switches, setting or deleting the jumbo MTU size on an IRB
interface or RVI while the switch is transmitting packets might cause packets to be
dropped.
NOTE: The MTU for an IRB interface is calculated by removing the Ethernet header overhead
[6(DMAC)+6(SMAC)+2(EtherType)]. Because, the MTU is the lower value of the MTU configured
on the IRB interface and the MTU configured on the IRB’s associated bridge domain IFDs or IFLs,
the IRB MTU is calculated as follows:
769
• In case of Layer 2 IFL configured with the flexible-vlan-tagging statement, the IRB MTU is
calculated by including 8 bytes overhead (SVLAN+CVLAN).
• In case of Layer 2 IFL configured with the vlan-tagging statement, the IRB MTU is calculated
by including a single VLAN 4 bytes overhead.
NOTE:
• If a packet whose size is larger than the configured MTU size is received on the receiving
interface, the packet is eventually dropped. The value considered for MRU (maximum receive
unit) size is also the same as the MTU size configured on that interface.
• Not all devices allow you to set an MTU value, and some devices have restrictions on the
range of allowable MTU values. You cannot configure an MTU for management Ethernet
interfaces (fxp0, em0, or me0) or for loopback, multilink, and multicast tunnel devices.
• On ACX Series routers, you can configure the protocol MTU by including the mtu statement
at the [edit interfaces interface-name unit logical-unit-number family inet] or [edit interfaces
interface-name unit logical-unit-number family inet6] hierarchy level.
• If you configure the protocol MTU at any of these hierarchy levels, the configured value is
applied to all families that are configured on the logical interface.
• If you are configuring the protocol MTU for both inet and inet6 families on the same
logical interface, you must configure the same value for both the families. It is not
recommended to configure different MTU size values for inet and inet6 families that are
configured on the same logical interface.
• Starting in Release 14.2, MTU for IRB interfaces is calculated by removing the Ethernet
header overhead (6(DMAC)+6(SMAC)+2(EtherType)), and the MTU is a minimum of the two
values:
• Configured MTU
• Associated bridge domain's physical or logical interface MTU
• For Layer 2 logical interfaces configured with flexible-vlan-tagging, IRB MTU is

calculated by including 8 bytes overhead (SVLAN+CVLAN).
770
• For Layer 2 logical interfaces configured with vlan-tagging, IRB MTU is calculated by
including single VLAN 4 bytes overhead.
NOTE: Changing the Layer 2 logical interface option from vlan-tagging to flexible-
vlan-tagging or vice versa adjusts the logical interface MTU by 4 bytes with the
existing MTU size. As a result, the Layer 2 logical interface is deleted and re-added,
and the IRB MTU is re-computed appropriately.
For more information about configuring MTU for specific interfaces and router or switch combinations,
see Configuring the Media MTU.
Options
bytes—MTU size.
• Range: 256 through 9192 bytes, 256 through 9216 (EX Series switch interfaces), 256 through 9500
bytes (Junos OS 12.1X48R2 for PTX Series routers), 256 through 9500 bytes (Junos OS 16.1R1 for
MX Series routers)
NOTE: Starting in Junos OS Release 16.1R1, the MTU size for a media or protocol is
increased from 9192 to 9500 for Ethernet interfaces on the following MX Series MPCs:
• MPC1
• MPC2
• MPC2E
• MPC3E
• MPC4E
• MPC5E
• MPC6E
• Default: 1500 bytes (INET, INET6, and ISO families), 1448 bytes (MPLS), 1514 bytes (EX Series
switch interfaces)
771
interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
Release Information
Support for Layer 2 VPNs and VPLS introduced in Junos OS Release 10.4.
Statement introduced in Junos OS Release 12.2 for ACX Series Universal Metro Routers.
Support at the[set interfaces interface-name unit logical-unit-number family ccc] hierarchy level
introduced in Junos OS Release 12.3R3 for MX Series routers.
Configuring the Media MTU

Configuring the MTU for Layer 2 Interfaces
Setting the Protocol MTU
network-summary-export
IN THIS SECTION
Syntax | 772
Description | 772
Options | 772

772
Syntax
network-summary-export policy-name;
Hierarchy Level

Description
Apply an export policy that specifies which network-summary link-state advertisements (LSAs) are
flooded into an OSPFv2 area.
Options


773
Release Information

network-summary-import
IN THIS SECTION
Syntax | 773
Description | 774
Options | 774
Syntax
network-summary-import policy-name;
774
Hierarchy Level

Description
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.
Options

Release Information

775

no-advertise-adjacency-segment (Protocols OSPF)
IN THIS SECTION
Syntax | 775
Description | 776
Default | 776
Syntax
no-advertise-adjacency-segment;
Hierarchy Level
[edit logical-systems logical-system-name protocols ospf area nameinterface

interface-name],
name protocols ospf area nameinterface interface-name],
[edit protocols ospf area nameinterface interface-name],
[edit routing-instances routing-instance-name protocols ospf area name interface
interface-name],
776
Description
Disable advertising of the adjacency segment for the specified interface.
Default
Enabled
Release Information
OSPF Overview | 2
source-packet-routing
no-domain-vpn-tag
IN THIS SECTION
Syntax | 777

777
Description | 777
Options | 777
Syntax
no-domain-vpn-tag;
Hierarchy Level

[edit routing-instances routing-instance-name protocols (ospf | ospf3)]
Description
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.
Options
None.
778
Release Information
Configuring Routing Between PE and CE Routers in Layer 3 VPNs
no-neighbor-down-notification
IN THIS SECTION
Syntax | 778
Description | 779
Syntax
no-neighbor-down-notification;
779
Hierarchy Level

interface-name],
[edit protocols ospf area area-id interface interface-name]
Description
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.
Release Information
no-nssa-abr
IN THIS SECTION
Syntax | 780
Description | 780

780
Syntax
no-nssa-abr;
Hierarchy Level

Description
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).

781
Release Information
no-rfc-1583
IN THIS SECTION
Syntax | 781
Description | 782
Default | 782
Syntax
no-rfc-1583;
782
Hierarchy Level

Description
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.
Default
Compatibility with RFC 1583 is enabled by default.
routing-control-level—To add this statement to the configuration.

783
Release Information
no-source-packet-routing (Protocols OSPF)
IN THIS SECTION
Syntax | 783
Description | 784
Syntax
no-source-packet-routing;
784
Hierarchy Level
[edit logical-systems logical-system-name protocols ospf backup-spf-options],

name protocols ospf backup-spf-options],
[edit protocols ospf backup-spf-options],
[edit routing-instances routing-instance-name protocols ospf backup-spf-options]
Description
Disables use of source packet routing node segment labels for computing backup paths for normal IPv4
OSPF prefixes and OSPF source packet routing node segments.
Release Information
OSPF Overview | 2
785
node-segment (Protocols OSPF)
IN THIS SECTION
Syntax | 785
Description | 786
Options | 786
Syntax
node-segment {
ipv4-index index;
index-range index range;
}
Hierarchy Level
[edit logical-systems logical-system-name protocols ospf source-packet-routing],

name protocols ospf source-packet-routing],
[edit protocols ospf source-packet-routing],
[edit routing-instances routing-instance-name protocols ospf source-packet-
routing]
786
Description
Enable source packet routing in networking (SPRING) at all levels. SPRING, or segment routing, is a
control-plane architecture that enables an ingress router to steer a packet through a specific set of
nodes and links in the network without relying on the intermediate nodes in the network to determine
the actual path it should take.
NOTE: You can provision an IPv4 node segment index for a routing instance, not for a specific
OSPF area. A node segment index is attached to the IPv4 router-id, if the router-ids are
configured on the loopback interface. Otherwise, the lowest IP address on the loopback interface
is chosen to attach the node segment identifier..
Options
index-range index range Range of node segment indices allowed.
• Default: 4096
ipv4-index index IPv4 node segment index.
Release Information

787
OSPF Overview | 2
nssa
IN THIS SECTION
Syntax | 787
Description | 788
Options | 788
Syntax
nssa {
area-range network/mask-length <restrict> <exact> <override-metric metric>;
default-lsa {
default-metric metric;
metric-type type;
type-7;
}
(no-summaries | summaries);
}
788
Hierarchy Level

id],
Description
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.
Options
summaries | Configure whether or not area border routers advertise summary routes into an not-so-
no-summaries 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.
789
Release Information

stub | 830
ospf
IN THIS SECTION
Syntax | 790
Description | 790
Options | 791

790
Syntax
ospf {
domain-id domain-id;
domain-vpn-tag number;
route-type-community (iana | vendor);
<advertise-unnumbered-interfaces>;
<credibility-protocol-preference>;
ignore-lsp-metrics;
multicast-rpf-routes;
no-topology;
shortcuts {
lsp-metric-into-summary;
}
}
}
Hierarchy Level
[edit logical-systems logical-system-name protocols],

name protocols],
[edit protocols],
[edit routing-instances routing-instance-name protocols]
Description
Enable OSPF routing on the routing device. You must include the ospf statement to enable OSPF on the
routing device. By default, OSPF is disabled.
791
Options
domain-id The domain ID identifies the OSPF domain from which the route originated. If the
domain-id router ID is not configured in the routing instance, the router ID is derived from an
interface address belonging to the routing instance. The default OSPF domain ID is
the null value 0.0.0.0.
domain-vpn-tag Set a virtual private network (VPN) tag for OSPFv2 external routes generated by the
number provider edge (PE) routing device. The number corresponds to the VPN tag.
route-type- Specify an extended community value to encode the OSPF route type. Each
community (iana extended community is coded as an eight-octet value. This statement sets the most
| vendor)
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.
Release Information

792
ospf3
IN THIS SECTION
Syntax | 792
Description | 793
Options | 793
Syntax
ospf3 {
domain-id domain-id;
domain-vpn-tag number;
route-type-community (iana | vendor);
ignore-lsp-metrics;
no-topology;
shortcuts {
}
}
}
793
Hierarchy Level
[edit logical-systems logical-system-name protocols],

name protocols],
[edit protocols],
[edit routing-instances routing-instance-name protocols]
Description
Enable OSPFv3 routing on the routing device. You must include the ospf3 statement to enable OSPFv3.
By default, OSPFv3 is disabled.
Options
domain-id The domain ID identifies the OSPF domain from which the route originated. If the
domain-id router ID is not configured in the routing instance, the router ID is derived from an
interface address belonging to the routing instance. The default OSPF domain ID is
the null value 0.0.0.0.
domain-vpn-tag Set a virtual private network (VPN) tag for OSPFv2 external routes generated by the
number provider edge (PE) routing device. The number corresponds to the VPN tag.
route-type- Specify an extended community value to encode the OSPF route type. Each
community (iana extended community is coded as an eight-octet value. This statement sets the most
| vendor)
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.

794
Release Information
overload (Protocols OSPF)
IN THIS SECTION
Syntax | 794
Description | 795
Options | 795
Syntax
overload {
timeout seconds;
}
795
Hierarchy Level
[edit logical-systems logical-system-name protocols (oospf | ospf3)],

ipv4-multicast | name)],
[edit logical systems logical-system-name routing-instances routing-instance-
name protocols ospf topology (default | ipv4-multicast | name)],
[edit protocols ospf topology (default | ipv4-multicast | name)],
ipv4-multicast | name],
unicast | ipv4-multicast | ipv6-multicast)],
Description
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.
796
• Range: 60 through 1800 seconds
The timeout is configured with a prefix-limit. If the number of prefixes exceeds the configured limit, the
overload state is reached. The routing device remains in the overload state even though the prefixes
have been reduced under the limit. Therefore, you need to clear the overload state using the "clear (ospf
| ospf3) overload" on page 871 command.
NOTE: Multitopology Routing does not support the timeout option.
Release Information
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.

Traffic
Example: Configuring Multitopology Routing to Provide Redundancy for Multicast Traffic over
Separate Network Paths
797
passive (Protocols OSPF)
IN THIS SECTION
Syntax | 797
Description | 798
Syntax
passive {
}
Hierarchy Level

798

Description
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.
Release Information
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.
799

peer-interface (Protocols OSPF)
IN THIS SECTION
Syntax | 799
Description | 800
Options | 800
Syntax
peer-interface interface-name {
disable;
}
800
Hierarchy Level

[edit protocols ospf area area-id]
Description
Configure a peer interface.
Options
interface-name—Name of the peer interface. To configure all interfaces, you can specify all.
Release Information

Configuring RSVP and OSPF for LMP Peer Interfaces
Configuring a Hierarchy of RSVP LSPs to Tunnel Multiple RSVP LSPs Over a Single RSVP LSP
801
post-convergence-lfa (Protocols OSPF)
IN THIS SECTION
Syntax | 801
Description | 801
Options | 802
Syntax
post-convergence-lfa <fate-sharing-protection fate-sharing-protection<node-

protection <cost cost> <srlg-protection>;
Hierarchy Level
[edit logical-systems name protocols ospf area interface interface-name ],

[edit logical-systems name routing-instances name protocols ospf area interface
interface-name],
[edit protocols ospf area interface interface-name ],
[edit routing-instances name protocols ospf area interface interface-name]
Description
Configure the installation of backup-paths that follow the post-convergence paths corresponding to the
failure of this interface.
802
Options
fate- Enable fate-sharing protection. A list of fate-sharing groups are configured on each point
sharing- of local repair (PLR) with the links in each fate-sharing group identified by their respective
protection
IP addresses. The PLR associates a cost with each fate-sharing group. The fate-sharing-
aware post-convergence path is computed by assuming that the cost of each link in the
same fate-sharing group as the failed link has increased the cost associated with that
group.
node- Enable node protection mode for topology-independent loop-free alternate (TI-LFA)
protection routes for OSPF.
cost Enable a node-protecting post-convergence backup path to be computed

for all primary next-hops using this interface. Configure the cost of all the
links used for calculating the TI-LFA post-convergence failure path cost. If
node protection is enabled without configuring a cost value, then the cost is
set to the maximum cost or default value of 65535.
• Default: 65535
srlg- Enable Shared Risk Link Group (SRLG) protection in an OSPFv2 network if
protection you want OSPFv2 to choose a fast reroute path that does not include SRLG
links in the topology-independent loop-free alternate (TI-LFA) backup
paths. If you have configured fate-sharing-protection in addition to srlg-
protection then both costs are added to the link metric to calculate the final
TI-LFA backup path. These links have a higher metric cost and therefore TI-
LFA backup computation enables OSPFv2 to avoid these links.
routing
Release Information
Statement introduced in Junos OS Release 18.2R1 for MX Series, PTX Series, and QFX Series.
803
fate-sharing-protection option introduced in Junos OS release 20.3R1 for MX Series and PTX Series.
srlg-protection option introduced in Junos OS release 20.3R1 for MX Series and PTX Series.

prefix-export-limit (Protocols OSPF)
IN THIS SECTION
Syntax | 803
Description | 804
Options | 804
Syntax
prefix-export-limit number;
Hierarchy Level

804

Description
Configure a limit to the number of prefixes exported into OSPF.
Options
number—Prefix limit.
• Range: 0 through 4,294,967,295 (232 – 1)
• Default: None

805
Release Information

Traffic
Understanding Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic
Understanding Multitopology Routing in Conjunction with PIM
protocols
IN THIS SECTION
Syntax | 806
Description | 807
Options | 807

806
Syntax
protocols {
bgp {
... bgp-configuration ...
}
isis {
... isis-configuration ...
}
ldp {
... ldp-configuration ...
}
mpls {
... mpls -configuration ...
}
msdp {
... msdp-configuration ...
}
mstp {
... mstp-configuration ...
}
ospf {
}
ospf3 {
}
pim {
... pim-configuration ...
}
rip {
... rip-configuration ...
}
ripng {
... ripng-configuration ...
}
rstp {
rstp-configuration;
}
rsvp{
... rsvp-configuration ...
807
}
vstp {
vstp configuration;
}
vpls {
vpls configuration;
}
}
Hierarchy Level

name],
[edit routing-instances routing-instance-name]
Description
Specify the protocol for a routing instance. You can configure multiple instances of many protocol types.
Not all protocols are supported on the switches. See the switch CLI.
Options
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 or for a virtual router instance.
l2vpn Specify Layer 2 VPN as the protocol for a routing instance.
mpls Specify MPLS 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.
808
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.
rsvp Specify the RSVP for a 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.
Release Information
Support for RIPng introduced in Junos OS Release 9.0.
mpls and rsvp options added in Junos OS Release 15.1.

809
realm
IN THIS SECTION
Syntax | 809
Description | 810
Options | 810
Syntax
realm (ipv4-unicast | ipv4-multicast | ipv6-unicast) {

area area-id {
}
}
Hierarchy Level
[edit logical-systems logical-system-name protocols ospf3],

name protocols ospf3],
[edit protocols ospf3],
[edit routing-instances routing-instance-name protocols ospf3]
810
Description
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.
Options
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.
Release Information

811
reference-bandwidth (Protocols OSPF)
IN THIS SECTION
Syntax | 811
Description | 812
Options | 812
Syntax
reference-bandwidth reference-bandwidth;
Hierarchy Level

812
Description
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.
Release Information
813
rib-group (Protocols OSPF)
IN THIS SECTION
Syntax | 813
Description | 814
Options | 814
Syntax
rib-group group-name;
Hierarchy Level

814

Description
Install routes learned from OSPF routing instances into routing tables in the OSPF routing table group.
Options
group-name—Name of the routing table group.
Release Information
Example: Exporting Specific Routes from One Routing Table Into Another Routing Table
Example: Populating a Routing Table Created by Virtual Router Configuration
Understanding Multiprotocol BGP
interface-routes
rib-group
815
routing-instances (Multiple Routing Entities)
IN THIS SECTION
Syntax | 815
Description | 815
Default | 816
Options | 816
Syntax
routing-instances routing-instance-name { ... }
Hierarchy Level
[edit],
[edit logical-systems logical-system-name]
Description
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.
Each routing instance consist of the following:

816
• 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.
Routes are installed into the default routing instance inet.0 by default, unless a routing instance is
specified.
In Junos OS Release 9.0 and later, you can no longer specify a routing-instance name of primary, default,
or bgp or include special characters within the name of a routing instance.
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. Routing-instance names, further, are
restricted from having the form __.*__ (beginning and ending with underscores). The colon : character
cannot be used when multitopology routing (MTR) is enabled.
Default
Routing instances are disabled for the router.
Options
routing-instance-name —Name of the routing instance. This must be a non-reserved string of not
more than 128 characters.
remote-vtep-list Configure static remote VXLAN tunnel endpoints.
remote-vtep-v6-list Configure static IPv6 remote VXLAN tunnel endpoints.

817
Release Information
remote-vtep-v6-list statement introduced in Junos OS Release 17.3 for MX Series routers with MPC
and MIC interfaces.
Example: Configuring Interprovider Layer 3 VPN Option A

Example: Configuring Interprovider Layer 3 VPN Option B
Example: Configuring Interprovider Layer 3 VPN Option C
sham-link
IN THIS SECTION
Syntax | 818
Description | 818
Options | 819

818
Syntax
sham-link {
local address;
}
Hierarchy Level

name protocols ospf],
Description
Configure the local endpoint of a sham link.
over the VPN backbone. This is because the backup link is considered an intra-area link, while the VPN
backbone is always considered an inter-area link. Intra-area links are always preferred over inter-area
links.
address.
819
Options
local address—The address for the local endpoint of the sham link.
routing-control—To add this statement to the configuration
Release Information

sham-link-remote
IN THIS SECTION
Syntax | 820
Description | 820
Options | 821

820
Syntax
sham-link-remote address {
demand-circuit;
ipsec-sa name;
metric metric;
}
Hierarchy Level

Description
Configure the remote endpoint of a sham link.
over the VPN backbone. This is ecause the backup link is considered an intra-area link, while the VPN
backbone is always considered an inter-area link. Intra-area links are always preferred over inter-area
links.
address.
821
Options
address Address for the remote end point of the sham link.
demand- Configure an interface as a demand circuit.

circuit
ipsec-sa Apply the named IPsec authentication to the OSPF interface or virtual link or to an
name OSPFv2 remote sham link.
metric metric 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. Range is 1 through 65,535. 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.
Release Information
Support for ipsec-sa statement added in Junos OS Release 8.3.

sham-link | 817
822
shortcuts (Protocols OSPF)
IN THIS SECTION
Syntax | 822
Description | 823
Options | 823
Syntax
shortcuts {
}
Hierarchy Level
[edit logical-systems logical-system-name protocols (ospf | ospf3) traffic-

engineering],
name protocols (ospf | ospf3) traffic-engineering],
[edit protocols (ospf | ospf3) traffic-engineering],
[edit routing-instances routing-instance-name protocols (ospf | ospf3)traffic-
engineering]
823
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.
Options
lsp-metric-into-summary Advertise the LSP metric in summary LSAs.
Release Information
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.

824
source-packet-routing (Protocols OSPF)
IN THIS SECTION
Syntax | 824
Description | 825
Default | 825
Options | 825
Syntax
source-packet-routing {
adjacency-segment {
hold-time hold-time;
}
disable;
explicit-null;
node-segment {
ipv4-index index;
}
srgb {
start-label start-label;
}
}
825
Hierarchy Level
[edit logical-systems logical-system-name protocols ospf],

[edit protocols ospf],
Description
Configures source packet routing in networking (SPRING) feature.
Default
Disabled on all the levels.
Options
adjacency- Configure attributes for adjacency segments in source packet routing in networking
segment (SPRING), or configure segment routing (SR) to ensure that the adjacency segment
<hold-time
hold-time> identifiers are retained during adjacency or link flaps. The adjacency segments are not
released immediately and are retained for the configured hold time duration.
• hold-time hold-time—(Optional) Duration, in milliseconds, to retain adjacency

segments after isolating from an interface. The range is 180,000 through 900,000,
with the default being 300,000 milliseconds for IS-IS interfaces and 180,000
milliseconds for OSPF interfaces.
disable Disable source packet routing from a specific level.
explicit-null Configure E and P bits in all prefix segment identifier (SID) advertisements.
node- Enable source packet routing in networking (SPRING) at all levels. SPRING or segment
segment routing is a control-plane architecture that enables an ingress router to steer a packet
826
through a specific set of nodes and links in the network without relying on the
intermediate nodes in the network to determine the actual path it should take.
NOTE: Provisioning the IPv4 and IPv6 node segment index is allowed per
routing-instance, and will NOT be allowed per IS-IS level. Node segment index is
attached to the IPv4 and IPv6 router-id, if the router-ids are configured on the
loopback interface. Else, lowest IP address on the loopback is chosen to attach
the node-sid.
index-range Range of node segment indices allowed. The range is 32 through 16384,
index range and the default is 4096.
ipv4-index IPv4 node segment index. The range is 0 through 199999.

index
NOTE: Starting with Junos OS Release 17.2, the maximum index

for IPv4 node segment index is 199999.
ipv6-index IPv6 node segment index. The range is 0 through 199999.

index
NOTE: Starting with Junos OS Release 17.2, the maximum index

for IPv6 node segment index is 199999.
Release Information

827
OSPF Overview | 2
spf-options (Protocols OSPF)
IN THIS SECTION
Syntax | 827
Description | 828
Options | 828
Syntax
spf-options {
delay milliseconds;
holddown milliseconds;
rapid-runs number;
}
Hierarchy Level

828

Description
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. 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.
Running the SPF algorithm is usually the beginning of a series of larger system-wide events. For
example, the SPF algorithm can lead to interior gateway protocol (IGP) prefix changes, which then lead
to BGP nexthop resolution changes. Consider what happens if there are rapid link changes in the
network. The local routing device can become overwhelmed. This is why it sometimes makes sense to
throttle the scheduling of the SPF algorithm.
Options
delay milliseconds—Time interval between the detection of a topology change and when the SPF
algorithm runs.
• Range: 50 through 8000 milliseconds

829
• Default: 200 milliseconds
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.
• 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.
• Default: 3
Release Information

Traffic
830
stub
IN THIS SECTION
Syntax | 830
Description | 831
Options | 831
Syntax
stub <default-metric metric> <(no-summaries | summaries)>;
Hierarchy Level

831
id],
Description
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
default-metric Metric value, ranging from 1 through 16,777,215.

metric
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.
Release Information
832

nssa | 787
stub-network
IN THIS SECTION
Syntax | 832
Description | 833
Syntax
stub-network;
Hierarchy Level

[edit routing-instances name protocols ospf overload]
833
Description
Advertise Stub Network with maximum metric.
Release Information

as-external | 704
topology (OSPF)
IN THIS SECTION
Syntax | 834
Description | 834
Options | 835

834
Syntax
topology (default | ipv4-multicast | name) {

spf-options {
delay milliseconds;
holddown milliseconds;
rapid-runs number;
}
topology-id number;
}
Hierarchy Level
[edit logical-systems logical-system-name protocols ospf],

[edit protocols ospf],
Description
Enable a topology for OSPF multitopology routing. You must first configure one or more topologies
under the [edit routing-options] hierarchy level.
835
Options
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 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.
Release Information
Traffic
836
topology (OSPF Interface)
IN THIS SECTION
Syntax | 836
Description | 837
Default | 837
Options | 837
Syntax

metric metric;
}
Hierarchy Level

interface-name],
name protocols ospf area area-id interface interface-name],
[edit protocols ospf area area-id interface interface-name],
interface interface-name]
837
Description
Configure interface-specific properties for multitopology OSPF, including topology-specific metric

values for an interface.
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.
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.
• Default: 1

838
Release Information
Traffic
traceoptions (Protocols OSPF)
IN THIS SECTION
Syntax | 838
Description | 839
Default | 839
Options | 840
Syntax
traceoptions {
file filename <files number> <size size> <world-readable | no-world-
readable>;
839
flag flag <flag-modifier> <disable>;

}
Hierarchy Level

Description
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 systems.
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.
840
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 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 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.
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.
841
• 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
• 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.
flag-modifier—(Optional) Modifier for the tracing flag. You can specify one or more of these modifiers:
• detail—Detailed trace information.
• receive—Packets being received.
• send—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), 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.
842
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.
routing and trace—To view this statement in the configuration.
routing-control and trace-control—To add this statement to the configuration.
Release Information

843
traffic-engineering (OSPF)
IN THIS SECTION
Syntax | 843
Description | 844
Default | 844
Options | 844
Syntax
ignore-lsp-metrics;
no-topology;
igp-topology;
shortcuts {
}
}
Hierarchy Level

[edit protocols (ospf | ospf3)]
844
Description
Enable the OSPF traffic engineering features.
Default
Traffic engineering support is disabled.
Options
advertise-unnumbered-interfaces—(Optional) (OSPFv2 only) Include the link-local identifier in the link-

local traffic-engineering link-state advertisement. This statement must be included on both ends of an
unnumbered link to allow an ingress LER to update the link in its traffic engineering database and use it
for CSPF calculations. The link-local identifier is then used by RSVP 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.
ignore-lsp-metrics—(Optional) Ignore RSVP LSP metrics in OSPF traffic engineering shortcut

calculations.
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.
845
no-topology—(Optional) (OSPFv2 only) Disable the dissemination of the link-state topology information.
igp-topology—Download IGP topology information into the traffic engineering database (TED). In Junos
OS, the IGPs install topology information into a database called the traffic engineering database. The
traffic engineering database contains the aggregated topology information. The IGP routes are installed
by the traffic engineering database on behalf of the corresponding IGP into a user-visible routing table
called lsdist.0, subject to route policies.
CAUTION: When the OSPF traffic engineering configuration is considerably modified,

the routing table entries are deleted and the routing table is recreated. Changes to
configuration that can cause this behavior include enabling or disabling:
• Traffic engineering shortcuts
• IGP shortcuts
• LDP tunneling
• Multiprotocol LSP
• Advertise summary metrics
• Multicast RPF routes
Release Information
multicast-rpf-routes option introduced in Junos OS Release 7.5.
advertise-unnumbered-interfaces option introduced in Junos OS Release 8.5.
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.
846
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.
Support for igp-topology statement introduced in Junos OS Release 17.4R1 for MX series, and PTX
Series.
traffic-engineering (Passive TE Mode)
IN THIS SECTION
Syntax | 846
Description | 847
Default | 847
Options | 847
Syntax
remote-node-id address;
remote-node-router-id address;
}
847
Hierarchy Level

interface interface-name passive],
ipv4-multicast | ipv6-multicast) area area-id interface interface-name passive],
name protocols (ospf | ospf3) area area-id interface interface-name passive],
area-id interface interface-name passive],
[edit protocols (ospf | ospf3) area area-id interface interface-name passive],
area area-id interface interface-name passive],
id interface interface-name passive],
unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name
passive]
Description
Configure an interface in OSPF passive traffic engineering mode to enable dynamic discovery of OSPF
AS boundary routers.
Default
OSPF passive traffic-engineering mode is disabled.
Options
remote-node-id IP address at the far end of the inter-AS link.

address
848
remote-node- Router ID at the far end of the inter-AS link.

router-id address
NOTE: The remote-node-router-id address option does not apply under the
[edit routing-instances routing-instance-name] and [edit protocols ospf3
area area-id] hierarchy levels.
Release Information
remote-node-router-id address option introduced in Junos OS Release 14.2.

Junos OS MPLS Applications User Guide
849
use-post-convergence-lfa (Protocols OSPF)
IN THIS SECTION
Syntax | 849
Description | 849
Options | 850
Syntax
use-post-convergence-lfa <maximum-backup-paths maximum-backup-paths> <maximum-

labels maximum-labels> ;
Hierarchy Level
[edit logical-systems name protocols ospf backup-spf-options],

[edit logical-systems name routing-instances name protocols ospf backup-spf-
options],
[edit protocols ospf backup-spf-options],
[edit routing-instances name protocols ospf backup-spf-options]
Description
Calculate post-convergence MPLS fast reroute (FRR) backup next hops for the OSPF protocol using
segment routing (SR). Junos OS allows you to control the maximum number of equal-cost multipath
850
(ECMP) backup paths installed for a given destination. Junos OS also allows you to control the maximum
number of labels in the installed backup paths. Configure the use-source-packet-routing statement at
[edit protocols ospf backup-spf-options] hierarchy level to allow the backup paths to be available for
inet.0 routing table along with inet.3 routing table.
Options
maximum- Set the maximum number of equal-cost post-convergence backup paths to be installed.
backup-paths
• Default: 1
• Range: 1-8
maximum- Set the maximum number of labels used to construct a post-convergence backup path.
labels If the backup path for a particular prefix requires more labels than the configured
maximum labels, then the backup path for that particular prefix is not installed.
NOTE: If the maximum-labels option is not configured, then the maximum

number of labels used to construct a post-convergence backup path is 3.
• Default: 3
• Range: 2-5
routing
Release Information
Statement introduced in Junos OS Release 18.2R1 for MX Series, PTX Series, and QFX Series.
851

virtual-link
IN THIS SECTION
Syntax | 851
Description | 852
Options | 852
Syntax
virtual-link neighbor-id router-id transit-area area-id {

disable;
authentication key <key-id identifier>;
ipsec-sa name;
}
852
Hierarchy Level

Description
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.
Options
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.
ipsec-sa name Apply the named IPsec authentication to the OSPF interface or virtual link or to
an OSPFv2 remote sham link.

853
Release Information

20 CHAPTER
Operational Commands
clear bfd adaptation | 856
clear bfd session | 858
clear (ospf | ospf3) database-protection | 864
clear (ospf | ospf3) io-statistics | 866
clear (ospf | ospf3) overload | 871
show bfd session | 876
show (ospf | ospf3) backup neighbor | 895
show (ospf | ospf3) interface | 929
show (ospf | ospf3) io-statistics | 939
show (ospf | ospf3) log | 941

show (ospf | ospf3) overview | 955
show (ospf | ospf3) route | 963
show policy | 977
show route | 981
show route instance | 994
show route protocol | 1000

856
clear bfd adaptation
IN THIS SECTION
Syntax | 856
Description | 856
Options | 857
Additional Information | 857
Output Fields | 857
Sample Output | 857
Syntax

<all>
<address session-address>
<discriminator discr-number>
Description
Clear adaptation for Bidirectional Forwarding Detection (BFD) sessions. BFD is a simple hello
mechanism that detects failures in a network. Configured BFD interval timers can change, adapting to
network situations. Use this 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 routing device.
857
Options
all Clear adaptation for all BFD sessions.
address session-address (Optional) Clear adaptation for all BFD sessions matching the specified
address.
discriminator discr-number (Optional) Clear adaptation for the local BFD session matching the
specified discriminator.
Additional Information
For more information, see the description of the bfd-liveness-detection configuration statement in the
Junos Routing Protocols Configuration Guide.
clear
Output Fields
When you enter this command, you are provided feedback on the status of your request.
Sample Output
user@host> clear bfd adaptation

858
Release Information
Command introduced before Junos OS Release 7.4.
show bfd session
clear bfd session
IN THIS SECTION
Syntax | 858
Syntax (EX Series Switch and QFX Series) | 859
Description | 859
Options | 859
Output Fields | 859
Sample Output | 860
Syntax
clear bfd session

<all>
<logical-system (all | logical-system-name)>
859
Syntax (EX Series Switch and QFX Series)
clear bfd session

<all>
Description
Drop one or more Bidirectional Forwarding Detection (BFD) sessions.
Options
all Drop all BFD sessions.
address session-address (Optional) Drop all BFD sessions matching the specified address.
discriminator discr-number (Optional) Drop the local BFD session matching the specified
discriminator.
logical-system (all | logical- (Optional) Perform this operation on all logical systems or on a
system-name) particular logical system.
clear
Output Fields
860
Sample Output
clear bfd session all
user@host> clear bfd session all
Release Information
show bfd session
clear (ospf | ospf3) database
IN THIS SECTION
Syntax | 861
Description | 862
Options | 862
Output Fields | 863
Sample Output | 864

861
Syntax

<all>
<advertising-router (router-id | self)>
<area area-id>
<asbrsummary>
<external>
<instance instance-name>
<inter-area-prefix>
<inter-area-router>
<intra-area-prefix>
<link-local>
<lsa-id lsa-id>
<netsummary>
<network>
<nssa>
<opaque-area>
<purge>
<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)>
<router>

<all>
<advertising-router (router-id | self)>
<area area-id>
<asbrsummary>
<external>
<inter-area-prefix>
<inter-area-router>
<intra-area-prefix>
<link-local>
<lsa-id lsa-id>
<netsummary>
862
<network>
<nssa>
<opaque-area>
<purge>
<router>
Description
With the primary Routing Engine, delete entries in the Open Shortest Path First (OSPF) link-state
advertisement (LSA) database. With the backup Routing Engine, delete the OSPF LSA database and sync
the new database with the primary Routing Engine.
CAUTION: You can also use the purge command with any of the options to discard
rather than delete the specified LSA entries. This command is useful only for testing.
Use it with care, because it causes significant network disruption.
Options
all Delete all LSAs other than the system’s own LSAs, which are regenerated. To
resynchronize the database, the system destroys all adjacent neighbors that
are in the state EXSTART or higher. The neighbors are then reacquired and
the databases are synchronized.
advertising-router (Optional) Discard entries for the LSA entries advertised by the specified
(router-id | self) routing device or by this routing device.
area area-id (Optional) Discard entries for the LSAs in the specified area.
asbrsummary (Optional) Discard summary AS boundary router LSA entries.
external (Optional) Discard external LSAs.
instance instance-name (Optional) Delete or discard entries for the specified routing instance only.
inter-area-prefix (OSPFv3 only) (Optional) Discard interarea prefix LSAs.
inter-area-router (OSPFv3 only) (Optional) Discard interarea router LSAs.

863
intra-area-prefix (OSPFv3 only) (Optional) Discard intra-area prefix LSAs.
logical-system (all | (Optional) Perform this operation on all logical systems or on a particular
logical-system-name) logical system.
link-local (Optional) Delete link-local LSAs.
lsa-id lsa-id (Optional) Discard the LSA entries with the specified LSA identifier.
netsummary (Optional) Discard summary network LSAs.
network (Optional) Discard network LSAs.
nssa (Optional) Discard not-so-stubby area (NSSA) LSAs.
opaque-area (Optional) Discard opaque area-scope LSAs.
realm (ipv4-multicast | (OSPFv3 only) (Optional) Delete the entries for the specified OSPFv3 realm,
ipv4-unicast | ipv6- or address family. Use the realm option to specify an address family for
multicast)
OSPFv3 other than IPv6 unicast, which is the default.
router (Optional) Discard router LSAs.
purge (Optional) Discard all entries in the link-state advertisement database. All
link-state advertisements are set to MAXAGE and are flooded. The database
is repopulated when the originators of the link-state advertisements receive
the MAXAGE link-state advertisements and reissue them.
clear
Output Fields
864
Sample Output
clear ospf database all
user@host> clear ospf database all
Release Information
advertising-router router-id, netsummary, network, nssa, opaque-area, and router options added in
Junos OS Release 8.3. You must use the purge command with these options.
area area-id option added in Junos OS Release 8.3.
realm option added in Junos OS Release 9.2.
advertising-router (router-id | self) option added in Junos OS Release 9.5.
advertising-router (router-id | self) option introduced in Junos OS Release 9.5 for EX Series switches.
purge option (and all options that are dependent on the purge option) hidden in Junos OS Release 13.3.

clear (ospf | ospf3) database-protection
IN THIS SECTION
Syntax | 865
Description | 865
865
Options | 865
Output Fields | 866
Sample Output | 866
Syntax
clear (ospf | ospf3) database-protection

Description
Clear the Open Shortest Path First (OSPF) link-state database from its isolated state. Reset the ignore
count, ignore timer, and reset timer, and resume normal operations.
Options
instance instance- (Optional) Clear the OSPF link-state database for the specified routing instance
name only.
clear
866
Output Fields
This command produces no output.
Sample Output
clear ospf database-protection
user@host> clear ospf database-protection
Release Information
Command introduced in Junos OS Release 10.2.
clear (ospf | ospf3) io-statistics
IN THIS SECTION
Syntax | 867
Description | 867
Options | 867
Output Fields | 867
Sample Output | 868

867
Syntax
clear (ospf | osfp3) io-statistics

clear (ospf | osfp3) io-statistics
Description
Clear Open Shortest Path First (OSPF) input and output statistics.
Options
none Clear OSPF input and output statistics.
logical-system (all | logical- (Optional) Perform this operation on all logical systems or on a particular
system-name) logical system.
clear
Output Fields
868
Sample Output
clear ospf io-statistics
user@host> clear ospf io-statistics
Release Information
clear (ospf | ospf3) neighbor
IN THIS SECTION
Syntax | 868
Description | 869
Options | 869
Output Fields | 870
Sample Output | 870
Syntax

<all>
<area area-id>
869
<interface interface-name>
<neighbor>

<all>
<area area-id>
<neighbor>
Description
Tear down Open Shortest Path First (OSPF) neighbor connections.
Options
all Tear down OSPF connections with all neighbors for all routing instances.
area area-id (Optional) Tear down neighbor connections for the specified area only.
instance instance-name (Optional) Tear down neighbor connections for the specified routing instance
only.
interface interface-name (Optional) Tear down neighbor connections for the specified interface only.
neighbor (Optional) Clear the state of the specified neighbor only.

870
realm (ipv4-multicast | (Optional) (OSPFv3 only) Clear the state of the specified OSPFv3 realm, or
ipv4-unicast | ipv6- address family. Use the realm option to specify an address family for OSPFv3
multicast)
other than IPv6 unicast, which is the default.
clear
Output Fields
Sample Output
clear ospf neighbor all
user@host> clear ospf neighbor all
Release Information
realm option introduced in Junos OS Release 9.2.

871
clear (ospf | ospf3) overload
IN THIS SECTION
Syntax | 871
Syntax (EX Series Switches) | 871
Description | 871
Options | 872
Output Fields | 872
Sample Output | 872
Syntax

Syntax (EX Series Switches)

Description
Clear the Open Shortest Path First (OSPF) overload bit and rebuild link-state advertisements (LSAs).
872
Options
none Clear the overload bit and rebuild LSAs for all routing instances.
instance instance-name (Optional) Clear the overload bit and rebuild LSAs for the specified
routing instance only.
clear
Output Fields
Sample Output
clear ospf overload
user@host> clear ospf overload
Release Information

873
clear (ospf | ospf3) statistics
IN THIS SECTION
Syntax | 873
Description | 873
Options | 874
Output Fields | 874
Sample Output | 874
Syntax
clear (ospf | osfp3) statistics

clear (ospf | osfp3) statistics

Description
Clear Open Shortest Path First (OSPF) statistics.

874
Options
none Clear OSPF statistics.
instance instance-name (Optional) Clear statistics for the specified routing instance only.
realm (ipv4-multicast | ipv4- (Optional) (OSPFv3 only) Clear statistics for the specified OSPFv3 realm,
unicast | ipv6-multicast) or address family. Use the realm option to specify an address family for
OSPFv3 other than IPv6 unicast, which is the default.
clear
Output Fields
See "show (ospf | ospf3) statistics" on page 972 for an explanation of output fields.
Sample Output
clear ospf statistics
The following sample output displays OSPF statistics before and after the clear ospf statistics command
is entered:
user@host> show ospf statistics
Packet type Total Last 5 seconds

Sent Received Sent Received
Hello 3254 2268 3 1
DbD 41 46 0 0
LSReq 8 7 0 0
875
LSUpdate 212 154 0 0

LSAck 65 98 0 0
DBDs retransmitted : 3, last 5 seconds : 0

LSAs flooded : 12, last 5 seconds : 0
LSAs flooded high-prio : 0, last 5 seconds : 0
LSAs retransmitted : 0, last 5 seconds : 0
LSAs transmitted to nbr: 3, last 5 seconds : 0
LSAs requested : 5, last 5 seconds : 0
LSAs acknowledged : 19, last 5 seconds : 0
Flood queue depth : 0

Total rexmit entries : 0
db summaries : 0
lsreq entries : 0
Receive errors:
626 subnet mismatches
user@host> clear ospf statistics

Hello 3 1 3 1
DbD 0 0 0 0
LSReq 0 0 0 0
LSUpdate 0 0 0 0
LSAck 0 0 0 0


db summaries : 0
876
lsreq entries : 0
Receive errors:
None
Release Information
show bfd session
IN THIS SECTION
Syntax | 877
Description | 877
Options | 877
Output Fields | 878
Sample Output | 885

877
Syntax
show bfd session

<brief | detail | extensive | summary>
<address address>
<client rsvp-oam (brief | detail | extensive | summary) | vpls-oam (brief |
detail | extensive | instance instance-name | summary)>
<discriminator discriminator>
<prefix address>
<subscriber (address destination-address | discriminator discriminator |
extensive)>
show bfd session

<address address>
<client rsvp-oam (brief | detail | extensive | summary) | vpls-oam (brief |
detail | extensive | instance instance-name | summary)>
<discriminator discriminator>
<prefix address>
Description
Display information about active Bidirectional Forwarding Detection (BFD) sessions.
Options
none (Same as brief) Display information about active BFD sessions.
brief | detail | extensive | (Optional) Display the specified level of output.

summary
878
address address (Optional) Display information about the BFD session for the
specified neighbor address.
client rsvp-oam (brief | detail | (Optional) Display information about RSVP-OAM or VPLS-OAM
extensive | summary) | vpls-oam BFD sessions in the specified level of output. For VPLS-OAM,
(brief | detail | extensive |
instance instance-name | display the specified level of output or display information about all
summary) of the BFD sessions for the specified VPLS routing instance.
discriminator discriminator (Optional) Display information about the BFD session using the
specified local discriminator.
<subscriber (address destination- (Optional) Display information about all BFD sessions for
address | discriminator subscribers, or for a single BFD subscriber session with a particular
discriminator | extensive)>
destination address, or with a particular denominator.
view
Output Fields
Table 6 on page 878 describes the output fields for the show bfd session command. Output fields are
listed in the approximate order in which they appear.
Table 6: show bfd session Output Fields
Field Name Field Description Level of Output
Address Address on which the BFD session is active. brief detail

extensive none
State State of the BFD session: Up, Down, Init (initializing), or Failing. brief detail
extensive none
879
Table 6: show bfd session Output Fields (Continued)
Interface Interface on which the BFD session is active. brief detail

extensive none
Detect Time Negotiated time interval, in seconds, used to detect BFD control brief detail
packets. extensive none
Transmit Time interval, in seconds, used by the transmitting system to brief detail
Interval send BFD control packets. extensive none
Multiplier Negotiated multiplier by which the time interval is multiplied to detail extensive
determine the detection time for the transmitting system.
Session up How long a BFD session has been established. detail extensive
time
Client Protocol or process for which the BFD session is active: ISIS, detail extensive
OSPF, DHCP, Static, or VGD.
TX interval Time interval, in seconds, used by the host system to transmit brief detail
BFD control packets. extensive none
RX interval Time interval, in seconds, used by the host system to receive brief detail
BFD control packets. extensive none
Authenticate Indicates that BFD authentication is configured. detail extensive
keychain Name of the security authentication keychain being used by a extensive

specific client.
BFD authentication information for a client is provided in a

single line and includes the keychain, algo, and mode
parameters. Multiple clients can be configured on a BFD session.
880
algo BFD authentication algorithm being used for a specific client: extensive
keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-
keyed-sha-1, or simple-password.

mode Level of BFD authentication enforcement being used by a extensive

specific client: strict or loose. Strict enforcement indicates that
authentication is configured at both ends of the session (the
default). Loose enforcement indicates that one end of the
session might not be authenticated.

Local Local diagnostic information about failing BFD sessions. detail extensive
diagnostic
Following are the expected values for Local Diagnostic output
field:
• None—No diagnostic
• CtlExpire—Control detection time expired
• EchoExpire—Echo detection time expired
• NbrSignal—Neighbor signalled session down
• FwdPlaneReset—Forwarding plane reset
• PathDown—Path down
• ConcatPathDown—Concatenated path down
• AdminDown—Administratively down
881
Remote Remote diagnostic information about failing BFD sessions. detail extensive
diagnostic
Following are the expected values for Remote Diagnostic output
field:
• None—No diagnostic
• CtlExpire—Control detection time expired
• EchoExpire—Echo detection time expired
• NbrSignal—Neighbor signalled session down
• FwdPlaneReset—Forwarding plane reset
• PathDown—Path down
• ConcatPathDown—Concatenated path down
• AdminDown—Administratively down
Remote state Reports whether the remote system's BFD packets have been detail extensive
received and whether the remote system is receiving transmitted
control packets.
Version BFD version: 0 or 1. extensive
Replicated The replicated flag appears when nonstop routing or graceful detail extensive
Routing Engine switchover is configured and the BFD session
has been replicated to the backup Routing Engine.
Min async Minimum amount of time, in seconds, between asynchronous extensive

interval control packet transmissions across the BFD session.
Min slow Minimum amount of time, in seconds, between synchronous extensive

interval control packet transmissions across the BFD session.
882
Adaptive async Transmission interval being used because of adaptation. extensive

TX interval
RX interval Minimum required receive interval. extensive
Local min TX Minimum amount of time, in seconds, between control packet extensive
interval transmissions on the local system.
Local min RX Minimum amount of time, in seconds, between control packet extensive
interval detections on the local system.
Remote min TX Minimum amount of time, in seconds, between control packet extensive
interval transmissions on the remote system.
Remote min TX Minimum amount of time, in seconds, between control packet extensive
interval detections on the remote system.
Threshold Threshold for notification if the transmission interval increases. extensive

transmission
interval
Threshold for Threshold for notification if the detection time increases. extensive
detection time
Local Authentication code used by the local system to identify that extensive
discriminator BFD session.
Remote Authentication code used by the remote system to identify that extensive
discriminator BFD session.
883
Echo mode Information about the state of echo transmissions on the BFD extensive
session.
Prefix LDP FEC address associated with the BFD session. All levels
Egress, Displays the LDP FEC destination address. This field is displayed All levels
Destination only on a router at the egress of an LDP FEC, where the BFD
session has an LDP Operation, Administration, and Maintenance
(OAM) client.
Remote is The BFD session on the remote peer is running on its Packet extensive
control-plane Forwarding Engine. In this case, when the remote node
independent undergoes a graceful restart, the local peer can help the remote
peer with the graceful restart.
The following BFD sessions are not distributed to the Packet

Forwarding Engine: tunnel-encapsulated sessions, and sessions
over integrated routing and bridging (IRB) interfaces.
884
Authentication Summary status of BFD authentication: extensive
• status—enabled/active indicates authentication is configured

and active. enabled/inactive indicates authentication is
configured but not active. This only occurs when the remote
end of the session does not support authentication and loose
checking is configured.
• keychain—Name of the security authentication keychain

associated with the specified BFD session.
• algo—BFD authentication algorithm being used: keyed-md5,

keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-
sha-1, or simple-password.
• mode—Level of BFD authentication enforcement: strict or

loose. Strict enforcement indicates authentication is
configured at both ends of the session (the default). Loose
enforcement indicates that one end of the session might not
be authenticated.
This information is only shown if BFD authentication is

configured.
Session ID The BFD session ID number that represents the protection using detail extensive
MPLS fast reroute (FRR) and loop-free alternate (LFA).
sessions Total number of active BFD sessions. All levels
clients Total number of clients that are hosting active BFD sessions. All levels
Cumulative Total number of BFD control packets transmitted per second on All levels
transmit rate all active sessions.
Cumulative Total number of BFD control packets received per second on all All levels
receive rate active sessions.
885
Multi-hop, min- Minimum time to live (TTL) accepted if the session is configured extensive
recv-TTL for multihop.
route table Route table used if the session is configured for multihop. extensive
local address Local address of the source used if the session is configured for extensive
multihop.
The source IP address for outgoing BFD packets from the egress
side of an MPLS BFD session is based on the outgoing interface
IP address.
Sample Output
show bfd session
user@host> show bfd session

Transmit
Address State Interface Detect Time Interval Multiplier
10.9.1.33 Up so-7/1/0.0 0.600 0.200 3
10.9.1.29 Up ge-4/0/0.0 0.600 0.200 3
show bfd session brief
The output for the show bfd session brief command is identical to that for the show bfd session
command.
886
show bfd session detail
user@host> show bfd session detail

Transmit
Address State Interface Detect 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
Session up time 3d 00:34:02
Replicated
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
Session up time 3d 00:29:04, previous down time 00:00:01
Local diagnostic NbrSignal, remote diagnostic AdminDown
Release Information
Options discriminator and address introduced in Junos OS Release 8.2.
Option prefix introduced in Junos OS Release 9.0.
Option client introduced in Junos OS Release 12.3R3.
Option subscriber introduced in Junos OS Release 15.1 for the MX Series.
clear bfd session

Understanding BFD for Static Routes for Faster Network Failure Detection
Understanding BFD for BGP
Understanding Bidirectional Forwarding Detection Authentication for PIM
887
Configuring BFD for PIM

Understanding BFD for IS-IS
show (ospf | ospf3) backup coverage
IN THIS SECTION
Syntax | 887
Syntax (QFX Series) | 888
Description | 888
Options | 888
Output Fields | 889
Sample Output | 890
Syntax

< logical-system (all | logical-system-name)>
<realm (ipv4-unicast | ipv46-unicast>
<topology topology-name>
888
Syntax (QFX Series)

Description
Display information about the level of backup coverage available for all the nodes and prefixes in the
network.
Options
none Display information about the level backup coverage for all OSPF routing
instances in all logical systems.
logical-system (all | (Optional) Display information about the level of backup coverage for all
logical-system-name) logical systems or for a specific logical system.
instance instance-name (Optional) Display information about the level of backup coverage for a
specific OSPF routing instance.
realm (ipv4-unicast | (Optional) (OSPFv3 only) Display information about the level of backup
ipv6-unicast) coverage for the specific OSPFv3 realm, or address family.
topology (default | (Optional) (OSPFv2 only) Display information about the level of backup
topology-name) coverage for the specific OSPF topology.
view
889
Output Fields
Table 7 on page 889 lists the output fields for the show (ospf | ospf3) backup coverage command.
Output fields are listed in the approximate order in which they appear.
Table 7: show (ospf | ospf3) backup coverage Output Fields
Field Name Field Description
rmorn, June 2020: Uplift Information about backup coverage for each OSPF node.
project, general cleanup
Area Area number. Area 0.0.0.0 is the backbone.
Covered Nodes Number of nodes for which backup coverage is available.
Total Nodes Total number of OSPF nodes.
Route Coverage Information about backup coverage for each type of OSPF route.
Path Type Type of OSPF path: Intra, Inter, Ext1, Ext2, and All.
Covered Routes For each path type, the number of routes for which backup coverage is
available.
Total Routes For each path type, the total number of configured routes.
Percent Covered For all nodes and for each path type, the percentage for which backup
coverage is available.
890
Sample Output
show ospf backup coverage
user@host> show ospf backup coverage

Topology default coverage:
Node Coverage:

Nodes Nodes Covered
0.0.0.0 4 5 80.00%
Route Coverage:

Intra 8 14 57.14%
Inter 0 0 100.00%
Ext1 0 0 100.00%
Ext2 1 1 100.00%
All 9 15 60.00%
show ospf3 backup coverage
user @host > show ospf3 backup coverage

show ospf3 backup coverage
Node Coverage:

Nodes Nodes Covered
0.0.0.0 4 5 80.00%
Route Coverage:

Intra 4 6 66.67%
Inter 0 0 100.00%
Ext1 0 0 100.00%
891
Ext2 1 1 100.00%
All 5 7 71.43%
Release Information
show (ospf | ospf3) backup lsp
IN THIS SECTION
Syntax | 892
Description | 892
Options | 892
Output Fields | 893
Sample Output | 894
Sample Output | 894

892
Syntax
show (ospf | ospf3) backup lsp

<logical-system (all | logical-system-name>
<realm (ipv4-unicast | ipv6-unicast)>
Description
Display information about MPLS label-switched-paths (LSPs) designated as backup routes for OSPF
routes.
NOTE: MPLS LSPs can be used as backup routes only for routes in the default OSPFv2 topology
and not for any configured topology. Additionally, MPLS LSPs cannot be used as backup routes
for nondefault instances either for OSPFv2 or OSPFv3.
Options
none Display information all MPLS LSPs designated as backup routes.
logical-system (all | (Optional) Display information about MPLS LSPs designated as backup routes
logical-system-name) for all logical systems or a specific logical system.
realm (ipv4-unicast | (Optional) (OSPFv3 only) Display information about MPLS LSPs designated as
ipv6-unicast) backup routes for a specific realm, or address family.
view
893
Output Fields
Table 8 on page 893 lists the output fields for the show (ospf | ospf3) backup lsp command. Output
fields are listed in the approximate order in which they appear.
Table 8: show (ospf | ospf3) backup lsp Output Fields
MPLS LSP name Name of each MPLS LSP designated as a backup path.
Egress IP address of the egress router for the LSP.
Status State of the LSP:
• Up—The router can detect RSVP hello messages from the neighbor.
• Down—The router has received one of the following indications:
• Communication failure from the neighbor.
• Communication from IGP that the neighbor is unavailable.
• Change in the sequence numbers in the RSVP hello messages

sent by the neighbor.
• Deleted—The LSP is no longer available as a backup path.
Last change Time elapsed since the neighbor state changed either from up or down
or from down to up. The format is hh:mm:ss.
TE-metric Configured traffic engineering metric.
Metric Configured metric.

894
Sample Output
show ospf backup lsp
user@host> show ospf backup lsp

tobanff
Sample Output
show ospf3 backup lsp
user@host> show ospf3 backup lsp

tobanff
Release Information

895
show (ospf | ospf3) backup neighbor
IN THIS SECTION
Syntax | 895
Description | 896
Options | 896
Output Fields | 896
Sample Output | 897
Syntax

<area area-id>
<instance (default | instance-name)>
<logical-system (default | ipv4-multicast | logical-system-name)>
<topology (default | ipv4-multicast | topology-name)>
Syntax (QFX Series)

<area area-id>
896
Description
Display the neighbors through which direct next hops for the backup paths are available.
Options
none Display all neighbors that have direct next hops for backup paths.
area area-id (Optional) Display the area information.
instance (default | instance- (Optional) Display information about the default routing instance or a
name) particular routing instance.
logical-system (default | ipv4- (Optional) Display information about the default logical system, IPv4
multicast | logical-system- multicast logical system, or a particular logical system.
name)
topology (default | ipv4- (OSPFv2 only) (Optional) Display information about the default
multicast | topology-name) topology, IPv4 multicast topology, or a particular topology.
view
Output Fields
Table 9 on page 896 lists the output fields for the show (ospf |ospf3) backup neighbor command.
Output fields are listed in the approximate order in which they appear.
Table 9: show (ospf |ospf3) backup neighbor Output Fields
Neighbor to Metric from the backup neighbor to the OSPF node. All levels
Self Metric
897
Table 9: show (ospf |ospf3) backup neighbor Output Fields (Continued)
Self to Metric from the OSPF node to the backup neighbor. All levels
Neighbor
Metric
Direct next- Interface and address of the direct next hop. All levels
hop
Sample Output
show ospf backup neighbor
user@host> show ospf backup neighbor

10.0.0.5
10.0.0.6
Release Information

898
show (ospf | ospf3) backup spf
IN THIS SECTION
Syntax | 898
Description | 899
Options | 899
Output Fields | 900
Sample Output | 901
Syntax

<brief | detail>
<area area-id>
<logical-system (all | logical-system-name>
<no-coverage>
<node-id>
<realm (ipv4–unicast | ipv6–unicast)>
899
Syntax (QFX Series)

<brief | detail>
<area area-id>
<no-coverage>
<node-id>
Description
Display information about OSPF shortest-path-first calculations for backup paths.
Options
none Display information about OSPF shortest-path-first (SPF) calculations

for all backup paths for all destination nodes.
brief | detail (Optional) Display the specified level of output.
area area-id (Optional) Display the area information.
instance instance-name (Optional) Display information about the routing instance.
logical-system (all | logical- (Optional) Display information about all logical systems or a specific
no-coverage (Optional) Display information if there is no backup coverage.
node-id (Optional) Display information about the node specified.
realm (ipv4–unicast | ipv6– (Optional) Display information about the ipv4 or ipv6 realm.
unicast)
topology (default | ipv4- (Optional) (OSPFv2 only) Display information about the default
multicast | topology-name) topology, IPv4 multicast topology, or a specifc topology.
900
view
Output Fields
Table 10 on page 900 lists the output fields for the show (ospf |ospf3) backup spf command. Output
Table 10: show (ospf |ospf3) backup spf Output Fields
Area area-id Area for which the results are displayed. Area 0.0.0.0 is the All levels
results backbone area.
address Address of the node for which the results are displayed. All levels
Self to Metric from the node to the destination. All levels

Destination
Metric
Parent Node Address of the parent node. All levels
Primary next- Address of the next hop. All levels

hop
901
Table 10: show (ospf |ospf3) backup spf Output Fields (Continued)
Backup Address of the backup neighbor or LSP endpoint and the All levels
Neighbor following information:
• Neighbor to Destination Metric
• Neighbor to Self Metric
• Self to Neighbor Metric
• Status (Eligible, Not Eligible, Not Evaluated) and the reason

for the status.
NOTE: If the backup neighbor is an LSP endpoint, it is indicated

as such after the neighbor address.
Sample Output
show ospf backup spf
user@host> show ospf backup spf

Topology default results:
pro16-d-lo0.xxx.yyyy.net
Parent Node: pro16-b-lo0.xxx.yyyy.net
Primary next-hop: at-1/0/1.0
Backup Neighbor: pro16-c-lo0.xxx.yyyy.net (LSP endpoint)
Backup Neighbor: pro16-d-lo0.xxx.yyyy.net
Not eligible, Reason: Primary next-hop link fate sharing
902
...
Release Information
show ospf context-identifier
IN THIS SECTION
Syntax | 902
Syntax (EX Series Switches and QFX Series) | 903
Description | 903
Options | 903
Output Fields | 904
Sample Output | 905
Syntax

<brief | detail>
<area area-id>
<context-id>
903
Syntax (EX Series Switches and QFX Series)

<brief | detail>
<area area-id>
<context-id>
Description
Display the context identifier information processed and advertised by Open Shortest Path First (OSPF)
for egress protection.
Options
none Display information about all context identifiers.
brief | detail (Optional) Display the specified level of output.
area area-id (Optional) Display information about the context identifier for the specified
area.
context-id (Optional) Display information about the specified context identifier.
instance instance-name (Optional) Display information about the context identifier for the specified
routing instance.
view
904
Output Fields
Table 11 on page 904 lists the output fields for the show ospf context-identifier command. Output
Table 11: show ospf context-identifier Output Fields
Context IPv4 address that defines a protection pair. The context is All levels
manually configured on both primary and protector provider
edge (PE) devices.
Status State of the path: active or inactive. All levels
Metric Advertised OSPF metric. All levels
Area OSPF area number. All levels
Other Other advertisements received by the OSPF node: detail

Advertisement
• Advertising router– Address of the device that sent the
s
advertisement.
• Type–Type of OSPF path: inter-area and stub.
• Metric–Advertised OSPF metric.
• None–No additional advertisements were received by the

OSPF node.
905
Sample Output
user@host> show ospf context-identifier

Context-id: 2.2.4.3
Status: active, Metric: 65534, PE role: protector, Area: 0.0.0.0
show ospf context-identifier detail
user@host> show ospf context-identifier detail

Context-id: 88.24.13.1
Status: inactive, Metric: 0, PE role: protector, Area: 0.0.0.13
Other Advertisements:
Advertising router: 8.8.8.103
Type: stub link
Metric: 65534
Release Information
egress-protection (Layer 2 circuit)

Junos OS VPNs Library for Routing Devices
egress-protection (MPLS)
Junos OS VPNs Library for Routing Devices
906
show ospf database
IN THIS SECTION
Syntax | 906
Description | 907
Options | 907
Output Fields | 908
Sample Output | 912
Syntax
show ospf database

<advertising-router (address | self)>
<area area-id>
<asbrsummary>
<external>
<link-local>
<lsa-id lsa-id>
<netsummary>
<network>
<nssa>
<opaque-area>
<router>
907
show ospf database

<area area-id>
<asbrsummary>
<external>
<link-local>
<lsa-id lsa-id>
<netsummary>
<network>
<nssa>
<opaque-area>
<router>
Description
Display the entries in the OSPF version 2 (OSPFv2) link-state database, which contains data about link-
state advertisement (LSA) packets.
Options
none Display standard information about entries in the OSPFv2 link-state

database for all routing instances.

summary
advertising-router (address | (Optional) Display the LSAs advertised either by a particular routing
self) device or by this routing device.
area area-id (Optional) Display the LSAs in a particular area.
asbrsummary (Optional) Display summary AS boundary router LSA entries.
external (Optional) Display external LSAs.

908
instance instance-name (Optional) Display all OSPF database information under the named
routing instance.
link-local (Optional) Display information about link-local LSAs.
lsa-id lsa-id (Optional) Display the LSA with the specified LSA identifier.
netsummary (Optional) Display summary network LSAs.
network (Optional) Display information about network LSAs.
nssa (Optional) Display information about not-so-stubby area (NSSA) LSAs.
opaque-area (Optional) Display opaque area-scope LSAs.
router (Optional) Display information about router LSAs.
view
Output Fields
Table 12 on page 908 describes the output fields for the show ospf database command. Output fields
are listed in the approximate order in which they appear.
Table 12: show ospf database Output Fields
area Area number. Area 0.0.0.0 is the backbone area. All levels
Type Type of link advertisement: ASBRSum, Extern, Network, NSSA, All levels
OpaqArea, Router, or Summary.
909
Table 12: show ospf database Output Fields (Continued)
ID LSA identifier included in the advertisement. An asterisk All levels

preceding the identifier marks database entries that originated
from the local routing device.
Adv Rtr Address of the routing device that sent the advertisement. All levels
Seq Link sequence number of the advertisement. All levels
Age Time elapsed since the LSA was originated, in seconds. All levels
Opt Optional OSPF capabilities associated with the LSA. All levels
Cksum Checksum value of the LSA. All levels
Len Length of the advertisement, in bytes. All levels

910
Router Router link-state advertisement information: detail extensive
• bits—Flags describing the routing device that generated the

LSP.
• link count—Number of links in the advertisement.
• id—ID of a routing device or subnet on the link.
• data—For stub networks, the subnet mask. Otherwise, the IP

address of the routing device that generated the LSP.
• type—Type of link. It can be PointToPoint, Transit, Stub, or

Virtual.
• TOS count—Number of type-of-service (ToS) entries in the

advertisement.
• TOS 0 metric—Metric for ToS 0.
• TOS—Type-of-service (ToS) value.
• metric—Metric for the ToS.
Network Network link-state advertisement information: detail extensive
• mask—Network mask.
• attached router—ID of the attached neighbor.
Summary Summary link-state advertisement information: detail extensive
• mask—Network mask.
• TOS—Type-of-service (ToS) value.
• metric—Metric for the ToS.
Gen timer How long until the LSA is regenerated. extensive

911
Aging timer How long until the LSA expires. extensive
Installed hh:mm:ss How long ago the route was installed. extensive
ago
expires in hh:mm:ss How long until the route expires. extensive
sent hh:mm:ss ago How long ago the LSA was sent. extensive
Last changed How long ago the route was changed. extensive
hh:mm:ss ago
Change count Number of times the route has changed. extensive
Ours Indicates that this is a local advertisement. extensive
Router LSAs Number of router link-state advertisements in the link-state summary

database.
Network LSAs Number of network link-state advertisements in the link-state summary

database.
Summary LSAs Number of summary link-state advertisements in the link-state summary

database.
NSSA LSAs Number of not-so-stubby area link-state advertisements in the summary

link-state database.
912
Sample Output
show ospf database
user@host> show ospf database

OSPF link state database, Area 0.0.0.1
Router 10.255.70.103 10.255.70.103 0x80000002 215 0x20 0x4112 48
Router *10.255.71.242 10.255.71.242 0x80000002 214 0x20 0x11b1 48
Summary *23.1.1.0 10.255.71.242 0x80000002 172 0x20 0x6d72 28
Summary *24.1.1.0 10.255.71.242 0x80000002 177 0x20 0x607e 28
NSSA *33.1.1.1 10.255.71.242 0x80000002 217 0x28 0x73bd 36

Router 10.255.71.52 10.255.71.52 0x80000004 174 0x20 0xd021 36
Router *10.255.71.242 10.255.71.242 0x80000003 173 0x20 0xe191 36
Network *23.1.1.1 10.255.71.242 0x80000002 173 0x20 0x9c76 32
Summary *12.1.1.0 10.255.71.242 0x80000001 217 0x20 0xfeec 28
Summary *24.1.1.0 10.255.71.242 0x80000002 177 0x20 0x607e 28
NSSA *33.1.1.1 10.255.71.242 0x80000001 222 0x28 0xe047 36

Router 10.255.71.238 10.255.71.238 0x80000003 179 0x20 0x3942 36
Router *10.255.71.242 10.255.71.242 0x80000003 177 0x20 0xf37d 36
Network *24.1.1.1 10.255.71.242 0x80000002 177 0x20 0xc591 32
Summary *12.1.1.0 10.255.71.242 0x80000001 217 0x20 0xfeec 28
Summary *23.1.1.0 10.255.71.242 0x80000002 172 0x20 0x6d72 28
NSSA *33.1.1.1 10.255.71.242 0x80000001 222 0x28 0xeb3b 36
show ospf database
The output for show ospf databse nssa with nssa-only configuration statement enabled at [edit policy-
options policy-statement policy-name term term name then external], which clears P-bit on type 7 LSA.
user@host> show ospf database

Router 10.255.70.103 10.255.70.103 0x80000002 215 0x20 0x4112 48
913
Router *10.255.71.242 10.255.71.242 0x80000002 214 0x20 0x11b1 48

Summary *23.1.1.0 10.255.71.242 0x80000002 172 0x20 0x6d72 28
Summary *24.1.1.0 10.255.71.242 0x80000002 177 0x20 0x607e 28
NSSA *33.1.1.1 10.255.71.242 0x80000002 217 0x20 0x73bd 36

Router 10.255.71.52 10.255.71.52 0x80000004 174 0x20 0xd021 36
Router *10.255.71.242 10.255.71.242 0x80000003 173 0x20 0xe191 36
Network *23.1.1.1 10.255.71.242 0x80000002 173 0x20 0x9c76 32
Summary *12.1.1.0 10.255.71.242 0x80000001 217 0x20 0xfeec 28
Summary *24.1.1.0 10.255.71.242 0x80000002 177 0x20 0x607e 28
NSSA *33.1.1.1 10.255.71.242 0x80000001 222 0x28 0xe047 36

Router 10.255.71.238 10.255.71.238 0x80000003 179 0x20 0x3942 36
Router *10.255.71.242 10.255.71.242 0x80000003 177 0x20 0xf37d 36
Network *24.1.1.1 10.255.71.242 0x80000002 177 0x20 0xc591 32
Summary *12.1.1.0 10.255.71.242 0x80000001 217 0x20 0xfeec 28
Summary *23.1.1.0 10.255.71.242 0x80000002 172 0x20 0x6d72 28
NSSA *33.1.1.1 10.255.71.242 0x80000001 222 0x20 0xeb3b 36
show ospf database brief
The output for the show ospf database brief command is identical to that for the show ospf database
command. For sample output, see "show ospf database" on page 912.
show ospf database detail
user@host> show ospf database detail

Router 10.255.70.103 10.255.70.103 0x80000002 261 0x20 0x4112 48
bits 0x0, link count 2
id 10.255.71.242, data 12.1.1.1, Type PointToPoint (1)
TOS count 0, TOS 0 metric 1
id 12.1.1.0, data 255.255.255.0, Type Stub (3)
Router *10.255.71.242 10.255.71.242 0x80000002 260 0x20 0x11b1 48
914
id 10.255.70.103, data 12.1.1.2, Type PointToPoint (1)

id 12.1.1.0, data 255.255.255.0, Type Stub (3)
Summary *23.1.1.0 10.255.71.242 0x80000002 218 0x20 0x6d72 28
mask 255.255.255.0
TOS 0x0, metric 1
Summary *24.1.1.0 10.255.71.242 0x80000002 223 0x20 0x607e 28
mask 255.255.255.0
TOS 0x0, metric 1
NSSA *33.1.1.1 10.255.71.242 0x80000002 263 0x28 0x73bd 36
mask 255.255.255.255
Type 2, TOS 0x0, metric 0, fwd addr 12.1.1.2, tag 0.0.0.0

Router 10.255.71.52 10.255.71.52 0x80000004 220 0x20 0xd021 36
id 23.1.1.1, data 23.1.1.2, Type Transit (2)
Router *10.255.71.242 10.255.71.242 0x80000003 219 0x20 0xe191 36
Network *23.1.1.1 10.255.71.242 0x80000002 219 0x20 0x9c76 32
mask 255.255.255.0
attached router 10.255.71.242
Summary *12.1.1.0 10.255.71.242 0x80000001 263 0x20 0xfeec 28
mask 255.255.255.0
TOS 0x0, metric 1
Summary *24.1.1.0 10.255.71.242 0x80000002 223 0x20 0x607e 28
mask 255.255.255.0
TOS 0x0, metric 1
NSSA *33.1.1.1 10.255.71.242 0x80000001 268 0x28 0xe047 36
mask 255.255.255.255

Router 10.255.71.238 10.255.71.238 0x80000003 225 0x20 0x3942 36
915

Router *10.255.71.242 10.255.71.242 0x80000003 223 0x20 0xf37d 36
Network *24.1.1.1 10.255.71.242 0x80000002 223 0x20 0xc591 32
mask 255.255.255.0
Summary *12.1.1.0 10.255.71.242 0x80000001 263 0x20 0xfeec 28
mask 255.255.255.0
TOS 0x0, metric 1
Summary *23.1.1.0 10.255.71.242 0x80000002 218 0x20 0x6d72 28
mask 255.255.255.0
TOS 0x0, metric 1
NSSA *33.1.1.1 10.255.71.242 0x80000001 268 0x28 0xeb3b 36
mask 255.255.255.255
show ospf database summary
user@host> show ospf database summary

Area 0.0.0.1:
2 Router LSAs
2 Summary LSAs
1 NSSA LSAs
Area 0.0.0.2:
2 Router LSAs
1 Network LSAs
2 Summary LSAs
1 NSSA LSAs
Area 0.0.0.3:
2 Router LSAs
1 Network LSAs
2 Summary LSAs
1 NSSA LSAs
Externals:
Interface fe-2/2/1.0:
Interface ge-0/3/2.0:
916
Interface so-0/1/2.0:
Release Information
advertising-router self (address | self) option introduced in Junos OS Release 9.5.
advertising-router self (address | self) option introduced in Junos OS Release 9.5 for EX Series switches.
show ospf3 database
IN THIS SECTION
Syntax | 917
Description | 918
Options | 918
Output Fields | 919
Sample Output | 928

917
Syntax
show ospf3 database

<area area-id>
<external>
<inter-area-prefix>
<inter-area-router>
<intra-area-prefix>
<link>
<link-local>
<lsa-id lsa-id>
<network>
<nssa>
<router>
show ospf3 database

<area area-id>
<external>
<inter-area-prefix>
<inter-area-router>
<intra-area-prefix>
<link>
<link-local>
<lsa-id lsa-id>
<network>
<nssa>
<router>
918
Description
Display the entries in the OSPF version 3 (OSPFv3) link-state database, which contains data about link-
state advertisement (LSA) packets.
Options
none Display standard information about all entries in the OSPFv3 link-state
database.

summary
advertising-router (address | (Optional) Display the LSAs advertised either by a particular routing
self) device or by this routing device.
area area-id (Optional) Display the LSAs in a particular area.
external (Optional) Display external LSAs.
instance instance-name (Optional) Display all OSPF database information under the named
routing instance.
inter-area-prefix (Optional) Display information about interarea-prefix LSAs.
inter-area-router (Optional) Display information about interarea-router LSAs.
intra-area-prefix (Optional) Display information about intra-area-prefix LSAs.
link (Optional) Display information about link LSAs.
link-local (Optional) Display information about link-local LSAs.
lsa-id lsa-id (Optional) Display the LSA with the specified LSA identifier.
network (Optional) Display information about network LSAs.
nssa (Optional) Display information about not-so-stubby area (NSSA) LSAs.

919
realm (ipv4-multicast | ipv4- (Optional) Display information about the specified OSPFv3 realm, or
unicast | ipv6-multicast) address family. Use the realm option to specify an address family other
than IPv6 unicast, which is the default.
router (Optional) Display information about router LSAs.
view
Output Fields
Table 13 on page 919 lists the output fields for the show ospf3 database command. Output fields are
Table 13: show ospf3 database Output Fields
OSPF link state Entries in the link-state database for this area. brief detail
database, area area- extensive
number
OSPF AS SCOPE link Entries in the AS scope link-state database. brief detail
state database extensive
OSPF Link-Local link Entries in the link-local link-state database for this interface. brief detail
state database, extensive
interface interface-
name
area Area number. Area 0.0.0.0 is the backbone area. All levels
920
Table 13: show ospf3 database Output Fields (Continued)
Type Type of link advertisement: Extern, InterArPfx, InterArRtr, brief detail

IntraArPrx , Link, Network, NSSA, or Router. extensive
ID Link identifier included in the advertisement. An asterisk (*) brief detail

preceding the identifier marks database entries that originated extensive
from the local routing device.
Adv Rtr Address of the routing device that sent the advertisement. brief detail
extensive
Seq Link sequence number of the advertisement. brief detail

extensive
Age Time elapsed since the LSA was originated, in seconds. brief detail
extensive
Cksum Checksum value of the LSA. brief detail

extensive
Len Length of the advertisement, in bytes. brief detail

extensive
Router (Router Link-State Advertisements)
bits Flags describing the routing device that generated the LSP. detail extensive
Options Option bits carried in the router LSA. detail extensive
For Each Router Link

921
Type Type of interface. The value of all other output fields describing detail extensive
a routing device interface depends on the interface’s type:
• PointToPoint (1)—Point-to-point connection to another

routing device.
• Transit (2)—Connection to a transit network.
• Virtual (4)—Virtual link.
Loc-if-id Local interface ID assigned to the interface that uniquely detail extensive
identifies the interface with the routing device.
Nbr-if-id Interface ID of the neighbor's interface for this routing device detail extensive
link.
Nbr-rtr-id Router ID of the neighbor routing device (for type 2 interfaces, detail extensive
the attached link’s designated router).
Metric Cost of the router link. detail extensive
Gen timer How long until the LSA is regenerated, in the format extensive
hours:minutes:seconds.
Aging timer How long until the LSA expires, in the format extensive
Installed nn:nn:nn ago How long ago the route was installed, in the format extensive
expires in nn:nn:nn How long until the route expires, in the format extensive
922
sent nn:nn:nn ago Time elapsed since the LSA was last transmitted or flooded to an extensive
adjacency or an interface, respectively, in the format
Network (Network Link-State Advertisements)
Options Option bits carried in the network LSA. detail extensive
Attached Router Router IDs of each of the routing devices attached to the link. detail extensive
Only routing devices that are fully adjacent to the designated
router are listed. The designated router includes itself in this list.
InterArPfx (Interarea-Prefix Link-State Advertisements)
Prefix IPv6 address prefix. detail extensive
Prefix-options Option bit associated with the prefix. detail extensive
Metric Cost of this route. Expressed in the same units as the interface detail extensive
costs in the router LSAs. When the interarea-prefix LSA is
describing a route to a range of addresses, the cost is set to the
maximum cost to any reachable component of the address
range.
923
InterArRtr (Interarea-Router Link-State Advertisements)
Dest-router-id Router ID of the routing device described by the LSA. detail extensive
options Optional capabilities supported by the routing device. detail extensive
Metric Cost of this route. Expressed in the same units as the interface detail extensive
costs in the router LSAs. When the interarea-prefix LSA is
describing a route to a range of addresses, the cost is set to the
maximum cost to any reachable component of the address
range.
Prefix IPv6 address prefix. extensive
Prefix-options Option bit associated with the prefix. extensive
Extern (External Link-State Advertisements)

924
Metric Cost of the route, which depends on the value of Type. detail extensive
Type n Type of external metric: Type 1 or Type 2. detail extensive
Link (Link-State Advertisements)
IPv6-Address IPv6 link-local address on the link for which this link LSA detail extensive
originated.
Options Option bits carried in the link LSA. detail extensive
priority Router priority of the interface attaching the originating routing detail extensive
device to the link.
925
Prefix-count Number of IPv6 address prefixes contained in the LSA. The rest detail extensive
of the link LSA contains a list of IPv6 prefixes to be associated
with the link.
IntraArPfx (Intra-Area-Prefix Link-State Advertisements)

926
Ref-lsa-type LSA type of the referenced LSA. detail extensive
• Router—Address prefixes are associated with a router LSA.
• Network—Address prefixes are associated with a network

LSA.
Ref-lsa-id Link-state ID of the referenced LSA. detail extensive
Ref-router-id Advertising router ID of the referenced LSA. detail extensive
Prefix-count Number of IPv6 address prefixes contained in the LSA. The rest detail extensive
of the link LSA contains a list of IPv6 prefixes to be associated
with the link.
Metric Cost of this prefix. Expressed in the same units as the interface detail extensive
costs in the router LSAs.
Installed hh:mm:ss How long ago the route was installed, in the format extensive
ago hours:minutes:seconds.
927
expires in hh:mm:ss How long until the route expires, in the format extensive
sent hh:mm:ss ago Time elapsed since the LSA was last transmitted or flooded to an extensive
n Router LSAs Number of router LSAs in the link-state database. summary
n Network LSAs Number of network LSAs in the link-state database. summary
n InterArPfx LSAs Number of interarea-prefix LSAs in the link-state database. summary
n InterArRtr LSAs Number of interarea-router LSAs in the link-state database. summary
n IntraArPfx LSAs Number of intra-area-prefix LSAs in the link-state database. summary
Externals Display of the external LSA database. summary
n Extern LSAs Number of external LSAs in the link-state database. summary
Interface interface- Name of the interface for which link-local LSA information is summary
name displayed.
n Link LSAs Number of link LSAs in the link-state database. summary

928
Sample Output
show ospf3 database brief
user@host> show ospf3 database brief

OSPF3 link state database, area 0.0.0.0
Router 0.0.0.1 10.255.4.85 0x80000003 885 0xa697 40
Router *0.0.0.1 10.255.4.93 0x80000002 953 0xc677 40
InterArPfx *0.0.0.2 10.255.4.93 0x80000001 910 0xb96f 44
InterArRtr *0.0.0.1 10.255.4.93 0x80000001 910 0xe159 32
IntraArPfx *0.0.0.1 10.255.4.93 0x80000002 432 0x788f 72
OSPF3 link state database, area 0.0.0.1

Router *0.0.0.1 10.255.4.93 0x80000003 916 0xea40 40
Router 0.0.0.1 10.255.4.97 0x80000006 851 0xc95b 40
Network 0.0.0.2 10.255.4.97 0x80000002 916 0x4598 32
InterArPfx *0.0.0.1 10.255.4.93 0x80000002 117 0xa980 44
InterArPfx *0.0.0.2 10.255.4.93 0x80000002 62 0xd47e 44
NSSA 0.0.0.1 10.255.4.97 0x80000002 362 0x45ee 44
IntraArPfx 0.0.0.1 10.255.4.97 0x80000006 851 0x2f77 52
OSPF3 AS SCOPE link state database

Extern 0.0.0.1 10.255.4.85 0x80000002 63 0x9b86 44
Extern *0.0.0.1 10.255.4.93 0x80000001 910 0x59c9 44
OSPF3 Link-Local link state database, interface ge-1/3/0.0

Link *0.0.0.2 10.255.4.93 0x80000003 916 0x4dab 64
show ospf3 database summary
user@host> show ospf3 database summary

Area 0.0.0.0:
2 Router LSAs
1 InterArPfx LSAs
1 InterArRtr LSAs
1 IntraArPfx LSAs
929
Area 0.0.0.1:
2 Router LSAs
1 Network LSAs
2 InterArPfx LSAs
1 NSSA LSAs
1 IntraArPfx LSAs
Externals:
2 Extern LSAs
Interface ge-1/3/0.0:
1 Link LSAs
Interface lo0.0:
1 Link LSAs
Release Information
advertising-router (address | self) option introduced in Junos Relase 9.5.
advertising-router (address | self) option introduced in Junos OS Release 9.5 for EX Series switches.
show (ospf | ospf3) interface
IN THIS SECTION
Syntax | 930

930
Description | 930
Options | 931
Output Fields | 931
Sample Output | 936
show ospf interface extensive (SRLG Protection Enabled) | 937
Syntax

<brief | detail | extensive>
<area area-id>
<interface-name>
<realm (ip4-multicast | ipv4-unicast | ipv6-multicast)>

<area area-id>
<interface-name>
Description
Display the status of OSPF interfaces.

931
Options
none Display standard information about the status of all OSPF interfaces for all
routing instances
brief | detail | extensive (Optional) Display the specified level of output.
area area-id (Optional) Display information about the interfaces that belong to the
specified area.
interface-name (Optional) Display information for the specified interface.
instance instance-name (Optional) Display all OSPF interfaces under the named routing instance.
realm (ipv4-multicast | (OSPFv3 only) (Optional) Display information about the interfaces for the
ipv4-unicast | ipv6- specified OSPFv3 realm, or address family. Use the realm option to specify
multicast)
an address family for OSPFv3 other than IPv6 unicast, which is the default.
view
Output Fields
Table 14 on page 931 lists the output fields for the show (ospf | ospf3) interface command. Output
Table 14: show (ospf | ospf3) interface Output Fields
Interface Name of the interface running OSPF version 2 or OSPF version All levels
3.
932
Table 14: show (ospf | ospf3) interface Output Fields (Continued)
State State of the interface: BDR, Down, DR, DRother, Loop, PtToPt, or All levels
Waiting.
Area Number of the area that the interface is in. All levels
DR ID Address of the area's designated router. All levels
BDR ID Backup designated router for a particular subnet. All levels
Nbrs Number of neighbors on this interface. All levels
Type Type of interface: LAN, NBMA, P2MP, P2P, or Virtual. detail extensive
Address IP address of the neighbor. detail extensive
Mask Netmask of the neighbor. detail extensive
Prefix-length (OSPFv3) IPv6 prefix length, in bits. detail extensive
OSPF3-Intf-Index (OSPFv3) OSPF version 3 interface index. detail extensive
MTU Interface maximum transmission unit (MTU). detail extensive
Cost Interface cost (metric). detail extensive
DR addr Address of the designated router. detail extensive
BDR addr Address of the backup designated router. detail extensive

933
Adj count Number of adjacent neighbors. detail extensive
Secondary Indicates that this interface is configured as a secondary detail extensive

interface for this area. This interface can belong to more than
one area, but can be designated as a primary interface for only
one area.
Flood Reduction Indicates that this interface is configured with flooding extensive
reduction. All self-originated LSAs from this interface are initially
sent with the DoNotAge bit set. As a result, LSAs are refreshed
only when a change occurs.
Priority Router priority used in designated router (DR) election on this detail extensive
interface.
Flood list List of link-state advertisements (LSAs) that might be about to extensive
flood this interface.
Ack list Acknowledgment list. List of pending acknowledgments on this extensive

interface.
Descriptor list List of packet descriptors. extensive
Hello Configured value for the hello timer. detail extensive
Dead Configured value for the dead timer. detail extensive

934
Auth type (OSPFv2) Authentication mechanism for sending and receiving detail extensive
OSPF protocol packets:
• MD5—The MD5 mechanism is configured in accordance with

RFC 2328.
• None—No authentication method is configured.
• Password—A simple password (RFC 2328) is configured.
Topology (Multiarea adjacency) Name of topology: default or name. detail extensive
LDP sync state (OSPFv2 and LDP synchronization) Current state of LDP extensive
synchronization: in sync, in holddown, and not supported.
reason (OSPFv2 and LDP synchronization) Reason for the current state extensive
of LDP synchronization. The LDP session might be up or down,
or adjacency might be up or down.
config holdtime (OSPFv2 and LDP synchronization) Configured value of the hold extensive
timer.
If the state is not synchronized, and the hold time is not infinity,
the remaining field displays the number of seconds that remain
until the configured hold timer expires.
IPSec SA name (OSPFv2) Name of the IPSec security association name. detail extensive
Active key ID (OSPFv2 and MD5) Number from 0 to 255 that uniquely detail extensive
identifies an MD5 key.
935
Start time (OSPFv2 and MD5) Time at which the routing device starts using detail extensive
an MD5 key to authenticate OSPF packets transmitted on the
interface on which this key is configured. To authenticate
received OSPF protocol packets, the key becomes effective
immediately after the configuration is committed. If the start
time option is not configured, the key is effective immediately
for send and receive and is displayed as Start time 1970 Jan 01
00:00:00 PST.
ReXmit Configured value for the Retransmit timer. detail extensive
Stub, Not Stub, or Stub Type of area. detail extensive

NSSA
Post convergence Post convergence protection can have the following types when extensive
Protection enabled
• Fate Sharing can have the following values
• Yes-You have configured fate-sharing protection.
• No-You have not configured fate-sharing protection.
• node protection can have the following values:
• Yes-You have configured node protection.
• No-You have not configured node protection.
• srlg protection can have the following values:
• Yes–You have configured Shared Risk Link Groutp (SRLG)

protection.
• No–You have not configured SRLG protection.
Node cost is the recalculated metric cost of the node.

936
Sample Output
show ospf interface brief
user@host> show ospf interface brief

Intf State Area DR ID BDR ID Nbrs
at-5/1/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-2/3/0.0 DR 0.0.0.0 192.168.4.16 192.168.4.15 1
lo0.0 DR 0.0.0.0 192.168.4.16 0.0.0.0 0
so-0/0/0.0 Down 0.0.0.0 0.0.0.0 0.0.0.0 0
so-6/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
so-6/0/2.0 Down 0.0.0.0 0.0.0.0 0.0.0.0 0
so-6/0/3.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
show ospf interface detail
user@host> show ospf interface detail

fe-0/0/1.0 BDR 0.0.0.0 192.168.37.12 10.255.245.215 1
Type LAN, address 192.168.37.11, Mask 255.255.255.248, MTU 4460, Cost 40
DR addr 192.168.37.12, BDR addr 192.168.37.11, Adj count 1, Priority 128
Hello 10, Dead 40, ReXmit 5, Not Stub
t1-0/2/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
Type P2P, Address 0.0.0.0, Mask 0.0.0.0, MTU 1500, Cost 2604
Adj count 0
Auth type: MD5, Active key ID 3, Start time 2002 Nov 19 10:00:00 PST
IPsec SA Name: sa
show ospf3 interface detail
user@host> show ospf3 interface so-0/0/3.0 detail

Interface State Area DR-ID BDR-ID Nbrs
so-0/0/3.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Address fe80::2a0:a5ff:fe28:1dfc, Prefix-length 64
OSPF3-Intf-index 1, Type P2P, MTU 4470, Cost 12, Adj-count 1
937
show ospf interface extensive (SRLG Protection Enabled)
command-name
user@host> show ospf interface extensive

ge-0/0/0.0 DR 0.0.0.0 10.205.172.20 10.205.171.195 1
Type: LAN, Address: 81.1.2.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1
DR addr: 81.1.2.1, BDR addr: 81.1.2.2, Priority: 128
Adj count: 1
Auth type: None
Protection type: Post Convergence
Post convergence protection: Enabled, Fate sharing: No, SRLG: Yes, Node cost:
65535
• Checking backup route in rib:
root@R0# run show route 6.6.6.6
6.6.6.6/32 *[OSPF/10] 00:08:52, metric 20

> to 41.41.41.2 via ge-0/0/1.0
> to 31.31.31.2 via ge-0/0/2.0, Push 800030

6.6.6.6/32 *[LDP/9] 00:07:33, metric 1

> to 41.41.41.2 via ge-0/0/1.0, Push 299808
[L-OSPF/10/5] 00:07:33, metric 20
> to 41.41.41.2 via ge-0/0/1.0, Push 800060
> to 31.31.31.2 via ge-0/0/2.0, Push 800030, Push 800060
command-name
user@host> show ospf interface extensive (Fate-Sharing Protection Enabled)

ge-0/0/0.0 DR 0.0.0.0 10.205.172.20 10.205.171.195 1
Type: LAN, Address: 81.1.2.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1
938
DR addr: 81.1.2.1, BDR addr: 81.1.2.2, Priority: 128

Adj count: 1
Auth type: None
Protection type: Post Convergence
Post convergence protection: Enabled, Fate sharing: Yes, SRLG: No, Node cost:
65535
• Checking backup route in rib:
root@R0# run show route 6.6.6.6
6.6.6.6/32 *[OSPF/10] 00:08:52, metric 20

> to 41.41.41.2 via ge-0/0/1.0
> to 31.31.31.2 via ge-0/0/2.0, Push 800030

6.6.6.6/32 *[LDP/9] 00:07:33, metric 1

> to 41.41.41.2 via ge-0/0/1.0, Push 299808
[L-OSPF/10/5] 00:07:33, metric 20
> to 41.41.41.2 via ge-0/0/1.0, Push 800060
> to 31.31.31.2 via ge-0/0/2.0, Push 800030, Push 800060
Release Information
area option introduced in Junos OS Release 9.2.
area option introduced in Junos OS Release 9.2 for EX Series switches.

939
show (ospf | ospf3) io-statistics
IN THIS SECTION
Syntax | 939
Description | 939
Options | 940
Output Fields | 940
Sample Output | 941
Syntax

Description
Display Open Shortest Path First (OSPF) input and output statistics.
940
Options
none Display OSPF input and output statistics.
view
Output Fields
Table 15 on page 940 lists the output fields for the show ospf io-statistics command. Output fields are
Table 15: show (ospf | ospf3) io-statistics Output Fields
Packets read Number of OSPF packets read since the last time the routing protocol
was started.
average per run Total number of packets divided by the total number of times the
OSPF read operation is scheduled to run.
max run Maximum number of packets for a given run among all scheduled runs.
Receive errors Number of faulty packets received with errors.

941
Sample Output
show ospf io-statistics
user@host> show ospf io-statistics
Packets read: 7361, average per run: 1.00, max run: 1

Receive errors:
None
Release Information
show (ospf | ospf3) log
IN THIS SECTION
Syntax | 942
Description | 942
Options | 942
Output Fields | 943
Sample Output | 943

942
Syntax
show (ospf | osfp3) log

show (ospf | osfp3) log

Description
Display the entries in the Open Shortest Path First (OSPF) log of SPF calculations.
Options
none Display entries in the OSPF log of SPF calculations for all routing
instances.
instance instance-name (Optional) Display entries for the specified routing instance.
topology topology-name (Optional) (OSPFv2 only) Display entries for the specified topology.
realm (ipv4-multicast | ipv4- (OSPFv3 only) (Optional) Display entries for the specified OSPFv3
unicast | ipv6-multicast) realm, or address family. Use the realm option to specify an address
family for OSPFv3 other than IPv6 unicast, which is the default.
943
view
Output Fields
Table 16 on page 943 lists the output fields for the show (ospf | ospf3) log command. Output fields are
Table 16: show (ospf | ospf3) log Output Fields
When Time, in weeks (w) and days (d), since the SPF calculation was made.
Type Type of calculation: Cleanup, External, Interarea, NSSA, Redist, SPF,

Stub, Total, or Virtuallink.
Elapsed Amount of time, in seconds, that elapsed during the operation, or the
time required to complete the SPF calculation. The start time is the
time displayed in the When field.
Sample Output
show ospf log
user@host> show ospf log

When Type Elapsed
1w4d 17:25:58 Stub 0.000017

1w4d 17:25:58 SPF 0.000070
1w4d 17:25:58 Stub 0.000019
1w4d 17:25:58 Interarea 0.000054
1w4d 17:25:58 External 0.000005
944
1w4d 17:25:58 Cleanup 0.000203

1w4d 17:25:58 Total 0.000537
1w4d 17:24:48 SPF 0.000125
1w4d 17:24:48 Stub 0.000017
1w4d 17:24:48 SPF 0.000100
1w4d 17:24:48 Stub 0.000016
1w4d 17:24:48 Interarea 0.000056
1w4d 17:24:48 External 0.000005
1w4d 17:24:48 Cleanup 0.000238
1w4d 17:24:48 Total 0.000600
...
show ospf log topology voice
user@host> show ospf log topology voice

Topology voice SPF log:
Last instance of each event type

When Type Elapsed
00:06:11 SPF 0.000116
00:06:11 Stub 0.000114
00:06:11 Interarea 0.000126
00:06:11 External 0.000067
00:06:11 NSSA 0.000037
00:06:11 Cleanup 0.000186
Maximum length of each event type

When Type Elapsed
00:13:43 SPF 0.000140
00:13:33 Stub 0.000116
00:13:43 Interarea 0.000128
00:13:33 External 0.000075
00:13:38 NSSA 0.000039
00:13:53 Cleanup 0.000657
Last 100 events

When Type Elapsed
00:13:53 SPF 0.000090

00:13:53 Stub 0.000041
00:13:53 Interarea 0.000123
945
00:13:53 External 0.000040

00:13:53 NSSA 0.000038
00:13:53 Cleanup 0.000657
00:13:53 Total 0.001252
.
.
00:06:11 SPF 0.000116
00:06:11 Stub 0.000114
00:06:11 Interarea 0.000126
00:06:11 External 0.000067
00:06:11 NSSA 0.000037
00:06:11 Cleanup 0.000186
00:06:11 Total 0.000818
Release Information
topology option introduced in Junos OS Release 9.0.
topology option introduced in Junos OS Release 9.0 for EX Series switches.
IN THIS SECTION
Syntax | 946
Description | 946
Options | 947
Output Fields | 947

946
Sample Output | 952
Syntax

<area area-id>
<instance (all | instance-name)>
<neighbor>

<area area-id>
<instance (all | instance-name)>
<neighbor>
Description
Display information about OSPF neighbors.
CPU utilization might increase while the device learns its OSPF neighbors. We recommend that you use
the show (ospf | ospf3) neighbor command after the device learns and establishes OSPF neighbor
adjacencies. Depending on the size of your network, this might take several minutes. If you receive a
“timeout communicating with routing daemon” error when using the show (ospf | ospf3) neighbor
947
command, wait several minutes before attempting to use the command again. This is not a critical
system error, but you might experience a delay in using the CLI.
Options
none Display standard information about all OSPF neighbors for all routing
instances.
area area-id (Optional) Display information about the OSPF neighbors for the specified
area.
instance (all | instance- (Optional) Display all OSPF interfaces for all routing instances or under the
name) named routing instance.
interface interface-name (Optional) Display information about OSPF neighbors for the specified
logical interface.
neighbor (Optional) Display information about the specified OSPF neighbor.
realm (ipv4-multicast | (OSPFv3 only) (Optional) Display information about the OSPF neighbors for
ipv4-unicast | ipv6- the specified OSPFv3 realm, or address family. Use the realm option to
multicast)
specify an address family for OSPFv3 other than IPv6 unicast, which is the
default.
view
Output Fields
Table 17 on page 948 lists the output fields for the show (ospf | ospf3) neighbor command. Output
948
Table 17: show (ospf | ospf3) neighbor Output Fields
Address Address of the neighbor. All levels
Interface Interface through which the neighbor is reachable. All levels

949
Table 17: show (ospf | ospf3) neighbor Output Fields (Continued)
State State of the neighbor: All levels
• Attempt—Valid only for neighbors attached to nonbroadcast

networks. It indicates that no recent information has been
received from the neighbor, but that a more concerted effort
must be made to contact the neighbor.
• Down—Initial state of a neighbor conversation. It indicates

that no recent information has been received from the
neighbor. Hello packets might continue to be sent to
neighbors in the Down state, although at a reduced
frequency.
• Exchange—Routing device is describing its entire link-state

database by sending database description packets to the
neighbor. Each packet has a sequence number and is
explicitly acknowledged.
• ExStart—First step in creating an adjacency between the two

neighboring routing devices. The goal of this step is to
determine which routing device is the primary, and to
determine the initial sequence number.
• Full—Neighboring routing devices are fully adjacent. These

adjacencies appear in router link and network link
advertisements.
• Init—A hello packet has recently been sent by the neighbor.

However, bidirectional communication has not yet been
established with the neighbor. This state may occur, for
example, because the routing device itself did not appear in
the neighbor's hello packet.
• Loading—Link-state request packets are sent to the neighbor

to acquire more recent advertisements that have been
discovered (but not yet received) in the Exchange state.
950
• 2Way—Communication between the two routing devices is

bidirectional. This state has been ensured by the operation of
the Hello Protocol. This is the most advanced state short of
beginning adjacency establishment. The (backup) designated
router is selected from the set of neighbors in state 2Way or
greater.
ID Router ID of the neighbor. All levels
Pri Priority of the neighbor to become the designated router. All levels
Dead Number of seconds until the neighbor becomes unreachable. All levels
Link state Number of link-state acknowledgments received. extensive

acknowledgme
nt list
Link state Total number of link-state advertisements retransmitted. For detail extensive
retransmission extensive output only, the following information is also
list displayed:
• Type—Type of link advertisement: ASBR, Sum, Extern,

Network, NSSA, OpaqArea, Router, or Summary.
• LSA ID—LSA identifier included in the advertisement. An

asterisk preceding the identifier marks database entries that
originated from the local routing device.
• Adv rtr—Address of the routing device that sent the

advertisement.
• Seq—Link sequence number of the advertisement.

951
Neighbor- (OSPFv3 only) If the neighbor uses virtual links, the Neighbor- detail extensive
address address is the site-local, local, or global address. If the neighbor
uses a physical interface, the Neighbor-address is an IPv6 link-
local address.
area Area that the neighbor is in. detail extensive
OSPF3-Intf- (OSPFv3 only) Displays the OSPFv3 interface index. detail extensive
Index
opt Option bits received in the hello packets from the neighbor. detail extensive
DR or DR-ID Address of the designated router. detail extensive
BDR or BDR- Address of the backup designated router. detail extensive

ID
Up Length of time since the neighbor came up. detail extensive
adjacent Length of time since the adjacency with the neighbor was detail extensive
established.
SPRING Segment routing in networking adjacency labels. detail extensive

Adjacency
NOTE: Displayed only when segment routing is enabled
Labels
Label Segment routing label. detail extensive
Flags Segment routing flags. Flags VL indicate value and local. detail extensive
952
Sample Output
show ospf neighbor brief
user@host> show ospf neighbor brief

Address Intf State ID Pri Dead
192.168.254.225 fxp3.0 2Way 10.250.240.32 128 36
192.168.254.230 fxp3.0 Full 10.250.240.8 128 38
192.168.254.229 fxp3.0 Full 10.250.240.35 128 33
10.1.1.129 fxp2.0 Full 10.250.240.12 128 37
10.1.1.131 fxp2.0 Full 10.250.240.11 128 38
10.1.2.1 fxp1.0 Full 10.250.240.9 128 32
10.1.2.81 fxp0.0 Full 10.250.240.10 128 33
show ospf neighbor detail
user@host> show ospf neighbor detail

10.0.6.60 lt-1/2/0.12 Full 1.1.1.60 128 38
Area 0.0.0.0, opt 0x52, DR 0.0.0.0, BDR 0.0.0.0
Up 23:53:47, adjacent 23:53:34
Label Flags
299968 VL
10.0.10.70 lt-1/2/0.14 Full 1.1.1.70 128 37

Area 0.0.0.0, opt 0x52, DR 0.0.0.0, BDR 0.0.0.0
Up 23:53:47, adjacent 23:53:47
Label Flags
299952 VL
953
show ospf neighbor extensive
user@host> show ospf neighbor extensive

10.5.1.2 ge-1/2/0.1 Full 10.5.1.2 128 33
area 0.0.0.1, opt 0x42, DR 10.5.1.2, BDR 10.5.1.1
Up 06:09:42, adjacent 05:17:50
Link state retransmission list:
Type LSA ID Adv rtr Seq
Summary 10.8.56.0 172.25.27.82 0x8000004d
Router 10.5.1.94 10.5.1.94 0x8000005c
Network 10.5.24.2 10.5.1.94 0x80000036
Summary 10.8.57.0 172.25.27.82 0x80000024
Extern 1.10.90.0 10.8.1.2 0x80000041
Extern 1.4.109.0 10.6.1.2 0x80000041
Router 10.5.1.190 10.5.1.190 0x8000005f
Network 10.5.48.2 10.5.1.190 0x8000003d
Summary 10.8.58.0 172.25.27.82 0x8000004d
Extern 1.10.91.0 10.8.1.2 0x80000041
Extern 1.4.110.0 10.6.1.2 0x80000041
Router 10.5.1.18 10.5.1.18 0x8000005f
Network 10.5.5.2 10.5.1.18 0x80000033
Summary 10.8.59.0 172.25.27.82 0x8000003a
Summary 10.8.62.0 172.25.27.82 0x80000025
10.5.10.2 ge-1/2/0.10 ExStart 10.5.1.38 128 38

954
area 0.0.0.1, opt 0x42, DR 10.5.10.2, BDR 10.5.10.1

Up 06:09:42
master, seq 0xac1530f8, rexmit DBD in 2 sec
rexmit LSREQ in 0 sec
10.5.11.2 ge-1/2/0.11 Full 10.5.1.42 128 33
area 0.0.0.1, opt 0x42, DR 10.5.11.2, BDR 10.5.11.1
Up 06:09:42, adjacent 05:27:00
Link state retransmission list:
Type LSA ID Adv rtr Seq
Summary 10.8.58.0 172.25.27.82 0x8000004d
Extern 1.10.91.0 10.8.1.2 0x80000041
Extern 1.1.247.0 10.5.1.2 0x8000003f
Extern 1.4.110.0 10.6.1.2 0x80000041
Router 10.5.1.18 10.5.1.18 0x8000005f
Network 10.5.5.2 10.5.1.18 0x80000033
Summary 10.8.59.0 172.25.27.82 0x8000003a
Release Information
instance all option introduced in Junos OS Release 9.1.
instance all option introduced in Junos OS Release 9.1 for EX Series switches.
area, interface, and realm options introduced in Junos OS Release 9.2.
area and interface options introduced in Junos OS Release 9.2 for EX Series switches.

955
IN THIS SECTION
Syntax | 955
Description | 956
Options | 956
Output Fields | 956
Sample Output | 960
Syntax

<brief | extensive>

<brief | extensive>
956
Description
Display Open Shortest Path First (OSPF) overview information.
Options
none Display standard information about all OSPF neighbors for all routing
instances.
brief | extensive (Optional) Display the specified level of output.
instance instance-name (Optional) Display all OSPF interfaces under the named routing instance.
realm (ipv4-multicast | (Optional) (OSPFv3 only) Display information about the specified OSPFv3
ipv4-unicast | ipv6- realm, or address family. Use the realm option to specify an address family
multicast)
for OSPFv3 other than IPv6 unicast, which is the default.
view
Output Fields
Table 18 on page 957 lists the output fields for the show ospf overview command. Output fields are
957
Table 18: show ospf overview Output Fields
Field name Field Description Level of Output
Instance OSPF routing instance. All levels
Router ID Router ID of the routing device. All levels
Route table index Route table index. All levels
Configured overload Overload capability is enabled. If the overload timer is also All levels
configured, display the time that remains before it is set to
expire. This field is not displayed after the timer expires.
Topology Topology identifier. All levels
Prefix export count Number of prefixes exported into OSPF. All levels
Full SPF runs Number of complete Shortest Path First calculations. All levels
SPF delay Delay before performing consecutive Shortest Path First All levels
calculations.
SPF holddown Delay before performing additional Shortest Path First (SPF) All levels
calculations after the maximum number of consecutive SPF
calculations is reached.
SPF rapid runs Maximum number of Shortest Path First calculations that can be All levels
performed in succession before the hold-down timer begins.
LSA refresh time Refresh period for link-state advertisement (in minutes). All levels
SPRING Source protocol routing in networking: enable or disable. All levels

958
Table 18: show ospf overview Output Fields (Continued)
Node Segments Nodes of source protocol routing in networking:enable or All levels

disable.
Ipv4 Index Ipv4 Index. All levels
Index Range Ipv4 Index range. All levels
Node Segment Blocks Details about node segment blocks. All levels
Allocated
Database protection Current state of database protection. All levels

state
Warning threshold Threshold at which a warning message is logged (percentage of All levels
maximum LSA count).
Non self-generated Number of LSAs whose router ID is not equal to the local router All levels
LSAs ID: Current, Warning (threshold), and Allowed.
Ignore time How long the database has been in the ignore state. All levels
Reset time How long the database must stay out of the ignore or isolated All levels
state before it returns to normal operations.
Ignore count Number of times the database has been in the ignore state: All levels
Current and Allowed.
Restart Graceful restart capability: enabled or disabled. All levels
Restart duration Time period for complete reacquisition of OSPF neighbors. All levels
959
Table 18: show ospf overview Output Fields (Continued)
Restart grace period Time period for which the neighbors should consider the All levels
restarting routing device as part of the topology.
Graceful restart (OSPFv2) Standard graceful restart helper capability (based on All levels
helper mode RFC 3623): enabled or disabled.
Restart-signaling (OSPFv2) Restart signaling-based graceful restart helper All levels

helper mode capability (based on RFC 4811, RFC 4812, and RFC 4813):
enabled or disabled.
Helper mode (OSPFv3) Graceful restart helper capability: enabled or disabled. All levels
Trace options OSPF-specific trace options. extensive
Trace file Name of the file to receive the output of the tracing operation. extensive
Area Area number. Area 0.0.0.0 is the backbone area. All levels
Stub type Stub type of area: Normal Stub, Not Stub, or Not so Stubby Stub. All levels
Authentication Type Type of authentication: None, Password, or MD5. All levels
NOTE: The Authentication Type field refers to the

authentication configured at the [edit protocols ospf area area-
id] level. Any authentication configured for an interface in this
area will not affect the value of this field.
Area border routers Number of area border routers. All levels
Neighbors Number of autonomous system boundary routers. All levels

960
Sample Output
show ospf overview (without SRGB)
user@host> show ospf overview

Instance: master
Router ID: 10.255.245.6
Configured overload, expires in 118 seconds
SPRING: Enabled
Node Segments: Enabled
Ipv4 Index : 10, Index Range: 2048
Node Segment Blocks Allocated:
Start Index : 0, Size : 256, Label-Range: [ 802048, 802303 ]
Restart: Enabled
Restart duration: 20 sec
Restart grace period: 40 sec
Helper mode: enabled
Area: 0.0.0.0
Stub type: Not Stub
Authentication Type: None
Neighbors
Full SPF runs: 1
961
show ospf overview (with SRGB)

Instance: master
Router ID: 10.10.10.10
Traffic engineering
SPRING: Enabled
SRGB Config Range :
SRGB Start-Label : 1000, SRGB Index-Range : 2000
SRGB Block Allocation: Success
SRGB Start Index : 1000, SRGB Size : 2000, Label-Range: [ 1000, 2999 ]
Node Segments: Enabled
Ipv4 Index : 1000
Post Convergence Backup: Disabled
Area: 0.0.0.0
Stub type: Not Stub
Neighbors
Full SPF runs: 5
Backup SPF: Enabled, Remote Backup calculation enabled
show ospf overview (With Database Protection)

Instance: master
Router ID: 10.255.112.218
Traffic engineering
Restart: Enabled
Restart duration: 180 sec
Restart grace period: 210 sec
Graceful restart helper mode: Enabled
962
Restart-signaling helper mode: Enabled

Database protection state: Normal
Warning threshold: 70 percent
Non self-generated LSAs: Current 582, Warning 700, Allowed 1000
Ignore time: 30, Reset time: 60
Ignore count: Current 0, Allowed 1
Area: 0.0.0.0
Stub type: Not Stub
Neighbors
Full SPF runs: 70
show ospf3 overview (With Database Protection)
user@host> show ospf3 overview

Instance: master
Router ID: 10.255.112.128
Database protection state: Normal
Warning threshold: 80 percent
Non self-generated LSAs: Current 3, Warning 8, Allowed 10
Ignore time: 30, Reset time: 60
Ignore count: Current 0, Allowed 2
Area: 0.0.0.0
Stub type: Not Stub
Neighbors
Full SPF runs: 7
963
show ospf overview extensive
user@host> show ospf overview extensive

Instance: master
Router ID: 1.1.1.103
Full SPF runs: 13, SPF delay: 0.200000 sec
Restart: Disabled
Trace options: lsa
Trace file: /var/log/ospf size 131072 files 10
Area: 0.0.0.0
Stub type: Not Stub
Neighbors
Release Information
Database protection introduced in Junos 10.2.
IN THIS SECTION
Syntax | 964
Description | 965
Options | 965
964
Output Fields | 966
Sample Output | 969
Syntax

<abr | asbr | extern | inter | intra>
<destination>
<instance (default | ipv4-multicast | instance-name)>
<logical-system (default | ipv4-multicast | logical-system-name)>
<network>
<no-backup-coverage>
<router>
<transit>

<abr | asbr | extern | inter | intra>
<destination>
<instance instance-name
<network>
<no-backup-coverage>
<router>
<transit>
965
Description
Display the entries in the Open Shortest Path First (OSPF) routing table.
Options
none Display standard information about all entries in the OSPF routing table for
all routing instances and all topologies.
destination Display routes to the specified IP address (with optional destination prefix
length).
abr (Optional) Display routes to area border routers.
asbr (Optional) Display routes to autonomous system border routers.
extern (Optional) Display external routes.
inter (Optional) Display interarea routes.
intra (Optional) Display intra-area routes.
instance (default | ipv4- (Optional) Display entries for the default routing instance, the IPv4
multicast | instance-name) multicast routing instance, or for the specified routing instance.
logical-system (default | (Optional) Perform this operation on the default logical system, the IPv4
ipv4-multicast | logical- multicast logical system, or on a particular logical system.
system-name)
network (Optional) Display routes to networks.
no-backup-coverage (Optional) Display routes with no backup coverage.
realm (ipv4-multicast | (OSPFv3 only) (Optional) Display entries in the routing table for the
ipv4-unicast | ipv6- specified OSPFv3 realm, or address family. Use the realm option to specify
multicast)
an address family for OSPFv3 other than IPv6 unicast, which is the default.
router (Optional) Display routes to all routers.

966
topology (default | ipv4- (OSPFv2 only) (Optional) Display routes for the default OSPF topology,
multicast | topology- IPv4 multicast topology, or for a particular topology.
name)
transit (Optional) (OSPFv3 only) Display OSPFv3 routes to pseudonodes.
view
Output Fields
Table 19 on page 966 list the output fields for the show (ospf | ospf3) route command. Output fields
are listed in the approximate order in which they appear.
Table 19: show (ospf | ospf3) route Output Fields
Field Name Field Description Output Level
Topology Name of the topology. All levels
Prefix Destination of the route. All levels
Path type How the route was learned: All levels
• Inter—Interarea route
• Ext1—External type 1 route
• Ext2—External type 2 route
• Intra—Intra-area route
967
Table 19: show (ospf | ospf3) route Output Fields (Continued)
Route type The type of routing device from which the route was learned: All levels
• AS BR—Route to AS border router.
• Area BR—Route to area border router.
• Area/AS BR—Route to router that is both an Area BR and AS

BR.
• Network—Network router.
• Router—Route to a router that is neither an Area BR nor an

AS BR.
• Transit—(OSPFv3 only) Route to a pseudonode representing a

transit network, LAN, or nonbroadcast multiaccess (NBMA)
link.
• Discard—Route to a summary discard.
NH Type Next-hop type: LSP or IP. All levels
Metric Route's metric value. All levels
NH-interface (OSPFv3 only) Interface through which the route's next hop is All levels
reachable.
NH-addr (OSPFv3 only) IPv6 address of the next hop. All levels
NextHop Interface (OSPFv2 only) Interface through which the route's next hop is All levels
reachable.
Nexthop addr/label (OSPFv2 only) If the NH Type is IP, then it is the address of the All levels
next hop. If the NH Type is LSP, then it is the name of the label-
switched path.
968
Area Area ID of the route. detail
Origin Router from which the route was learned. detail
Type 7 Route was learned through a not-so-stubby area (NSSA) link- detail
state advertisement (LSA).
P-bit Route was learned through NSSA LSA and the propagate bit was detail
set.
Fwd NZ Forwarding address is nonzero. Fwd NZ is only displayed if the detail

route is learned through an NSSA LSA.
optional-capability Optional capabilities propagated in the router LSA. This field is in detail
the output for intra-area router routes only (when Route Type is
Area BR, AS BR, Area/AS BR, or Router), not for interarea router
routes or network routes. Three bits in this field are defined as
follows:
• 0x4 (V)—Routing device is at the end of a virtual active link.
• 0x2 (E)—Routing device is an autonomous system boundary

router.
• 0x1 (B)—Routing device is an area border router.
priority The priority assigned to the prefix: detail
• high
• medium
• low
NOTE: The priority field applies only to routes of type Network.

969
BGP-ORR Generation- Display the BGP-ORR generation identifier of the main OSPF extensive
ID route. This field is shown only for non-zero values.
Sample Output
show ospf route
user@host> show ospf route


1.1.1.60/32 Intra Network Spring 6 lt-1/2/0.14 10.0.10.70
Bkup SPRING lt-1/2/0.12 10.0.6.60
1.1.1.70/32 Intra Network IP 1 lt-1/2/0.14 10.0.10.70
Bkup LSP (null)
Bkup SPRING lt-1/2/0.12 10.0.6.60
1.1.1.80/32 Intra Network IP 6 lt-1/2/0.14 10.0.10.70
Bkup IP lt-1/2/0.12 10.0.6.60
802068 (S=0) Intra Network Mpls 0 lt-1/2/0.14 10.0.10.70

Bkup MPLS lt-1/2/0.12 10.0.6.60
Bkup MPLS lt-1/2/0.12 10.0.6.60
Bkup MPLS lt-1/2/0.12 10.0.6.60
Bkup MPLS lt-1/2/0.12 10.0.6.60
Bkup MPLS lt-1/2/0.12 10.0.6.60
Bkup MPLS lt-1/2/0.12 10.0.6.60
970
802118 Intra Network Mpls 0 lt-1/2/0.14 10.0.10.70

Bkup MPLS lt-1/2/0.12 10.0.6.60
show ospf route extensive
user@host> show ospf route extensive


area 0.0.0.0, origin 1.1.1.1, optional-capability 0x0
area 0.0.0.0, origin 1.1.1.1, priority medium
BGP-ORR generation-id: 1
show ospf3 route
user@host> show ospf3 route

NH-interface fe-0/0/2.0, NH-addr fe80::290:69ff:fe9b:e002
10.255.71.13;0.0.0.2
10.255.245.1 Intra Router IP 40 fxp1.1 192.168.36.17
area 0.0.0.0, origin 10.255.245.1 optional-capability 0x0,
10.255.245.3 Intra AS BR IP 1 fxp2.3 192.168.36.34
area 0.0.0.0, origin 10.255.245.3 optional-capability 0x0,
10.255.245.1/32 Intra Network IP 40 fxp1.1 192.168.36.17
area 0.0.0.0, origin 10.255.245.1, priority high
area 0.0.0.0, origin 10.255.245.2, priority medium
10.255.245.3/32 Intra Network IP 1 fxp2.3 192.168.36.34
area 0.0.0.0, origin 10245.3, priority low
Intra Transit IP 1
192::168:222:84/126 Intra Network IP 1
abcd::71:12/128 Intra Network IP 0
971
NH-interface lo0.0
abcd::71:13/128 Intra Network LSP 1
NH-interface fe-0/0/2.0, NH-addr lsp-cd
show ospf route topology voice
user@host show ospf route topology voice

Topology voice Route Table:
10.255.8.2 Intra Router IP 1 so-0/2/0.0
10.255.8.3 Intra Router IP 2 so-0/2/0.0
10.255.8.2/32 Intra Network IP 1 so-0/2/0.0
Release Information
topology option introduced in Junos OS Release 9.0.

972
show (ospf | ospf3) statistics
IN THIS SECTION
Syntax | 972
Description | 972
Options | 973
Output Fields | 973
Sample Output | 975
Syntax


Description
Display OSPF statistics.

973
Options
none Display OSPF statistics for all routing instances.
instance instance-name (Optional) Display all statistics for the specified routing instance.
realm (ipv4-multicast | (Optional) (OSPFv3 only) Display all statistics for the specified OSPFv3
ipv4-unicast | ipv6- realm, or address family. Use the realm option to specify an address family
multicast)
for OSPFv3 other than IPv6 unicast, which is the default.
view
Output Fields
Table 20 on page 973 lists the output fields for the show (ospf | ospf3) statistics command. Output
Table 20: show (ospf | ospf3) statistics Output Fields
Packet type Type of OSPF packet.
Total Sent/Total Received Total number of packets sent and received.
Last 5 seconds Sent/Last 5 Total number of packets sent and received in the last 5 seconds.
seconds Received
974
Table 20: show (ospf | ospf3) statistics Output Fields (Continued)
DBDs retransmitted Total number of database description packets retransmitted, and

number retransmitted in the last 5 seconds.
LSAs flooded Total number of link-state advertisements flooded, and number

flooded in the last 5 seconds.
LSAs flooded high-prio Total number of high priority link-state advertisements flooded, and
number flooded in the last 5 seconds.
A link-state advertisement is deemed a high priority if it has changed

since it was last sent.
LSAs retransmitted Total number of link-state advertisements retransmitted, and number

retransmitted in the last 5 seconds.
LSAs transmitted to nbr Total number of link-state advertisements transmitted to a neighbor,

and number transmitted in the last 5 seconds.
LSAs requested Total number of link-state advertisements requested by neighboring

devices, and number requested in the last 5 seconds.
LSAs acknowledged Total number of link-state advertisements acknowledged, and number

acknowledged in the last 5 seconds.
Flood queue depth Total number of entries in the extended queue.
Total rexmit entries Total number of retransmission entries waiting to be sent from the
OSPF routing instance.
db summaries Total number of database description summaries waiting to be sent

from the OSPF routing instance.
975
Table 20: show (ospf | ospf3) statistics Output Fields (Continued)
lsreq entries Total number of link-state request entries waiting to be sent from the
OSPF routing instance.
Receive errors Number and type of receive errors. Some sample receive errors
include:
• mtu mismatches
• no interface found
• no virtual link found
• nssa mismatches
• stub area mismatches
• subnet mismatches
If there are no receive errors, the output displays none.
Sample Output
show ospf statistics

Hello 31 14 2 2
DbD 9 10 0 0
LSReq 2 2 0 0
LSUpdate 8 16 0 0
LSAck 9 9 0 0

976


db summaries : 0
lsreq entries : 0
Receive errors:
862 no interface found
115923 no virtual link found
show ospf3 statistics
user@host> show ospf3 statistics

Hello 0 0 0 0
DbD 0 0 0 0
LSReq 0 0 0 0
LSUpdate 0 0 0 0
LSAck 0 0 0 0


db summaries : 0
lsreq entries : 0
Receive errors:
None
977
Release Information
show policy
IN THIS SECTION
Syntax | 977
Description | 978
Options | 978
Output Fields | 979
Sample Output | 979
Syntax
show policy
<policy-name>
<statistics >
978
show policy
<policy-name>
Description
Display information about configured routing policies.
Options
none List the names of all configured routing policies.
logical-system (Optional) Perform this operation on all logical systems or on a particular logical
(all | logical- system.
system-name)
policy-name (Optional) Show the contents of the specified policy.
statistics (Optional) Use in conjunction with the test policy command to show the length of
time (in microseconds) required to evaluate a given policy and the number of times it
has been executed. This information can be used, for example, to help structure a
policy so it is evaluated efficiently. Timers shown are per route; times are not
cumulative. Statistics are incremented even when the router is learning (and thus
evaluating) routes from peering routers.
view
979
Output Fields
Table 21 on page 979 lists the output fields for the show policy command. Output fields are listed in
the approximate order in which they appear.
Table 21: show policy Output Fields
policy-name Name of the policy listed.
term Name of the user-defined policy term. The term name unnamed is
used for policy elements that occur outside of user defined terms
from Match condition for the policy.
then Action for the policy.
Sample Output
show policy
user@host> show policy

Configured policies:
__vrf-export-red-internal__
__vrf-import-red-internal__
red-export
rf-test-policy
multicast-scoping
show policy policy-name
user@host> show policy vrf-import-red-internal

Policy vrf-import-red-internal:
980
from
203.0.113.0/28 accept
203.0.113.32/28 accept
then reject
show policy statistics policy-name
user@host> show policy statistics iBGP-v4-RR-Import

Policy iBGP-v4-RR-Import:
[1243328] Term Lab-Infra:
from [1243328 0] proto BGP
[28 0] route filter:
10.11.0.0/8 orlonger
10.13.0.0/8 orlonger
then [28 0] accept
[1243300] Term External:
from [1243300 1] proto BGP
[1243296 0] community Ext-Com1 [64496:1515 ]
[1243296 0] prefix-list-filter Customer-Routes
[1243296 0] aspath AS6221
[1243296 1] route filter:
172.16.49.0/12 orlonger
172.16.50.0/12 orlonger
172.16.51.0/12 orlonger
172.16.52.0/12 orlonger
172.16.56.0/12 orlonger
172.16.60.0/12 orlonger
then [1243296 2] community + Ext-Com2 [64496:2000 ] [1243296 0] accept
[4] Term Final:
then [4 0] reject
Release Information
statistics option introduced in Junos OS Release 16.1 for MX Series routers.

981
show policy damping

test policy
show route
IN THIS SECTION
Syntax | 981
Description | 982
Options | 982
Output Fields | 983
Sample Output | 990
Syntax
show route
<all>
<destination-prefix>
<private>
<te-ipv4-prefix-ip te-ipv4-prefix-ip>
<te-ipv4-prefix-node-ip te-ipv4-prefix-node-ip>
<te-ipv4-prefix-node-iso te-ipv4-prefix-node-iso>
<rib-sharding (main | rib-shard-name)>
982
show route
<all>
<destination-prefix>
<private>
Description
Display the active entries in the routing tables.
Options
none Display brief information about all active entries in the routing tables.
all (Optional) Display information about all routing tables, including private,
or internal, routing tables.
destination-prefix (Optional) Display active entries for the specified address or range of
addresses.
private (Optional) Display information only about all private, or internal, routing
tables.
programmed detail (Optional) Display API-programmed routes.
display-client-data (Optional) Display client id and cookie information for routes installed by
the routing protocol process client applications.
te-ipv4-prefix-ip te-ipv4- (Optional) Display IPv4 address of the traffic-engineering prefix, without
prefix-ip the mask length if present in the routing table.
983
te-ipv4-prefix-node-ip te- (Optional) Display all prefixes that have originated from the traffic-
ipv4-prefix-node-ip engineering node. You can filter IPv4 node addresses from the traffic-
engineered routes in the lsdist.0 table.
te-ipv4-prefix-node-iso te- (Optional) Display all prefixes that have originated from the traffic-
ipv4-prefix-node-iso engineering node. You can filter IPv4 routes with the specified ISO circuit
ID from the lsdist.0 table.
rib-sharding (main | rib- (Optional) Display the rib shard name.

shard-name)
view
Output Fields
Table 22 on page 983 describes the output fields for the show route command. Output fields are listed
in the approximate order in which they appear.
Table 22: show route Output Fields
routing-table- Name of the routing table (for example, inet.0).

name
number Number of destinations for which there are routes in the routing table.
destinations
984
Table 22: show route Output Fields (Continued)
number routes Number of routes in the routing table and total number of routes in the following
states:
• active (routes that are active).
• holddown (routes that are in the pending state before being declared inactive).
A holddown route was once the active route and is no longer the active route.
The route is in the holddown state because a protocol still has interest in the
route, meaning that the interest bit is set. A protocol might have its interest bit
set on the previously active route because the protocol is still advertising the
route. The route will be deleted after all protocols withdraw their advertisement
of the route and remove their interest bit. A persistent holddown state often
means that the interested protocol is not releasing its interest bit properly.
However, if you have configured advertisement of multiple routes (with the

add-path or advertise-inactive statement), the holddown bit is most likely set
because BGP is advertising the route as an active route. In this case, you can
ignore the holddown state because nothing is wrong.
If you have configured uRPF-loose mode, the holddown bit is most likely set
because Kernel Routing Table (KRT) is using inactive route to build valid
incoming interfaces. In this case, you can ignore the holddown state because
nothing is wrong.
• hidden (routes that are not used because of a routing policy).

985
destination-prefix Route destination (for example:10.0.0.1/24). Sometimes the route information is

presented in another format, such as:
• MPLS-label (for example, 80001).
• interface-name (for example, ge-1/0/2).
• neighbor-address:control-word-status:encapsulation type:vc-id:source (Layer 2

circuit only. For example, 10.1.1.195:NoCtrlWord:1:1:Local/96):
• neighbor-address—Address of the neighbor.
• control-word-status—Whether the use of the control word has been

negotiated for this virtual circuit: NoCtrlWord or CtrlWord.
• encapsulation type—Type of encapsulation, represented by a number: (1)

Frame Relay DLCI, (2) ATM AAL5 VCC transport, (3) ATM transparent cell
transport, (4) Ethernet, (5) VLAN Ethernet, (6) HDLC, (7) PPP, (8) ATM VCC
cell transport, (10) ATM VPC cell transport.
• vc-id—Virtual circuit identifier.
• source—Source of the advertisement: Local or Remote.
[ protocol, Protocol from which the route was learned and the preference value for the route.
preference ]
• +—A plus sign indicates the active route, which is the route installed from the
routing table into the forwarding table.
• - —A hyphen indicates the last active route.
• *—An asterisk indicates that the route is both the active and the last active
route. An asterisk before a to line indicates the best subpath to the route.
In every routing metric except for the BGP LocalPref attribute, a lesser value is
preferred. In order to use common comparison routines, Junos OS stores the 1's
complement of the LocalPref value in the Preference2 field. For example, if the
LocalPref value for Route 1 is 100, the Preference2 value is -101. If the LocalPref
value for Route 2 is 155, the Preference2 value is -156. Route 2 is preferred
because it has a higher LocalPref value and a lower Preference2 value.
986
weeks:days How long the route been known (for example, 2w4d 13:11:14, or 2 weeks, 4 days,
hours:minutes:sec 13 hours, 11 minutes, and 14 seconds).
onds
metric Cost value of the indicated route. For routes within an AS, the cost is determined
by the IGP and the individual protocol metrics. For external routes, destinations, or
routing domains, the cost is determined by a preference value.
localpref Local preference value included in the route.
from Interface from which the route was received.

987
AS path AS path through which the route was learned. The letters at the end of the AS path
indicate the path origin, providing an indication of the state of the route at the
point at which the AS path originated:
• I—IGP.
• E—EGP.
• ?—Incomplete; typically, the AS path was aggregated.
When AS path numbers are included in the route, the format is as follows:
• [ ]—Brackets enclose the local AS number associated with the AS path if more
than one AS number is configured on the routing device, or if AS path
prepending is configured.
• { }—Braces enclose AS sets, which are groups of AS numbers in which the order
does not matter. A set commonly results from route aggregation. The numbers
in each AS set are displayed in ascending order.
• ( )—Parentheses enclose a confederation.
• ( [ ] )—Parentheses and brackets enclose a confederation set.
NOTE: In Junos OS Release 10.3 and later, the AS path field displays an
unrecognized attribute and associated hexadecimal value if BGP receives attribute
128 (attribute set) and you have not configured an independent domain in any
routing instance.
encapsulated Extended next-hop encoding capability enabled for the specified BGP community
for routing IPv4 traffic over IPv6 tunnels. When BGP receives routes without the
tunnel community, IPv4-0ver IPv6 tunnels are not created and BGP routes are
resolved without encapsulation.
Route Labels Stack of labels carried in the BGP route update.

988
validation-state (BGP-learned routes) Validation status of the route:
• Invalid—Indicates that the prefix is found, but either the corresponding AS

received from the EBGP peer is not the AS that appears in the database, or the
prefix length in the BGP update message is longer than the maximum length
permitted in the database.
• Unknown—Indicates that the prefix is not among the prefixes or prefix ranges in
the database.
• Unverified—Indicates that the origin of the prefix is not verified against the
database. This is because the database got populated and the validation is not
called for in the BGP import policy, although origin validation is enabled, or the
origin validation is not enabled for the BGP peers.
• Valid—Indicates that the prefix and autonomous system pair are found in the
database.
to Next hop to the destination. An angle bracket (>) indicates that the route is the
selected route.
If the destination is Discard, traffic is dropped.

989
via Interface used to reach the next hop. If there is more than one interface available
to the next hop, the interface that is actually used is followed by the word
Selected. This field can also contain the following information:
• Weight—Value used to distinguish primary, secondary, and fast reroute backup

routes. Weight information is available when MPLS label-switched path (LSP)
link protection, node-link protection, or fast reroute is enabled, or when the
standby state is enabled for secondary paths. A lower weight value is preferred.
Among routes with the same weight value, load balancing is possible.
• Balance—Balance coefficient indicating how traffic of unequal cost is distributed

among next hops when a routing device is performing unequal-cost load
balancing. This information is available when you enable BGP multipath load
balancing.
• lsp-path-name—Name of the LSP used to reach the next hop.
• label-action—MPLS label and operation occurring at the next hop. The

operation can be pop (where a label is removed from the top of the stack), push
(where another label is added to the label stack), or swap (where a label is
replaced by another label). For VPNs, expect to see multiple push operations,
corresponding to the inner and outer labels required for VPN routes (in the case
of a direct PE-to-PE connection, the VPN route would have the inner label push
only).
Private unicast (Enhanced subscriber management for MX Series routers) Indicates that an access-
internal route is managed by enhanced subscriber management. By contrast,
access-internal routes not managed by enhanced subscriber management are
displayed with associated next-hop and media access control (MAC) address
information.
balance Distribution of the load based on the underlying operational interface bandwidth
for equal-cost multipaths (ECMP) across the nexthop gateways in percentages.
990
Sample Output
show route
user@host> show route

1:65500:1:10.0.0.20/240
*[MVPN/70] 19:53:41, metric2 1
Indirect
1:65500:1:10.0.0.40/240
*[BGP/170] 19:53:29, localpref 100, from 10.0.0.30
AS path: I
> to 10.0.24.4 via lt-0/3/0.24, label-switched-path toD
[BGP/170] 19:53:26, localpref 100, from 10.0.0.33
AS path: I
> to 10.0.24.4 via lt-0/3/0.24, label-switched-path toD
1:65500:1:10.0.0.60/240
*[BGP/170] 19:53:29, localpref 100, from 10.0.0.30
AS path: I
> to 10.0.28.8 via lt-0/3/0.28, label-switched-path toF
AS path: I
> to 10.0.28.8 via lt-0/3/0.28, label-switched-path toF
show route (VPN)
The following sample output shows a VPN route with composite next hops enabled. The first Push
operation corresponds to the outer label. The second Push operation corresponds to the inner label.
user@host> show route 192.0.2.0
13979:665001.inet.0: 871 destinations, 3556 routes (871 active, 0 holddown, 0

hidden)
192.0.2.0/24 [BGP/170] 00:28:32, localpref 100, from 10.9.9.160

AS path: 13980 ?, validation-state: unverified
> to 10.100.0.42 via ae2.0, Push 16, Push 300368(top)
991

AS path: 13980 ?, validation-state: unverified
#[Multipath/255] 00:28:28, metric2 102
to 10.100.0.42 via ae2.0, Push 16, Push 300368(top)
show route (with Destination Prefix)
user@host> show route 192.168.0.0/12

192.168.0.0/12 *[Static/5] 2w4d 12:54:27

> to 192.168.167.254 via fxp0.0
show route destination-prefix detail
user@host> show route 198.51.100.0 detail

198.51.100.0/24 (2 entries, 2 announced)
*BGP Preference: 170/-101
...
BGP-Static Preference: 4294967292
Next hop type: Discard
Address: 0x9041ae4
State: <NoReadvrt Int Ext AlwaysFlash>
Inactive reason: Route Preference
Local AS: 200
Age: 4d 1:40:40
Task: RT
Announcement bits (1): 2-BGP_RT_Background
AS path: 4 5 6 I
992
show route extensive
user@host> show route extensive

v1.mvpn.0: 5 destinations, 8 routes (5 active, 1 holddown, 0 hidden)
1:65500:1:10.0.0.40/240 (1 entry, 1 announced)
*BGP Preference: 170/-101
PMSI: Flags 0x0: Label[0:0:0]: PIM-SM: Sender 10.0.0.40 Group
203.0.113.1
Next hop type: Indirect
Address: 0x92455b8
Source: 10.0.0.30
Protocol next hop: 10.0.0.40
Indirect next hop: 2 no-forward
State: <Active Int Ext>
Local AS: 64510 Peer AS: 64511
Age: 3 Metric2: 1
Task: BGP_64510.10.0.0.30+179
Announcement bits (2): 0-PIM.v1 1-mvpn global task
AS path: I (Originator) Cluster list: 10.0.0.30
AS path: Originator ID: 10.0.0.40
Communities: target:64502:100 encapsulation:0L:14
Import Accepted
Localpref: 100
Router ID: 10.0.0.30
Primary Routing Table bgp.mvpn.0
Indirect next hops: 1
Protocol next hop: 10.0.0.40 Metric: 1
Indirect next hop: 2 no-forward
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.0.24.4 via lt-0/3/0.24 weight 0x1
10.0.0.40/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.0.24.4 via lt-0/3/0.24
993
show route programmed detail
user@host> show route programmed detail

100.75.1.0/27 (2 entries, 1 announced)
*Static Preference: 5/100
Address: 0xcc38a10
Session Id: 0x0
Next hop: via fti0.1001 weight 0x8001
Session Id: 0x0
State: <Active Int NSR-incapable Programmed>
Age: 37
Announcement bits (1): 0-KRT
AS path: I
Release Information
Option private introduced in Junos OS Release 9.5.
Option private introduced in Junos OS Release 9.5 for EX Series switches.
Option display-client-data introduced in Junos OS Release 16.2R1 on MX80, MX104, MX240, MX480,
MX960, MX2010, MX2020, vMX Series routers.
Options te-ipv4-prefix-ip, te-ipv4-prefix-node-ip, and te-ipv4-prefix-node-iso introduced in Junos OS

Release 17.2R1 on MX Series and PTX Series.
rib-sharding option introduced in cRPD Release 20.1R1.
Understanding IS-IS Configuration

Verifying and Managing Junos OS Enhanced Subscriber Management
994
show route instance
IN THIS SECTION
Syntax | 994
Description | 995
Options | 995
Output Fields | 995
Sample Output | 998
Syntax
show route instance

<brief | detail | summary>
<instance-name>
<operational>
show route instance

<brief | detail | summary>
<instance-name>
<operational>
995
Description
Display routing instance information.
Options
none (Same as brief) Display standard information about all routing instances.
brief | detail | (Optional) Display the specified level of output. If you do not specify a level of
summary output, the system defaults to brief. (These options are not available with the
operational keyword.)
instance-name (Optional) Display information for all routing instances whose name begins with
this string (for example, cust1, cust11, and cust111 are all displayed when you
run the show route instance cust1 command).
logical-system (all | (Optional) Perform this operation on all logical systems or on a particular logical
logical-system-name) system.
operational (Optional) Display operational routing instances.
view
Output Fields
Table 23 on page 996 lists the output fields for the show route instance command. Output fields are
996
Table 23: show route instance Output Fields
Instance or instance- Name of the routing instance. All levels

name
Operational Routing (operational keyword only) Names of all operational —

Instances routing instances.
Type Type of routing instance: forwarding, l2vpn, no- All levels

forwarding, vpls, virtual-router, or vrf.
State State of the routing instance: active or inactive. brief detail none
Interfaces Name of interfaces belonging to this routing instance. brief detail none
Restart State Status of graceful restart for this instance: Pending or detail
Complete.
Path selection timeout Maximum amount of time, in seconds, remaining until detail
graceful restart is declared complete. The default is 300.
Tables Tables (and number of routes) associated with this brief detail none
routing instance.
Route-distinguisher Unique route distinguisher associated with this routing detail

instance.
Vrf-import VPN routing and forwarding instance import policy detail

name.
Vrf-export VPN routing and forwarding instance export policy detail

name.
997
Table 23: show route instance Output Fields (Continued)
Vrf-import-target VPN routing and forwarding instance import target detail

community name.
Vrf-export-target VPN routing and forwarding instance export target detail

community name.
Vrf-edge-protection-id Context identifier configured for edge-protection. detail
Fast-reroute-priority Fast reroute priority setting for a VPLS routing instance: detail
high, medium, or low. The default is low.
Restart State Restart state: detail
• Pending:protocol-name—List of protocols that have

not yet completed graceful restart for this routing
table.
• Complete—All protocols have restarted for this

routing table.
Primary rib Primary table for this routing instance. brief none
summary
Active/holddown/ Number of active, hold-down, and hidden routes. All levels

hidden
998
Sample Output
show route instance
user@host> show route instance

Instance Type
Primary RIB Active/holddown/hidden
master forwarding
inet.0 16/0/1
iso.0 1/0/0
mpls.0 0/0/0
inet6.0 2/0/0
l2circuit.0 0/0/0
__juniper_private1__ forwarding
__juniper_private1__.inet.0 12/0/0
__juniper_private1__.inet6.0 1/0/0
show route instance detail (VPLS Routing Instance)
user@host> show route instance detail test-vpls

test-vpls:
Router ID: 0.0.0.0
Type: vpls State: Active
Interfaces:
lsi.1048833
lsi.1048832
fe-0/1/0.513
Route-distinguisher: 10.255.37.65:1
Vrf-import: [ __vrf-import-test-vpls-internal__ ]
Vrf-export: [ __vrf-export-test-vpls-internal__ ]
Vrf-import-target: [ target:300:1 ]
Vrf-export-target: [ target:300:1 ]
Vrf-edge-protection-id: 166.1.3.1 Fast-reroute-priority: high
Tables:
test-vpls.l2vpn.0 : 3 routes (3 active, 0 holddown, 0 hidden)
999
show route instance operational
user@host> show route instance operational

Operational Routing Instances:
master
default
show route instance summary
user@host> show route instance summary

Instance Type Primary rib Active/holddown/hidden
master forwarding
inet.0 15/0/1
iso.0 1/0/0
mpls.0 35/0/0
l3vpn.0 0/0/0
inet6.0 2/0/0
l2vpn.0 0/0/0
l2circuit.0 0/0/0
BGP-INET vrf
BGP-INET.inet.0 5/0/0
BGP-INET.iso.0 0/0/0
BGP-INET.inet6.0 0/0/0
BGP-L vrf
BGP-L.inet.0 5/0/0
BGP-L.iso.0 0/0/0
BGP-L.mpls.0 4/0/0
BGP-L.inet6.0 0/0/0
L2VPN l2vpn
L2VPN.inet.0 0/0/0
L2VPN.iso.0 0/0/0
L2VPN.inet6.0 0/0/0
L2VPN.l2vpn.0 2/0/0
LDP vrf
LDP.inet.0 4/0/0
LDP.iso.0 0/0/0
LDP.mpls.0 0/0/0
LDP.inet6.0 0/0/0
LDP.l2circuit.0 0/0/0
1000
OSPF vrf
OSPF.inet.0 7/0/0
OSPF.iso.0 0/0/0
OSPF.inet6.0 0/0/0
RIP vrf
RIP.inet.0 6/0/0
RIP.iso.0 0/0/0
RIP.inet6.0 0/0/0
STATIC vrf
STATIC.inet.0 4/0/0
STATIC.iso.0 0/0/0
STATIC.inet6.0 0/0/0
Release Information
Example: Transporting IPv6 Traffic Across IPv4 Using Filter-Based Tunneling

show route protocol
IN THIS SECTION
Syntax | 1001
Description | 1001
Options | 1001
Output Fields | 1003

1001
Sample Output | 1003
Syntax
show route protocol protocol

<brief | detail | extensive | terse>
show route protocol protocol

<brief | detail | extensive | terse>
Description
Display the route entries in the routing table that were learned from a particular protocol.
Options
brief | detail | (Optional) Display the specified level of output. If you do not specify a level of
extensive | terse output, the system defaults to brief.
logical-system (Optional) Perform this operation on all logical systems or on a particular logical
(all | logical- system.
system-name)
protocol Protocol from which the route was learned:
1002
• access—Access route for use by DHCP application
• access-internal—Access-internal route for use by DHCP application
• aggregate—Locally generated aggregate route
• arp—Route learned through the Address Resolution Protocol
• atmvpn—Asynchronous Transfer Mode virtual private network
• bgp—Border Gateway Protocol
• ccc—Circuit cross-connect
• direct—Directly connected route
• dvmrp—Distance Vector Multicast Routing Protocol
• esis—End System-to-Intermediate System
• flow—Locally defined flow-specification route
• frr—Precomputed protection route or backup route used when a link goes down
• isis—Intermediate System-to-Intermediate System
• ldp—Label Distribution Protocol
• l2circuit—Layer 2 circuit
• l2vpn—Layer 2 virtual private network
• local—Local address
• mpls—Multiprotocol Label Switching
• msdp—Multicast Source Discovery Protocol
• ospf—Open Shortest Path First versions 2 and 3
• ospf2—Open Shortest Path First versions 2 only
• ospf3—Open Shortest Path First version 3 only
• pim—Protocol Independent Multicast
• rip—Routing Information Protocol
• ripng—Routing Information Protocol next generation

1003
• rsvp—Resource Reservation Protocol
• rtarget—Local route target virtual private network
• static—Statically defined route
• tunnel—Dynamic tunnel
• vpn—Virtual private network
NOTE: EX Series switches run a subset of these protocols. See the switch CLI
for details.
view
Output Fields
For information about output fields, see the output field tables for the show route command, the show
route detail command, the show route extensive command, or the show route terse command.
Sample Output
show route protocol access
user@host> show route protocol access

13.160.0.3/32 *[Access/13] 00:00:09

> to 13.160.0.2 via fe-0/0/0.0
13.160.0.4/32 *[Access/13] 00:00:09
> to 13.160.0.2 via fe-0/0/0.0
1004
13.160.0.5/32 *[Access/13] 00:00:09

> to 13.160.0.2 via fe-0/0/0.0
show route protocol arp
user@host> show route protocol arp

cust1.inet.0: 1033 destinations, 2043 routes (1033 active, 0 holddown, 0 hidden)

20.20.1.3/32 [ARP/4294967293] 00:04:35, from 20.20.1.1

Unusable
20.20.1.4/32 [ARP/4294967293] 00:04:35, from 20.20.1.1
Unusable
20.20.1.5/32 [ARP/4294967293] 00:04:32, from 20.20.1.1
Unusable
20.20.1.6/32 [ARP/4294967293] 00:04:34, from 20.20.1.1
Unusable
20.20.1.7/32 [ARP/4294967293] 00:04:35, from 20.20.1.1
Unusable
20.20.1.8/32 [ARP/4294967293] 00:04:35, from 20.20.1.1
Unusable
20.20.1.9/32 [ARP/4294967293] 00:04:35, from 20.20.1.1
Unusable
20.20.1.10/32 [ARP/4294967293] 00:04:35, from 20.20.1.1
Unusable
20.20.1.11/32 [ARP/4294967293] 00:04:33, from 20.20.1.1
Unusable
20.20.1.12/32 [ARP/4294967293] 00:04:33, from 20.20.1.1
Unusable
20.20.1.13/32 [ARP/4294967293] 00:04:33, from 20.20.1.1
Unusable
...
1005
show route protocol bgp
user@host> show route protocol bgp 192.168.64.0/21

inet.0: 335832 destinations, 335833 routes (335383 active, 0 holddown, 450
hidden)
192.168.64.0/21 *[BGP/170] 6d 10:41:16, localpref 100, from 192.168.69.71

AS path: 10458 14203 2914 4788 4788 I
> to 192.168.167.254 via fxp0.0
show route protocol direct
user@host> show route protocol direct
inet.0: 335843 destinations, 335844 routes (335394 active, 0 holddown, 450

hidden)
172.16.8.0/24 *[Direct/0] 17w0d 10:31:49

> via fe-1/3/1.0
10.255.165.1/32 *[Direct/0] 25w4d 04:13:18
> via lo0.0
172.16.30.0/24 *[Direct/0] 17w0d 23:06:26
> via fe-1/3/2.0
192.168.164.0/22 *[Direct/0] 25w4d 04:13:20
> via fxp0.0

47.0005.80ff.f800.0000.0108.0001.0102.5516.5001/152
*[Direct/0] 25w4d 04:13:21
> via lo0.0

2001:db8::10:255:165:1/128
*[Direct/0] 25w4d 04:13:21
1006
> via lo0.0

fe80::2a0:a5ff:fe12:ad7/128
*[Direct/0] 25w4d 04:13:21
> via lo0.0
show route protocol frr
user@host> show route protocol frr

cust1.inet.0: 1033 destinations, 2043 routes (1033 active, 0 holddown, 0 hidden)

20.20.1.3/32 *[FRR/200] 00:05:38, from 20.20.1.1

> to 20.20.1.3 via ge-4/1/0.0
20.20.1.4/32 *[FRR/200] 00:05:38, from 20.20.1.1
> to 20.20.1.4 via ge-4/1/0.0
20.20.1.5/32 *[FRR/200] 00:05:35, from 20.20.1.1
> to 20.20.1.5 via ge-4/1/0.0
20.20.1.6/32 *[FRR/200] 00:05:37, from 20.20.1.1
> to 20.20.1.6 via ge-4/1/0.0
20.20.1.7/32 *[FRR/200] 00:05:38, from 20.20.1.1
> to 20.20.1.7 via ge-4/1/0.0
20.20.1.8/32 *[FRR/200] 00:05:38, from 20.20.1.1
> to 20.20.1.8 via ge-4/1/0.0
20.20.1.9/32 *[FRR/200] 00:05:38, from 20.20.1.1
> to 20.20.1.9 via ge-4/1/0.0
20.20.1.10/32 *[FRR/200] 00:05:38, from 20.20.1.1
...
1007
show route protocol ldp
user@host> show route protocol ldp


192.168.16.1/32 *[LDP/9] 1d 23:03:35, metric 1

> via t1-4/0/0.0, Push 100000
192.168.17.1/32 *[LDP/9] 1d 23:03:35, metric 1
> via t1-4/0/0.0
private1__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

100064 *[LDP/9] 1d 23:03:35, metric 1

> via t1-4/0/0.0, Pop
100064(S=0) *[LDP/9] 1d 23:03:35, metric 1
> via t1-4/0/0.0, Pop
100080 *[LDP/9] 1d 23:03:35, metric 1
> via t1-4/0/0.0, Swap 100000
show route protocol ospf (Layer 3 VPN)
user@host> show route protocol ospf

10.39.1.4/30 *[OSPF/10] 00:05:18, metric 4

> via t3-3/2/0.0
10.39.1.8/30 [OSPF/10] 00:05:18, metric 2
> via t3-3/2/0.0
10.255.14.171/32 *[OSPF/10] 00:05:18, metric 4
> via t3-3/2/0.0
10.255.14.179/32 *[OSPF/10] 00:05:18, metric 2
> via t3-3/2/0.0
172.16.233.5/32 *[OSPF/10] 20:25:55, metric 1
1008
VPN-AB.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

10.39.1.16/30 [OSPF/10] 00:05:43, metric 1

> via so-0/2/2.0
10.255.14.173/32 *[OSPF/10] 00:05:43, metric 1
> via so-0/2/2.0
172.16.233.5/32 *[OSPF/10] 20:26:20, metric 1
show route protocol rip
user@host> show route protocol rip

VPN-AB.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

10.255.14.177/32 *[RIP/100] 20:24:34, metric 2
> to 10.39.1.22 via t3-0/2/2.0
172.16.233.9/32 *[RIP/100] 00:03:59, metric 1
Release Information
ospf2 and ospf3 options introduced in Junos OS Release 9.2.
ospf2 and ospf3 options introduced in Junos OS Release 9.2 for EX Series switches.
flow option introduced in Junos OS Release 10.0.
flow option introduced in Junos OS Release 10.0 for EX Series switches.
show route
show route detail
1009
show route extensive

show route terse

Juniper OSPF

Uploaded by

Copyright:

Available Formats

Juniper OSPF

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Juniper OSPF

Uploaded by

Copyright:

Available Formats

Junos® OS

OSPF User Guide

Juniper Networks, Inc.

Junos® OS OSPF User Guide

YEAR 2000 NOTICE

END USER LICENSE AGREEMENT

OSPF Packets Overview | 7

Understanding OSPF External Metrics | 10

Supported OSPF and OSPFv3 Standards | 11

2 Understand OSPF Configurations

3 Configure OSPF Interfaces

About OSPF Interfaces | 17

Example: Configuring an Interface on a Broadcast or Point-to-Point Network | 19

Example: Configuring OSPF Demand Circuits | 23

Example: Configuring a Passive OSPF Interface | 27

Example: Configuring OSPFv2 Peer interfaces | 30

Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network | 33

Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint Network | 38

Understanding Multiple Address Families for OSPFv3 | 41

Example: Configuring Multiple Address Families for OSPFv3 | 42

4 Configure OSPF Areas

Understanding OSPF Areas | 50

OSPF Designated Router Overview | 53

Example: Configuring an OSPF Router Identifier | 54

Example: Controlling OSPF Designated Router Election | 57

Understanding OSPF Areas and Backbone Areas | 60

Example: Configuring a Single-Area OSPF Network | 62

Example: Configuring a Multiarea OSPF Network | 65

Understanding Multiarea Adjacency for OSPF | 71

Example: Configuring Multiarea Adjacency for OSPF | 71

Understanding Multiarea Adjacencies for OSPFv3 | 78

Example: Configuring a Multiarea Adjacency for OSPFv3 | 79

Example: Configuring OSPF Stub and Totally Stubby Areas | 90

Example: Configuring OSPF Not-So-Stubby Areas | 96

Understanding OSPFv3 Stub and Totally Stubby Areas | 104

Example: Configuring OSPFv3 Stub and Totally Stubby Areas | 104

Understanding OSPFv3 Not-So-Stubby Areas | 120

Example: Configuring OSPFv3 Not-So-Stubby Areas | 120

Understanding Not-So-Stubby Areas Filtering | 140

Example: Configuring OSPFv3 Not-So-Stubby Areas with Filtering | 140

Understanding OSPF Virtual Links for Noncontiguous Areas | 151

Example: Configuring OSPF Virtual Links to Connect Noncontiguous Areas | 152

Example: Configuring OSPFv3 Virtual Links | 159

5 Configure OSPF Route Control

Understanding OSPF Route Summarization | 195

Example: Limiting the Number of Prefixes Exported to OSPF | 205

Understanding OSPF Traffic Control | 208

Example: Controlling the Cost of Individual OSPF Network Segments | 210

Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth | 217

Example: Controlling OSPF Route Preferences | 220

Understanding OSPF Overload Function | 223

Example: Configuring OSPF to Make Routing Devices Appear Overloaded | 225

Understanding the SPF Algorithm Options for OSPF | 230

Example: Configuring SPF Algorithm Options for OSPF | 231

Configuring OSPF Refresh and Flooding Reduction in Stable Topologies | 235

Understanding Synchronization Between LDP and IGPs | 237

Example: Configuring Synchronization Between LDP and OSPF | 237

OSPFv2 Compatibility with RFC 1583 Overview | 242

Example: Disabling OSPFv2 Compatibility with RFC 1583 | 243

6 Configure OSPF Authentication