Purpose
For OSPF to run on a router in your network, you must include the interfaces that run OSPF at the [edit protocols ospf] hierarchy level and, for those interfaces, the family inet statement must be included at the [edit interfaces interface-name unit logical-unit-number] hierarchy level.
Figure 10illustrates an example an OSPF autonomous system (AS) consisting of multiple areas and different types of OSPF routers.
Figure 10: Multi-Area OSPF Network Topology
The AS in Figure 10 is organized hierarchically around a backbone area, 0.0.0.0. Portions of the network are designated as separate areas: 0.0.0.1, 0.0.0.2, and 0.0.0.3. The backbone is the connecting point for all other areas, and each area must attach to the backbone in at least one location. OSPF is based on the concept of a link-state database in which each OSPF router attempts to form adjacencies with its OSPF neighbor. Once the adjacencies are in place, each router generates and floods LSAs into the network. The LSAs are placed into the link-state database on each router where the shortest path first (SPF) algorithm is calculated to find the best path to each end node in the network.
All non-backbone areas (0.0.0.1, 0.0.0.2, and 0.0.0.3) contain routers internal to that area (R1, R5, and R6) as well as a single area border router (ABR) (R2, R3, and R4). Internal routers generate LSAs within their area. The ABR translates these internal LSAs into summary LSAs that represent the LSAs within its non-backbone area and floods the summary LSAs to the backbone. The ABR is also responsible for generating summary LSAs that represent the backbone LSAs and injecting them into its attached areas. Because the ABR belongs to more than one area, it maintains a separate topological database for each area to which it is connected.
In Figure 10, the ABRs belong to different non-backbone areas. R2 is in area 0.0.0.1, a not-so-stubby area (NSSA); R3 is in area 0.0.0.3; and R4 is in area 0.0.0.2, a stub area.
The NSSA (0.0.0.1) consists of two routers: R1 and R2. An NSSA allows external routes to be flooded within its area. These routes are then leaked to other areas within the AS. However, external routes learned from other areas within the AS do not enter the NSSA.
The stub area (0.0.0.2) consists of two routers: R4 and R5. A stub area does not allow external routes to be flooded within its area. A stub area is useful when much of the AS consists of external LSAs because it reduces the size of the topological database within the stub area and subsequently the amount of memory required by the routers in the area.
Area 0.0.0.3 is a non-backbone area consisting of two routers: R3 and R6.
External Routers A and B reside outside the AS. When an OSPF router exchanges routing information with routers in other ASs, that router is called an autonomous system boundary router (ASBR). The ASBRs shown in Figure 10 are R1 and R6.
Figure 11 provides interface and IP address information for the example OSPF network topology used for the procedures in this topic.
Figure 11: OSPF Network Topology with Details
To verify that OSPF is configured correctly on routers in different areas of the network, follow these steps:
To verify the OSPF configuration on an ASBR router.
To verify the OSPF configuration on an ASBR router in your network, enter the following JUNOS command-line interface (CLI) operational mode commands:
The following sample output is for an OSPF configuration on R1,an ASBR router shown in Figure 11:
user@R1> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.12.1/30;
}
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.13.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 10.0.0.100/32 next-hop 10.1.13.2;
}
router-id 10.0.0.1;
}
protocols {
ospf {
export export-to-ospf;
area 0.0.0.1 {
nssa;
interface so-0/0/0.0;
interface lo0.0 {
passive;
}
}
}
}
policy-options {
policy-statement export-to-ospf {
term external-router {
from {
route-filter 10.0.0.100/32 exact;
}
then accept;
}
}
}
user@R1> show ospf interface
Interface State Area DR ID BDR ID Nbrs
lo0.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
so-0/0/0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
- The following sample output is for an OSPF configuration
on R6,an ASBR router shown in Figure 11:
user@R6> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.56.2/30;
}
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.6/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 10.0.0.101/32 next-hop 10.1.56.1;
}
router-id 10.0.0.6;
}
protocols {
ospf {
export export-to-ospf;
area 0.0.0.3 {
interface so-0/0/3.0;
interface lo0.0 {
passive;
}
}
}
}
policy-options {
policy-statement export-to-ospf {
term external-router {
from {
route-filter 10.0.0.101/32 exact;
}
then accept;
}
}
}
user@R6> show ospf interface
Interface State Area DR ID BDR ID Nbrs
lo0.0 DRother 0.0.0.3 0.0.0.0 0.0.0.0 0
so-0/0/3.0 PtToPt 0.0.0.3 0.0.0.0 0.0.0.0 1
The sample output shows a basic OSPF configuration at the [edit protocols ospf] and [edit interfaces] hierarchy levels on the R1 and R6 ASBR routers. In addition, both routers have an export policy, export-to-ospf, configured. The export policy allows external routes to be injected into the OSPF database and communicated throughout the AS.
R1 has two interfaces included at the [edit protocols ospf] hierarchy level: so-0/0/0 and the loopback interface (lo0). Both interfaces have the family inet statement included at the [edit interfaces] hierarchy level and are in area 0.0.0.1. Area 0.0.0.1 is attached to the backbone through R2, an ABR.
In addition, R1 has the nssa statement included at the [edit protocols ospf] hierarchy level indicating that it is an ASBR running in an NSSA. An NSSA allows external routes from outside the AS to be flooded within it. In this instance, the routes learned from external router B through the export policy export-to-ospf are injected into the R1 OSPF database and communicated throughout the AS. For more information on OSPF routes, see Examine OSPF Routes .
R6 has two interfaces included at the [edit protocols ospf] hierarchy level: so-0/0/3 and the loopback interface (lo0). Both interfaces have the family inet statement included at the [edit interfaces] hierarchy level and are in area 0.0.0.3. Area 0.0.0.3 is attached to the backbone through R3, an ABR. In addition, external router B is attached to R6 which has the export policy export-to-ospf configured. The export policy allows external routes to be injected into the R6 OSPF database and communicated throughout the AS.
Both routers (R1 and R6) have the router ID configured manually to avoid possible problems when the OSPF router ID (RID) changes: for example, when multiple loopback addresses are configured. The RID uniquely identifies the router within the OSPF network. It is transmitted within the LSAs used to populate the link-state database and calculate the shortest-path tree. In a link-state network, it is important that two routers do not share the same RID value, otherwise IP routing problems may occur.
An ASBR exchanges routing information with routers in other autonomous systems. ASBRs advertise externally learned routes throughout the AS. With the exception of routers in stub areas, any router in the AS—an internal router, an area border router, or a backbone router—can be an ASBR.
See the JUNOS Routing Protocols Configuration Guide for more information on configuring OSPF on a router.
To verify the OSPF configuration on an ABR router.
To verify the OSPF configuration on an ABR router in your network, enter the following JUNOS CLI operational mode commands:
The following sample output is for an OSPF configuration on R2, an NSSA ABR shown in Figure 11:
user@R2> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.12.2/30;
}
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.23.1/30;
}
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.24.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.2/32;
}
}
}
}
routing-options {
}
router-id 10.0.0.2;
}
protocols {
ospf {
area 0.0.0.1 {
nssa {
default-lsa default-metric 10;
}
interface so-0/0/0.0;
}
area 0.0.0.0 {
interface so-0/0/3.0;
interface so-0/0/1.0;
interface lo0.0 {
passive;
}
}
}
}
user@R2> show ospf interface
Interface State Area DR ID BDR ID Nbrs
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
so-0/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
so-0/0/3.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
so-0/0/0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
user@R3> show configuration
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.34.1/30;
}
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.23.2/30;
}
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.3/32;
}
}
}
}
routing-options {
router-id 10.0.0.3;
}
protocols {
ospf {
area 0.0.0.0 {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface lo0.0 {
passive;
}
}
area 0.0.0.3 {
interface so-0/0/3.0;
}
}
user@R3> show ospf interface
Interface State Area DR ID BDR ID Nbrs
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
so-0/0/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
so-0/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
so-0/0/3.0 PtToPt 0.0.0.3 0.0.0.0 0.0.0.0 1
user@R4> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.34.2/30;
}
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.45.1/30;
}
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.24.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.4/32;
}
}
}
}
routing-options {
router-id 10.0.0.4;
}
protocols {
ospf {
area 0.0.0.0 {
interface so-0/0/0.0;
interface so-0/0/3.0;
interface lo0.0 {
passive;
}
}
area 0.0.0.2 {
stub default-metric 10;
interface so-0/0/2.0;
}
}
}
user@R4> show ospf interface
Interface State Area DR ID BDR ID Nbrs
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
so-0/0/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
so-0/0/3.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
so-0/0/2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
The sample output shows a basic OSPF configuration at the [edit protocols ospf] and [edit interfaces] hierarchy levels on the R2, R3, and R4 ABR routers.
R2 has four interfaces included at the [edit protocols ospf] hierarchy level, and those interfaces have the family inet statement included at the [edit interfaces] hierarchy level. Three interfaces—so-0/0/1.0, so-0/0/3.0, and the loopback (lo0) interface—are in the backbone (0.0.0.0). One interface, so-0/0/0.0, is in the NSSA (0.0.0.1). Because R2 has one interface configured for an NSSA, external routes learned from outside the AS (through R1) are redistributed throughout the network. For more information on OSPF routes, see Examine OSPF Routes .
R3 has four interfaces included at the [edit protocols ospf] hierarchy level, and those interfaces have the family inet statement included at the [edit interfaces] hierarchy level. Three interfaces—so-0/0/0.0, so-0/0/1.0, and the loopback (lo0) interface— are in the backbone (0.0.0.0). One interface, so-0/0/3.0, is in a non-backbone area (0.0.0.3).
R4 has four interfaces included at the [edit protocols ospf] hierarchy level, and those interfaces have the family inet statement included at the [edit interfaces] hierarchy level. Two interfaces, so-0/0/0.0 and so-0/0/3.0, are in the backbone (0.0.0.0). One interface, so-0/0/2.0,is in the stub area (0.0.0.2). Because internal routers within a stub area do not receive external LSA information, they must rely on either direct static routes or a default route to get to external destinations. A default route can be statically configured on the internal router or learned from the stub ABR. To advertise a default LSA from the stub ABR, include the stub default-metric statement at the [edit protocols ospf area area-id] hierarchy level to activate the default route.
All routers (R2, R3, and R4) have the router ID configured manually to avoid possible problems when the OSPF router ID (RID) changes; for example, when multiple loopback addresses are configured. The RID uniquely identifies the router within the OSPF network. It is transmitted within the LSAs used to populate the link-state database and calculate the shortest-path tree. In a link-state network, it is important that two routers do not share the same RID value, otherwise IP routing problems may occur.
An ABR belongs to more than one area and maintains a separate topological database for each area to which it is connected. For more information on the OSPF database, see Examine the OSPF Link-State Database.
See the JUNOS Routing Protocols Configuration Guide for more information on configuring OSPF on a router.
To verify the OSPF configuration on a stub router.
To verify the OSPF configuration on a stub router in your network, enter the following commands:
The following sample output is for an OSPF configuration on R5, a stub router shown in Figure 11:
user@R5> show configuration
[...Output truncated...]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.1.45.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.5/32;
}
}
}
}
routing-options {
router-id 10.0.0.5;
}
protocols {
ospf {
area 0.0.0.2 {
stub;
interface so-0/0/2.0;
interface lo0.0 {
passive;
}
}
}
}
user@R5> show ospf interface
Interface State Area DR ID BDR ID Nbrs
lo0.0 DRother 0.0.0.2 0.0.0.0 0.0.0.0 0
so-0/0/2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
The sample output shows a basic OSPF configuration at the [edit protocols ospf] and [edit interfaces] hierarchy levels on R5, a stub router.
R5 has two interfaces included at the [edit protocols ospf] hierarchy level, and those interfaces have the family inet statement included at the [edit interfaces] hierarchy level. Both interfaces, so-0/0/2.0 and the loopback interface (lo0), are in the stub area (0.0.0.2).
R5 has the router ID configured manually to avoid possible problems when the OSPF router ID (RID) changes; for example, when multiple loopback addresses are configured. The RID uniquely identifies the router within the OSPF network. It is transmitted within the LSAs used to populate the link-state database and calculate the shortest-path tree. In a link-state network, it is important that two routers do not share the same RID value, otherwise IP routing problems may occur.
A stub area does not allow AS external advertisements to flood within that area. R5 relies on a default route (0.0.0.0/0) to reach destinations outside the AS. The default route can be statically configured on R5 or advertised by an ABR (R4). In this network, the default LSA is advertised by R4.
A stub area is useful if you want to reduce the size of the topological database and therefore the amount of memory required from the routers in the stub area. However, some restrictions apply to a stub area. You cannot create a virtual link through a stub area, and a stub area cannot contain an ASBR.