Supported Platforms
Example: Configuring a Multiarea Adjacency for OSPFv3
Understanding Multiarea Adjacencies for OSPFv3
An area is a set of networks and hosts within an OSPFv3 domain that have been administratively grouped together. By default, a single interface can belong to only one OSPFv3 area. However, in some situations, you might want to configure an interface to belong to more than one area to avoid suboptimal routing. Doing so allows the corresponding link to be considered an intra-area link in multiple areas and to be preferred over higher-cost intra-area links.
In Junos OS Release 9.2 and later, you can configure an interface to belong to more than one OSPFv2 area. Support for OSPFv3 was introduced in Junos OS Release 9.4. As defined in RFC 5185, OSPF Multi-Area Adjacency, the ABRs establish multiple adjacencies belonging to different areas over the same logical interface. Each multiarea adjacency is announced as a point-to-point unnumbered link in the configured area by the routers connected to the link.
An interface is considered to be primarily in one area. When you configure the same interface in another area, it is considered to be secondarily in the other area. You designate the secondary area by including the secondary statement at the [edit protocols ospf3 area area-number interface interface-name] hierarchy level.
Example: Configuring a Multiarea Adjacency for OSPFv3
This example shows how to configure a multiarea adjacency for OSPFv3.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
OSPFv3 intra-area paths are preferred over inter-area paths. In this example, Device R1 and Device R2 are area border routers (ABRs) with interfaces in both area 0 and in area 1. The link between Device R1 and R2 is in area 0 and is a high-speed link. The links in area 1 are lower speed.
If you want to forward some of area 1’s traffic between Device R1 and Device R2 over the high-speed link, one method to accomplish this goal is to make the high-speed link a multiarea adjacency so that the link is part of both area 0 and area 1.
If the high-speed link between Device R1 and Device R2 remains in area 1 only, Device R1 always routes traffic to Device R4 and Device R5 through area 1 over the lower-speed links. Device R1 also uses the intra-area area 1 path through Device R3 to get to area 1 destinations downstream of Device R2.
Clearly, this scenario results in suboptimal routing.
An OSPF virtual link cannot be used to resolve this issue without moving the link between Device R1 and Device R2 to area 1. You might not want to do this if the physical link belongs to the network's backbone topology.
The OSPF/OSPFv3 protocol extension described in RFC 5185, OSPF Multi-Area Adjacency resolves the issue, by allowing the link between Device R1 and Device R2 to be part of both the backbone area and area 1.
To create a multiarea adjacency, you configure an interface to be in two areas, with ge-1/2/0 on Device R1 configured in both area 0 and area 1, and ge-1/2/0 on Device R2 configured in both area 0 and area 1. On both Device R1 and Device R2, area 0 contains the primary interface and is the primary link between the devices. Area 1 contains the secondary logical interface, which you configure by including the secondary statement.
Figure 1: OSPFv3 Multiarea Adjacency
CLI Quick Configuration shows the configuration for all of the devices in Figure 1. The section Step-by-Step Procedure describes the steps on Device R1 and Device R2.
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.
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.
To configure Device R1:
- Configure the interfaces.[edit interfaces]user@R1# set ge-1/2/0 unit 0 family inet6 address 9009:1::1/64user@R1# set fe-1/2/1 unit 0 family inet6 address 9009:2::2/64user@R1# set lo0 unit 0 family inet address 1.1.1.1/32user@R1# set lo0 unit 0 family inet6 address 1::1/128
- Enable OSPFv3 on the interfaces that are in area 0.[edit protocols ospf3 area 0.0.0.0]user@R1# set interface ge-1/2/0.0user@R1# set interface lo0.0 passive
- Enable OSPFv3 on the interface that is in area 1.[edit protocols ospf3 area 0.0.0.1]user@R1# set interface fe-1/2/1.0user@R1# set interface ge-1/2/0.0 secondary
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 R2:
- Configure the interfaces.[edit interfaces]user@R2# set ge-1/2/0 unit 0 family inet6 address 9009:1::2/64user@R2# set fe-1/2/1 unit 0 family inet6 address 9009:4::1/64user@R2# set fe-1/2/2 unit 0 family inet6 address 9009:6::2/64user@R2# set lo0 unit 0 family inet address 2.2.2.2/32user@R2# set lo0 unit 0 family inet6 address 2::2/128
- Enable OSPFv3 on the interfaces that are in area 0.[edit protocols ospf3 area 0.0.0.0]user@R2# set interface ge-1/2/0.0user@R2# set interface lo0.0 passive
- Enable OSPFv3 on the interface that is in area 1.[edit protocols ospf3 area 0.0.0.1]user@R2# set interface fe-1/2/2.0user@R2# set interface fe-1/2/1.0user@R2# set interface ge-1/2/0.0 secondary
Results
From configuration mode, confirm your configuration by entering the show interfaces and show protocols commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
Device R1
Device R2
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
Verifying the Flow of Traffic
Purpose
Verify that traffic uses the high-speed link between Device R1 and Device R2 to reach destinations in area 1.
Action
From operational mode on Device R1, use the traceroute command check the traffic flow to Device R5 and Device R6.
user@R1> traceroute 6::6traceroute6 to 6::6 (6::6) from 9009:1::1, 64 hops max, 12 byte packets 1 9009:1::2 (9009:1::2) 1.361 ms 1.166 ms 1.117 ms 2 6::6 (6::6) 1.578 ms 1.484 ms 1.488 ms
user@R1> traceroute 5::5traceroute6 to 5::5 (5::5) from 9009:1::1, 64 hops max, 12 byte packets 1 9009:1::2 (9009:1::2) 1.312 ms 1.472 ms 1.132 ms 2 9009:4::1 (9009:4::1) 1.137 ms 1.174 ms 1.126 ms 3 5::5 (5::5) 1.591 ms 1.445 ms 1.441 ms
Meaning
The traceroute output shows that traffic uses the 9009:1:: link between Device R1 and Device R2.
Verifying That the Traffic Flow Changes When You Remove the Multiarea Adjacency
Purpose
Verify the results without the multiarea adjacency configured.
Action
- Deactivate the backbone link interfaces in area 1.user@R1# deactivate protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0user@R1# commituser@R2# deactivate protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0user@R2# commit
- From operational mode on Device R1, use the traceroute command check the traffic flow to Device R5 and Device R6.
user@R1> traceroute 6::6traceroute6 to 6::6 (6::6) from 9009:2::2, 64 hops max, 12 byte packets 1 9009:2::1 (9009:2::1) 1.314 ms 8.523 ms 8.310 ms 2 9009:3::2 (9009:3::2) 1.166 ms 1.162 ms 1.172 ms 3 9009:4::1 (9009:4::1) 1.386 ms 1.182 ms 1.138 ms 4 6::6 (6::6) 1.605 ms 1.469 ms 1.438 ms
user@R1> traceroute 5::5traceroute6 to 5::5 (5::5) from 9009:2::2, 64 hops max, 12 byte packets 1 9009:2::1 (9009:2::1) 1.365 ms 1.174 ms 1.133 ms 2 9009:3::2 (9009:3::2) 1.157 ms 1.198 ms 1.138 ms 3 5::5 (5::5) 1.584 ms 1.461 ms 1.443 ms
Meaning
Without the multiarea adjacency, the output shows suboptimal routing with traffic taking the path through the area 1 low-speed-links.
