Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring OSPF on Logical Systems

OSPF Overview

OSPF is an interior gateway protocol (IGP) that routes packets within a single autonomous system (AS). OSPF uses link-state information to make routing decisions, making route calculations using the shortest-path-first (SPF) algorithm (also referred to as the Dijkstra algorithm). Each router running OSPF floods link-state advertisements throughout the AS or area that contain information about that router’s attached interfaces and routing metrics. Each router uses the information in these link-state advertisements to calculate the least cost path to each network and create a routing table for the protocol.

Junos OS supports OSPF version 2 (OSPFv2) and OSPF version 3 (OSPFv3), including virtual links, stub areas, and for OSPFv2, authentication. Junos OS does not support type-of-service (ToS) routing.

OSPF was designed for the Transmission Control Protocol/Internet Protocol (TCP/IP) environment and as a result explicitly supports IP subnetting and the tagging of externally derived routing information. OSPF also provides for the authentication of routing updates.

OSPF routes IP packets based solely on the destination IP address contained in the IP packet header. OSPF quickly detects topological changes, such as when router interfaces become unavailable, and calculates new loop-free routes quickly and with a minimum of routing overhead traffic.

Note: On SRX Series devices, when only one link-protection is configured under the OSPF interface, the device does not install an alternative route in the forwarding table. When the per-packet load-balancing is enabled as a workaround, the device does not observe both the OSPF metric and sending the traffic through both the interfaces.

An OSPF AS can consist of a single area, or it can be subdivided into multiple areas. In a single-area OSPF network topology, each router maintains a database that describes the topology of the AS. Link-state information for each router is flooded throughout the AS. In a multiarea OSPF topology, each router maintains a database that describes the topology of its area, and link-state information for each router is flooded throughout that area. All routers maintain summarized topologies of other areas within an AS. Within each area, OSPF routers have identical topological databases. When the AS or area topology changes, OSPF ensures that the contents of all routers’ topological databases converge quickly.

All OSPFv2 protocol exchanges can be authenticated. OSPFv3 relies on IPsec to provide this functionality. This means that only trusted routers can participate in the AS’s routing. A variety of authentication schemes can be used. A single authentication scheme is configured for each area, which enables some areas to use stricter authentication than others.

Externally derived routing data (for example, routes learned from BGP) is passed transparently throughout the AS. This externally derived data is kept separate from the OSPF link-state data. Each external route can be tagged by the advertising router, enabling the passing of additional information between routers on the boundaries of the AS.

Note: By default, Junos OS is compatible with RFC 1583, OSPF Version 2. In Junos OS Release 8.5 and later, you can disable compatibility with RFC 1583 by including the no-rfc-1583 statement. For more information, see Example: Disabling OSPFv2 Compatibility with RFC 1583.

This topic describes the following information:

• OSPF Default Route Preference Values
• OSPF Routing Algorithm
• OSPF Three-Way Handshake
• OSPF Version 3

OSPF Default Route Preference Values

The Junos OS routing protocol process assigns a default preference value to each route that the routing table receives. The default value depends on the source of the route. The preference value is from 0 through 4,294,967,295 (232 – 1), with a lower value indicating a more preferred route. Table 1 lists the default preference values for OSPF.

OSPF Routing Algorithm

OSPF uses the shortest-path-first (SPF) algorithm, also referred to as the Dijkstra algorithm, to determine the route to each destination. All routing devices in an area run this algorithm in parallel, storing the results in their individual topological databases. Routing devices with interfaces to multiple areas run multiple copies of the algorithm. This section provides a brief summary of how the SPF algorithm works.

When a routing device starts, it initializes OSPF and waits for indications from lower-level protocols that the router interfaces are functional. The routing device then uses the OSPF hello protocol to acquire neighbors, by sending hello packets to its neighbors and receiving their hello packets.

On broadcast or nonbroadcast multiaccess networks (physical networks that support the attachment of more than two routing devices), the OSPF hello protocol elects a designated router for the network. This routing device is responsible for sending link-state advertisements (LSAs) that describe the network, which reduces the amount of network traffic and the size of the routing devices’ topological databases.

The routing device then attempts to form adjacencies with some of its newly acquired neighbors. (On multiaccess networks, only the designated router and backup designated router form adjacencies with other routing devices.) Adjacencies determine the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies, and topological database updates are sent only along adjacencies. When adjacencies have been established, pairs of adjacent routers synchronize their topological databases.

A routing device sends LSA packets to advertise its state periodically and when its state changes. These packets include information about the routing device’s adjacencies, which allows detection of nonoperational routing devices.

Using a reliable algorithm, the routing device floods LSAs throughout the area, which ensures that all routing devices in an area have exactly the same topological database. Each routing device uses the information in its topological database to calculate a shortest-path tree, with itself as the root. The routing device then uses this tree to route network traffic.

The description of the SPF algorithm up to this point has explained how the algorithm works within a single area (intra-area routing). For internal routers to be able to route to destinations outside the area (interarea routing), the area border routers must inject additional routing information into the area. Because the area border routers are connected to the backbone, they have access to complete topological data about the backbone. The area border routers use this information to calculate paths to all destinations outside its area and then advertise these paths to the area’s internal routers.

Autonomous system (AS) boundary routers flood information about external autonomous systems throughout the AS, except to stub areas. Area border routers are responsible for advertising the paths to all AS boundary routers.

OSPF Three-Way Handshake

OSPF creates a topology map by flooding LSAs across OSPF-enabled links. LSAs announce the presence of OSPF-enabled interfaces to adjacent OSPF interfaces. The exchange of LSAs establishes bidirectional connectivity between all adjacent OSPF interfaces (neighbors) using a three-way handshake, as shown in Figure 1.

Figure 1: OSPF Three-Way Handshake

In Figure 1, 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:

• All neighbor ID information is based on a 32-bit router ID.
• The protocol runs per link rather than per subnet.
• Router and network link-state advertisements (LSAs) do not carry prefix information.
• Two new LSA types are included: link-LSA and intra-area-prefix-LSA.
• Flooding scopes are as follows:
  • Link-local
  • Area
  • AS
• Link-local addresses are used for all neighbor exchanges except virtual links.
• Authentication is removed. The IPv6 authentication header relies on the IP layer.
• The packet format has changed as follows:
  • Version number 2 is now version number 3.
  • The db option field has been expanded to 24 bits.
  • Authentication information has been removed.
  • Hello messages do not have address information.
  • Two new option bits are included: R and V6.
• Type 3 summary LSAs have been renamed inter-area-prefix-LSAs.
• Type 4 summary LSAs have been renamed inter-area-router-LSAs.

Example: Configuring OSPF on Logical Systems Within the Same Router

This example shows how to configure an OSPF network using multiple logical systems that are running on a single physical router. The logical systems are connected by logical tunnel interfaces.

• Requirements
• Overview
• Configuration
• Verification

Requirements

You must connect the logical systems by using logical tunnel (lt) interfaces. See Example: Connecting Logical Systems Within the Same Router Using Logical Tunnel Interfaces.

Overview

This example shows the configuration of a single OSPF area with three logical systems running on one physical router. Each logical system has its own routing table. The configuration enables the protocol on all logical system interfaces that participate in the OSPF domain and specifies the area that the interfaces are in.

Figure 2 shows the sample network.

Figure 2: OSPF on Logical Systems

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

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 user@host# set logical-systems LS2 interfaces lt-1/2/0 unit 1 peer-unit 2 user@host# set logical-systems LS2 interfaces lt-1/2/0 unit 1 family inet address 10.0.0.2/30

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

7. Configure OSPF on all the interfaces.

   [edit]user@host# set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.0 user@host# set logical-systems LS1 protocols ospf area 0.0.0.0 interface lt-1/2/0.2 user@host# set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.1 user@host# set logical-systems LS2 protocols ospf area 0.0.0.0 interface lt-1/2/0.4 user@host# set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.5 user@host# set logical-systems LS3 protocols ospf area 0.0.0.0 interface lt-1/2/0.3

8. If you are done configuring the device, commit the configuration.

   [edit]user@host# commit

Results

Confirm your configuration by issuing the show logical-systems command.

Verification

Confirm that the configuration is working properly.

• Verifying That the Logical Systems Are Up
• Verifying Connectivity Between the Logical Systems

Verifying That the Logical Systems Are Up

Purpose

Make sure that the interfaces are properly configured.

Action

Interface               Admin Link Proto    Local                 Remote
...
lt-1/2/0                up    up  
lt-1/2/0.0              up    up   inet     10.0.1.2/30     
lt-1/2/0.1              up    up   inet     10.0.0.2/30     
lt-1/2/0.2              up    up   inet     10.0.0.1/30     
lt-1/2/0.3              up    up   inet     10.0.2.1/30     
lt-1/2/0.4              up    up   inet     10.0.2.2/30     
lt-1/2/0.5              up    up   inet     10.0.1.1/30     
...

Verifying Connectivity Between the Logical Systems

Purpose

Make sure that the OSPF adjacencies are established by checking the OSPF neighbor tables, checking the routing tables, and pinging the logical systems.

Action

Address          Interface              State     ID               Pri  Dead
10.0.1.1         lt-1/2/0.0             Full      10.0.1.1         128    37
10.0.0.2         lt-1/2/0.2             Full      10.0.0.2         128    33

Address          Interface              State     ID               Pri  Dead
10.0.0.1         lt-1/2/0.1             Full      10.0.0.1         128    32
10.0.2.1         lt-1/2/0.4             Full      10.0.1.1         128    36

Address          Interface              State     ID               Pri  Dead
10.0.2.2         lt-1/2/0.3             Full      10.0.0.2         128    36
10.0.1.2         lt-1/2/0.5             Full      10.0.0.1         128    37

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/30        *[Direct/0] 00:28:00
                    > via lt-1/2/0.2
10.0.0.1/32        *[Local/0] 00:28:00
                      Local via lt-1/2/0.2
10.0.1.0/30        *[Direct/0] 00:28:00
                    > via lt-1/2/0.0
10.0.1.2/32        *[Local/0] 00:28:00
                      Local via lt-1/2/0.0
10.0.2.0/30        *[OSPF/10] 00:27:05, metric 2
                    > to 10.0.1.1 via lt-1/2/0.0
                      to 10.0.0.2 via lt-1/2/0.2
224.0.0.5/32       *[OSPF/10] 00:28:03, metric 1
                      MultiRecv

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

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

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/30        *[OSPF/10] 00:28:23, metric 2
                    > to 10.0.2.2 via lt-1/2/0.3
                      to 10.0.1.2 via lt-1/2/0.5
10.0.1.0/30        *[Direct/0] 00:29:13
                    > via lt-1/2/0.5
10.0.1.1/32        *[Local/0] 00:29:15
                      Local via lt-1/2/0.5
10.0.2.0/30        *[Direct/0] 00:29:14
                    > via lt-1/2/0.3
10.0.2.1/32        *[Local/0] 00:29:15
                      Local via lt-1/2/0.3
224.0.0.5/32       *[OSPF/10] 00:29:16, metric 1
                      MultiRecv

PING 10.0.2.1 (10.0.2.1): 56 data bytes
64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=1.215 ms
64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=1.150 ms
64 bytes from 10.0.2.1: icmp_seq=2 ttl=64 time=1.134 ms

PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=1.193 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=1.114 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=1.190 ms