Ospf
Ospf
Published
2023-12-12
ii
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.
The information in this document is current as of the date on the title page.
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.
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 | xviii
1 OSPF Overview
Introduction to OSPF | 2
OSPF Overview | 2
Requirements | 19
Overview | 19
Configuration | 20
Verification | 23
Requirements | 24
Overview | 24
Configuration | 25
Verification | 27
Requirements | 28
Overview | 28
Configuration | 29
Verification | 30
iv
Requirements | 31
Overview | 32
Configuration | 32
Verification | 33
Requirements | 34
Overview | 35
Configuration | 36
Verification | 38
Requirements | 39
Overview | 39
Configuration | 40
Verification | 42
Requirements | 43
Overview | 44
Configuration | 45
Verification | 48
Requirements | 55
Overview | 56
Configuration | 56
Verification | 58
Requirements | 58
Overview | 58
Configuration | 59
Verification | 60
Requirements | 63
Overview | 63
Configuration | 64
Verification | 65
Requirements | 66
Overview | 67
Configuration | 68
Verification | 72
Requirements | 73
Overview | 73
Configuration | 75
Verification | 78
Requirements | 81
Overview | 81
Configuration | 82
Verification | 88
Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas | 90
Requirements | 92
Overview | 93
vi
Configuration | 94
Verification | 97
Requirements | 98
Overview | 98
Configuration | 100
Verification | 104
Requirements | 106
Overview | 107
Configuration | 108
Verification | 118
Requirements | 122
Overview | 122
Configuration | 124
Verification | 135
Requirements | 142
Overview | 142
Configuration | 143
Verification | 149
Requirements | 154
Overview | 154
Configuration | 155
Verification | 159
vii
Requirements | 160
Overview | 160
Configuration | 161
Verification | 175
Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements Sent into the
Backbone Area | 197
Requirements | 197
Overview | 198
Configuration | 200
Verification | 205
Requirements | 206
Overview | 207
Configuration | 207
Verification | 209
Requirements | 212
Overview | 213
Configuration | 214
Verification | 217
Requirements | 220
Overview | 221
Verification | 221
Requirements | 223
Overview | 224
viii
Verification | 225
Requirements | 228
Overview | 228
Configuration | 229
Verification | 230
Requirements | 233
Overview | 233
Configuration | 234
Verification | 236
Requirements | 239
Overview | 240
Configuration | 241
Verification | 244
Requirements | 245
Overview | 245
Configuration | 246
Verification | 247
Requirements | 256
Overview | 257
Configuration | 257
Verification | 259
Requirements | 260
Overview | 261
Configuration | 261
Verification | 263
Requirements | 264
Overview | 264
Configuration | 265
Verification | 268
Requirements | 271
Overview | 271
Configuration | 274
Verification | 278
Installing Routes from OSPF Routing Instances into the OSPF Routing Table Group | 283
Requirements | 284
Overview | 284
Configuration | 287
x
Verification | 293
Requirements | 297
Overview | 297
Configuration | 298
Verification | 304
Requirements | 309
Overview | 309
Configuration | 311
Verification | 313
Requirements | 325
Overview | 326
Configuration | 327
Verification | 331
Example: Configuring the Helper Capability Mode for OSPFv2 Graceful Restart | 332
xi
Requirements | 332
Overview | 333
Configuration | 333
Verification | 337
Example: Configuring the Helper Capability Mode for OSPFv3 Graceful Restart | 338
Requirements | 338
Overview | 338
Configuration | 339
Verification | 342
Example: Disabling Strict LSA Checking for OSPF Graceful Restart | 343
Requirements | 343
Overview | 344
Configuration | 344
Verification | 347
Requirements | 360
Overview | 360
Configuration | 361
Verification | 373
xii
Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network | 389
Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks | 391
Requirements | 391
Overview | 392
Configuration | 393
Verification | 403
Requirements | 415
Overview | 416
Configuration | 416
Verification | 422
Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface | 424
Requirements | 424
Overview | 424
Configuration | 424
Verification | 426
Requirements | 427
Overview | 428
Configuration | 428
Verification | 430
Requirements | 431
Overview | 432
Configuration | 434
xiii
Verification | 450
How to Configure Flexible Algorithms in OSPF for Segment Routing Traffic Engineering | 458
Overview | 469
Requirements | 470
Configuration | 471
Verification | 491
| 502
| 502
| 502
Overview | 517
Requirements | 517
Topology | 517
Configuration | 518
Verification | 537
Configuring Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 568
Example: Configuring Backup Selection Policy for the OSPF or OSPF3 Protocol | 570
Requirements | 570
Overview | 570
Configuration | 572
Verification | 597
Example: Injecting OSPF Routes into the BGP Routing Table | 604
Requirements | 604
Overview | 604
Configuration | 605
Verification | 608
Troubleshooting | 609
Requirements | 610
Overview | 610
Configuration | 611
Verification | 613
Requirements | 614
Overview | 614
Configuration | 615
Verification | 619
xv
Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through
OSPF | 620
Requirements | 621
Overview | 621
Configuration | 622
Verification | 626
Requirements | 627
Overview | 628
Configuration | 630
Verification | 639
Requirements | 640
Overview | 640
Configuration | 642
Verification | 651
Requirements | 653
Overview | 653
Configuration | 654
Verification | 662
Requirements | 670
Overview | 670
Configuration | 672
Verification | 679
Example: Configuring OSPF on Logical Systems Within the Same Router | 686
Requirements | 686
Overview | 686
Configuration | 688
Verification | 693
Evaluating the Solution to Check Whether the Network Problem Is Resolved | 707
Requirements | 729
xvii
Overview | 729
Configuration | 731
Verification | 736
Use this guide to configure, monitor, and troubleshoot the OSPF routing protocol on your Juniper
Network devices.
OSPF Overview
Introduction to OSPF | 2
2
Introduction to OSPF
IN THIS SECTION
OSPF Overview | 2
OSPF Overview
IN THIS SECTION
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 Firewalls, 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"
on page 245.
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
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.
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
5
(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 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.
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:
• Router and network link-state advertisements (LSAs) do not carry prefix information.
• Link-local
• Area
• AS
• Link-local addresses are used for all neighbor exchanges except virtual links.
SEE ALSO
IN THIS SECTION
Hello Packets | 8
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:
• 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.
• 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" on
page 34.)
Hello packets consist of the OSPF header plus the following fields:
• Hello interval—How often the router sends hello packets. All routers on a shared network must use
the same hello interval.
• 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.
• Neighbor—IP addresses of the routers from which valid hello packets have been received within the
time specified by the router dead interval.
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.
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 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:
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 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.
SEE ALSO
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.
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
Junos OS substantially supports the following RFCs and Internet drafts, which define standards for
OSPF and OSPF version 3 (OSPFv3).
Support is provided by the update-threshold configuration statement at the [edit protocols rsvp interface
interface-name ] hierarchy level.
• RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
• 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)
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 5340, OSPF for IPv6 (RFC 2740 is obsoleted by RFC 5340)
The following RFCs do not define standards, but provide information about OSPF and related
technologies. The IETF classifies them as “Informational.”
• RFC 5309, Point-to-Point Operation over LAN in Link State Routing Protocols
SEE ALSO
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:
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)
IN THIS SECTION
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 point-to-point interface provides a connection between a single source and a single destination
(there is only one OSPF adjacency).
• 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
IN THIS SECTION
Requirements | 19
Overview | 19
Configuration | 20
Verification | 23
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" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
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.
20
In Junos OS Release 9.3 and later, an OSPF point-to-point interface can be an Ethernet interface
without a subnet. If you configure an interface on a broadcast network, designated router and backup
designated router election is performed.
NOTE: Using both the interface name and the IP address of the same interface produces an
invalid configuration.
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
Procedure | 21
Results | 22
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
NOTE:
all protocols or services
Procedure
Step-by-Step Procedure
[edit]
user@host# set interfaces ge-0/2/0 unit 0 family inet address 10.0.0.1
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
5. Configure the security zone to allow the inbound OSPF traffic into the interfaces that are active For
more information about security zone, see No Link Title.
[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
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
NOTE:
all protocols or services
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.
}
}
To confirm your OSPFv3 configuration, enter the show interfaces and the show protocols ospf3
commands.
Verification
IN THIS SECTION
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.
SEE ALSO
No Link Title
24
IN THIS SECTION
Requirements | 24
Overview | 24
Configuration | 25
Verification | 27
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 the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 25
25
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.
• 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
Configuration
IN THIS SECTION
Procedure | 26
Results | 27
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
Step-by-Step Procedure
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit ]
user@host# edit protocols ospf area 0.0.0.1
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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.
28
IN THIS SECTION
Requirements | 28
Overview | 28
Configuration | 29
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:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
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.
29
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 | 30
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
Procedure
Step-by-Step Procedure
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
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
IN THIS SECTION
Requirements | 31
Overview | 32
Configuration | 32
Verification | 33
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
32
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
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 | 33
Results | 33
To quickly configure an OSPFv2 peer 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 peer-interface oxc1
33
Procedure
Step-by-Step Procedure
[edit]
user@host# edit protocols ospf area 0.0.0.0
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.
Verification
IN THIS SECTION
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
IN THIS SECTION
Requirements | 34
Overview | 35
Configuration | 36
Verification | 38
This example shows how to configure an OSPFv2 interface on a nonbroadcast multiaccess (NBMA)
network.
Requirements
Before you begin:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58.
35
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 36
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.
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.
36
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
Procedure
Step-by-Step Procedure
[edit]
user@host# set interfaces at-0/1/0 unit 0 family inet address 192.0.2.1
37
[edit]
user@host# edit protocols ospf area 0.0.0.1
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.
}
}
Verification
IN THIS SECTION
Purpose
Verify the interface configuration. Confirm that the Type field displays NBMA.
Action
From operational mode, enter the show ospf interface detail command.
SEE ALSO
IN THIS SECTION
Requirements | 39
Overview | 39
Configuration | 40
Verification | 42
Requirements
Before you begin:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 40
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.
40
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 | 41
[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
Procedure
Step-by-Step Procedure
[edit]
user@host# set interfaces at-0/1/0 unit 0 family inet address 192.0.2.2
41
[edit]
user@host# edit protocols ospf area 0.0.0.1
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.
}
}
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.
By default, OSPFv3 supports only unicast IPv6 routes. In Junos OS Release 9.2 and later, you can
configure OSPFv3 to support multiple address families, including IPv4 unicast, IPv4 multicast, and IPv6
multicast. This mutliple address family support allows OSPFv3 to support both IPv6 and IPv4 nodes.
Junos OS maps each address family to a separate realm as defined in 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:
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.
IN THIS SECTION
Requirements | 43
Overview | 44
Configuration | 45
Verification | 48
This example shows how to configure multiple address families for OSPFv3.
Requirements
Before you begin:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
44
Overview
IN THIS SECTION
Topology | 45
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 45 shows a connection between Routers R0 and R1. In this example, you configure
interface fe-0/1/0 on Router R0 in area 0 to advertise IPv4 unicast routes, in addition to the default
unicast IPv6 routes in area 1, by including the realm ipv4-unicast statement. Depending on your network
requirements, you can also advertise IPv4 multicast routes by including the realm-ipv4-multicast
statement, and you can advertise IPv6 multicast routes by including the realm-ipv6-multicast statement.
45
Topology
Configuration
IN THIS SECTION
Procedure | 46
Results | 47
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
46
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter
commit from configuration mode.
[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
Step-by-Step Procedure
[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
[edit ]
user@host# edit protocols ospf3
4. Configure an IPv4 unicast realm. This allows OSPFv3 to support both IPv4 unicast and IPv6 unicast
routes.
NOTE: Repeat this entire configuration on the neighboring device that is part of the realm.
Results
Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If the
output does not display the intended configuration, repeat the instructions in this example to correct
the configuration.
Verification
IN THIS SECTION
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.
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
IN THIS SECTION
Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas | 90
IN THIS SECTION
Areas | 51
Backbone Areas | 52
AS Boundary Routers | 52
Backbone Router | 52
Internal Router | 52
Stub Areas | 53
Not-So-Stubby Areas | 53
Transit Areas | 53
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.
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.
53
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.
The following table gives details about OSPF area types and accepted LSAs:
54
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:
• 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
55
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.
IN THIS SECTION
Requirements | 55
Overview | 56
Configuration | 56
Verification | 58
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
56
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 | 57
Results | 57
57
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
Step-by-Step Procedure
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.
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.
IN THIS SECTION
Requirements | 58
Overview | 58
Configuration | 59
Verification | 60
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
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.
59
Configuration
IN THIS SECTION
Procedure | 59
Results | 60
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,
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.3 interface ge-0/0/1 priority 200
Procedure
Step-by-Step Procedure
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
60
[edit]
user@host# commit
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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.
61
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.
OSPF networks in an autonomous system (AS) are administratively grouped into areas. Each area within
an AS operates like an independent network and has a unique 32-bit area ID, which functions similar to
a network address. Within an area, the topology database contains only information about the area, link-
state advertisements (LSAs) are flooded only to nodes within the area, and routes are computed only
within the area. The topology of an area is hidden from the rest of the AS, thus significantly reducing
routing traffic in the AS. Subnetworks are divided into other areas, which are connected to form the
whole of the main network. Routing devices that are wholly within an area are called internal routers. All
interfaces on internal routers are directly connected to networks within the area.
The central area of an AS, called the backbone area, has a special function and is always assigned the
area ID 0.0.0.0. (Within a simple, single-area network, this is also the ID of the area.) Area IDs are unique
numeric identifiers, in dotted decimal notation, but they are not IP addresses. Area IDs need only be
unique within an AS. All other networks or areas in the AS must be directly connected to the backbone
area by a routing device that has interfaces in more than one area. These connecting routing devices are
called border area routers (ABRs). Figure 3 on page 61 shows an OSPF topology of three areas
connected by two ABRs.
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
62
transmitting the traffic through the appropriate ABR to the destination area. The ABRs summarize the
link-state records of each area and advertise destination address summaries to neighboring areas. The
advertisements contain the ID of the area in which each destination lies, so that packets are routed to
the appropriate ABR. For example, in the OSPF areas shown in Figure 3 on page 61, 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 62 shows a virtual link between a noncontiguous area
and the backbone area through an area connected to both.
In the topology shown in Figure 4 on page 62, 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.
63
IN THIS SECTION
Requirements | 63
Overview | 63
Configuration | 64
Verification | 65
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
Overview
IN THIS SECTION
Topology | 64
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.
64
To use OSPF on the device, you must configure at least one OSPF area, such as the one shown in Figure
5 on page 64.
Topology
Configuration
IN THIS SECTION
Procedure | 65
Results | 65
To quickly configure a single-area OSPF 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 protocols ospf area 0.0.0.0 interface ge-0/0/0
65
Procedure
Step-by-Step Procedure
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
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
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.
Action
From operational mode, enter the show ospf interface command for OSPFv2, and enter the show ospf3
interface command for OSPFv3.
IN THIS SECTION
Requirements | 66
Overview | 67
Configuration | 68
Verification | 72
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:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
67
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
Overview
IN THIS SECTION
Topology | 68
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
68, 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 68. 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.
68
Topology
Configuration
IN THIS SECTION
Procedure | 68
Results | 71
Procedure
To quickly configure a multiarea OSPF 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.
Device A
[edit]
set protocols ospf area 0.0.0.0 interface ge-0/0/0
set protocols ospf area 0.0.0.0 interface ge-0/0/1
69
Device C
[edit]
set protocols ospf area 0.0.0.0 interface ge-0/0/0
Device B
[edit]
set protocols ospf area 0.0.0.0 interface ge-0/0/0
set protocols ospf area 0.0.0.2 interface ge-0/0/2
Device D
[edit]
set protocols ospf area 0.0.0.2 interface ge-0/0/0
set protocols ospf area 0.0.0.2 interface ge-0/0/2
Device E
[edit]
set protocols ospf area 0.0.0.2 interface ge-0/0/2
Step-by-Step Procedure
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
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
71
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
72
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.
Action
From operational mode, enter the show ospf interface command for OSPFv2, and enter the show ospf3
interface command for OSPFv3.
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.
73
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.
IN THIS SECTION
Requirements | 73
Overview | 73
Configuration | 75
Verification | 78
Requirements
Before you begin, plan your multiarea OSPF network. See "Example: Configuring a Multiarea OSPF
Network" on page 66.
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
74
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.
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.
75
Configuration
IN THIS SECTION
Procedure | 75
Results | 77
To quickly configure a secondary logical interface for an OSPF area, 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 so-0/0/0 unit 0 family inet address 192.0.2.45/24
set routing-options router-id 10.255.0.1
set protocols ospf area 0.0.0.1 interface so-0/0/0
set protocols ospf area 0.0.0.2 interface so-0/0/0 secondary
[edit]
set interfaces so-1/0/0 unit 0 family inet address 192.0.2.37/24
set routing-options router-id 10.255.0.2
set protocols ospf area 0.0.0.1 interface so-1/0/0
set protocols ospf area 0.0.0.2 interface so-1/0/0 secondary
Procedure
Step-by-Step Procedure
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]
user@R2# set interfaces so-1/0/0 unit 0 family inet address 192.0.2.37/24
[edit]
user@R1# set routing-options router-id 10.255.0.1
[edit]
user@R2# set routing-options router-id 10.255.0.2
3. On each ABR, configure the primary interface for the OSPF area.
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@R1# set protocols ospf area 0.0.0.1 interface so-0/0/0
[edit ]
user@R2# set protocols ospf area 0.0.0.1 interface so-1/0/0
77
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
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.
}
area 0.0.0.2 {
interface so-0/0/0.0 {
secondary;
}
}
Verification
IN THIS SECTION
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.
Action
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
Purpose
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..
Purpose
Verify the primary and secondary neighbor adjacencies. The Secondary field displays if the neighbor is
on a secondary interface.
80
Action
From operational mode, enter the show ospf neighbor detail command for OSPFv2, and enter the show ospf3
neighbor detail command 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
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.
IN THIS SECTION
Requirements | 81
Overview | 81
Configuration | 82
Verification | 88
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.
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.
82
"CLI Quick Configuration" on page 82 shows the configuration for all of the devices in Figure 8 on page
82. The section "No Link Title" on page 84 describes the steps on Device R1 and Device R2.
Configuration
IN THIS SECTION
Procedure | 82
Procedure
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
Device R2
Device R3
Device R4
Device R5
Device R6
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
[edit interfaces]
user@R1# set ge-1/2/0 unit 0 family inet6 address 2001:db8:9009:1::1/64
user@R1# set fe-1/2/1 unit 0 family inet6 address 2001:db8:9009:2::2/64
user@R1# set lo0 unit 0 family inet address 10.1.1.1/32
user@R1# set lo0 unit 0 family inet6 address 2001:db8:9009::1/128
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
[edit interfaces]
user@R2# set ge-1/2/0 unit 0 family inet6 address 2001:db8:9009:1::2/64
user@R2# set fe-1/2/1 unit 0 family inet6 address 2001:db8:9009:4::2/64
user@R2# set fe-1/2/2 unit 0 family inet6 address 2001:db8:9009:6::2/64
user@R2# set lo0 unit 0 family inet address 10.2.2.2/32
user@R2# set lo0 unit 0 family inet6 address 2001:db8:9009::2/128
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
}
area 0.0.0.1 {
interface fe-1/2/1.0;
interface ge-1/2/0.0 {
secondary;
}
}
}
Device R2
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
IN THIS SECTION
Verifying That the Traffic Flow Changes When You Remove the Multiarea Adjacency | 89
Purpose
Verify that traffic uses the high-speed link between Device R1 and Device R2 to reach destinations in
area 1.
89
Action
From operational mode on Device R1, use the traceroute command check the traffic flow to Device R5
and Device R6.
Meaning
The traceroute output shows that traffic uses the 9009:1:: link between Device R1 and Device R2.
Verifying That the Traffic Flow Changes When You Remove the Multiarea Adjacency
Purpose
Action
2. From operational mode on Device R1, use the traceroute command check the traffic flow to Device
R5 and Device R6.
Meaning
Without the multiarea adjacency, the output shows suboptimal routing with traffic taking the path
through the area 1 low-speed-links.
Figure 9 on page 91 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.
91
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 91 is not directly connected to the outside network. All
outbound traffic is routed through the ABR to the backbone and then to the destination addresses. By
designating area 0.0.0.3 as a stub area, you reduce the size of the topology database for that area by
limiting the route entries to only those routes internal to the area.
A stub area that only allows routes internal to the area and restricts Type 3 LSAs from entering the stub
area is often called a totally stubby area. You can convert area 0.0.0.3 to a totally stubby area by
configuring the ABR to only advertise and allow the default route to enter into the area. External routes
and destinations to other areas are no longer summarized or allowed into a totally stubby area.
NOTE: If you incorrectly configure a totally stubby area, you might encounter network
connectivity issues. You should have advanced knowledge of OSPF and understand your
network environment before configuring totally stubby areas.
92
Similar to area 0.0.0.3 in Figure 9 on page 91, 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.
IN THIS SECTION
Requirements | 92
Overview | 93
Configuration | 94
Verification | 97
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:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
93
Overview
IN THIS SECTION
Topology | 94
The backbone area, which is 0 in Figure 10 on page 94, 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.
• You cannot configure an area as both a stub area and an not-so-stubby area (NSSA).
In this example, you configure each routing device in area 7 (area ID 0.0.0.7) as a stub router and some
additional settings on the ABR:
• stub—Specifies that this area become a stub area and not be flooded with Type 5 LSAs. You must
include the stub statement on all routing devices that are in area 7 because this area has no external
connections.
• default-metric—Configures the ABR to generate a default route with a specified metric into the stub
area. This default route enables packet forwarding from the stub area to external destinations. You
configure this option only on the ABR. The ABR does not automatically generate a default route
when attached to a stub. You must explicitly configure this option to generate a default route.
• no-summaries—(Optional) Prevents the ABR from advertising summary routes into the stub area by
converting the stub area into a totally stubby area. If configured in combination with the default-
metric statement, a totally stubby area only allows routes internal to the area and advertises the
default route into the area. External routes and destinations to other areas are no longer summarized
94
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.
• 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
Configuration
IN THIS SECTION
Procedure | 95
Results | 96
95
• 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
Step-by-Step Procedure
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
96
[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
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
Configuration on the ABR (the output also includes the optional setting):
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
97
Verification
IN THIS SECTION
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
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
Purpose
Verify that the OSPF area is a stub area. Confirm that the output displays Normal Stub as the Stub type.
Action
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3
overview command for OSPFv3.
98
IN THIS SECTION
Requirements | 98
Overview | 98
Configuration | 100
Verification | 104
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:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 100
The backbone area, which is 0 in Figure 11 on page 100, 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.
99
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
configure this option only on the ABR. The ABR does not automatically generate a default route
when attached to an NSSA. You must explicitly configure this option for the ABR to generate a
default route.
• metric-type—(Optional) Specifies the external metric type for the default LSA, which can be either
Type 1 or Type 2. When OSPF exports route information from external ASs, it includes a cost, or
external metric, in the route. The difference between the two metrics is how OSPF calculates the
cost of the route. Type 1 external metrics are equivalent to the link-state metric, where the cost is
equal to the sum of the internal costs plus the external cost. Type 2 external metrics use only the
external cost assigned by the AS boundary router. By default, OSPF uses the Type 2 external
metric.
100
• 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
Disabling the Export of Type 7 Link State Advertisements into Not-So-Stubby Areas | 103
101
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
Step-by-Step Procedure
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
102
4. (Optional) On the ABR, specify the external metric type for the default route.
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
Configuration on the ABR. The output also includes the optional metric-type and type-7 statements.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
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
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. 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
Step-by-Step Procedure
You can configure this setting if you have an AS boundary router that is also an ABR with an NSSA area
attached.
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
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
Purpose
Verify that the OSPF area is a stub area. Confirm that the output displays Not so Stubby Stub as the
Stub type.
Action
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3
overview command for OSPFv3.
Purpose
Verify the type of LSAs that are in the area. If you disabled exporting Type 7 LSAs into an NSSA, confirm
that the Type field does not include NSSA as a type of LSA.
Action
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3
overview command for OSPFv3.
106
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.
• You cannot configure an area as both a stub area and an not-so-stubby area (NSSA).
IN THIS SECTION
Requirements | 106
Overview | 107
Configuration | 108
Verification | 118
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
No special configuration beyond device initialization is required before configuring this example.
107
Overview
Figure 12 on page 107 shows the topology used in this example.
In this example, you configure each routing device in area 7 (area ID 0.0.0.7) as a stub router and some
additional settings on the ABR:
• stub—Specifies that this area become a stub area and not be flooded with Type 5 LSAs. You must
include the stub statement on all routing devices that are in area 7 because this area has no external
connections.
• default-metric—Configures the ABR to generate a default route with a specified metric into the stub
area. This default route enables packet forwarding from the stub area to external destinations. You
configure this option only on the ABR. The ABR does not automatically generate a default route
when attached to a stub. You must explicitly configure this option to generate a default route.
• no-summaries—(Optional) Prevents the ABR from advertising summary routes into the stub area by
converting the stub area into a totally stubby area. If configured in combination with the default-
metric statement, a totally stubby area only allows routes internal to the area and advertises the
default route into the area. External routes and destinations to other areas are no longer summarized
108
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.
• 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.
"CLI Quick Configuration" on page 108 shows the configuration for all of the devices in Figure 12 on
page 107. The section "No Link Title" on page 110 describes the steps on Device 2, Device 6, Device 7,
and Device 8.
Configuration
IN THIS SECTION
Procedure | 108
Procedure
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device 1
Device 2
Device 3
Device 4
Device 5
Device 6
Device 7
Device 8
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 2:
[edit interfaces]
user@2# set fe-1/2/0 unit 0 family inet6 address 2001:db8:9009:2::2/64
111
6. (Optional) On the ABR, restrict summary LSAs from entering the area.
This step converts the stub area into a totally stubby area.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
112
To configure Device 6:
[edit interfaces]
user@6# set fe-1/2/0 unit 0 family inet6 address 2001:db8:9009:4::2/64
user@6# set lo0 unit 0 family inet address 10.6.6.6/32
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 7:
[edit interfaces]
user@7# set fe-1/2/0 unit 0 family inet6 address 2001:db8:9009:5::2/64
user@7# set fe-1/2/1 unit 0 family inet6 address 2001:db8:9009:7::1/64
user@7# set lo0 unit 0 family inet address 10.7.7.7/32
113
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 8:
[edit interfaces]
user@8# set fe-1/2/0 unit 0 family inet6 address 2001:db8:9009:7::2/64
user@8# set lo0 unit 0 family inet address 10.8.8.8/32
114
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
interface fe-1/2/0.0;
interface lo0.0 {
passive;
}
}
area 0.0.0.7 {
stub default-metric 10 no-summaries;
interface fe-1/2/1.0;
}
}
Device 6
Device 7
Device 8
If you are done configuring the device, enter commit from configuration mode.
118
Verification
IN THIS SECTION
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.
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
Backup SPF: Not Needed
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.
Purpose
Make sure that the expected routes are present in the routing tables.
Action
From operational mode on Device 6 and Device 2, enter the show route command.
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
2001:db8:9009:4::/64 and the OSPFv3 multicast address ff02::5/128 for all SPF link-state routers, also
known as AllSPFRouters.
On Device 2, all of the OSPFv3 routes have been learned, including the external customer routes,
2001:db8:1010::1/128 and 2001:db8:2020::1/128.
122
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.
IN THIS SECTION
Requirements | 122
Overview | 122
Configuration | 124
Verification | 135
This example shows how to configure an OSPFv3 not-so-stubby area (NSSA) to control the
advertisement of external routes into the area.
Requirements
No special configuration beyond device initialization is required before configuring this example.
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
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.
123
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
configure this option only on the ABR. The ABR does not automatically generate a default route
when attached to an NSSA. You must explicitly configure this option for the ABR to generate a
default route.
• metric-type—(Optional) Specifies the external metric type for the default LSA, which can be either
Type 1 or Type 2. When 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 into
NSSAs for Junos OS release 5.0 and later. To support backward compatibility with earlier Junos
OS releases, include the type-7 statement.
124
"CLI Quick Configuration" on page 125 shows the configuration for all of the devices in Figure 13 on
page 124. The section "No Link Title" on page 127 describes the steps on Device 3, Device 7, and
Device 9.
Configuration
IN THIS SECTION
Procedure | 125
125
Procedure
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device 1
Device 3
Device 4
Device 5
Device 7
Device 8
Device 9
Device 10
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 3:
[edit interfaces]
user@3# set fe-1/2/0 unit 0 family inet6 address 2001:db8:9009:3::2/64
user@3# set fe-1/2/1 unit 0 family inet6 address 2001:db8:9009:5::1/64
user@3# set lo0 unit 0 family inet address 10.3.3.3/32
6. (Optional) On the ABR, specify the external metric type for the default route.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 5:
129
[edit interfaces]
user@5# set fe-1/2/0 unit 0 family inet6 address 2001:db8:9009:6::2/64
user@5# set fe-1/2/1 unit 0 family inet6 address 2001:db8:9009:7::1/64
user@5# set lo0 unit 0 family inet address 10.5.5.5/32
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 7:
130
[edit interfaces]
user@7# set fe-1/2/0 unit 0 family inet6 address 2001:db8:9009:5::2/64
user@7# set fe-1/2/1 unit 0 family inet6 address 2001:db8:9009:7::1/64
user@7# set lo0 unit 0 family inet address 10.7.7.7/32
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 8:
[edit interfaces]
user@8# set fe-1/2/0 unit 0 family inet6 address 2001:db8:9009:7::2/64
user@8# set lo0 unit 0 family inet address 10.8.8.8/32
131
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 3
area 0.0.0.0 {
interface fe-1/2/0.0;
interface lo0.0 {
passive;
}
}
area 0.0.0.9 {
nssa {
default-lsa {
default-metric 10;
metric-type 1;
type-7;
}
no-summaries;
}
interface fe-1/2/1.0;
}
}
Device 5
}
}
Device 7
}
}
lo0 {
unit 0 {
family inet {
address 10.7.7.7/32;
}
}
}
Device 8
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
IN THIS SECTION
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.
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
Backup SPF: Not Needed
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
Make sure that the expected routes are present in the routing tables.
Action
From operational mode on Device 7 and Device 3, enter the show route command.
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.
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,
2001:db8:1010::1/128 and 2001:db8:2020::1/128.
141
Purpose
Action
From operational mode on Device 7, enter the show ospf3 database nssa detail command.
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.
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
142
7 LSAs), you can disable exporting Type 7 LSAs into the NSSA by including the no-nssa-abr statement on
the routing device.
IN THIS SECTION
Requirements | 142
Overview | 142
Configuration | 143
Verification | 149
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
No special configuration beyond device initialization is required before configuring this example.
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
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.
143
Figure 14: OSPFv3 Network Topology with an NSSA ABR That Is Also an ASBR
"CLI Quick Configuration" on page 143 shows the configuration for all of the devices in Figure 14 on
page 143. The section "No Link Title" on page 145 describes the steps on Device 4.
Configuration
IN THIS SECTION
Procedure | 143
Procedure
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
144
Device 1
Device 2
Device 3
Device 4
Device 5
Device 6
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see “Using the CLI Editor in Configuration Mode” in the CLI User
Guide.
To configure Device 4:
[edit interfaces]
user@4# set fe-1/2/0 unit 0 family inet6 address 2001:db8:9009:1::2/64
user@4# set fe-1/2/1 unit 0 family inet6 address 2001:db8:9009:6::1/64
146
6. (Optional) On the ABR, specify the external metric type for the default route.
This setting is useful if you have an AS boundary router that is also an ABR with an NSSA area
attached.
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.
148
Device 4
default-metric 10;
metric-type 1;
type-7;
}
no-summaries;
}
interface fe-1/2/1.0;
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
IN THIS SECTION
Purpose
Make sure that the expected routes are present in the routing tables.
Action
From operational mode on Device 1 and Device 6, enter the show route command.
fe80::2a0:a514:0:44c/128
*[Local/0] 03:25:34
Local via fe-1/2/0.0
fe80::2a0:a514:0:74c/128
*[Local/0] 03:25:34
Local via fe-1/2/1.0
ff02::5/128 *[OSPF3/10] 03:27:00, 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 2001:db8:3030::1 and 2001:db8:4040::1 have been learned from
Device 2. The 2001:db8:1010::1 and 2001:db8:2020::1 routes have been suppressed. They are not
needed because the default route can be used instead.
Purpose
Action
From operational mode on Device 1, enter the show ospf3 database nssa detail command.
Meaning
Device 4 is not sending Type 7 (NSSA) LSAs for customer routes 2001:db8:1010::1/128 and
2001:db8: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
2001:db8:1010::1/128 and 2001:db8:2020::1/128.
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
routing information and it cannot be a stub area. For example, Figure 15 on page 153 shows a virtual
link between a noncontiguous area and the backbone area through an area connected to both.
In the topology shown in Figure 15 on page 153, 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.
154
IN THIS SECTION
Requirements | 154
Overview | 154
Configuration | 155
Verification | 159
This example shows how to configure an OSPF virtual link to connect noncontiguous areas.
Requirements
Before you begin:
• Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices.
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 155
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
155
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 155. 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.
• 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.
Topology
Configuration
IN THIS SECTION
Procedure | 156
Results | 158
156
• To quickly configure an OSPF virtual link on the local routing device (Device R1), copy the following
commands and paste them into the CLI.
NOTE: You must configure both routing devices that are part of the virtual link and specify
the applicable neighbor ID on each routing device.
[edit]
set routing-options router-id 192.0.2.5
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 routing-options router-id 192.0.2.3
set protocols ospf area 0.0.0.0 virtual-link neighbor-id 192.0.2.5 transit-area 0.0.0.2
Procedure
Step-by-Step Procedure
To configure an OSPF virtual link on the local routing device (Device R1):
[edit]
user@R1# set routing-options router-id 192.0.2.5
NOTE: For an OSPFv3 virtual link, include the ospf3 statement at the [edit protocols] hierarchy
level.
[edit]
user@R1# edit protocols ospf area 0.0.0.0
3. Configure an OSPF virtual link and specify the transit area 0.0.0.2.
This routing device must be an ABR that is physically connected to the backbone.
Step-by-Step Procedure
To configure an OSPF virtual link on the remote ABR (Device R2, the routing device at the other end of
the link):
[edit]
user@R2# set routing-options router-id 192.0.2.3
NOTE: For an OSPFv3 virtual link, include the ospf3 statement at the [edit protocols] hierarchy
level.
[edit]
user@R2# edit protocols ospf area 0.0.0.0
3. Configure an OSPF virtual link on the remote ABR and specify the transit area 0.0.0.2.
This routing device is not physically connected to the backbone.
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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.
160
Purpose
Verify that the OSPFv2 or OSPFv3 interface is configured and status displays. The Type field displays
the type of interface. If the interface is configured as part of a virtual link, the Type is Virtual.
Action
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
IN THIS SECTION
Requirements | 160
Overview | 160
Configuration | 161
Verification | 175
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
No special configuration beyond device initialization is required before configuring this example.
Overview
Figure 17 on page 161 shows the topology used in this example.
161
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 | 162
162
Procedure
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device 0
Device 1
Device 2
Device 3
Device 4
Device 5
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 0:
[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 inet address 192.168.0.1/32
user@0# set lo0 unit 0 family inet6 address feee::10:255:71:4/128
[edit routing-options]
user@0# set router-id 192.168.0.1
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 1:
165
[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
user@1# set lo0 unit 0 family inet address 192.168.1.1/32
user@1# set lo0 unit 0 family inet6 address feee::10:255:71:1/128
[edit routing-options]
user@1# set router-id 192.168.1.1
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 2:
[edit interfaces]
user@2# set so-0/2/0 unit 0 family inet6 address 9009:3::1/64
user@2# set fe-1/1/0 unit 0 family inet6 address 9009:4::1/64
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
user@2# set lo0 unit 0 family inet address 192.168.2.1/32
user@2# set lo0 unit 0 family inet6 address feee::10:255:71:11/128
166
2. Add the interfaces connected to Device 1, Device 3, and Device 4 into the OSPFv3 process.
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.
[edit routing-options]
user@2# set router-id 192.168.2.1
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 3:
[edit interfaces]
user@3# set so-0/3/2 unit 0 family inet6 address 9009:1::2/64
user@3# set t1-0/2/1 unit 0 family inet6 address 9009:5::1/64
user@3# set so-0/3/0 unit 0 family inet6 address 9009:3::2/64
user@3# set lo0 unit 0 family inet address 192.168.3.1/32
user@3# set lo0 unit 0 family inet6 address feee::10:255:71:3/128
167
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.
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.
[edit routing-options]
user@3# set router-id 192.168.3.1
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 4:
[edit interfaces]
user@4# set t1-0/2/1 unit 0 family inet6 address 9009:5::2/64
user@4# set fe-0/0/0 unit 0 family inet6 address 9009:6::1/64
user@4# set fe-1/1/0 unit 0 family inet6 address 9009:4::2/64
168
3. Configure the virtual link to Device 3 through Area 1 so that Device 5 can access the OSPF
backbone.
[edit routing-options]
user@4# set router-id 192.168.4.1
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure Device 5:
[edit interfaces]
user@5# set fe-0/0/0 unit 0 family inet6 address 9009:6::2/64
user@5# set lo0 unit 0 family inet address 192.168.5.1/32
user@5# set lo0 unit 0 family inet6 address feee::10:255:71:6/128
169
[edit routing-options]
user@5# set router-id 192.168.5.1
Results
From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and
show routing-options commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.
Device 0
interface so-0/3/2.0;
interface lo0.0 {
passive;
}
}
}
user@0# show routing-options
router-id 192.168.0.1;
Device 1
Device 2
}
user@2# show protocols
ospf3 {
area 0.0.0.0 {
virtual-link neighbor-id 192.168.3.1 transit-area 0.0.0.1;
interface at-0/3/1.0;
}
area 0.0.0.1 {
interface fe-1/1/0.0;
interface so-0/2/0.0;
interface lo0.0 {
passive;
}
}
}
user@2# show routing-options
router-id 192.168.2.1;
Device 3
lo0 {
unit 0 {
family inet {
address 192.168.3.1/32;
}
family inet6 {
address feee::10:255:71:3/128;
}
}
}
user@3# show protocols
ospf3 {
area 0.0.0.1 {
interface so-0/3/0.0;
interface t1-0/2/1.0;
interface lo0.0 {
passive;
}
}
area 0.0.0.0 {
virtual-link neighbor-id 192.168.2.1 transit-area 0.0.0.1;
virtual-link neighbor-id 192.168.4.1 transit-area 0.0.0.1;
interface so-0/3/2.0;
}
}
user@3# show routing-options
router-id 192.168.3.1;
Device 4
}
}
}
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;
}
}
}
user@4# show protocols
ospf3 {
area 0.0.0.1 {
interface fe-1/1/0.0;
interface t1-0/2/1.0;
interface lo0.0 {
passive;
}
}
area 0.0.0.2 {
interface fe-0/0/0.0;
}
area 0.0.0.0 {
virtual-link neighbor-id 192.168.3.1 transit-area 0.0.0.1;
}
}
user@4# show routing-options
router-id 192.168.4.1;
175
Device 5
If you are done configuring the devices, enter commit from configuration mode.
Verification
IN THIS SECTION
To verify proper operation of OSPFv3 for IPv6, use the following commands:
• 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
Neighbor-address fe80::2a0:a514:0:24c
Device 1 Status
Purpose
Verify that Device 1 has learned the expected routes and has established the expected neighbor
adjacencies.
Action
Device 2 Status
Purpose
Verify that Device 2 has learned the expected routes and has established the expected neighbor
adjacencies.
Action
Area 0.0.0.1
Type ID Adv Rtr Seq Age Cksum Len
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
NH-interface so-0/2/0.0
feee::10:255:71:4/128 Intra Network IP 2
NH-interface so-0/2/0.0
feee::10:255:71:5/128 Intra Network IP 1
NH-interface fe-1/1/0.0
feee::10:255:71:6/128 Inter Network IP 2
NH-interface fe-1/1/0.0
feee::10:255:71:11/128 Intra Network IP 0
NH-interface lo0.0
Device 3 Status
Purpose
Verify that Device 3 has learned the expected routes and has established the expected neighbor
adjacencies.
Action
Area 0.0.0.1
Type ID Adv Rtr Seq Age Cksum Len
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
NH-interface so-0/3/2.0
192.168.1.1 Intra Router IP 2
NH-interface (null), NH-addr feee::10:255:71:11
192.168.2.1 Intra Area BR IP 1
NH-interface so-0/3/0.0
192.168.4.1 Intra Area BR IP 1
NH-interface t1-0/2/1.0
9009:1::/64 Intra Network IP 1
NH-interface so-0/3/2.0
9009:1::2/128 Intra Network IP 0
NH-interface so-0/3/2.0
9009:2::/64 Intra Network IP 2
NH-interface so-0/3/0.0
9009:2::2/128 Intra Network IP 1
NH-interface so-0/3/0.0
9009:3::/64 Intra Network IP 1
NH-interface so-0/3/0.0
9009:4::/64 Intra Network IP 2
NH-interface so-0/3/0.0
NH-interface t1-0/2/1.0
9009:5::/64 Intra Network IP 1
NH-interface t1-0/2/1.0
9009:6::/64 Inter Network IP 2
NH-interface t1-0/2/1.0
9009:6::1/128 Inter Network IP 1
NH-interface t1-0/2/1.0
feee::10:255:71:1/128 Intra Network IP 2
NH-interface so-0/3/0.0
feee::10:255:71:3/128 Intra Network IP 0
NH-interface lo0.0
feee::10:255:71:4/128 Intra Network IP 1
NH-interface so-0/3/2.0
feee::10:255:71:5/128 Intra Network IP 1
NH-interface t1-0/2/1.0
feee::10:255:71:6/128 Inter Network IP 2
NH-interface t1-0/2/1.0
feee::10:255:71:11/128 Intra Network IP 1
NH-interface so-0/3/0.0
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
inet6 fe80::2a0:a50f:fc56:14c
feee::10:255:71:3
...
Device 4 Status
Purpose
Verify that Device 4 has learned the expected routes and has established the expected neighbor
adjacencies.
Action
Area 0.0.0.1
Type ID Adv Rtr Seq Age Cksum Len
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
InterArPfx 0.0.0.4 192.168.3.1 0x8000008f 2014 0xc34e 44
191
Area 0.0.0.2
Type ID Adv Rtr Seq Age Cksum Len
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
Device 5 Status
Purpose
Verify that Device 5 has learned the expected routes and has established the expected neighbor
adjacencies.
Action
RELATED DOCUMENTATION
OSPF Overview | 2
OSPF Packets Overview | 7
Understanding OSPF Configurations | 14
5 CHAPTER
IN THIS SECTION
Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements Sent into the Backbone
Area | 197
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.
197
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.
IN THIS SECTION
Requirements | 197
Overview | 198
Configuration | 200
Verification | 205
This example shows how to summarize routes sent into the backbone area.
Requirements
Before you begin:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a static route. See Examples: Configuring Static Routes in the Junos OS Routing Protocols
Library for Routing Devices.
198
Overview
IN THIS SECTION
Topology | 199
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 199 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
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.
199
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
200
Configuration
IN THIS SECTION
Procedure | 201
Results | 203
• To quickly configure route summarization for an OSPF area, copy the following commands and paste
them into the CLI. The following is the configuration on ABR R5:
[edit]
set interfaces fe-0/0/1 unit 0 family inet address 10.0.8.3/30
set interfaces fe-0/0/2 unit 0 family inet address 10.0.8.4/30
set interfaces fe-0/0/0 unit 0 family inet address 10.0.2.3/30
set interfaces fe-0/0/4 unit 0 family inet address 10.0.2.5/30
set protocols ospf area 0.0.0.4 stub
set protocols ospf area 0.0.0.4 interface fe-0/0/1
set protocols ospf area 0.0.0.4 interface fe-0/0/2
set protocols ospf area 0.0.0.0 interface fe-0/0/0
set protocols ospf area 0.0.0.0 interface fe-0/0/4
set protocols ospf area 0.0.0.4 area-range 10.0.8.0/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]
set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.10/30
set interfaces fe-0/0/2 unit 0 family inet address 10.0.4.1/30
set interfaces fe-0/0/0 unit 0 family inet address 10.0.2.1/30
set interfaces fe-0/0/4 unit 0 family inet address 10.0.2.7/30
set protocols ospf area 0.0.0.3 interface fe-0/0/1
set protocols ospf area 0.0.0.3 interface fe-0/0/2
set protocols ospf area 0.0.0.0 interface fe-0/0/0
set protocols ospf area 0.0.0.0 interface fe-0/0/4
201
Procedure
Step-by-Step Procedure
[edit]
user@R5# set interfaces fe-0/0/1 unit 0 family inet address 10.0.8.3/30
user@R5# set interfaces fe-0/0/2 unit 0 family inet address 10.0.8.4/30
user@R5# set interfaces fe-0/0/0 unit 0 family inet address 10.0.2.3/30
user@R5# set interfaces fe-0/0/4 unit 0 family inet address 10.0.2.5/30
[edit]
user@R3# set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.10/30
user@R3# set interfaces fe-0/0/2 unit 0 family inet address 10.0.4.1/30
user@R3# set interfaces fe-0/0/0 unit 0 family inet address 10.0.2.1/30
user@R3# set interfaces fe-0/0/4 unit 0 family inet address 10.0.2.7/30
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@R5# set protocols ospf area 0.0.0.4 stub
[edit]
user@R3# set protocols ospf area 0.0.0.3 nssa
[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
203
[edit]
user@host# commit
Results
Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If the
output does not display the intended configuration, repeat the instructions in this example to correct
the configuration.
}
}
family inet {
address 10.0.2.7/32;
}
}
}
To confirm your OSPFv3 configuration, enter the show interfaces and show protocols ospf3 commands.
Verification
IN THIS SECTION
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.
206
Action
From operational mode, enter the show ospf database command for OSPFv2, and enter the show ospf3
database command for OSPFv3.
IN THIS SECTION
Requirements | 206
Overview | 207
Configuration | 207
Verification | 209
This example shows how to limit the number of prefixes exported to OSPF.
Requirements
Before you begin:
• Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
207
Overview
IN THIS SECTION
Topology | 207
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 | 208
Results | 208
To quickly limit the number of prefixes exported to OSPF, copy the following commands, paste them
into a text file, remove any line breaks, change any details necessary to match your network
208
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 prefix-export-limit 100000
Procedure
Step-by-Step Procedure
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# set protocols ospf prefix-export-limit 100000
[edit]
user@host# commit
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
209
Verification
IN THIS SECTION
Purpose
Verify the prefix export counter that displays the number or routes exported into OSPF.
Action
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3
overview command for OSPFv3.
IN THIS SECTION
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 interface throughput. The
default algorithm computes the interface metric based on a reference bandwidth of 100 Mbps using the
formula cost = reference-bandwidth / interface bandwidth. The result is any interface operating at 100 Mbps
or faster is assigned the same metric value of 1. You can manually assign the OSPF interface metric to
override the default value. Alternatively, given current Juniper platforms support interfaces that operate
210
at 400 Gbps, its often a good idea to configure a larger reference-bandwidth value. Configuring a reference
bandwidth value that is based on a multiple of the highest speed interface in your network automatically
optimizes network paths based on interface speed and provides room for growth in network speeds.
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 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
211
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.
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 (for example, if the
lag loses an interface member or if the interface speed is administratively changed), Junos OS
automatically sets the interface metric to the value associated with the appropriate bandwidth threshold
value. Junos OS uses the smallest configured bandwidth threshold value that is equal to or greater than
the actual interface bandwidth to determine the metric value. If the interface bandwidth is greater than
any of the configured bandwidth threshold values, the metric value configured for the interface is used
instead of any of the bandwidth-based metric values configured. The ability to recalculate the metric for
an interface when its bandwidth changes is especially useful for aggregate interfaces.
NOTE: You must also configure a metric for the interface when you enable bandwidth-based
metrics.
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.
212
SEE ALSO
OSPF Overview | 2
Example: Controlling OSPF Route Preferences | 222
Example: Configuring ECMP Flow-Based Forwarding
IN THIS SECTION
Requirements | 212
Overview | 213
Configuration | 214
Verification | 217
This example shows how to control the cost of individual OSPF network segments.
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
213
Overview
IN THIS SECTION
Topology | 214
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.
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 214 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.
214
Topology
Configuration
IN THIS SECTION
To quickly configure the reference bandwidth, 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
215
paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration
mode.
[edit]
set protocols ospf reference-bandwidth 10g
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[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.
[edit]
user@host# commit
NOTE: Repeat this entire configuration on all routing devices in a shared network.
216
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
To quickly configure a metric for a specific 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 fe-1/0/1 metric 5
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf area 0.0.0.0
217
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
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
SEE ALSO
IN THIS SECTION
Requirements | 220
Overview | 221
219
Verification | 221
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
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf area 0.0.0.0
3. Configure the bandwidth threshold values and associated metric values. With this configuration
when aggregated Ethernet interface’s bandwidth is 1g, OSPF considers metric 60 for this interface.
When aggregated Ethernet interface’s bandwidth is 10g , OSPF considers metric 50 for this 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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
221
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
Overview
IN THIS SECTION
Topology | 221
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
Verification
IN THIS SECTION
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
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
IN THIS SECTION
Requirements | 223
Overview | 224
Verification | 225
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.
Configuration
To quickly configure the OSPF route preference values, 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 preference 168 external-preference 169
223
Step-by-Step Procedure
1. Enter OSPF configuration mode and set the external and internal routing preferences.
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# set protocols ospf preference 168 external-preference 169
[edit]
user@host# commit
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
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 device interfaces. See the Interfaces User Guide for Security Devices.
Overview
IN THIS SECTION
Topology | 224
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.
• 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).
• 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
225
Verification
IN THIS SECTION
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
If the time elapsed after the OSPF instance is enabled is less than the specified timeout, overload mode
is set.
You can configure the local routing device so that it appears to be overloaded. An overloaded routing
device determines it is unable to handle any more OSPF transit traffic, which results in sending OSPF
transit traffic to other routing devices. OSPF traffic to directly attached interfaces continues to reach the
routing device. You might configure overload mode for many reasons, including:
• If you want the routing device to participate in OSPF routing, but do not want it to be used for
transit traffic. This could include a routing device that is connected to the network for analysis
purposes, but is not considered part of the production network, such as network management
routing devices.
• If you are performing maintenance on a routing device in a production network. You can move traffic
off that routing device so network services are not interrupted during your maintenance window.
226
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.
• Advertise external prefix with max possible metric—OSPF AS external prefixes are redistributed
during OSPF overload and the prefixes are advertised with maximum cost.
• allow-route-leaking at the [edit protocols <ospf | ospf3> overload] hierarchy level to advertise the external
prefixes with normal cost.
227
• 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.
[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
IN THIS SECTION
Requirements | 228
Overview | 228
Configuration | 229
Verification | 230
This example shows how to configure a routing device running OSPF to appear to be overloaded.
228
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 228
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.
• overload—Configures the local routing device so it appears to be overloaded. You might configure
this if you want the routing device to participate in OSPF routing, but do not want it to be used for
transit traffic, or you are performing maintenance on a routing device in a production network.
• timeout seconds—(Optional) Specifies the number of seconds at which the overload is reset. If no
timeout interval is specified, the routing device remains in the overload state until the overload
statement is deleted or a timeout is set. In this example, you configure 60 seconds as the amount of
time the routing device remains in the overload state. By default, the timeout interval is 0 seconds
(this value is not configured). The range is from 60 through 1800 seconds.
Topology
229
Configuration
IN THIS SECTION
Procedure | 229
Procedure
To quickly configure a local routing device to appear as overloaded, 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 overload timeout 60
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf
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.
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration. The
output includes the optional timeout and prefix-export-limit statements.
prefix-export-limit 50;
overload timeout 60;
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
Purpose
Verify that the traffic has moved off the upstream devices.
Action
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.
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 overview
command for OSPFv3.
232
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
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.
• The delay in the time between the detection of a topology change and when the SPF algorithm
actually runs.
• The maximum number of times that the SPF algorithm can run in succession before the hold-down
timer begins.
• The time to hold down, or wait, before running another SPF calculation after the SPF algorithm has
run in succession the configured number of times. 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.
233
IN THIS SECTION
Requirements | 233
Overview | 233
Configuration | 234
Verification | 236
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:
• Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 234
234
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
Configuration
IN THIS SECTION
Procedure | 235
235
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
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf
3. Configure the maximum number of times that the SPF algorithm can run in succession.
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3
overview command for OSPFv3.
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.
• OSPFv3 realms
• Logical systems
To configure flooding reduction for an OSPF interface, include the flood-reduction statement at the [edit
protocols (ospf | ospf3) area area-id interface interface-id] hierarchy level.
NOTE: If you configure flooding reduction for an interface configured as a demand circuit, the
LSAs are not initially flooded, but sent only when their content has changed. Hello packets and
LSAs are sent and received on a demand-circuit interface only when a change occurs in the
network topology.
In the following example, the OSPF interface so-0/0/1.0 is configured for flooding reduction. As a result,
all the LSAs generated by the routes that traverse the specified interface have the DoNotAge bit set
when they are initially flooded, and LSAs are refreshed only when a change occurs.
[edit]
protocols ospf {
area 0.0.0.0 {
interface so-0/0/1.0 {
flood-reduction;
}
interface lo0.0;
interface so-0/0/0.0;
}
}
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.
239
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
IN THIS SECTION
Requirements | 239
Overview | 240
Configuration | 241
Verification | 244
This example shows how to configure synchronization between LDP and OSPFv2.
Requirements
Before you begin:
• Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
240
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 240
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
241
Configuration
IN THIS SECTION
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 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
Step-by-Step Procedure
[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
242
3. Configure a time period of 10 seconds to advertise the maximum cost metric for a link that is not
fully operational.
Results
Confirm your configuration by entering the show protocols ldp and show protocols ospf commands. If the
output does not display the intended configuration, repeat the instructions in this example to correct
the configuration.
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
Step-by-Step Procedure
[edit ]
user@host# set protocols ospf area 0.0.0.0 interface so-1/0/3 ldp-synchronization disable
[edit]
user@host# commit
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
Verification
IN THIS SECTION
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.
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
IN THIS SECTION
Requirements | 245
Overview | 245
Configuration | 246
Verification | 247
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 | 245
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
246
Configuration
IN THIS SECTION
Procedure | 246
Results | 247
Procedure
To quickly disable OSPFv2 compatibility with RFC 1583, 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. You configure this setting on all devices that are part of the OSPF domain.
[edit]
set protocols ospf no-rfc-1583
Step-by-Step Procedure
[edit]
user@host# set protocols ospf no-rfc-1583
[edit]
user@host# commit
247
NOTE: Repeat this configuration on each routing device that participates in an OSPF routing
domain.
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
Verification
IN THIS SECTION
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.
RELATED DOCUMENTATION
OSPF Overview | 2
Understanding OSPF Configurations | 14
6 CHAPTER
IN THIS SECTION
IN THIS SECTION
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.
250
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:
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
• 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
252
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 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.
• 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.
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.
254
Starting in Junos OS Release 22.4R1, we support advertising OSPF MD5 authentication with multiple
active keys to send packets with a maximum limit of two keys per interface. Having multiple keys active
at any one time at the interface enables the smooth transition from one key to another for OSPF. You
can delete old keys without any impact on the OSPF session.
Starting in Junos OS Release 23.3R1 and Junos OS Evolved Release 23.3R1, you can enable OSPFv2
HMAC-SHA1 authentication with keychain to authenticate packets reaching or originating from an
OSPF interface. This ensures smooth transition from one key to another for OSPFv2 with enhanced
security. You can enable OSPFv2 to send packets authenticated with only the latest MD5 key once all
the neighbours switch to the latest configured key. Prior to this release, we support advertising
authenticated OSPF packets always with multiple active MD5 keys with a maximum limit of two keys
per interface.
• Migration from other existing authentication types to keychain with hitless session.
NOTE:
• Keychain activeness is based on the absolute time (wall clock) and wall clock may go
backward after commit. This kind of error cannot be caught in commit time, So it is important
to have the system time synchronized on all the devices when keychain is active on a OSPF
session.
SEE ALSO
Overview of IPsec
255
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
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.
256
• Use AH to provide authentication to the OSPFv3 protocol headers, portions of the IPv6 header, and
portions of the extension headers.
• 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
IN THIS SECTION
Requirements | 256
Overview | 257
Configuration | 257
Verification | 259
This example shows how to enable simple authentication for OSPFv2 exchanges.
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.
257
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
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 | 258
Results | 259
258
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
Step-by-Step Procedure
[edit]
user@host# edit protocols ospf area 0.0.0.0
NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices in the area.
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
NOTE: After you configure the password, you do not see the password itself. The output displays
the encrypted form of the password you configured.
Verification
IN THIS SECTION
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.
260
Action
From operational mode, enter the show ospf interface and the show ospf overview commands.
IN THIS SECTION
Requirements | 260
Overview | 261
Configuration | 261
Verification | 263
This example shows how to enable MD5 authentication for OSPFv2 exchanges.
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.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
261
Overview
IN THIS SECTION
Topology | 261
MD5 authentication uses an encoded MD5 checksum that is included in the transmitted packet. The
receiving routing device uses an authentication key (password) to verify the packet.
You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts
routing updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing
device only accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that
interface.
In this example, you create the backbone area (area 0.0.0.0), specify OSPFv2 interface so-0/2/0, set the
authentication type to md5, and then define the authentication key ID as 5 and the password as
PssWd8.
Topology
Configuration
IN THIS SECTION
Procedure | 262
Results | 262
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
262
Procedure
Step-by-Step Procedure
[edit]
user@host# edit protocols ospf area 0.0.0.0
NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices.
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
263
NOTE: After you configure the password, you do not see the password itself. The output displays
the encrypted form of the password you configured.
Verification
IN THIS SECTION
Purpose
Verify that the authentication method for sending and receiving OSPF protocol packets is configured.
When configured for MD5 authentication, the Authentication Type field displays MD5, the Active key
ID field displays the unique number you entered that identifies the MD5 key, and the Start time field
displays the date as Start time 1970 Jan 01 00:00:00 PST. Do not be alarmed by this start time. This is
the default start time that the routing device displays if the MD5 key is effective immediately.
Action
From operational mode, enter the show ospf interface and the show ospf overview commands.
264
IN THIS SECTION
Requirements | 264
Overview | 264
Configuration | 265
Verification | 268
This example shows how to configure a transition of MD5 keys on an OSPFv2 interface.
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.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 265
265
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.
You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts
routing updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing
device only accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that
interface.
For increased security, you can configure multiple MD5 keys, each with a unique key ID, and set the
date and time to switch to a new key. The receiver of the OSPF packet uses the ID to determine which
key to use for authentication.
In this example, you configure new keys to take effect at 12:01 AM on the first day of the next three
months on OSPFv2 interface fe-0/0/1 in the backbone area (area 0.0.0.0), and you configure the
following MD5 authentication settings:
• md5—Specifies the MD5 authentication key ID. The key ID can be set to any value between 0 and
255, with a default value of 0. The routing device only accepts OSPFv2 packets sent using the same
key ID that is defined for that interface.
• key—Specifies the MD5 key. Each key can be a value from 1 through 16 characters long. Characters
can include ASCII strings. If you include spaces, enclose all characters in quotation marks (“ “).
• start-time—Specifies the time to start using the MD5 key. This option enables you to configure a
smooth transition mechanism for multiple keys. The start time is relevant for transmission but not for
receiving OSPF packets.
NOTE: You must set the same passwords and transition dates and times on all devices in the area
so that OSPFv2 adjacencies remain active.
Topology
Configuration
IN THIS SECTION
Procedure | 266
Results | 267
266
To quickly configure multiple MD5 keys on an OSPFv2 interface, copy the following commands, remove
any line breaks, and then paste the commands into the CLI.
[edit]
set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 1 key $2010HaL
set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 2 key NeWpsswdFEB start-
time 2011-02-01.00:01
set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 3 key NeWpsswdMAR start-
time 2011-03-01.00:01
set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 4 key NeWpsswdAPR start-
time 2011-04-01.00:01
Procedure
Step-by-Step Procedure
[edit]
user@host# edit protocols ospf area 0.0.0.0
3. Configure MD5 authentication and set an authentication password and key ID.
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.
267
NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices.
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
NOTE: After you configure the password, you do not see the password itself. The output displays
the encrypted form of the password you configured.
Verification
IN THIS SECTION
Purpose
Verify that the authentication method for sending and receiving OSPF protocol packets is configured.
When configured for MD5 authentication with a transition of keys, the Auth type field displays MD5,
the Active key ID field displays the unique number you entered that identifies the MD5 key, and the
Start time field displays the time at which the routing device starts using an MD5 key to authenticate
OSPF packets transmitted on the interface you configured.
Action
From operational mode, enter the show ospf interface and the show ospf overview commands.
269
IN THIS SECTION
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.
IN THIS SECTION
Requirements | 271
Overview | 271
271
Configuration | 274
Verification | 278
This example shows how to enable IP Security (IPsec) authentication for an OSPF interface.
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.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 274
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.
272
NOTE: You can configure IPsec authentication together with either MD5 or simple
authentication.
• For an OSPFv2 interface, include the ipsec-sa name statement for a specific interface:
• For a remote sham link, include the ispec-sa name statement for the remote end point of the sham link:
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:
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.
• For an OSPFv3 interface, include the ipsec-sa name statement for a specific interface:
• For a virtual link, include the ipsec-sa name statement for a specific virtual link:
1. Configure IPsec authentication. To do this, define a manual SA named sa1 and specify the processing
direction, the protocol used to protect IP traffic, the security parameter index (SPI), and the
authentication algorithm and key.
a. Configure the following option at the [edit security ipsec security-association sa-name mode] hierarchy
level:
transport—Specifies transport mode. This mode protects traffic when the communication
endpoint and the cryptographic endpoint are the same. The data portion of the IP packet is
encrypted, but the IP header is not.
b. Configure the following option at the [edit security ipsec security-association sa-name manual
direction] hierarchy level:
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.
274
Topology
Configuration
IN THIS SECTION
To quickly configure a manual SA to be used for IPsec authentication on an OSPF interface, copy the
following commands, remove any line breaks, and then paste the commands into the CLI.
[edit]
set security ipsec security-association sa1
set security ipsec security-association sa1 mode transport
set security ipsec security-association sa1 manual direction bidirectional
set security ipsec security-association sa1 manual direction bidirectional protocol ah
set security ipsec security-association sa1 manual direction bidirectional spi 256
set security ipsec security-association sa1 manual direction bidirectional authentication
algorithm hmac-md5-96 key ascii-text 123456789012abcd
Step-by-Step Procedure
[edit]
user@host# edit security ipsec security-association sa1
275
NOTE: Repeat this entire configuration on all peer OSPF routing devices.
276
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.
NOTE: After you configure the password, you do not see the password itself. The output displays
the encrypted form of the password you configured.
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
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf area 0.0.0.0
NOTE: Repeat this entire configuration on all peer OSPF routing devices.
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
}
}
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
Purpose
Verify the configured IPsec security association settings. Verify the following information:
• The Security association field displays the name of the configured security association.
Action
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.
279
Action
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
SEE ALSO
Release Description
22.4R1
7 CHAPTER
IN THIS SECTION
Installing Routes from OSPF Routing Instances into the OSPF Routing Table Group | 283
IN THIS SECTION
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.
• OSPFv2—Forwarding, Layer 2 virtual private network (VPN), nonforwarding, VPN routing and
forwarding (VRF), virtual router, and virtual private LAN service (VPLS).
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.
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.
To configure a routing instance for OSPFv3, you must include at least the following statements in the
configuration:
[edit]
routing-instances {
routing-instance-name {
interface interface-name;
instance-type (no-forwarding | virtual-router | vrf);
283
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 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:
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.
284
IN THIS SECTION
Requirements | 284
Overview | 284
Configuration | 287
Verification | 293
Requirements
Before you begin:
• Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
Overview
IN THIS SECTION
Topology | 286
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.
285
2. Configure an OSPFv2 or OSPFv3 routing instance for each additional OSPFv2 or OSPFv3 routing
entity, configuring the following:
• Interfaces
• Routing options
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 286 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.
286
Topology
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.
287
Configuration
IN THIS SECTION
Procedure | 287
Procedure
To quickly configure multiple routing instances of 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.
Configuration on Device 1:
[edit]
set routing-instances voice-policy interface so-2/2/2
set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface
so-2/2/2
set routing-instances other-policy interface so-4/2/2
set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface
so-4/2/2
set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.0
other-policy.inet.0 ]
set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 ]
set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0 inet.0 ]
set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-2/2/2
set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-4/2/2
Configuration on Device 3:
[edit]
set routing-instances voice-policy interface so-3/2/2
set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface
so-3/2/2
set routing-instances other-policy interface so-5/2/2
288
set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface
so-5/2/2
set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.0
other-policy.inet.0 ]
set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 ]
set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0 inet.0 ]
set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-3/2/2
set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-5/2/2
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit routing-instances protocols]
hierarchy level.
[edit]
user@D1# set routing-instances voice-policy interface so-2/2/2
user@D1# set routing-instances voice-policy protocols ospf rib-group voice-to-inet area
0.0.0.0 interface so-2/2/2
user@D1# set routing-instances other-policy interface so-4/2/2
user@D1# set routing-instances other-policy protocols ospf rib-group other-to-inet area
0.0.0.0 interface so-4/2/2
[edit]
user@D3# set routing-instances voice-policy interface so-3/2/2
user@D3# set routing-instances voice-policy protocols ospf rib-group voice-to-inet area
0.0.0.0 interface so-3/2/2
user@D3#set routing-instances other-policy interface so-5/2/2
user@D3# set routing-instances other-policy protocols ospf rib-group other-to-inet area
0.0.0.0 interface so-5/2/2
289
2. Configure the routing table group inet-to-voice-and-other to take routes from inet.0 (default routing
table) and place them in the voice-policy.inet.0 and other-policy.inet.0 routing tables.
[edit]
user@D1# set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-
policy.inet.0 other-policy.inet.0 ]
[edit]
user@D3# set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-
policy.inet.0 other-policy.inet.0 ]
3. Configure the routing table group voice-to-inet to take routes from voice-policy.inet.0 and place
them in the inet.0 default routing table.
[edit]
user@D1# set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0
inet.0 ]
[edit]
user@D3# set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0
inet.0 ]
4. Configure the routing table group other-to-inet to take routes from other-policy.inet.0 and place
them in the inet.0 default routing table.
[edit]
user@D1# set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0
inet.0 ]
[edit]
user@D3# set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.0
inet.0 ]
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
user@D1# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-4/2/2
[edit]
user@D3# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-3/2/2
user@D3# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-5/2/2
[edit]
user@host# commit
Results
Confirm your configuration by entering the show routing-instances, show routing-options, and show protocols
ospf commands. If the output does not display the intended configuration, repeat the instructions in this
example to correct the configuration.
Configuration on Device 1:
other-policy {
interface so-4/2/2.0;
protocols {
ospf {
rib-group other-to-inet;
area 0.0.0.0 {
interface so-4/2/2.0;
}
}
}
}
Configuration on Device 3:
rib-group voice-to-inet;
area 0.0.0.0 {
interface so-3/2/2.0;
}
}
}
}
other-policy {
interface so-5/2/2.0;
protocols {
ospf {
rib-group other-to-inet;
area 0.0.0.0 {
interface so-5/2/2.0;
}
}
}
}
To confirm your OSPFv3 configuration, enter the show routing-instances, show routing-options, and show
protocols ospf3 commands.
Verification
IN THIS SECTION
Purpose
Action
From operational mode, enter the show route instance detail command.
SEE ALSO
RELATED DOCUMENTATION
IN THIS SECTION
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).
• 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).
NOTE: For EX Series and QFX Series switches, the hello interval is 10 seconds or longer.
• 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.
296
• LSA retransmission interval—When a routing device sends LSAs to its neighbors, the routing device
expects to receive an acknowledgment packet from each neighbor within a certain amount of time.
The LSA retransmission interval specifies the length of time, in seconds, that the routing device waits
to receive an LSA packet before retransmitting the LSA to an interface’s neighbors. By default, the
routing device waits 5 seconds for an acknowledgment before retransmitting the LSA.
• Dead interval—If a routing device does not receive a hello packet from a neighbor within a fixed
amount of time, the routing device modifies its topology database to indicate that the neighbor is
nonoperational. The dead interval specifies the length of time, in seconds, that the routing device
waits before declaring that a neighboring routing device is unavailable. This is an interval during
which the routing device receives no hello packets from the neighbor. This interval must be the same
on all routing devices on a shared network. By default, this interval is four times the default hello
interval, which is 40 seconds (broadcast and point-to-point networks) and 120 seconds (NBMA
networks).
• Transit delay—Before a link-state update packet is propagated out of an interface, the routing device
must increase the age of the packet. The transit delay sets the estimated time required to transmit a
link-state update on the interface. By default, the transit delay is 1 second. You should never have to
modify the transit delay time.
SEE ALSO
IN THIS SECTION
Requirements | 297
Overview | 297
Configuration | 298
Verification | 304
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
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
• Transit delay
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.
298
NOTE: For EX Series and QFX Series switches, the hello interval is 10 seconds or longer.
• 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.
The link-state advertisement (LSA) retransmission interval optimizes the sending and receiving of LSA
and acknowledgement packets. You must configure the LSA retransmission interval to be equal to or
greater than 3 seconds to avoid triggering a retransmit trap because the Junos OS delays LSA
acknowledgments by up to 2 seconds. If you have a virtual link, you might find increased performance
by increasing the value of the LSA retransmission interval.
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
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
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf area 0.0.0.0
NOTE: Repeat this entire configuration on all routing devices in a shared network.
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
301
To quickly configure the LSA retransmission interval, 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 fe-0/0/1 retransmit-interval 8
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf area 0.0.0.1
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
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
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 fe-1/0/1 transit-delay 2
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf area 0.0.0.1
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
304
Verification
IN THIS SECTION
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.
RELATED DOCUMENTATION
IN THIS SECTION
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: EX4600 switches do not support minimum interval values of less than 1 second.
NOTE: BFD is supported for OSPFv3 in Junos OS Release 9.3 and later.
307
NOTE: For branch SRX Series Firewalls, we recommend 1000 ms as the minimum keepalive time
interval for BFD packets.
• 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, the following may 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 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
interval of 100 ms.
• For distributed BFD sessions with NSR configured, the minimum interval
recommendations are unchanged and depend only on your network deployment.
308
• Junos OS 21.2R1 and later support distributed OSPFv3 and ISIS BFD sessions with IPv6
link local addresses on MX series routers running MPCs 1 through 9 (it is not supported on
MPC 10 or MPC 11). The default for IPv6 link local BFD is inline mode.
• BFD is not distributed prior to Junos 21.2 (because for OSPFv3, BFD is based in the
Routing Engine).
• 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 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.
IN THIS SECTION
Requirements | 309
Overview | 309
Configuration | 311
Verification | 313
This example shows how to configure the Bidirectional Forwarding Detection (BFD) protocol for OSPF.
Requirements
Before you begin:
• Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58.
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 311
310
An alternative to adjusting the OSPF hello interval and dead interval settings to increase route
convergence is to configure BFD. The BFD protocol is a simple hello mechanism that detects failures in a
network. The BFD failure detection timers have shorter timer limits than the OSPF failure detection
mechanisms, thereby providing faster detection.
BFD is useful on interfaces that are unable to detect failure quickly, such as Ethernet interfaces. Other
interfaces, such as SONET interfaces, already have built-in failure detection. Configuring BFD on those
interfaces is unnecessary.
You configure BFD on a pair of neighboring OSPF interfaces. Unlike the OSPF hello interval and dead
interval settings, you do not have to enable BFD on all interfaces in an OSPF area.
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:
311
• 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 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 | 311
Procedure
To quickly configure the BFD protocol for 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
312
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 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
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf area 0.0.0.0
4. Configure the number of missed hello packets that cause the originating interface to be declared
down.
5. Configure BFD sessions only for OSPF neighbors with full neighbor adjacency.
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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 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.
IN THIS SECTION
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
315
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:
• 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.
• 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.
316
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.
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.
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.
317
IN THIS SECTION
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:
[edit]
user@host# set protocols ospf area 0.0.0.1 interface if2-ospf bfd-liveness-detection
authentication algorithm keyed-sha-1
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.
318
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.
• At least one key, a unique integer between 0 and 63. Creating multiple keys enables multiple
clients to use the BFD 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
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.
319
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.
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.
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.
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.
RELATED DOCUMENTATION
bfd-liveness-detection
Junos OS Administration Library for Routing Devices
CLI Explorer
Example: Configuring BFD Authentication for OSPF
10 CHAPTER
IN THIS SECTION
Example: Configuring the Helper Capability Mode for OSPFv2 Graceful Restart | 332
Example: Configuring the Helper Capability Mode for OSPFv3 Graceful Restart | 338
Example: Disabling Strict LSA Checking for OSPF Graceful Restart | 343
IN THIS SECTION
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.
324
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.
325
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.
IN THIS SECTION
Requirements | 325
Overview | 326
Configuration | 327
Verification | 331
This example shows how to configure graceful restart specifically for OSPF.
Requirements
Before you begin:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58.
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
326
Overview
IN THIS SECTION
Topology | 326
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
327
Configuration
IN THIS SECTION
To quickly enable graceful restart for OSPF, copy the following commands and paste them into the CLI.
[edit]
set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4
set interfaces fe-1/1/2 unit 0 family inet address 10.0.0.5
set protocols ospf area 0.0.0.0 interface fe-1/1/1
set protocols ospf area 0.0.0.0 interface fe-1/1/2
set routing-options graceful-restart
set protocols ospf graceful-restart restart-duration 190
set protocols ospf graceful-restart notify-duration 40
Step-by-Step Procedure
[edit]
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.5
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/1
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/2
[edit]
user@host#edit routing-options graceful-restart
[edit]
user@host# edit protocols ospf graceful-restart
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.
To confirm an OSPFv3 configuration, enter the show interfaces and the show protocols ospf3 commands.
To quickly disable graceful restart for 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
330
paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration
mode.
[edit]
user@host# set protocols ospf graceful-restart disable
Step-by-Step Procedure
This command does not affect the global graceful restart configuration setting.
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# set protocols ospf graceful-restart disable
[edit]
user@host# commit
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
Verification
IN THIS SECTION
Purpose
Action
From operational mode, enter the show ospf overview command for OSPFv2. Enter the show ospf3 overview
command for OSPFv3.
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.
Purpose
Action
From operational mode, enter the show route instance detail command.
332
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.
IN THIS SECTION
Requirements | 332
Overview | 333
Configuration | 333
Verification | 337
This example shows how to disable and reenable the helper mode capability for OSPFv2 graceful
restart.
Requirements
Before you begin:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
333
Overview
IN THIS SECTION
Topology | 333
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
To quickly enable graceful restart for OSPFv2 with helper mode disabled, copy the following commands
and paste them into the CLI.
[edit]
set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4
set interfaces fe-1/1/2 unit 0 family inet address 10.0.0.5
set protocols ospf area 0.0.0.0 interface fe-1/1/1
set protocols ospf area 0.0.0.0 interface fe-1/1/2
set protocols ospf graceful-restart helper-disable standard
Step-by-Step Procedure
[edit]
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.5
[edit]
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/1
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/2
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
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.
interface fe-1/1/2.0;
}
To quickly reenable standard helper-mode for OSPFv2, 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]
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.
Step-by-Step Procedure
[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.
337
Verification
IN THIS SECTION
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
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
From operational mode, enter the show route instance detail command.
338
IN THIS SECTION
Requirements | 338
Overview | 338
Configuration | 339
Verification | 342
This example shows how to disable and reenable the helper mode capability for OSPFv3 graceful
restart.
Requirements
Before you begin:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 339
339
The OSPF graceful restart helper capability assists a neighboring routing device attempting a graceful
restart. By default, the helper capability is globally enabled when you start the routing platform. This
means that the helper capability is enabled when you start OSPF, even if graceful restart is not globally
enabled or specifically enabled for OSPF. You can further modify your graceful restart configuration to
disable the helper capability.
In the first example, interfaces fe-1/1/1 and fe-1/1/2 are in OSPFv3 area 0.0.0.0, and you configure
those interfaces for graceful restart. You then disable the OSPFv3 graceful restart helper capability by
including the helper-disable statement.
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 OSPFv3 restart helper capability that you disabled in
the first example.
Topology
Configuration
IN THIS SECTION
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 area 0.0.0.0 interface fe-1/1/1
340
Step-by-Step Procedure
[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::
[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
[edit]
user@host# set protocols ospf3 graceful-restart helper-disable
[edit]
user@host# commit
341
Results
Confirm your configuration by entering the show interfaces and the show protocols ospf3 commands. If the
output does not display the intended configuration, repeat the instructions in this example to correct
the configuration.
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
342
Step-by-Step Procedure
[edit]
user@host# delete protocols ospf3 graceful-restart helper-disable
[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
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.
343
Action
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
From operational mode, enter the show route instance detail command.
IN THIS SECTION
Requirements | 343
Overview | 344
Configuration | 344
Verification | 347
This example shows how to disable strict link-state advertisement (LSA) checking for OSPF graceful
restart.
Requirements
Before you begin:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
344
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 344
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.
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.
Topology
Configuration
IN THIS SECTION
Procedure | 345
345
Procedure
To quickly enable graceful restart for OSPF with strict LSA checking disabled, copy the following
commands and paste them into the CLI.
[edit]
set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4
set interfaces fe-1/1/2 unit 0 family inet address 10.0.0.5
set protocols ospf area 0.0.0.0 interface fe-1/1/1
set protocols ospf area 0.0.0.0 interface fe-1/1/2
set protocols ospf graceful-restart no-strict-lsa-checking
Step-by-Step Procedure
To enable graceful restart for OSPF with strict LSA checking disabled:
[edit]
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.5
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/1
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/2
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
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.
interface fe-1/1/2.0;
}
To confirm your OSPFv3 configuration, enter the show interfaces and the show protocols ospf3 commands.
Verification
IN THIS SECTION
Purpose
Verify information about your OSPF graceful restart configuration. The Restart field displays the status
of graceful restart as either enabled or disabled.
Action
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3
overview command for OSPFv3.
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.
348
Action
From operational mode, enter the show route instance detail command.
RELATED DOCUMENTATION
IN THIS SECTION
Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network | 389
Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks | 391
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.
The following topology explains the deployment case where per prefix LFA feature is applicable.
351
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}.
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
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.
352
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.
• Configure the per-prefix-calculation configuration statement at the [edit protocols (ospf | ospf3) backup-
spf-options] hierarchy level.
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:
• 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.
353
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.
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.
• Logical systems
• Include the link-protection statement at the [edit protocols (ospf | ospf3) area area-id interface
interface-name] hierarchy level.
354
BEST PRACTICE: When you configure link protection for OSPF, you must also configure a
per-packet load-balancing routing policy to ensure that the routing protocol process installs
all the next hops for a given route in the routing table.
In the following example, the OSPF interface so-0/0/0.0 in area 0.0.0.0 is configured for link protection.
If a link for a destination route that traverses this interface becomes unavailable, Junos OS creates a
loop-free backup path through another interface on the neighboring node, thus avoiding the link that is
no longer available.
[edit]
protocols {
ospf {
area 0.0.0.0 {
interface so-0/0/0.0 {
link-protection;
}
}
}
}
SEE ALSO
link-protection
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.
• Logical systems
• Include the node-link-protection statement at the [edit protocols (ospf | ospf3) area area-id interface
interface-name] hierarchy level.
BEST PRACTICE: You must also configure a per-packet load-balancing routing policy to
ensure that the routing protocol process installs all the next hops for a given route in the
routing table.
In the following example, the OSPF interface so-0/0/0.0 in area 0.0.0.0 is configured for node-link
protection. If a link for a destination route that traverses this interface becomes unavailable, Junos OS
creates a loop-free backup path through a different routing device altogether, thus avoiding the primary
next-hop routing device.
[edit]
protocols {
ospf {
area 0.0.0.0 {
interface so-0/0/0.0 {
node-link-protection;
}
}
}
}
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.
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
356
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.
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).
• Include the node-link-degradation statement at the [edit protocols (ospf | ospf3) backup-spf-options]
hierarchy level.
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.
• Include the no-eligible-backup statement at the [edit protocols (ospf | ospf3) area area-id interface
interface-name] hierarchy level.
In the following example, interface so-0/0/0.0 has been configured to prohibit backup traffic for traffic
destined for a protected interface. This means that if a neighboring next-hop path or node for a
protected interface fails, interface so-0/0/0.0 cannot be used to transmit traffic to a backup path.
[edit]
protocols {
ospf {
area 0.0.0.0 {
interface so-0/0/0.0 {
no-eligible-backup;
}
}
}
}
357
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.
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.
358
In the following example, backup next hops for the OSPF topology voice are not installed in the routing
table or forwarding table. Any calculated backup next hops for other OSPF instances or topologies
continue to be installed.
[edit]
protocols {
ospf {
topology voice {
backup-spf-options {
no-install;
}
}
}
}
You can limit the calculation of backup next hops to downstream paths, as defined in RFC 5286. You can
specify for Junos OS to use only downstream paths as backup next hops for protected interfaces for an
OSPF instance or a specific topology in an OSPF instance. In a downstream path, the distance from the
backup neighbor to the destination must be smaller than the distance from the calculating routing
device to the destination. Using only downstream paths as loop-free alternate paths for protected
interfaces ensures that these paths do not result in microloops. However, you might experience less
than optimal backup coverage for your network.
• Include the downstream-paths-only statement at the [edit protocols (ospf | ospf3) backup-spf-options] or
[edit protocols ospf backup-spf-options topology topology-name] hierarchy level.
In the following example, only downstream paths are calculated as backup next hops for the topology
voice:
[edit]
protocols {
ospf {
topology voice {
backup-spf-options {
downstream-paths-only;
}
}
}
}
359
SEE ALSO
backup-spf-options
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.
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;
}
}
}
360
IN THIS SECTION
Requirements | 360
Overview | 360
Configuration | 361
Verification | 373
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
No special configuration beyond device initialization is required before configuring this example.
Overview
IN THIS SECTION
Topology | 361
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.
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.
361
Topology
"CLI Quick Configuration" on page 361 shows the configuration for all of the devices in Figure 22 on
page 361.
The section "No Link Title" on page 367 describes the steps on Device R1.
Configuration
IN THIS SECTION
Procedure | 367
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
362
Device R1
Device R2
Device R3
Device R4
Device R5
Device R6
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
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
368
3. Enable MPLS on the interfaces, and configure backup LSPs to Device R3.
8. Configure the routing protocol process (rpd) to request an acknowledgement when creating a new
forwarding next hop.
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.
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 {
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;
}
}
371
}
}
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;
}
}
If you are done configuring the device, enter commit from configuration mode.
373
Verification
IN THIS SECTION
Purpose
Action
Meaning
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
Node Coverage:
Route Coverage:
Node Coverage:
Route Coverage:
Purpose
On Device R1, use the show (ospf | ospf3) backup lsp command to check LSPs designated as backup routes
for OSPF routes.
Action
path1
Egress: 10.255.164.3, Status: up, Last change: 01:13:48
TE-metric: 19, Metric: 0
path2
Egress: 10.255.164.3, Status: up, Last change: 01:13:48
TE-metric: 19, Metric: 0
378
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
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
Neighbor to Self Metric: 10
Self to Neighbor Metric: 10
Direct next-hop: so-0/2/2.0 via 192.168.242.2
Direct next-hop: t1-0/1/2.0 via 192.168.241.2
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
379
10.255.164.2
Neighbor to Self Metric: 10
Self to Neighbor Metric: 10
Direct next-hop: so-0/2/2.0 via 192.168.242.2
Direct next-hop: t1-0/1/2.0 via 192.168.241.2
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
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
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
380
192.168.241.18
Self to Destination Metric: 10
Parent Node: 10.255.164.1
Primary next-hop: t1-0/1/0.0
Backup next-hop: so-0/2/0.0 via 192.168.242.18
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 30, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Track Item: 10.255.164.1
Track Item: 10.255.164.2
Track Item: 10.255.164.4
Not eligible, Reason: Path loops
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Eligible, Reason: Contributes backup next-hop
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Track Item: 10.255.164.1
Not evaluated, Reason: Interface is already covered
192.168.242.2
Self to Destination Metric: 10
Parent Node: 10.255.164.1
Primary next-hop: so-0/2/2.0
Backup next-hop: path2
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
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Interface is already covered
381
192.168.242.18
Self to Destination Metric: 10
Parent Node: 10.255.164.1
Primary next-hop: so-0/2/0.0
Backup next-hop: t1-0/1/0.0 via 192.168.241.18
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 30, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Track Item: 10.255.164.1
Track Item: 10.255.164.2
Track Item: 10.255.164.4
Not eligible, Reason: Path loops
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Eligible, Reason: Contributes backup next-hop
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Track Item: 10.255.164.1
Not evaluated, Reason: Interface is already covered
10.255.164.2
Self to Destination Metric: 10
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
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Track Item: 10.255.164.2
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 0, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
382
10.255.164.4
Self to Destination Metric: 10
Parent Node: 192.168.241.18
Parent Node: 192.168.242.18
Primary next-hop: so-0/2/0.0 via 192.168.242.18
Primary next-hop: t1-0/1/0.0 via 192.168.241.18
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.4
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 0, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Track Item: 10.255.164.1
Track Item: 10.255.164.4
Not evaluated, Reason: Primary next-hop multipath
192.168.241.10
Self to Destination Metric: 20
Parent Node: 10.255.164.4
Primary next-hop: so-0/2/0.0 via 192.168.242.18
Primary next-hop: t1-0/1/0.0 via 192.168.241.18
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
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
383
192.168.242.6
Self to Destination Metric: 20
Parent Node: 10.255.164.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
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 30, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Track Item: 10.255.164.1
Track Item: 10.255.164.2
Not evaluated, Reason: Primary next-hop multipath
192.168.242.10
Self to Destination Metric: 20
Parent Node: 10.255.164.4
Primary next-hop: so-0/2/0.0 via 192.168.242.18
Primary next-hop: t1-0/1/0.0 via 192.168.241.18
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
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
192.168.242.22
384
10.255.164.3
Self to Destination Metric: 20
Parent Node: 192.168.242.6
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
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 0, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
10.255.164.5
Self to Destination Metric: 20
Parent Node: 192.168.241.10
Parent Node: 192.168.242.10
Parent Node: 192.168.242.22
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
385
192.168.242.14
Self to Destination Metric: 25
Parent Node: 10.255.164.5
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
Primary next-hop: so-0/2/0.0 via 192.168.242.18
Primary next-hop: t1-0/1/0.0 via 192.168.241.18
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 15, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 15, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
192.168.242.26
Self to Destination Metric: 25
Parent Node: 10.255.164.3
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
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 5, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
386
10.255.164.6
Self to Destination Metric: 25
Parent Node: 192.168.242.14
Parent Node: 192.168.242.26
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
Primary next-hop: so-0/2/0.0 via 192.168.242.18
Primary next-hop: t1-0/1/0.0 via 192.168.241.18
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 5, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 15, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 15, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
192.168.241.14
Self to Destination Metric: 30
Parent Node: 10.255.164.5
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
Primary next-hop: so-0/2/0.0 via 192.168.242.18
Primary next-hop: t1-0/1/0.0 via 192.168.241.18
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 15, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
387
192.168.241.26
Self to Destination Metric: 30
Parent Node: 10.255.164.3
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
Backup Neighbor: 10.255.164.3 (LSP endpoint)
Neighbor to Destination Metric: 10, Neighbor to Self Metric: 20
Self to Neighbor Metric: 20, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.2
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
Backup Neighbor: 10.255.164.4
Neighbor to Destination Metric: 25, Neighbor to Self Metric: 10
Self to Neighbor Metric: 10, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath
SEE ALSO
Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data
Traffic
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.
388
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:
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:
389
• 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.
SEE ALSO
auto-targeted-session
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:
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.
1. Enable remote LFA backup to determine the backup next hop using dynamic LDP label-switched
path.
2. Enable automatically targeted LDP sessions using the loopback addresses between the PLR and the
remote LFA node.
3. Specify a time interval for which the targeted LDP sessions are kept up even after the remote LFA
node goes down.
4. Specify the maximum number of automatically targeted LDP sessions to optimize memory usage.
SEE ALSO
auto-targeted-session
backup-spf-options
391
IN THIS SECTION
Requirements | 391
Overview | 392
Configuration | 393
Verification | 403
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.
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).
392
Overview
IN THIS SECTION
Topology | 392
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.
Topology
In the topology Figure 23 on page 393 shows the remote LFA over LDP tunnels in OSPF networks is
configured on Device R6.
393
Configuration
IN THIS SECTION
Results | 401
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.
394
R0
R1
R2
R3
R4
R5
R6
R7
R8
Configuring Device R6
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
[edit interfaces]
user@R6# set ge-0/0/0 unit 0 family inet address 10.60.1.2/24
user@R6# set ge-0/0/0 unit 0 family mpls
user@R6# set ge-0/0/1 unit 0 family inet address 10.70.1.1/24
user@R6# set ge-0/0/1 unit 0 family mpls
user@R6# set ge-0/0/2 unit 0 family inet address 10.80.1.2/24
user@R6# set ge-0/0/2 unit 0 family mpls
400
3. Configure the router ID. Apply the policy to the forwarding table of the local router with the export
statement.
[edit routing-options]
user@R6# set router-id 10.7.7.7
user@R6# set forwarding-table export per-packet
4. Enable remote LFA backup which calculates the backup next hop using dynamic LDP label-switched
path.
5. Configure the traffic engineering and the link protection for the interfaces in the OSPF area.
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.
8. Configure the policy options to load balance the per-packet of the policy-statement routing policy.
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.
address 10.80.1.2/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.7.7.7/32;
}
family mpls;
}
}
teardown-delay 20;
maximum-sessions 60;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface lo0.0;
}
If you are done configuring the device, enter commit from the configuration mode.
Verification
IN THIS SECTION
Purpose
Action
On Device R6, from operational mode, run the show route 10.6.6.6/24 command to display the routes in
the routing table.
Task: LDP
Announcement bits (1): 0-Resolve tree 1
AS path: I
Meaning
The output shows all the routes in the routing table of Device R6.
Purpose
Action
From operational mode, enter the show ldp session auto-targeted detail command.
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.
ge-0/0/2.0 10.80.1.1
10.5.5.5/32 Intra Network IP 2 ge-0/0/0.0 10.60.1.1
Bkup LSP LDP->10.4.4.4
10.6.6.6/32 Intra Network IP 1 ge-0/0/0.0 10.60.1.1
Bkup LSP LDP->10.4.4.4
10.7.7.7/32 Intra Network IP 0 lo0.0
10.8.8.8/32 Intra Network IP 1 ge-0/0/1.0 10.70.1.2
10.9.9.9/32 Intra Network IP 2 ge-0/0/2.0 10.80.1.1
Bkup LSP LDP->10.4.4.4
10.1.1.0/24 Intra Network IP 2 ge-0/0/2.0 10.80.1.1
Bkup LSP LDP->10.4.4.4
10.20.1.0/24 Intra Network IP 2 ge-0/0/2.0 10.80.1.1
Bkup LSP LDP->10.4.4.4
10.30.1.0/24 Intra Network IP 3 ge-0/0/2.0 10.80.1.1
Bkup IP ge-0/0/0.0 10.60.1.1
10.40.1.0/24 Intra Network IP 3 ge-0/0/0.0 10.60.1.1
Bkup IP ge-0/0/2.0 10.80.1.1
10.50.1.0/24 Intra Network IP 2 ge-0/0/0.0 10.60.1.1
Bkup LSP LDP->10.4.4.4
10.60.1.0/24 Intra Network IP 1 ge-0/0/0.0
10.70.1.0/24 Intra Network IP 1 ge-0/0/1.0
10.80.1.0/24 Intra Network IP 1 ge-0/0/2.0
90.1.1.0/24 Intra Network IP 3 ge-0/0/2.0 10.80.1.1
Bkup LSP LDP->10.4.4.4
10.100.1.0/24 Intra Network IP 2 ge-0/0/2.0 10.80.1.1
Bkup LSP LDP->10.4.4.4
10.110.1.0/24 Intra Network IP 3 ge-0/0/2.0 10.80.1.1
Bkup LSP LDP->10.4.4.4
Meaning
The output shows all the LDP backup routes in the OSPF routing table of Device R6.
Purpose
Display the remote LFA next hop determined for a given destination.
409
Action
From operational mode, enter the show ospf backup spf results command.
10.6.6.6
Self to Destination Metric: 1
Parent Node: 10.60.1.2
Primary next-hop: ge-0/0/0.0 via 60.1.1.1
Backup next-hop: LDP->10.4.4.4 via ge-0/0/2.0
Backup Neighbor: 10.6.6.6 via: Direct
Neighbor to Destination Metric: 0, Neighbor to Self Metric: 1
Self to Neighbor Metric: 1, Backup preference: 0x0
Not eligible, Reason: Primary next-hop link fate sharing
Backup Neighbor: 10.2.2.2 via: Direct
Neighbor to Destination Metric: 2, Neighbor to Self Metric: 1
Self to Neighbor Metric: 1, Backup preference: 0x0
Not eligible, Reason: Path loops
Backup Neighbor: 10.8.8.8 via: Direct
Neighbor to Destination Metric: 2, Neighbor to Self Metric: 1
Self to Neighbor Metric: 1, Backup preference: 0x0
Not eligible, Reason: Path loops
Backup Neighbor: 10.4.4.4 via: LDP (LSP endpoint)
Neighbor to Destination Metric: 2, Neighbor to Self Metric: 3
Self to Neighbor Metric: 3, Backup preference: 0x0
Eligible, Reason: Contributes backup next-hop
Meaning
The output indicates whether a specific interface or node has been designated as a remote backup path
and why.
410
Purpose
Action
From operational mode, enter the show ospf backup neighbor command.
Meaning
The output displays the backup neighbors available for area 0.0.0.0.
411
SEE ALSO
auto-targeted-session
12 CHAPTER
IN THIS SECTION
Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface | 424
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:
414
• 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.
• 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
415
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.
IN THIS SECTION
Requirements | 415
Overview | 416
Configuration | 416
Verification | 422
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 the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure BGP per your network requirements. See the BGP User Guide
• Configure MPLS per your network requirements. See the MPLS Applications User Guide.
416
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 | 416
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 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.
417
Configuration on R1:
[edit]
set routing-options router-id 10.0.0.1
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
set protocols ospf traffic-engineering shortcuts lsp-metric-into-summary
set protocols mpls traffic-engineering bgp-igp
set protocols mpls label-switched-path R1-to-R4 to 10.0.0.4
Configuration on R2:
[edit]
set routing-options router-id 10.0.0.2
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
set protocols ospf traffic-engineering
Configuration on R3:
[edit]
set routing-options router-id 10.0.0.3
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
set protocols ospf traffic-engineering
Configuration on R4:
[edit]
set routing-options router-id 10.0.0.4
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
set protocols ospf traffic-engineering
Step-by-Step Procedure
To enable OSPF traffic engineering support to advertise LSP metrics in summary LSAs:
418
[edit]
user@R1# set routing-options router-id 10.0.0.1
[edit]
user@R2# set routing-options router-id 10.0.0.2
[edit]
user@R3# set routing-options router-id 10.0.0.3
[edit]
user@R4# set routing-options router-id 10.0.0.4
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@R1# set protocols ospf area 0.0.0.0 interface all
user@R1# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
[edit]
user@R2# set protocols ospf area 0.0.0.0 interface all
user@R2# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
[edit]
user@R3# set protocols ospf area 0.0.0.0 interface all
user@R3# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
[edit]
user@R4# set protocols ospf area 0.0.0.0 interface all
user@R4# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
420
[edit]
user@R1# set protocols ospf traffic-engineering shortcuts lsp-metric-into-summary
[edit]
user@R2# set protocols ospf traffic-engineering
[edit]
user@R3# set protocols ospf traffic-engineering
[edit]
user@R4# set protocols ospf traffic-engineering
[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 instructions in this
example to correct the configuration.
421
To confirm your OSPFv3 configuration, enter the show routing-options, show protocols ospf3, and show
protocols mpls commands.
Verification
IN THIS SECTION
Verifying That the Traffic Engineering Database Is Learning Node Information from OSPF | 423
Purpose
Verify that traffic engineering has been enabled for OSPF. By default, traffic engineering is disabled.
Action
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3
overview for OSPFv3.
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
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
IN THIS SECTION
Requirements | 424
Overview | 424
Configuration | 424
Verification | 426
This example shows how to configure the OSPF metric value used for traffic engineering.
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure OSPF for traffic engineering. See "Example: Enabling OSPF Traffic Engineering Support" on
page 415
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 | 425
425
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
Step-by-Step Procedure
To configure an OSPF traffic engineering metric for a specific interface used only for traffic engineering:
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf area 0.0.0.0
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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.
427
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.
IN THIS SECTION
Requirements | 427
Overview | 428
Configuration | 428
Verification | 430
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 the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure BGP per your network requirements. See the BGP User Guide.
• Configure the LSP per your network requirements. See the MPLS Applications User Guide.
428
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63.
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
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.
• 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 | 429
429
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
Procedure
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[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.
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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
From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show
ospf3 interface detail command for OSPFv3.
431
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:
2. Use the LSP metric configured for the label-switched path under MPLS.
3. If you do not configure any of the above, use the default OSPFv2 metric of 1.
NOTE: If you want an LSP that is announced into OSPFv2 to be used in SPF calculations, there
must be a reverse link (that is, a link from the tail end of the LSP to the head end). You can
accomplish this by configuring an LSP in the reverse direction and also announcing it in OSPFv2.
IN THIS SECTION
Requirements | 431
Overview | 432
Configuration | 434
Verification | 450
Requirements
Before you begin, configure the device interfaces. See the Junos OS Network Interfaces Library for
Routing Devices.
432
Overview
IN THIS SECTION
Topology | 433
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:
• 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.
433
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 434 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.
• 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.
Configuration
IN THIS SECTION
The following examples require you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Modifying the Junos OS Configuration in CLI User Guide.
To configure the devices to advertise an LSP into OSPFv2, perform the following tasks:
435
Configuring BGP
To quickly configure BGP on each routing device, copy the following commands and paste them into the
CLI.
[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 neighbor 10.0.0.6
set protocols bgp group internal-peers peer-as 65000
[edit]
set routing-options autonomous-system 65000
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 10.0.0.3
set protocols bgp group internal-peers neighbor 10.0.0.1
set protocols bgp group internal-peers neighbor 10.0.0.6
set protocols bgp group internal-peers peer-as 65000
[edit]
set routing-options autonomous-system 65000
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 10.0.0.6
set protocols bgp group internal-peers neighbor 10.0.0.1
set protocols bgp group internal-peers neighbor 10.0.0.3
set protocols bgp group internal-peers peer-as 65000
Step-by-Step Procedure
To configure BGP:
436
[edit]
user@R1# set routing-options autonomous-system 65000
[edit]
user@R3# set routing-options autonomous-system 65000
[edit]
user@R6# set routing-options autonomous-system 65000
[edit]
user@R1# set protocols bgp group internal-peers type internal
user@R1# set protocols bgp group internal-peers local-address 10.0.0.1
user@R1# set protocols bgp group internal-peers neighbor 10.0.0.3
user@R1# set protocols bgp group internal-peers neighbor 10.0.0.6
user@R1# set protocols bgp group internal-peers peer-as 65000
[edit]
user@R3# set protocols bgp group internal-peers type internal
user@R3# set protocols bgp group internal-peers local-address 10.0.0.3
user@R3# set protocols bgp group internal-peers neighbor 10.0.0.1
user@R3# set protocols bgp group internal-peers neighbor 10.0.0.6
user@R3# set protocols bgp group internal-peers peer-as 65000
[edit]
user@R6# set protocols bgp group internal-peers type internal
user@R6# set protocols bgp group internal-peers local-address 10.0.0.6
user@R6# set protocols bgp group internal-peers neighbor 10.0.0.1
user@R6# set protocols bgp group internal-peers neighbor 10.0.0.3
user@R6# set protocols bgp group internal-peers peer-as 65000
437
[edit]
user@host# commit
Results
Confirm your configuration by entering the show routing-options and show protocols bgp commands. If the
output does not display the intended configuration, repeat the instructions in this example to correct
the configuration.
Configuration on R1:
Configuration on R3:
neighbor 10.0.0.6;
}
Configuration on R6:
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.
[edit]
set interfaces so-0/0/2 unit 0 family mpls
set protocols mpls interface all
set protocols mpls interface fxp0.0 disable
[edit]
set interfaces so-0/0/2 unit 0 family mpls
set interfaces so-0/0/3 unit 0 family mpls
set protocols mpls interface all
set protocols mpls interface fxp0.0 disable
439
[edit]
set interfaces so-0/0/3 unit 0 family mpls
set protocols mpls interface all
set protocols mpls interface fxp0.0 disable
Step-by-Step Procedure
To configure MPLS:
[edit ]
user@R1# set interfaces so-0/0/2 unit 0 family mpls
[edit ]
user@R3# set interfaces so-0/0/2 unit 0 family mpls
user@R3# set interfaces so-0/0/3 unit 0 family mpls
[edit ]
user@R6# set interfaces so-0/0/3 unit 0 family mpls
2. Enable MPLS.
[edit ]
user@R1# set protocols mpls interface all
[edit ]
user@R3# set protocols mpls interface all
[edit ]
user@R6# set protocols mpls interface all
440
[edit ]
user@R1# set protocols mpls interface fxp0.0 disable
[edit ]
user@R3# set protocols mpls interface fxp0.0 disable
[edit ]
user@R6# set protocols mpls interface fxp0.0 disable
[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.
disable;
}
Configuring RSVP
To quickly configure RSVP on all of the routing devices in AS 65000, copy the following commands and
paste them into the CLI.
[edit]
set protocols rsvp interface so-0/0/2
set protocols rsvp interface fxp0.0 disable
[edit]
set protocols rsvp interface so-0/0/2
set protocols rsvp interface so-0/0/3
set protocols rsvp interface fxp0.0 disable
[edit]
set protocols rsvp interface so-0/0/3
set protocols rsvp interface fxp0.0 disable
Step-by-Step Procedure
To configure RSVP:
443
1. Enable RSVP.
[edit ]
user@R1# set protocols rsvp interface so-0/0/2
[edit ]
user@R3# set protocols rsvp interface so-0/0/2
user@R3# set protocols rsvp interface so-0/0/3
[edit ]
user@R6# set protocols rsvp interface so-0/0/3
[edit ]
user@R1# set protocols rsvp interface fxp0.0 disable
[edit ]
user@R3# set protocols rsvp interface fxp0.0 disable
[edit ]
user@R6# set protocols rsvp interface fxp0.0 disable
[edit]
user@host# commit
Results
Confirm your configuration by entering the show protocols rsvp command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
444
Configuring OSPF
To quickly configure OSPF, copy the following commands and paste them into the CLI.
[edit]
set routing-options router-id 10.0.0.1
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
445
[edit]
set routing-options router-id 10.0.0.3
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
[edit]
set routing-options router-id 10.0.0.6
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
Step-by-Step Procedure
To configure OSPF:
[edit]
user@R1# set routing-options router-id 10.0.0.1
[edit]
user@R3# set routing-options router-id 10.0.0.3
[edit]
user@R6# set routing-options router-id 10.0.0.6
446
[edit]
user@R1# set protocols ospf area 0.0.0.0 interface all
[edit]
user@R3# set protocols ospf area 0.0.0.0 interface all
[edit]
user@R6# set protocols ospf area 0.0.0.0 interface all
[edit]
user@R1# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
[edit]
user@R3# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
[edit]
user@R6# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
[edit ]
user@host# commit
Results
Confirm your configuration by entering the show routing-options and the show protocols ospf commands. If
the output does not display the intended configuration, repeat the instructions in this example to
correct the configuration.
447
}
}
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
Step-by-Step Procedure
[edit]
user@R1# edit protocols mpls
[edit ]
user@R1# commit
449
Results
Confirm your configuration by entering the show protocols mpls command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
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
Step-by-Step Procedure
[edit]
user@R1# edit protocols ospf
2. Include the label-switched-path statement, and specify the LSP R1-to-R6 that you created.
[edit]
user@R1# commit
Results
Confirm your configuration by entering the show protocols ospf command. If the output does not display
the intended configuration, repeat the instructions in this example to correct the configuration.
Verification
IN THIS SECTION
Purpose
Verify that another neighbor is listed and is reachable over the LSP. The interface field indicates the
name of the LSP.
451
Action
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:
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:
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
452
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 source-packet-routing srgb start-label 800000 index-range 4000;
user@host# set protocols ospf area 0.0.0.0 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
interface-name] hierarchy level.
• 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.
user@host# set protocols ospf area 0.0.0.0 interface ge-0/0/0.1 ipv4-adjacency-segment unprotected index 1;
user@host# set protocols ospf area 0.0.0.0 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 area
0.0.0.0 interface interface_name lan-neighbor neighbor-routerid] hierarchy level. The following is a sample
configuration:
[edit ]
protocols {
ospf {
area 0.0.0.0 {
interface <interface_name> {
ipv4-adjacency-segment {
protected {
453
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>
}
}
}
}
}
}
}
The following sample output displays the details of configured and dynamic adjacency SID.
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.
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
455
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:
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
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.
456
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-10.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-10.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.
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.
• 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
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).
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.
RELATED DOCUMENTATION
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 | 469
network controller. This is a light weight solution for
networks that have not implemented a controller | 502
with full fledged segment routing but still want to | 502
reap the benefits of segment routing in their
network. | 502
WHAT'S NEXT
For more information on configuring flexible algorithms, see the OSPF User Guide
IN THIS SECTION
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.
• 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.
• 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.
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.
460
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.
• priority: 0
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.
Starting in Junos OS 21.4R1, we support flexible Algorithm Definition (FAD)” and “Flexible Algorithm
Prefix Metric (FAPM)” in TED and implements two new corresponding TLVs "FAD TLV" and "FAPM TLV"
in BGP-LS. The value of FAD TLV contains Flex-Algorithm, Metric-Type, Calculation-Type and Priority, all
of which are one byte each. The TLV might have zero or more sub-TLVs included in it. The five sub-tlvs
are Flex Algo Exclude Any Affinity, Flex Algo Include Any Affinity, Flex Algo Include All Affinity, Flex Algo
Definition Flags and Flex Algo Exclude SRLG.
461
The FAD TLV can only be added to the BGP-LS Attribute of the Node NLRI if the corresponding node
originates in the underlying IGP TLV or sub-TLV. The BGP-LS Attribute associated with a Node NLRI
might include one or more FAD TLVs corresponding to the Flexible Algorithm Definition for each
algorithm that the node is advertising.
The value of FAPM TLV contains Flex-Algorithm (1 byte), Reserved (3 bytes) and Metric (4 bytes). The
FAPM TLV can be added to the BGP-LS Attribute of the Prefix NLRI originated by a node, only if the
corresponding node originates from the Prefix.
Starting in Junos OS Release 22.4R1, we've defined the Flexible Algorithm Prefix Metric (FAPM) to allow
optimal end-to-end path for an interarea prefix. The area border router (ABR) must include the FAPM
when advertising the prefix between areas that is reachable in that given Flexible Algorithm (flex algo).
When a prefix is unreachable, the ABR must not include that prefix in that flex algo when advertising
between areas. The defined FAPM provides inter-area support.
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.
Figure 25 on page 462 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:
(Continued)
Figure 26 on page 463 shows how FAD 128 routes traffic on any interface that is configured with admin
group red.
463
Figure 27 on page 464 shows how FAD 129 routes traffic on any interface that is configured with admin
group green.
464
Figure 28 on page 465 shows how FAD 130 routes traffic on any interface that is configured with admin
group green and blue.
465
Figure 29 on page 466 shows how FAD 135 routes traffic on any interface that is not configured with
admin group red.
466
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.
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.
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.
467
• Support for configuring and advertising prefix SIDs for different flexible algorithms.
• 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:
• 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.
• 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
advertisements is not supported.
Starting in Junos OS and Junos OS Evolved Release 22.2R1, you can advertise different te-attributes
such as te-metric, delay-metric, or admin-groups for RSVP and flexible algorithms on the same link. This
is done using flexible algorithm specific application-specific link attribute as defined in RFC 8920.
The advantage of having a flexible algorithm application-specific link attribute advertise te-metric, delay-
metric, or admin-groups is that a single link can advertise different te-link-attributes for legacy
applications such as RSVP and different te-link-attributes for flexible algorithms.
468
NOTE: The Junos OS and Junos OS Evolved implementation of application-specific link attribute
supports flexible algorithm applications only.
The default behavior of application-specific flexible algorithm is to use the flexible algorithm application-
specific te-attributes for a link if available, and if not, then fall back to the common application-specific
te-attributes, and if neither are available, use the legacy te-attributes.
The Operating System supports the following features in conjunction with application-specific link
attribute based flexible algorithm:
• The application-specific te-attribute subTLV to comply with RFC 8920. The application-specific te-
attributes sub-TLV is a sub-TLV of the OSPFv2 extended link TLV as defined in RFC 7684.
• Partially supports standard application identifier bit mask to advertise X-bit for flexible algorithms.
Only the te-metric, delay-metric, or admin-groups are advertised as part of the application-specific
link attribute sub-TLV.
The Operating System does not support the following features in conjunction with application-specific
link attribute based flexible algorithm:
• Advertising a common application-specific link attribute with standard application identifier bit mask
and user-defined application identifier bit masks length set to zero is not supported.
• Supporting traffic engineering for multiple applications is not supported, except for flexible
algorithms.
SEE ALSO
IN THIS SECTION
Overview | 469
Requirements | 470
Configuration | 471
Verification | 491
Overview
IN THIS SECTION
Topology | 470
470
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.
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.
Requirements
This example uses the following hardware and software components:
471
Configuration
IN THIS SECTION
Results | 487
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R0
Device R1
Device R2
set policy-options policy-statement prefix-sid term 1001 then prefix-segment algorithm 128 index
1282
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 algorithm 129 index
1292
set policy-options policy-statement prefix-sid term 1001 then prefix-segment algorithm 129 node-
segment
set policy-options policy-statement prefix-sid term 1001 then prefix-segment index 1002
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 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 all
set protocols mpls interface fxp0.0 disable
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/2.0 admin-group RED
set protocols mpls interface ge-0/0/3.0 admin-group BLUE
set protocols mpls interface ge-0/0/4.0 admin-group RED
set protocols mpls interface ge-0/0/5.0 admin-group GREEN
set protocols mpls interface ge-0/0/5.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 source-packet-routing flex-algorithm 129
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 post-convergence-lfa node-protection
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 post-convergence-lfa node-protection
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 post-convergence-lfa node-protection
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 post-convergence-lfa node-protection
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 post-convergence-lfa node-protection
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 post-convergence-lfa node-protection
set routing-options router-id 192.168.255.12
set routing-options autonomous-system 65000
set routing-options forwarding-table export pplb
477
Device R3
Device R4
Device R5
Configuring Device R0
To configure flexible algorithm for OSPFv2, perform the following steps on the device R0:
[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
user@R0set interfaces ge-0/0/1 description R0_to_R1_2
user@R0set interfaces ge-0/0/1 unit 0 family inet address 10.10.1.5/30
user@R0set interfaces ge-0/0/1 unit 0 family mpls
user@R0set interfaces ge-0/0/2 description R0_to_R3_1
user@R0set interfaces ge-0/0/2 unit 0 family inet address 10.10.3.1/30
482
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]
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
483
[edit]
user@R0set protocols mpls interface all
user@R0set protocols mpls interface fxp0.0 disable
7. Configure the MPLS label range to assign static labels for the links.
[edit]
user@R0set protocols mpls label-range static-label-range 1000 8000
8. 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
9. 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
10. 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
484
11. 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
user@R0set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 post-convergence-lfa node-
protection
user@R0set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 post-convergence-lfa node-
protection
user@R0set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 post-convergence-lfa node-
protection
12. 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
13. 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
485
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 te-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
user@R0set protocols mpls admin-groups BLUE 1
user@R0set protocols mpls admin-groups GREEN 2
[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
[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 GREEN
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
486
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
14. 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
[edit]
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 128 index 1280
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 128 node-segment
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 129 index 1290
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 129 node-segment
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 130 index 1300
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 130 node-segment
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 131 index 1310
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 131 node-segment
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 132 index 1320
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
algorithm 132 node-segment
user@R0set policy-options policy-statement prefix-sid term 1001 then prefix-segment
487
Results
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;
488
}
}
ge-0/0/2 {
description R0_to_R3_1
unit 0 {
family inet {
address 10.10.3.1/30;
}
family mpls;
}
}
ge-0/0/3 {
description R0_to_R3_2
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 {
load-balance per-packet;
}
}
policy-statement prefix-sid {
term 1001 {
from {
route-filter 192.168.255.10/32 exact;
}
then {
prefix-segment {
algorithm 128 index 1280 node-segment;
489
backup-spf-options {
use-post-convergence-lfa maximum-labels 5;
use-source-packet-routing;
}
traffic-engineering {
advertisement always;
}
source-packet-routing {
prefix-segment prefix-sid;
srgb start-label 80000 index-range 5000;
flex-algorithm [ 128 129 ];
}
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ge-0/0/0.0 {
post-convergence-lfa {
node-protection;
}
}
interface ge-0/0/1.0 {
post-convergence-lfa {
node-protection;
}
}
interface ge-0/0/2.0 {
post-convergence-lfa {
node-protection;
}
}
interface ge-0/0/3.0 {
post-convergence-lfa {
node-protection;
}
}
}
}
}
routing-options {
flex-algorithm 128 {
definition {
metric-type igp-metric;
491
spf;
admin-group include-any RED;
}
}
flex-algorithm 129 {
definition {
metric-type te-metric;
spf;
admin-group include-all [ GREEN BLUE ];
}
}
router-id 192.168.255.10;
autonomous-system 65000;
forwarding-table {
export pplb;
}
}
Verification
IN THIS SECTION
Action | 492
Action | 493
Action | 494
Action | 498
Action | 499
To confirm that the configuration is working properly, perform the following tasks:
492
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.
On R0
Meaning
Three segment-routing algorithms (including two flexible algorithms) are advertised by this device.
Purpose
Action
From operational mode, run the show ospf spring flex-algorithm <flex-algorithm-id> command.
On R0
Meaning
Purpose
Verifying that the fexible algorithm specific OSPF internal routes are displayed.
Action
From operational mode, run the show ospf route flex-algorithm <flex-algorithm-id> command.
On R0
Meaning
The show ospf route command is extended with flex-algorithm option to show flexible algorithm specific
OSPF internal routes. Each route is prefixed with the flex-algo-id:
Purpose
Verifying that the fexible algorithm specific OSPF internal routes are displayed.
498
Action
From operational mode, run the show route protocol ospf command.
On R0
192.168.255.11-128<c>/64
*[L-OSPF/10/5] 1w2d 01:23:04, metric 1
> to 10.10.1.2 via ge-0/0/0.0
to 10.10.3.2 via ge-0/0/2.0, Push 81281, Push 81283(top)
192.168.255.12-128<c>/64
*[L-OSPF/10/5] 1w2d 01:23:04, metric 2
to 10.10.1.2 via ge-0/0/0.0, Push 81283
> to 10.10.3.2 via ge-0/0/2.0, Push 81283
192.168.255.13-128<c>/64
*[L-OSPF/10/5] 1w2d 01:23:04, metric 1
> to 10.10.3.2 via ge-0/0/2.0
to 10.10.1.2 via ge-0/0/0.0, Push 81284, Push 81283(top)
192.168.255.14-128<c>/64
*[L-OSPF/10/5] 1w2d 01:23:04, metric 2
> to 10.10.3.2 via ge-0/0/2.0, Push 81286
to 10.10.1.2 via ge-0/0/0.0, Push 81286, Push 81283(top)
192.168.255.15-128<c>/64
*[L-OSPF/10/5] 1w2d 01:23:04, metric 3
to 10.10.1.2 via ge-0/0/0.0, Push 81287
> to 10.10.3.2 via ge-0/0/2.0, Push 81287
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
Purpose
Verifying that the OSPF logs displays the flexible algorithm keyword.
499
Action
On R0
Meaning
The output displays the FlexAlgo keyword added for the SPF logs.
Starting in Junos OS and Junos OS Evolved Release 22.2R1, you can advertise different te-attributes
such as te-metric, delay-metric, or admin-groups for RSVP and flexible algorithms on the same link. This
is done using flexible algorithm specific application-specific link attribute as defined in RFC 8920.
[edit protocols]
user@host#set protocols ospf area area-id
For example:
[edit protocols]
user@host#set protocols ospf area 0.0.0.0
503
For example:
For example:
5. Configure flexible algorithm specific te-attributes such as te-metric, delay-metric, and admin-
groups. Specify the te-metric for the attribute group. The te-metric indicates the metric type based
on which OSPFv2 calculates the path.
For example:
For example:
For example:
8. In case delay-metric is not configured, specify advertise-interface-delay to fetch the delay values
from the interface configuration hierarchy, that is legacy delay values.
For example:
NOTE: The following configuration can be committed only if all of the following criteria
match:
505
9. Specify the application for the attribute group. In the current implementation, only flexible
algorithm can be configured as an application. An attribute group can have more than one
applications associated with it and it equates to a single application-specific link attribute with the
application bits set in the standard application identifier bit mask field of the application-specific
link attribute sub.
ospf {
area 0.0.0.0
interface ge-0/0/0.0 {
application-specific {
attribute-group asla {
te-metric 15;
admin-group green;
delay-metric 123123;
advertise-interface-delay;
application flex-algorithm;
506
}
}
}
source-packet-routing {
strict-asla-based-flex-algorithm;
}
}
The Junos OS and Junos OS Evolved implementation supports application-specific link attribute
subTLV to comply with RFC 8920. The application-specific link attribute sub-TLV is a sub-TLV of the
OSPFv2 extended Link TLV as defined in RFC 7684.
To verify the presence of application-specific link attribute sub-TLVs in the OSPF database use the
show ospf database extensive operational command.
4
UDABM Length (2), length 1:
0
SABM (3), length 4:
0x10
UDABM (4), length 0:
0x0
TEMetric (5), length 4:
10
UnidirecLinkDelay (27), length 4:
123
MinMaxUnidirecLinkDelay (28), length 8:
Min DM: 123, Max DM: 123
UnidirecLinkDelayVar (29), length 4:
0
Color (9), length 4:
2
Gen timer 00:34:55
Aging timer 00:48:55
Installed 00:11:05 ago, expires in 00:48:55, sent 00:11:05 ago
Last changed 00:11:05 ago, Change count: 6, Ours, TE Link ID: 0
The output displays application-specific link attribute sub-TLV fields and attributes.
RELATED DOCUMENTATION
IN THIS SECTION
IN THIS SECTION
Link delay measurement and advertising in OSPF provides the following benefits:
• Highly beneficial in certain networks such as stock market data providers, where it is crucial to have
access to market data in real-time to make trades faster than the competition. This is where network
performance criteria or latency is becoming critical to data-path selection.
• Helps to make path-selection decisions based on performance data (such as latency) in a cost-
effective and scalable way.
• Superior alternative to using metrics such as hop count or cost as routing metrics.
Network performance is measured by using TWAMP -Light. Starting in Junos OS Release 21.4R1, you
can get the measurement of various performance metrics in IP networks, by using probe messages.
OSPF Traffic Engineering Extensions helps to distribute network-performance information in a scalable
fashion. This information can then be used to make path-selection decisions based on network
performance.
Border Gateway Protocol Link-State (BGP-LS) allows BGP to carry link-state information acquired from
IGPs, which then allows internet service providers (ISP) to selectively expose the information with other
ISPs, service providers, CDNs and so on, through normal BGP peering. New BGP-Link State (BGP-LS)
TLVs are defined to carry the IGP Traffic Engineering Metric Extensions.
509
The following illustration depicts the minimum IGP metric and minimum delay metric in networks that
consist a core, metro, and access network.
In this scenario, core network is cheaper but has longer delay. Access shortcut, with lowest latency is
expensive. As core network is cheaper, majority of traffic typically go from 1>2>3>4>5> to 6 by using
minimum IGP metric. As displayed in scenario a), you can achieve minimum IGP requirement by running
OSPF with appropriate cost configured and default OSPF algorithm set to zero. In businesses where
ultra-low latency is crucial, packets need to go from 1 to 6. As displayed in scenario b), you can achieve
minimum delay metric by defining OSPF flex algorithm with minimum latency, which minimize the delay
to the endpoint. This flex algorithm consists only node 1 and node 6.
SEE ALSO
In IP networks, the bulk of traffic often goes through the core network, which reduces costs but might
result in increased latency. Business traffic, however, often benefits from the ability to make path-
selection decisions based on other performance metrics, such as path latency, rather than relaying on
the traditional path optimization based simply on IGP metrics. Optimizing a path to reduce latency can
greatly benefit applications like real-time voice and video. It can also enable high performance access to
financial market data where milliseconds can translate into significant gains or losses.
Starting in Junos OS Release 21.4R1, you can enable OSPF link delay in IP networks. You can achieve
minimum IGP metric paths by configuring OSPF with the appropriate link cost using the default OSPF
algorithm. Doing so optimizes paths to the endpoint that are based strictly on the sum of the link
metrics. By using the OSPF delay flex algorithm you can optimize paths based on their end-to-end delay.
510
Link delay can be dynamically measured using Two-Way Active Measurement Probes (TWAMP). The
routers then flood their link delay parameters. The routers in the area store these parameters in the
shared Link State Database (LSDB). Ingress nodes run an SPF algorithm against the LSDB to compute
paths that are optimized on various attributes, such as link colors, IGP metric, traffic-engineering (TE)
metric.
[edit protocols]
user@host#set protocols ospf area area-id
For example:
[edit protocols]
user@host#set protocols ospf area 0.0.0.0
For example:
3. Configure dynamic OSPF link delay-measurement on the OSPF interface of the device.
4. Configure the delay-measurement advertisement on the OSPF interface of the device. You can either
configure accelerated or periodic advertisement.
5. To configure periodic advertisement, you can either configure interval or the threshold percentage.
For example:
For example:
For example:
To verify your configuration results, use the show protocols operational command.
ospf {
area 0.0.0.0
interface ge-0/0/0.0 {
delay-measurement {
advertisement {
accelerated {
threshold 100;
}
periodic {
interval 35;
threshold 100;
}
}
probe-count 10;
probe-interval 100;
}
delay-metric {
20000;
513
)
}
To verify that link delay parameters are present in the OSPF database use the show ospf database extensive
| match delay operational command.
The output displays the delay of 20000 microseconds that is configured on the interface.
SEE ALSO
IN THIS SECTION
• Microloop avoidance can prevent forwarding of looping packets and avoid wasteful bandwidth
consumption.
• Microloop avoidance path is computed only for the impacted links in case of multiple link failures. If
the second link failure does not impact the computed microloop avoidance path, OSPFv2 continues
to use the same microloop avoidance path.
Junos OS enables a device to defer OSPFv2 route download when an OSPFv2 link fails in order to avoid
micro loops. When local links go down, the OSPFv2 protocol floods an entire area with the database. If
the node connected to the local interface that has failed converges faster than the neighboring node,
then the connected node redirects traffic to the converged path. This redirection can result in micro
looping of traffic until the neighboring node converges. When the primary path of a protected node fails,
the connected node does not need to converge quickly if the configured backup path is not impacted. In
this case, traffic flow towards a converged path is deferred until the configured delay time. This time
delay helps in avoiding microloops because all routers do not arrive at the post-convergence forwarding
states simultaneously.
515
In the Figure 31 on page 515, the primary path from Source to Destination is SR0R1R2R3D.
When the link between R2 and R3 fails, traffic sent from S to D, is subject to transient forwarding loops
while routers update their forwarding state for destination D.
• If R0 updates its forwarding state before R5, packets loop between R0 and R5
• If both R0 and R5, have updated their forwarding states, and R4 has not, packets loop between R4 and
R5.
• R0 detects the link failure between R2 and R3, and temporarily steers traffic destined to Destination
over SR path [NodeSID(R4), AdjSID(R4->R3), D].
• When the configured timeout elapses, R0 just uses the node-SID to D to reach the destination.
Starting in Junos OS Release 22.1R1, you can enable a post convergence path calculation on a device to
avoid microloops if a link or metric change occurs in an OSPFv2 segment routed network. To configure
microloop avoidance in an OSPFv2 segment routing network for both local and remote network events
including link down, link-up, and metric-change, include the maximum-labelsdelay milliseconds statement at
the [edit protocols ospf spf-options microloop avoidance post-convergence-path] hierarchy level. For effective
microloop avoidance, configure this feature on all the nodes in the network.
NOTE: Micro-loop avoidance is not a replacement for local repair mechanisms like TI-LFA which
detects local failure very fast and activates a pre-computed loop-free-alternative path.
Routers that implement micro-loop avoidance compute the micro-loop avoiding path only after receiving
the link state update for the event. So, micro-loop avoidance mechanism is not a replacement for local
repair mechanisms like TI-LFA which detects local failure very fast and activates a pre-computed loop-
free-alternative path at PFE level. In the above example, if local repair mechanism is not present for the
R2R3 failure, there will be a lot of traffic loss before R0 can detect the failure (through global
convergence) and program a micro-loop avoiding path. Micro-loop avoidance cannot avoid traffic loss
due to delayed detection of the failure. Microloop avoidance avoids traffic loss due to micro-loops only.
516
Both local-repair mechanisms like TI-LFA and micro-loop avoidance, have to be enabled on all the nodes
in the network to ensure that traffic loss is in milli-seconds range.
1. After computing the new path to D, for a predetermined time, R installs an entry for D that steers
packets to D through a loop-free segment routed path. This time should be greater than worst case
delay of any router in the network.
2. After the configured time delay, R installs the post-convergence route entry for D, which is without
any SIDs.
• Microloop avoidance is supported on all the Junos OS platforms that support OSPF routing protocol.
Junos OS does not support the following features in conjunction with microloop avoidance:
• Microloop avoidance path that needs more than 8 labels is not supported. The maximum number of
labels installed for microloop avoidance path is 8. For the microloop avoidance ECMP path to be
usable, the number of labels must be less than or equal to maximum labels.
• If shortcuts are available OSPFv2 does not provide a microloop avoidance path.
IN THIS SECTION
Overview | 517
Requirements | 517
517
Topology | 517
Configuration | 518
Verification | 537
Overview
Microloops are packet forwarding loops that occur in the network following network change events
such as link down, link up, or metric change. When a network change event occurs, different routers
update their forwarding states at different times. This can lead to packets getting looped between
upstream and downstream routers for a transient period, resulting in packet loss, jitter, and out-of-order
packets. Microloops can consume the available bandwidth of the links, which impacts the efficient
transmission of useful packets.
Microloop avoidance can prevent forwarding of looping packets. The segment routing microloop
avoidance detects if microloops are possible following a topology change. When a network change
event is detected, the routes are programmed to take the post-convergence path, that uses a
combination of node and adjacency SIDs. This ensures the routers that might not yet have converged do
not loop the packets causing microloops. This behavior lasts for a configurable delay. Once the delay
timer expires, routes are programmed normally by using node-SID of the destinations.
Requirements
This example uses the following hardware and software components:
Topology
In Figure 32 on page 518 device R0 and device R7 are the ingress and egress routers that support
devices CE1 and CE2. The devices R1, R2, R3, R4, R5, and R6 comprise an IPv4 only provider core
network. All the devices belong to the same autonomous system. OSPFv2 is the interior gateway
protocol in the core configured to support microloop avoidance. In this example the device R2 is
configured as an IPv4 route reflector with IBGP peering sessions to both R0 and R7. No other routers
speak BGP in this example. The Device R6 has the firewall filter configured to detect packets with
microloops if any following a link down event.
518
Configuration
IN THIS SECTION
Results | 533
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
519
Device R0
Device R1
Device R2
Device R3
Device R4
Device R5
Device R6
Device R7
Configuring Device R0
Step-by-Step Procedure
To configure segment routing microloop avoidance path in an OSPFv2 network, perform the following
steps on the R0 device:
[edit]
user@R0#set interfaces xe-0/0/0:0 description To_R1
user@R0#set interfaces xe-0/0/0:0 unit 0 family inet address 10.10.1.1/30
uesr@R0#set interfaces xe-0/0/0:0 unit 0 family mpls
user@R0#set interfaces xe-0/0/0:3 description To_R4
user@R0#set interfaces xe-0/0/0:3 unit 0 family inet address 10.10.4.1/30
uesr@R0#set interfaces xe-0/0/0:3 unit 0 family mpls
user@R0#set interfaces xe-0/0/1:2 description to_CE1
user@R0#set interfaces xe-0/0/1:2 unit 1 family inet address 172.16.10.2/30
user@R0#set interfaces xe-0/0/1:2 unit 1 family mpls
2. Configure the loopback interface (lo0) addresses that is used as router ID for OSPF sessions.
[edit]
user@R0#set interfaces lo0 unit 0 family inet address 192.168.255.10/32
user@R0#set interfaces lo0 unit 0 family inet address 192.168.255.18/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@R0#set routing-options router-id 192.168.255.10
user@R0#set routing-options autonomous-system 65000
531
4. Define a policy to load balance packets and apply the per-packet policy to enable load balancing of
traffic.
[edit]
user@R0#set policy-options policy-statement pplb then load-balance per-packet
user@R0#set routing-options forwarding-table export pplb
5. Configure R0 to advertise the loopback address. The prefix-segment index option sets the base label
for each router's loopback. In this example the base index is set to reflect| the router number. As a
result, R0 uses 1000.
[edit]
user@R0#set policy-options policy-statement prefix-sid term 1 from route-filter
192.168.255.10/32 exact
user@R0#set policy-options policy-statement prefix-sid term 1 then prefix-segment index 1000
user@R0#set policy-options policy-statement prefix-sid term 1 then prefix-segment node-
segment
user@R0#set policy-options policy-statement prefix-sid term 1 then accept
6. Configure MPLS on all interfaces excluding the management interface. Also enable traffic
engineering.
[edit]
user@R0#set protocols mpls interface all
user@R0#set protocols mpls interface fxp0.0 disable
user@R0#set protocols mpls traffic-engineering
7. Configure the MPLS label range to assign static labels for the links.
[edit]
user@R0#set protocols mpls label-range static-label-range 60001 100000
8. Configure BGP peering between R0 and the route reflector R2. Configure the unicast network layer
reachability information (NRLI) to allocate a unique label for each prefix on the devices.
[edit]
user@R0#set protocols bgp group to-RR type internal
user@R0#set protocols bgp group to-RR local-address 192.168.255.10
532
user@R0#set protocols bgp group to-RR neighbor 192.168.255.12 family inet unicast
user@R0#set protocols bgp group to-RR neighbor 192.168.255.12 family inet-vpn unicast per-
prefix-label
9. 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@host#set protocols ospf backup-spf-options use-source-packet-routing
10. Configure backup shortest path first (SPF) attributes such as maximum equal-cost multipath (ECMP)
as 8 and maximum number of labels as 5 for TI-LFA for the OSPFv2 protocol.
[edit]
user@host#set protocols ospf backup-spf-options use-post-convergence-lfa maximum-labels 5
user@host#set protocols ospf backup-spf-options use-post-convergence-lfa maximum-backup-
paths 8
11. Configure prefix segment attributes, the start label and the index range for segment routing global
blocks (SRGBs) in SPRING for the OSPFv2 protocol.
[edit]
user@host#set protocols ospf source-packet-routing prefix-segment prefix-sid
user@host#set protocols ospf source-packet-routing node-segment ipv4-index 0
user@host#set protocols ospf source-packet-routing srgb start-label 800000
user@host#set protocols ospf source-packet-routing srgb index-range 80000
12. 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@host#set protocols ospf area 0.0.0.0 interface lo0.0 passive
13. Configure OSPF area 0 on the point-to-point interface of the device R0.
[edit]
user@host#set protocols ospf area 0.0.0.0 interface xe-0/0/0:0.0 interface-type p2p
533
14. Configure the computation and installation of a backup path that follows the post-convergence
path on the given area and interface for the OSPFv2 protocol. Also enable node-link protection on
the these interfaces that follow post-convergence path.
[edit]
user@host#set protocols ospf area 0.0.0.0 interface xe-0/0/0:0.0 post-convergence-lfa node-
protection
user@host#set protocols ospf area 0.0.0.0 interface xe-0/0/0:3.0 post-convergence-lfa node-
protection
15. Configure microloop avoidance that temporarily installs a post-convergence path for routes
potentially affected by microloops and specify a delay time period of 60000 milliseconds for the
OSPFv2 protocol. The temporary path reverts to the node SIDs of the destination after the delay
timer expires.
[edit]
user@host#set protocols ospf spf-options microloop-avoidance post-convergence-path delay
60000
Results
interfaces {
xe-0/0/0:0 {
description To_R1;
unit 0 {
family inet {
address 10.10.1.1/30;
}
family mpls;
}
}
xe-0/0/0:3 {
description To_R4;
534
unit 0 {
family inet {
address 10.10.4.1/30;
}
family mpls;
}
}
xe-0/0/1:2 {
description to_CE1;
unit 1 {
family inet {
address 172.16.10.2/30;
}
family mpls;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.255.10/32;
address 192.168.255.18/32;
}
family mpls;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
policy-statement prefix-sid {
term 1 {
from {
route-filter 192.168.255.10/32 exact;
}
then {
prefix-segment {
index 1000;
node-segment;
}
535
accept;
}
}
term 2 {
from {
route-filter 192.168.255.18/32 exact;
}
then {
prefix-segment {
index 1100;
}
accept;
}
}
}
}
routing-options {
router-id 192.168.255.10;
autonomous-system 100;
forwarding-table {
export pplb;
}
}
protocols {
bgp {
group to-RR {
type internal;
local-address 192.168.255.10;
neighbor 192.168.255.12 {
family inet {
unicast;
}
family inet-vpn {
unicast {
per-prefix-label;
}
}
}
}
}
mpls {
traffic-engineering;
label-range {
536
}
}
Verification
IN THIS SECTION
Verify Connectivity Between R0 and R7 Before the Link is Disabled Between R0 and R1 | 537
Verify Microloop-avoidance Path Installed for the Destination After the Link is Disabled | 539
Verify Microloop-avoidance Path Changes to Post-convergence- path After the Delay Timer
Expires | 541
Verify the Path Changes to Microloop-avoidance Path After the Link is Enabled | 543
The following section explains microloop avoidance for a link down event.
Verify Connectivity Between R0 and R7 Before the Link is Disabled Between R0 and R1
Purpose
Verify that the Device R0 can reach the destinations on Device R7.
Action
From operational mode, run the ping command on the device R0.
user@R0>ping 192.168.255.17
PING 192.168.255.17 (192.168.255.17): 56 data bytes
64 bytes from 192.168.255.17: icmp_seq=0 ttl=61 time=41.493 ms
64 bytes from 192.168.255.17: icmp_seq=1 ttl=61 time=57.242 ms
64 bytes from 192.168.255.17: icmp_seq=2 ttl=61 time=44.977 ms
64 bytes from 192.168.255.17: icmp_seq=3 ttl=61 time=202.092 ms
64 bytes from 192.168.255.17: icmp_seq=4 ttl=61 time=60.495 ms
538
Meaning
These results confirm that the device R0 can reach device R7 in the OSPFv2 network.
Purpose
Action
From configuration mode, run the disable interface command on the device R0
To verify the link is disabled, from operational mode, run the show interfaces command on the device
R0
Meaning
The output indicates the physical link between R0 and R1 is disabled and is administratively down.
Verify Microloop-avoidance Path Installed for the Destination After the Link is Disabled
Purpose
Verify microloop-avoidance path installed for the destination routes R7 from R0 when the link is
disabled between R0 and R1 by verifying routes in the inet.3 table and route label details in the mpls.0
table.
Action
From operational mode, run the show route table inet.3 command on the device R0.
From operational mode, run the show route label label value protocol ospf extensive command on the
device R0.
KRT in-kernel 801007 /52 -> {Swap 16, Push 801006 (top)}
*L-OSPF Preference: 10/5
Next hop type: Router, Next hop index: 649
Address: 0x7a1ed58
Next-hop reference count: 4, key opaque handle: 0x0
Next hop: 10.10.4.2 via xe-0/0/0:3.0 weight 0x1, selected
Label operation: Swap 16, Push 801006(top)
Load balance label: Label 16: None; Label 801006: None
Label element ptr: 0x8fd6ed0
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 321
State: <Active Int>
Local AS: 100
Age: 2:55:13 Metric: 130
Validation State: unverified
Area: 0.0.0.0
Task: OSPF
Announcement bits (1): 1-KRT
AS path: I
Thread: junos-main
Meaning
The output indicates that when the link between R0 and R1 goes down, the microloop-avoidance path is
installed for R7 from R0 through R4 until the delay timer expires.
Purpose
Action
From operational mode, run the show firewall command on the device R6.
user@R6>show firewall
Filter: mplsfilter
541
Counters:
Name Bytes Packets
v4sr-nsid-cnt 0 0
v4sr-psid-cnt 0 0
Meaning
The output displays the mplsfilter configured on the device R6 to display microloops if there are any.
The value 0 indicates there are no packets with microloops.
Verify Microloop-avoidance Path Changes to Post-convergence- path After the Delay Timer Expires
Purpose
Verify microloop-avoidance path installed for the destination routes R7 from R0 changes to post-
convergence-path after the delay timer 60000 ms expires.
Action
From operational mode, run the show route table inet.3 command on the device R0.
From operational mode, run the show route label label value protocol ospf extensive command on the
device R0.
Meaning
The output indicates that the microloop-avoidance path is changed to post-convergence-path after the
delay timer expires.
Purpose
Verify that the Device R0 can reach the destinations on Device R7.
Action
From operational mode, run the ping command on the device R0.
user@R0>ping 192.168.255.17
PING 192.168.255.17 (192.168.255.17): 56 data bytes
64 bytes from 192.168.255.17: icmp_seq=0 ttl=61 time=41.493 ms
64 bytes from 192.168.255.17: icmp_seq=1 ttl=61 time=57.242 ms
64 bytes from 192.168.255.17: icmp_seq=2 ttl=61 time=44.977 ms
64 bytes from 192.168.255.17: icmp_seq=3 ttl=61 time=202.092 ms
64 bytes from 192.168.255.17: icmp_seq=4 ttl=61 time=60.495 ms
543
Meaning
These results confirm that the device R0 can reach device R7 in the OSPFv2 network and that the traffic
flows with 0% packet loss in case of link down because of the microloop-avoidance path configured.
Verify the Path Changes to Microloop-avoidance Path After the Link is Enabled
Purpose
Verify the path changes to microloop-avoidance path for the destination when the link is enabled
between R0 and R1.
Action
From operational mode, run the show route table inet.3 command on the device R0.
From operational mode, run the show route label label value protocol ospf extensive command on the
device R0.
Address: 0x79329ac
Next-hop reference count: 3, key opaque handle: 0x0
Next hop: 10.10.4.2 via xe-0/0/0:3.0 weight 0x1, selected
Label operation: Push 801007
Load balance label: Label 801007: None;
Label element ptr: 0x8fd6458
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0
Next hop: 10.10.1.2 via xe-0/0/0:0.0 weight 0xf000, selected
Label operation: Swap 16, Push 801006(top)
Load balance label: Label 16: None; Label 801006: None;
Label element ptr: 0x8fd8e60
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0
State: <Active Int>
Local AS: 100
Age: 2:55:13 Metric: 40
Validation State: unverified
Area: 0.0.0.0
Task: OSPF
Announcement bits (1): 1-KRT
AS path: I
Thread: junos-main
Meaning
The output displays the routes to the destination R7 from R0 which includes microloop-avoidance path
and the post-convergence path after the link is enabled between R0 and R7.
13 CHAPTER
IN THIS SECTION
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.
• 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.
547
• 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
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.
• Logical systems
• OSPFv3 realms
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.
• 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.
RELATED DOCUMENTATION
database-protection
14 CHAPTER
IN THIS SECTION
Example: Configuring Backup Selection Policy for the OSPF or OSPF3 Protocol | 570
Example: Injecting OSPF Routes into the BGP Routing Table | 604
Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through OSPF | 620
IN THIS SECTION
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.
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.
As shown in Figure 33 on page 552, 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.
552
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 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.
553
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.
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
554
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
IN THIS SECTION
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.
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.
• 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.
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.
556
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.
The then statement is optional. If you omit it, one of the following occurs:
• 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.
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:
557
• 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
558
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
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.
[edit policy-options]
user@host# set policy-statement ecmp term 1 then load-balance per-packet
[edit protocols]
user@host# set rsvp interface all
[edit routing-options]
user@host# set srlg srlg-name srlg-value srlg-value
[edit routing-options]
user@host# set router-id router-id
560
8. Apply the routing policy to all equal cost multipaths exported from the routing table to the
forwarding table.
[edit routing-options]
user@host# set forwarding-table export ecmp
9. Enable link protection and configure metric values on all the interfaces for an area.
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.
[edit routing-options]
user@host# set backup-selection destination ip-address interface interface-name admin-group
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.
• Configure all the administrative groups if each link in the backup path requires all the listed
administrative groups in order to accept the path.
For example, to set all the administrative groups if each link requires all the listed administrative
groups in order to accept the path:
• 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.
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:
• Define an ordered set of an administrative group that specifies the preference of the backup
path.
For example, to set an ordered set of an administrative group that specifies the preference of
the backup path:
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.
[edit routing-options]
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.
[edit routing-options]
user@host# set backup-selection destination ip-address interface interface-name dest-
metric highest
• Configure the backup path that has the lowest destination metric.
[edit routing-options]
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.
[edit routing-options]
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 :
563
• [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.
[edit routing-options]
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.
[edit routing-options]
user@host# set backup-selection destination ip-address interface interface-name node
The backup path that has a router from the list is not selected as the loop-free alternative or
backup next hop.
[edit routing-options]
user@host# set backup-selection destination ip-address interface interface-name
protection-type link
[edit routing-options]
user@host# set backup-selection destination ip-address interface interface-name
protection-type node
• Select the backup path that allows either node or link protection LFA where node-protection
LFA is preferred over link-protection LFA.
[edit routing-options]
user@host# set backup-selection destination ip-address interface interface-name
protection-type 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.
[edit routing-options]
user@host# set backup-selection destination ip-address interface all root-metric highest
[edit routing-options]
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.
565
• Configure the backup path to allow common srlgs between the primary link and each link in the
backup path.
[edit routing-options]
user@host# set backup-selection destination ip-address interface all srlg loose
• 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.
[edit routing-options]
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.
[edit routing-options]
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
IN THIS SECTION
Understanding Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 566
Configuring Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 568
IN THIS SECTION
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
567
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
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.
568
• 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
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.
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:
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.
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.
RELATED DOCUMENTATION
source-packet-routing
use-post-convergence-lfa
post-convergence-lfa
570
IN THIS SECTION
Requirements | 570
Overview | 570
Configuration | 572
Verification | 597
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
This example uses the following hardware and software components:
• 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
2. Configure OSPF.
Overview
IN THIS SECTION
Topology | 571
571
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.
Topology
In this topology shown in Figure 34 on page 572, the backup selection policy is configured on Device
R3.
572
Configuration
IN THIS SECTION
Results | 591
573
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.
R0
R1
R2
R3
exclude c5
set routing-options backup-selection destination 172.16.30.0/30 interface all srlg strict
set routing-options backup-selection destination 172.16.30.0/30 interface all protection-type
node
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.30.0/30 interface all neighbor
preference 172.16.7.7
set routing-options backup-selection destination 172.16.30.0/30 interface all root-metric lowest
set routing-options backup-selection destination 172.16.30.0/30 interface all metric-order root
set routing-options backup-selection destination 172.16.45.0/30 interface all admin-group
exclude c5
set routing-options backup-selection destination 172.16.45.0/30 interface all srlg strict
set routing-options backup-selection destination 172.16.45.0/30 interface all protection-type
node
set routing-options backup-selection destination 172.16.45.0/30 interface all bandwidth-greater-
equal-primary
set routing-options backup-selection destination 172.16.45.0/30 interface all neighbor
preference 172.16.7.7
set routing-options backup-selection destination 172.16.45.0/30 interface all root-metric lowest
set routing-options backup-selection destination 172.16.45.1/30 interface all metric-order root
set protocols rsvp interface all
set protocols mpls admin-groups c0 0
set protocols mpls admin-groups c1 1
set protocols mpls admin-groups c2 2
set protocols mpls admin-groups c3 3
set protocols mpls admin-groups c4 4
set protocols mpls admin-groups c5 5
set protocols mpls admin-groups c6 6
set protocols mpls admin-groups c7 7
set protocols mpls admin-groups c8 8
set protocols mpls admin-groups c9 9
set protocols mpls admin-groups c10 10
set protocols mpls admin-groups c11 11
set protocols mpls admin-groups c12 12
set protocols mpls admin-groups c13 13
set protocols mpls admin-groups c14 14
set protocols mpls admin-groups c15 15
set protocols mpls admin-groups c16 16
set protocols mpls admin-groups c17 17
set protocols mpls admin-groups c18 18
set protocols mpls admin-groups c19 19
set protocols mpls admin-groups c20 20
581
R4
R5
R6
R7
Configuring Device R3
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
[edit interfaces]
user@R3# set ge-0/0/5 unit 0 family inet address 172.16.50.2/30
user@R3# set ge-0/0/5 unit 0 family inet6 address 2001:db8:50:1:1::2/64
user@R3# set ge-0/0/5 unit 0 family mpls
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 ge-1/0/0 unit 0 family inet address 172.16.80.1/30
user@R3# set ge-1/0/0 unit 0 family inet6 address 2001:db8:80:1:1::1/64
user@R3# set ge-1/0/0 unit 0 family mpls
user@R3# set ge-1/0/5 unit 0 family inet address 172.16.200.1/24
user@R3# set ge-1/0/5 unit 0 family inet6 address 2001:db8:200:1:1::1/64
user@R3# set ge-1/0/6 unit 0 family inet address 172.16.85.1/30
user@R3# set ge-1/0/6 unit 0 family inet6 address 2001:db8:85:1:1::1/64
user@R3# set ge-1/0/6 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
588
[edit routing-options]
user@R3# set srlg srlg1 srlg-value 1001
user@R3# set srlg srlg2 srlg-value 1002
user@R3# set srlg srlg3 srlg-value 1003
user@R3# set srlg srlg4 srlg-value 1004
user@R3# set srlg srlg5 srlg-value 1005
user@R3# set srlg srlg6 srlg-value 1006
user@R3# set srlg srlg7 srlg-value 1007
user@R3# set srlg srlg8 srlg-value 1008
user@R3# set srlg srlg9 srlg-value 1009
user@R3# set srlg srlg10 srlg-value 10010
user@R3# set srlg srlg11 srlg-value 10011
user@R3# set srlg srlg12 srlg-value 10012
[edit routing-options]
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.
[edit routing-options]
user@R3# set forwarding-table export ecmp
[edit protocols]
user@R3# set rsvp interface all
8. Enable MPLS on all the interfaces and configure administrative group for an interface.
9. Enable link protection and configure metric values on all the interfaces for an OSPF area.
10. Enable link protection and configure metric values on all the interfaces for an OSPF3 area.
[edit policy-options]
user@R3# set policy-statement ecmp term 1 then load-balance per-packet
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.
}
ge-1/0/0 {
unit 0 {
family inet {
address 192.168.80.1/30;
}
family inet6 {
address 2001:db8:80:1:1::1/64;
}
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;
}
593
}
lo0 {
unit 0 {
family inet {
address 172.16.3.3/32 {
primary;
}
}
family inet6 {
address 2001:db8:3:3:3:3/128 {
primary;
}
}
family mpls;
}
}
c18 18;
c19 19;
c20 20;
c21 21;
c22 22;
c23 23;
c24 24;
c25 25;
c26 26;
c27 27;
c28 28;
c29 29;
c30 30;
c31 31;
}
interface all;
interface ge-0/0/5.0 {
admin-group c0;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/5.0 {
link-protection;
metric 10;
}
interface xe-0/3/1.0 {
metric 21;
}
interface ge-1/0/0.0 {
metric 13;
}
interface ge-1/0/6.0 {
metric 15;
}
interface xe-1/3/0.0 {
link-protection;
metric 22;
}
}
}
ospf3 {
area 0.0.0.0 {
595
interface ge-0/0/5.0 {
link-protection;
metric 10;
}
interface xe-0/3/1.0 {
metric 21;
}
interface ge-1/0/0.0 {
metric 13;
}
interface ge-1/0/6.0 {
metric 15;
}
interface xe-1/3/0.0 {
link-protection;
metric 22;
}
}
}
interface xe-1/3/0.0 {
admin-group {
include-all c2;
}
}
interface all {
admin-group {
exclude c3;
}
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;
protection-type node;
bandwidth-greater-equal-primary;
node {
preference 172.16.7.7;
}
root-metric lowest;
metric-order root;
}
}
destination 192.168.45.0/30 {
interface all {
admin-group {
exclude c5;
}
srlg strict;
protection-type node;
bandwidth-greater-equal-primary;
node {
597
preference 172.16.7.7;
}
root-metric lowest;
metric-order root;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
IN THIS SECTION
Purpose
Action
From operational mode, run the show route command for the routing table.
47.0005.80ff.f800.0000.0108.0001.1280.9202.4195/152
*[Direct/0] 02:22:57
> via lo0.0
Meaning
Purpose
Action
From operational mode, run the show ospf route detail command for Device R3.
Meaning
Purpose
Action
From operational mode, run the show ospf3 route detail command for Device R3.
Meaning
Purpose
Action
From operational mode, run the show backup-selection command for Device R3.
Meaning
The output displays the configured policies per prefix per primary next-hop interface.
604
SEE ALSO
IN THIS SECTION
Requirements | 604
Overview | 604
Configuration | 605
Verification | 608
Troubleshooting | 609
This example shows how to create a policy that injects OSPF routes into the BGP routing table.
Requirements
Before you begin:
• Configure external peer sessions. See Example: Configuring External BGP Point-to-Point Peer
Sessions.
Overview
IN THIS SECTION
Topology | 605
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.
605
Topology
Configuration
IN THIS SECTION
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.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
4. Specify that the route is to be accepted if the previous conditions are matched.
[edit]
user@host# set protocols bgp export injectpolicy1
Results
Confirm your configuration by entering the show policy-options and show protocols bgp commands from
configuration mode. If the output does not display the intended configuration, repeat the instructions in
this example to correct the configuration.
}
}
If you are done configuring the device, enter commit from configuration mode.
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.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
Results
Confirm your configuration by entering the show policy-options and show routing-options commands from
configuration mode. If the output does not display the intended configuration, repeat the instructions in
this example to correct the configuration.
If you are done configuring the device, enter commit from configuration mode.
Verification
IN THIS SECTION
Purpose
Action
Troubleshooting
IN THIS SECTION
Using the show log Command to Examine the Actions of the Routing Policy | 609
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.
IN THIS SECTION
Requirements | 610
Overview | 610
610
Configuration | 611
Verification | 613
This example shows how to create a policy that redistributes static routes into OSPF.
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
Overview
IN THIS SECTION
Topology | 610
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
611
Configuration
IN THIS SECTION
Procedure | 611
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
Step-by-Step Procedure
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.
[edit]
user@host# edit policy-options policy-statement exportstatic1
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[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 the
output does not display the intended configuration, repeat the instructions in this example to correct
the configuration.
}
}
To confirm your OSPFv3 configuration, enter the show policy-options and the show protocols ospf3
commands.
Verification
IN THIS SECTION
Verifying That AS External LSAs Are Added to the Routing Table | 613
Purpose
Action
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.
614
Action
From operational mode, enter the show ospf database command for OSPFv2, and enter the show ospf3
database command for OSPFv3.
IN THIS SECTION
Requirements | 614
Overview | 614
Configuration | 615
Verification | 619
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:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58.
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63 .
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.
615
For OSPFv3, the link-state advertisement (LSA) is referred to as the interarea prefix LSA and performs
the same function as a network-summary LSA performs for OSPFv2. An area border router (ABR)
originates an interarea prefix LSA for each IPv6 prefix that must be advertised into an area.
OSPF import policy allows you to prevent external routes from being added to the routing tables of
OSPF neighbors. The import policy does not impact the OSPF database. This means that the import
policy has no impact on the link-state advertisements. The filtering is done only on external routes in
OSPF. The intra-area and interarea routes are not considered for filtering. The default action is to accept
the route when the route does not match the policy.
• 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 | 616
616
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.
[edit]
set interfaces so-0/2/0 unit 0 family inet address 10.0.2.1/30
set protocols ospf export export_static
set protocols ospf area 0.0.0.0 interface so-0/2/0
set policy-options policy-statement export_static from protocol static
set policy-options policy-statement export_static then accept
[edit]
set interfaces so-0/2/0 unit 0 family inet address 10.0.2.2/30
set protocols ospf import filter_routes
set protocols ospf area 0.0.0.0 interface so-0/2/0
set policy-options policy-statement filter_routes from route-filter 10.0.16.0/30 exact
set policy-options policy-statement filter_routes then reject
Procedure
Step-by-Step Procedure
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 theCLI User Guide.
[edit]
user@R1# set interfaces so-0/2/0 unit 0 family inet address 10.0.2.1/30
[edit]
user@R2# set interfaces so-0/2/0 unit 0 family inet address 10.0.2.2/30
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@R1# set protocols ospf area 0.0.0.0 interface so-0/2/0
[edit]
user@R2# set protocols ospf area 0.0.0.0 interface so-0/2/0
[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
[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
618
[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.
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
Purpose
Verify that OSPF is advertising the static route in the OSPF database.
Action
From operational mode, enter the show ospf database for OSPFv2, and enter the show ospf3 database
command for OSPFv3.
Purpose
Action
IN THIS SECTION
Requirements | 621
Overview | 621
Configuration | 622
Verification | 626
This example shows how to create an OSPF import policy that prioritizes specific prefixes learned
through OSPF.
621
Requirements
Before you begin:
• Configure the device interfaces. See the Interfaces User Guide for Security Devices.
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election See "Example: Controlling OSPF Designated Router
Election" on page 58
• Configure a single-area OSPF network. See "Example: Configuring a Single-Area OSPF Network" on
page 63 .
• Configure a multiarea OSPF network. See "Example: Configuring a Multiarea OSPF Network" on
page 66.
Overview
IN THIS SECTION
Topology | 622
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:
• Local routes that are not added to the routing table are assigned a priority of low.
622
• 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 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 | 623
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 interfaces fe-0/1/0 unit 0 family inet address 192.168.8.4/30
set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.5/30
set policy-options policy-statement ospf-import term t1 from route-filter 203.0.113.0/24 orlonger
623
Procedure
Step-by-Step Procedure
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 theCLI User Guide.
[edit]
user@host# set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.4/30
user@host# set interfaces fe-0/2/0 unit 0 family inet address 192.168.8.5/30
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# set protocols ospf area 0.0.0.0 interface fe-0/1/0
user@host# set protocols ospf area 0.0.0.0 interface fe-0/2/0
624
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
user@host# set policy-options policy-statement ospf-import term t2 from route-filter
198.51.100.0/24 orlonger
user@host# set policy-options policy-statement ospf-import term t2 then priority medium
user@host# set policy-options policy-statement ospf-import term t2 then accept
user@host# set policy-options policy-statement ospf-import term t3 from route-filter
192.0.2.0/24 orlonger
user@host# set policy-options policy-statement ospf-import term t3 then priority high
user@host# set policy-options policy-statement ospf-import term t3 then accept
[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 protocols ospf
commands. If the output does not display the intended configuration, repeat the instructions in this
example to correct the configuration.
}
fe-0/2/0 {
unit 0 {
family inet {
address 192.168.8.5/30;
}
}
}
then {
priority high;
accept;
}
}
}
To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show protocols
ospf3 commands.
Verification
IN THIS SECTION
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.
627
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.
IN THIS SECTION
Requirements | 627
Overview | 628
Configuration | 630
Verification | 639
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:
628
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58
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.
• 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 35 on page 629 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.
629
Figure 35: 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.
• 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.
• R4—Device R4 participates in area 0 and area 4. R4 is the ABR between area 0 and area 4, and
passes network-summary LSAs between the areas. Interface fe-0/0/1 has an IP address of 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.
630
• R5—Device R5 is an internal router in area 4. Interface fe-1/1/0 has an IP address of 10.0.8.5/30 and
connects to R4.
• R6—Device R6 is an internal router in area 4. Interface fe-1/0/0 has an IP address of 10.0.8.10/30 and
connects to R4.
Configuration
IN THIS SECTION
Procedure | 632
To quickly configure an OSPF export policy for network summaries, 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 fe-0/1/0 unit 0 family inet address 10.0.4.13/30
set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30
set protocols ospf area 0.0.0.3 interface fe-0/1/0
set protocols ospf area 0.0.0.3 interface fe-0/0/1
[edit]
set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30
set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.1/30
set protocols ospf area 0.0.0.3 interface fe-0/1/0
set protocols ospf area 0.0.0.3 interface fe-1/0/0
631
[edit]
set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30
set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30
set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
set protocols ospf area 0.0.0.3 interface fe-1/0/0
set protocols ospf area 0.0.0.3 interface fe-1/1/0
set protocols ospf area 0.0.0.0 interface fe-0/0/1
[edit]
set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.6/30
set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.9/30
set policy-options policy-statement export-policy term term1 from route-filter 10.0.4.4/30
prefix-length-range /30-/30
set policy-options policy-statement export-policy term term1 then accept
set protocols ospf area 0.0.0.0 interface fe-0/0/1
set protocols ospf area 0.0.0.4 interface fe-0/1/0
set protocols ospf area 0.0.0.4 interface fe-1/0/0
set protocols ospf area 0.0.0.4 network-summary-export export-policy
[edit]
set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30
set protocols ospf area 0.0.0.4 interface fe-0/1/0
[edit]
set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.10/30
set protocols ospf area 0.0.0.4 interface fe-1/0/0
632
Procedure
Step-by-Step Procedure
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.
[edit]
user@R1# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30
user@R1# set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30
[edit]
user@R2# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30
user@R2# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.1/30
[edit]
user@R3# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30
user@R3# set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30
user@R3#set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
[edit]
user@R4# set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
633
[edit]
user@R5# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30
[edit]
user@R6# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.10/30
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@R1# set protocols ospf area 0.0.0.3 interface fe-0/1/0
user@R1# set protocols ospf area 0.0.0.3 interface fe-0/0/1
[edit]
user@R2# set protocols ospf area 0.0.0.3 interface fe-0/1/0
user@R2# set protocols ospf area 0.0.0.3 interface fe-1/0/0
[edit]
user@R3# set protocols ospf area 0.0.0.3 interface fe-1/0/0
user@R3# set protocols ospf area 0.0.0.3 interface fe-1/1/0
user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/1
[edit]
user@R4# set protocols ospf area 0.0.0.0 interface fe-0/0/1
634
[edit]
user@R5# set protocols ospf area 0.0.0.4 interface fe-1/1/0
[edit]
user@R6# set protocols ospf area 0.0.0.4 interface fe-1/0/0
[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
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
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.
635
}
}
interface fe-1/0/0.0;
interface fe-1/1/0.0;
}
interface fe-1/1/0.0;
}
}
}
To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show 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.
640
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.
IN THIS SECTION
Requirements | 640
Overview | 640
Configuration | 642
Verification | 651
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:
• Configure the router identifiers for the devices in your OSPF network. See "Example: Configuring an
OSPF Router Identifier" on page 55.
• Control OSPF designated router election. See "Example: Controlling OSPF Designated Router
Election" on page 58.
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
641
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.
• 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 36 on page 641 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 36: Sample Topology Used for an OSPF Import Network Summary Policy
642
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.
• 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/30 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.
• R4—Device R4 participates in area 0 and area 4. R4 is the ABR between area 0 and area 4, and
passes network-summary LSAs between the areas. Interface fe-0/0/1 has an IP address of 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.
• R5—Device R5 is an internal router in area 4. Interface fe-1/1/0 has an IP address of 10.0.8.5/30 and
connects to R4.
• R6—Device R6 is an internal router in area 4. Interface fe-1/0/0 has an IP address of 10.0.8.10/30 and
connects to R4.
Configuration
IN THIS SECTION
Procedure | 643
643
Procedure
To quickly configure an OSPF import policy for network summaries, 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 fe-0/1/0 unit 0 family inet address 10.0.4.13/30
set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30
set protocols ospf area 0.0.0.3 interface fe-0/1/0
set protocols ospf area 0.0.0.3 interface fe-0/0/1
[edit]
set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30
set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.1/30
set protocols ospf area 0.0.0.3 interface fe-0/1/0
set protocols ospf area 0.0.0.3 interface fe-1/0/0
[edit]
set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30
set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30
set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
set policy-options policy-statement import-policy term term1 from route-filter 10.0.4.12/30
prefix-length-range /30-/30
set policy-options policy-statement import-policy term term1 then accept
set protocols ospf area 0.0.0.3 interface fe-1/0/0
set protocols ospf area 0.0.0.3 interface fe-1/1/0
set protocols ospf area 0.0.0.0 interface fe-0/0/1
set protocols ospf area 0.0.0.3 network-summary-import import-policy
644
[edit]
set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.6/30
set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.9/30
set protocols ospf area 0.0.0.0 interface fe-0/0/1
set protocols ospf area 0.0.0.4 interface fe-1/1/0
set protocols ospf area 0.0.0.4 interface fe-1/0/0
[edit]
set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30
set protocols ospf area 0.0.0.4 interface fe-1/1/0
[edit]
set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.10/30
set protocols ospf area 0.0.0.4 interface fe-1/0/0
Step-by-Step Procedure
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.
[edit]
user@R1# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30
user@R1# set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30
[edit]
user@R2# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30
user@R2# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.1/30
[edit]
user@R3# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30
user@R3# set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30
user@R3#set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
[edit]
user@R4# set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30
user@R4# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.6/30
user@R4# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.9/30
[edit]
user@R5# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30
[edit]
user@R6# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.10/30
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@R1# set protocols ospf area 0.0.0.3 interface fe-0/1/0
user@R1# set protocols ospf area 0.0.0.3 interface fe-0/0/1
[edit]
user@R2# set protocols ospf area 0.0.0.3 interface fe-0/1/0
user@R2# set protocols ospf area 0.0.0.3 interface fe-1/0/0
[edit]
user@R3# set protocols ospf area 0.0.0.3 interface fe-1/0/0
user@R3# set protocols ospf area 0.0.0.3 interface fe-1/1/0
user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/1
[edit]
user@R4# set protocols ospf area 0.0.0.0 interface fe-0/0/1
user@R4# set protocols ospf area 0.0.0.4 interface fe-1/1/0
user@R4# set protocols ospf area 0.0.0.4 interface fe-1/0/0
[edit]
user@R5# set protocols ospf area 0.0.0.4 interface fe-1/1/0
[edit]
user@R6# set protocols ospf area 0.0.0.4 interface fe-1/0/0
[edit ]
user@R3# set policy-options policy-statement import-policy term term1 from route-filter
10.0.4.12/30 prefix-length-range /30-/30
user@R3# set policy-options policy-statement import-policy term term1 then accept
647
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
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.
}
}
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;
}
}
}
address 10.0.8.5/30;
}
}
}
To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show 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 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.
IN THIS SECTION
Requirements | 653
Overview | 653
Configuration | 654
Verification | 662
653
This example shows how to redistribute OSPF routes into an IS-IS network.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
IN THIS SECTION
Topology | 654
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.
"CLI Quick Configuration" on page 655 shows the configuration for all of the devices in Figure 37 on
page 654. The section "No Link Title" on page 656 describes the steps on Device R2. "No Link Title" on
page 658 describes the steps on Device R3.
Topology
Configuration
IN THIS SECTION
Procedure | 655
655
Procedure
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
Device R2
Device R3
Step-by-Step Procedure
[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 fe-1/2/0 unit 0 family inet address 10.0.0.45/30
user@R2# set lo0 unit 0 family inet address 172.16.9.7/32
user@R2# set lo0 unit 0 family iso address 49.0002.0172.0016.0907.00
657
2. Configure IS-IS on the interface facing Device R1 and the loopback interface.
3. Configure the policy that enables Device R1 to reach the 10.0.0.44/30 network.
4. Apply the policy that enables Device R1 to reach the 10.0.0.44/30 network.
8. Configure the policy that enables Device R3 to reach the 10.0.0.36/30 network.
9. Apply the policy that enables Device R3 to reach the 10.0.0.36/30 network.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
Multiple addresses are configured on the loopback interface to simulate multiple route destinations.
[edit interfaces]
user@R3# set fe-1/2/0 unit 0 family inet address 10.0.0.46/30
user@R3# set lo0 unit 0 family inet address 192.168.1.1/32
user@R3# set lo0 unit 0 family inet address 192.168.2.1/32
user@R3# set lo0 unit 0 family inet address 192.168.3.1/32
user@R3# set lo0 unit 0 family inet address 192.168.0.1/32
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 R2
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;
}
}
}
}
then accept;
}
}
policy-statement send-direct-to-isis-neighbors {
from {
protocol direct;
route-filter 10.0.0.44/30 exact;
}
then accept;
}
policy-statement send-direct-to-ospf-neighbors {
from {
protocol direct;
route-filter 10.0.0.36/30 exact;
}
then accept;
}
Device R3
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
IN THIS SECTION
Purpose
Action
From operational mode on Device R2, enter the show route protocol ospf command.
MultiRecv
Meaning
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.
Meaning
Verifying Connectivity
Purpose
Action
Meaning
These results confirm that Device R1 can reach the destinations in the OSPF network.
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.
666
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.
RELATED DOCUMENTATION
IN THIS SECTION
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 38 on page 669 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
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.
669
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:
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.
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
670
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.
IN THIS SECTION
Requirements | 670
Overview | 670
Configuration | 672
Verification | 679
This example shows how to enable OSPFv2 sham links on a PE routing device.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
IN THIS SECTION
Topology | 671
The sham link is an unnumbered point-to-point intra-area link and is advertised by means of a type 1
link-state advertisement (LSA). Sham links are valid only for routing instances and OSPFv2.
Each sham link is identified by a combination of the local endpoint address and a remote endpoint
address and the OSPFv2 area to which it belongs. You manually configure the sham link between two PE
devices, both of which are within the same VPN routing and forwarding (VRF) routing instance, and you
specify the address for the local end point of the sham link. This address is used as the source for the
sham link packets and is also used by the remote PE routing device as the sham link remote end point.
You can also include the optional metric option to set a metric value for the remote end point. The metric
671
value specifies the cost of using the link. Routes with lower total path metrics are preferred over those
with higher path metrics.
• 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.
Topology
"CLI Quick Configuration" on page 672 shows the configuration for all of the devices in Figure 39 on
page 671. The section "Step-by-Step Procedure" on page 675 describes the steps on Device PE1.
672
Configuration
IN THIS SECTION
Procedure | 672
Procedure
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
CE1
PE1
PE2
CE2
Step-by-Step Procedure
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 CLI User Guide.
[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
[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
4. Configure OSPF on the core-facing interface and on the loopback interface that is being used in the
main instance.
5. Configure LDP or RSVP on the core-facing interface and on the loopback interface that is being
used in the main instance.
Include the extra loopback interface in the routing instance and also in the OSPF configuration.
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.
9. Configure the autonomous system (AS) number and the router ID.
[edit routing-options]
user@PE1# set router-id 192.0.2.2
user@PE1# set autonomous-system 2
10. If you are done configuring the device, commit the configuration.
[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 correct
the configuration.
}
}
unit 1 {
family inet {
address 198.51.100.2/24;
}
}
}
then accept;
}
term 2 {
then reject;
}
}
Verification
IN THIS SECTION
Verifying the Local and Remote End Points of the Sham Link | 680
680
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.
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.
681
Action
From operational mode, enter the show ospf interface instance instance-name detail command.
Purpose
Action
From operational mode, enter the show ospf neighbor instance instance-name command.
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.
682
Action
From operational mode, enter the show ospf database instance instance-name command.
Purpose
Verify that the Layer 3 VPN path is used instead of the backup path.
Action
From operational mode, enter the traceroute command from Device CE1 to Device CE2.
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.
RELATED DOCUMENTATION
IN THIS SECTION
Example: Configuring OSPF on Logical Systems Within the Same Router | 686
IN THIS SECTION
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.
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:
IN THIS SECTION
Requirements | 686
Overview | 686
Configuration | 688
Verification | 693
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 | 687
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
687
all logical system interfaces that participate in the OSPF domain and specifies the area that the
interfaces are in.
Topology
Configuration
IN THIS SECTION
Procedure | 689
Results | 691
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.
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
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
2. Configure the logical tunnel interface on Logical System LS1 connecting to Logical System LS3.
[edit]
user@host# set logical-systems LS1 interfaces lt-1/2/0 unit 0 description LS1->LS3
user@host# set logical-systems LS1 interfaces lt-1/2/0 unit 0 encapsulation ethernet
user@host# set logical-systems LS1 interfaces lt-1/2/0 unit 0 peer-unit 5
user@host# set logical-systems LS1 interfaces lt-1/2/0 unit 0 family inet address 10.0.1.2/30
3. Configure the logical tunnel interface on Logical System LS2 connecting to Logical System LS1.
[edit]
user@host# set logical-systems LS2 interfaces lt-1/2/0 unit 1 description LS2->LS1
user@host# set logical-systems LS2 interfaces lt-1/2/0 unit 1 encapsulation ethernet
690
4. Configure the logical tunnel interface on Logical System LS2 connecting to Logical System LS3.
[edit]
user@host# set logical-systems LS2 interfaces lt-1/2/0 unit 4 description LS2->LS3
user@host# set logical-systems LS2 interfaces lt-1/2/0 unit 4 encapsulation ethernet
user@host# set logical-systems LS2 interfaces lt-1/2/0 unit 4 peer-unit 3
user@host# set logical-systems LS2 interfaces lt-1/2/0 unit 4 family inet address 10.0.2.2/30
5. Configure the logical tunnel interface on Logical System LS3 connecting to Logical System LS2.
[edit]
user@host# set logical-systems LS3 interfaces lt-1/2/0 unit 3 description LS3->LS2
user@host# set logical-systems LS3 interfaces lt-1/2/0 unit 3 encapsulation ethernet
user@host# set logical-systems LS3 interfaces lt-1/2/0 unit 3 peer-unit 4
user@host# set logical-systems LS3 interfaces lt-1/2/0 unit 3 family inet address 10.0.2.1/30
6. Configure the logical tunnel interface on Logical System LS3 connecting to Logical System LS1.
[edit]
user@host# set logical-systems LS3 interfaces lt-1/2/0 unit 5 description LS3->LS1
user@host# set logical-systems LS3 interfaces lt-1/2/0 unit 5 encapsulation ethernet
user@host# set logical-systems LS3 interfaces lt-1/2/0 unit 5 peer-unit 0
user@host# set logical-systems LS3 interfaces lt-1/2/0 unit 5 family inet address 10.0.1.1/30
[edit]
user@host# set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.0
user@host# set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.2
user@host# set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.1
user@host# set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.4
user@host# set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.5
user@host# set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.3
691
[edit]
user@host# commit
Results
show logical-systems
LS1 {
interfaces {
lt-1/2/0 {
unit 0 {
description LS1->LS3;
encapsulation ethernet;
peer-unit 5;
family inet {
address 10.0.1.2/30;
}
}
unit 2 {
description LS1->LS2;
encapsulation ethernet;
peer-unit 1;
family inet {
address 10.0.0.1/30;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lt-1/2/0.0;
interface lt-1/2/0.2;
}
}
}
}
LS2 {
692
interfaces {
lt-1/2/0 {
unit 1 {
description LS2->LS1;
encapsulation ethernet;
peer-unit 2;
family inet {
address 10.0.0.2/30;
}
}
unit 4 {
description LS2->LS3;
encapsulation ethernet;
peer-unit 3;
family inet {
address 10.0.2.2/30;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lt-1/2/0.1;
interface lt-1/2/0.4;
}
}
}
}
LS3 {
interfaces {
lt-1/2/0 {
unit 3 {
description LS3->LS2;
encapsulation ethernet;
peer-unit 4;
family inet {
address 10.0.2.1/30;
}
}
unit 5 {
description LS3->LS1;
encapsulation ethernet;
693
peer-unit 0;
family inet {
address 10.0.1.1/30;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lt-1/2/0.5;
interface lt-1/2/0.3;
}
}
}
}
Verification
IN THIS SECTION
Purpose
Action
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
RELATED DOCUMENTATION
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
697
IN THIS SECTION
Evaluating the Solution to Check Whether the Network Problem Is Resolved | 707
IN THIS SECTION
Problem | 699
Solution | 700
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.
700
Solution
1. Identifying the Symptoms of a Broken Network ping (ip-address | hostname) show route (ip-address
Connection | 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 Network [edit] delete routing options static route
Problem destination-prefix commit and-quit show route
destination-prefix
1. Evaluating the Solution to Check Whether the Network show route (ip-address | hostname) ping (ip-address
Problem Is Resolved | hostname) count 3 traceroute (ip-address |
hostname)
By applying the standard four-step process illustrated in Figure 41 on page 700, 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.
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 42 on page 701 shows the network topology used in this topic to illustrate the process of
diagnosing problems in a network.
The network in Figure 42 on page 701 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:
IN THIS SECTION
Problem | 702
Solution | 702
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:
Sample Output
^C
--- 10.0.0.5 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
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.
704
IN THIS SECTION
Problem | 704
Solution | 704
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:
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
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).
IN THIS SECTION
Problem | 706
Solution | 706
706
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
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
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 (*).
IN THIS SECTION
Problem | 707
Solution | 708
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.
708
Solution
Sample Output
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 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).
709
IN THIS SECTION
Problem | 709
Solution | 709
Problem
Description
Table 3 on page 709 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
1. Configure Routing Protocol Tracing for a Specific Routing Protocol [edit] edit protocol protocol-name traceo
filename size size files number show com
log filename
1. Monitor Trace File Messages Written in Near-Real Time monitor start filename
1. Display Detailed BGP Protocol Information [edit] edit protocol bgp traceoptions se
detail show commit run show log filename
1. Display Sent or Received BGP Packets [edit] edit protocol bgp traceoptions se
(send | receive) show commit run show lo
1. Diagnose BGP Session Establishment Problems [edit] edit protocol bgp set traceoption
detail show commit run show log filename
1. Displaying Detailed IS-IS Protocol Information [edit] edit protocol isis traceoptions s
detail show commit run show log filename
1. Displaying Sent or Received IS-IS Protocol Packets [edit] edit protocols isis traceoptions
(send | receive) show commit run show lo
1. Analyzing IS-IS Link-State PDUs in Detail [edit] edit protocols isis traceoptions
detail show commit run show log filename
1. Diagnose OSPF Session Establishment Problems [edit] edit protocols ospf traceoptions
detail show commit run show log filename
1. Analyze OSPF Link-State Advertisement Packets in Detail [edit] edit protocols ospf traceoptions
update detail show commit run show log f
711
IN THIS SECTION
Action | 711
Meaning | 713
Action
[edit]
user@host# edit routing-options traceoptions
For example:
user@host# show
712
For example:
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.
For example:
Meaning
Table 4 on page 713 lists tracing flags and example output for Junos-supported routing protocol
daemon tracing.
policy Policy Nov 29 22:19:58 export: Dest 10.0.0.0 proto Static Nov 29 22:19:58
operations and policy_match_qual_or: Qualifier proto Sense: 0 Nov 29 22:19:58 policy_match_qual_or:
actions Qualifier proto Sense: 0 Nov 29 22:19:58 export: Dest 10.10.10.0 proto IS-IS
route Routing table Nov 29 22:23:59 Nov 29 22:23:59 rtlist_walker_job: rt_list walk for RIB inet.0 started
changes 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
task Interface Nov 29 22:50:04 foreground dispatch running job task_collect for task Scheduler Nov 29
transactions 22:50:04 task_collect_job: freeing task MGMT_Listen (DELETED) Nov 29 22:50:04
and processing foreground dispatch completed job task_collect 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
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
IN THIS SECTION
Action | 714
Meaning | 716
Action
To configure routing protocol tracing for a specific routing protocol, follow these steps:
715
[edit]
user@host# edit protocol protocol-name traceoptions
For example:
user@host# show
For example:
user@host# commit
716
For example:
Meaning
Table 5 on page 716 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.
IN THIS SECTION
Purpose | 717
Action | 718
Purpose
To monitor messages in near-real time as they are being written to a trace file.
718
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:
Sample Output
command-name
IN THIS SECTION
Action | 719
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:
Sample Output
IN THIS SECTION
IN THIS SECTION
IN THIS SECTION
Purpose | 722
Action | 722
Meaning | 722
722
Purpose
Verify that OSPF is running on a particular interface and that the interface is in the desired area.
Action
Sample Output
command-name
Meaning
The output shows a list of the device interfaces that are configured for OSPF. Verify the following
information:
• 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.
IN THIS SECTION
Purpose | 723
Action | 723
Meaning | 723
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
Sample Output
command-name
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:
724
• 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.
IN THIS SECTION
Purpose | 724
Action | 725
Meaning | 726
Purpose
Verify that the OSPF routing table has entries for the following:
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
Sample Output
command-name
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.
IN THIS SECTION
Purpose | 726
Action | 726
Meaning | 727
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
2. In the Host Name box, type the name of a host for which you want to verify reachability from the
device.
Sample Output
command-name
Meaning
Each numbered row in the output indicates a routing “hop” in the path to the host. The three-time
increments indicate the round-trip time (RTT) between the device and the hop, for each traceroute
packet. To ensure that the OSPF network is healthy, verify the following information:
• The final hop in the list is the host you want to reach.
• The number of expected hops to the host matches the number of hops in the traceroute output. The
appearance of more hops than expected in the output indicates that a network segment is likely not
reachable. In this case, verify the routes with the show ospf route command.
For information about show ospf route, see "Verifying the Number of OSPF Routes" on page 721
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.
• database-description—All database description packets, which are used in synchronizing the OSPF
topological database
• graceful-restart—Graceful-restart events
728
• hello—Hello packets, which are used to establish neighbor adjacencies and to determine whether
neighbors are reachable
• lsa-ack—Link-state acknowledgment packets, which are used in synchronizing the OSPF topological
database
• 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
You can optionally specify one or more of the following flag modifiers:
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:
• 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
NOTE: Use the trace flag all with caution as it might cause the CPU to become very busy.
IN THIS SECTION
Requirements | 729
Overview | 729
Configuration | 731
Verification | 736
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
730
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.
731
Configuration
IN THIS SECTION
Configuring Global Tracing Operations and Tracing OSPF Packet Information | 731
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
Step-by-Step Procedure
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 configure global routing tracing operations and tracing operations for OSPF packets:
732
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
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf traceoptions
user@host# set file ospf-log
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.
To confirm your OSPFv3 configuration, enter the show routing-options and the show protocols ospf3
commands.
734
To quickly trace SPF calculations, copy the following commands and paste them into the CLI.
[edit]
set protocols ospf traceoptions file ospf-log
set protocols ospf traceoptions flag spf
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf traceoptions
user@host# set file ospf-log
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
To quickly trace the creation, receipt, and retransmission of all LSAs, copy the following commands and
paste them into the CLI.
[edit]
set protocols ospf traceoptions file ospf-log
set protocols ospf traceoptions flag lsa-request
set protocols ospf traceoptions flag lsa-update
set protocols ospf traceoptions flag lsa-ack
Step-by-Step Procedure
NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# edit protocols ospf traceoptions
user@host# set file ospf-log
736
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.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
Verification
IN THIS SECTION
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.
RELATED DOCUMENTATION
IN THIS SECTION
Syntax | 739
Description | 739
Options | 739
Syntax
Description
Displays a list of sensors associated with the OSPF Source Packet Routing in Networking (SPRING) route
and next hops for segment routing traffic. The command only displays the information related to the
sensors and not the traffic statistics.
Options
view
Output Fields
Table 1 describes the output fields for the show ospf spring sensor info command. Output fields are listed
in the approximate order in which they appear.
Sensor-name Represents the router or interface that the sensor is associated with.
Sample Output
----------------------
Sensor-name Sensor-id
16 3489660934
500002 3489660937
Release Information
Command introduced in Junos OS Release 23.1R1 and Junos OS Evolved Release 23.1R1.
RELATED DOCUMENTATION
We've consolidated all Junos CLI commands and configuration statements in one place. Learn about the
syntax and options that make up the statements and commands and understand the contexts in which
you’ll use these CLI elements in your network configurations and operations.
Click the links to access Junos OS and Junos OS Evolved configuration statement and command
summary topics.
• Configuration Statements
• CLI Commands