Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configuring OSPF Interfaces

About OSPF Interfaces

To activate OSPF on a network, you must enable the OSPF protocol on one or more interfaces on each device within the network on which traffic is to travel. How you configure the interface depends on whether the interface is connected to a broadcast or point-to-point network, a point-to-multipoint network, a nonbroadcast multiaccess (NBMA) network, or across a demand circuit.

  • A broadcast interface behaves as if the routing device is connected to a LAN.

  • A point-to-point interface provides a connection between a single source and a single destination (there is only one OSPF adjacency).

  • A point-to-multipoint interface provides a connection between a single source and multiple destinations.

  • An NBMA interface behaves in a similar fashion to a point-to-multipoint interface, but you might configure an NBMA interface to interoperate with other equipment.

  • A demand circuit is a connection on which you can limit traffic based on user agreements. The demand circuit can limit bandwidth or access time based on agreements between the provider and user.

You can also configure an OSPF interface to be passive, to operate in passive traffic engineering mode, or to be a peer interface.

  • A passive interface advertises its address, but does not run the OSPF protocol (adjacencies are not formed and hello packets are not generated).

  • An interface operating in OSPF passive traffic engineering mode floods link address information within the autonomous system (AS) and makes it available for traffic engineering calculations.

  • A peer interface can be configured for OSPFv2 routing devices. A peer interface is required for Generalized MPLS (GMPLS) to transport traffic engineering information through a link separate from the control channel. You establish this separate link by configuring a peer interface. The peer interface name must match the Link Management Protocol (LMP) peer name. A peer interface is optional for a hierarchy of RSVP label-switched paths (LSPs). After you configure the forwarding adjacency, you can configure OSPFv2 to advertise the traffic engineering properties of a forwarding adjacency to a specific peer.

Point-to-point interfaces differ from multipoint in that only one OSPF adjacency is possible. (A LAN, for instance, can have multiple addresses and can run OSPF on each subnet simultaneously.) As such, when you configure a numbered point-to-point interface to OSPF by name, multiple OSPF interfaces are created. One, which is unnumbered, is the interface on which the protocol is run. An additional OSPF interface is created for each address configured on the interface, if any, which is automatically marked as passive.

For OSPFv3, one OSPF-specific interface must be created per interface name configured under OSPFv3. OSPFv3 does not allow interfaces to be configured by IP address.

Enabling OSPF on an interface (by including the interface statement), disabling it (by including the disable statement), and not actually having OSPF run on an interface (by including the passive statement) are mutually exclusive states.

Note:

When you configure OSPFv2 on an interface, you must also include the family inet statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. When you configure OSPFv3 on an interface, you must also include the family inet6 statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. In Junos OS Release 9.2 and later, you can configure OSPFv3 to support address families other than unicast IPv6.

See Also

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

This example shows how to configure an OSPF interface on a broadcast or point-to-point network.

Requirements

Before you begin:

Overview

If the interface on which you are configuring OSPF supports broadcast mode (such as a LAN), or if the interface supports point-to-point mode (such as a PPP interface or a point-to-point logical interface on Frame Relay), you specify the interface by including the IP address or the interface name for OSPFv2, or only the interface name for OSPFv3.

In Junos OS Release 9.3 and later, an OSPF point-to-point interface can be an Ethernet interface without a subnet. If you configure an interface on a broadcast network, designated router and backup designated router election is performed.

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

CLI Quick Configuration

To quickly configure an OSPF interface on a broadcast or point-to-point network and to allow the inbound OSPF into the interfaces that are active, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Note: You can also enable specific protocols or services for a security zone instead of all protocols or services. For instance, OSPF protocol or SSH service in this example:

Procedure

Step-by-Step Procedure

To configure an OSPF interface on a broadcast or point-to-point network:

  1. Configure the interface.

    Note:

    For an OSPFv3 interface, specify an IPv6 address.

  2. Create an OSPF area.

    Note:

    For an OSPFv3 interface, include the ospf3 statement at the [edit protocols] hierarchy level.

  3. Assign the interface to the area.

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

  5. Configure the security zone to allow the inbound OSPF traffic into the interfaces that are active For more information about security zone, see Security Zones.

    Note: You can also enable specific protocols or services for a security zone instead of all protocols or services. For instance, OSPF protocol or SSH service in this example:

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

Confirm that the configuration is working properly.

Verifying the OSPF Interface

Purpose

Verify the interface configuration. Depending on your deployment, the Type field might display LAN or P2P.

Action

From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3.

See Also

Example: Configuring OSPF Demand Circuits

This example shows how to configure an OSPF demand circuit interface.

Requirements

Before you begin:

Overview

OSPF sends periodic hello packets to establish and maintain neighbor adjacencies and uses link-state advertisements (LSAs) to make routing calculations and decisions. OSPF support for demand circuits is defined in RFC 1793, Extending OSPF to Support Demand Circuits, and suppresses the periodic hello packets and LSAs. A demand circuit is a connection on which you can limit traffic based on user agreements. The demand circuit can limit bandwidth or access time based on agreements between the provider and user.

You configure demand circuits on an OSPF interface. When the interface becomes a demand circuit, all hello packets and LSAs are suppressed as soon as OSPF synchronization is achieved. LSAs have a DoNotAge bit that stops the LSA from aging and prevents periodic updates from being sent. Hello packets and LSAs are sent and received on a demand-circuit interface only when there is a change in the network topology. This reduces the amount of traffic through the OSPF interface.

Consider the following when configuring OSPF demand circuits:

  • Periodic hellos are only suppressed on point-to-point and point-to-multipoint interfaces. If you configure demand circuits on an OSPF broadcast network or on an OSPF nonbroadcast multiaccess (NBMA) network, periodic hello packets are still sent.

  • Demand circuit support on an OSPF point-to-multipoint interface resembles that for point-to-point interfaces. If you configure a point-to-multipoint interface as a demand circuit, the device negotiates hello suppression separately on each interface that is part of the point-to-multipoint network.

This example assumes that you have a point-to-point connection between two devices using SONET/SDH interfaces. A demand-circuit interface automatically negotiates the demand-circuit connection with its OSPF neighbor. If the neighbor does not support demand circuits, then no demand circuit connection is established.

In this example, you configure OSPF interface so-0/1/0 in OSPF area 0.0.0.1 as a demand circuit.

Topology

Configuration

CLI Quick Configuration

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.

Procedure

Step-by-Step Procedure

To configure an OSPF demand circuit interface on one neighboring interface:

  1. Create an OSPF area.

    Note:

    For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

  2. Configure the neighboring interface as a demand circuit.

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

    Note:

    Repeat this entire configuration on the other neighboring interface.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.

Verification

Confirm that the configuration is working properly.

Verifying the Status of Neighboring Interfaces

Purpose

Verify information about the neighboring interface. When the neighbor is configured for demand circuits, a DC flag displays.

Action

From operational mode, enter the show ospf neighbor detail command for OSPFv2, and enter the show ospf3 neighbor detail command for OSPFv3.

Example: Configuring a Passive OSPF Interface

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:

Overview

By default, OSPF must be configured on an interface for direct interface addresses to be advertised as interior routes. To advertise the direct interface addresses without actually running OSPF on that interface (adjacencies are not formed and hello packets are not generated), you configure that interface as a passive interface.

Enabling OSPF on an interface (by including the interface statement), disabling it (by including the disable statement), and not actually having OSPF run on an interface (by including the passive statement) are mutually exclusive states.

Note:

If you do not want to see notifications for state changes in a passive OSPF interface, you can disable the OSPF traps for the interface by including the no-interface-state-traps statement. The no-interface-state-traps statement is supported only for OSPFv2.

In this example, you configure interface ge-0/2/0 as a passive OSPF interface in area 0.0.0.1 by including the passive statement.

Configuration

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

To configure a passive OSPF interface:

  1. Create an OSPF area.

    Note:

    For an OSPFv3 interface, include the ospf3 statement at the [edit protocols] hierarchy level.

  2. Configure the passive interface.

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

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

Confirm that the configuration is working properly.

Verifying the Status of OSPF Interfaces

Purpose

Verify the status of the OSPF interface. If the interface is passive, the Adj count field is 0 because no adjacencies have been formed. Next to this field, you might also see the word Passive.

Action

From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3.

Example: Configuring OSPFv2 Peer interfaces

This example shows how to configure an OSPFv2 peer interface.

Requirements

Before you begin:

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

CLI Quick Configuration

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.

Procedure

Step-by-Step Procedure

To configure a peer OSPFv2 interface used by the LMP:

  1. Create an OSPF area.

  2. Configure the peer interface.

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

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

Confirm that the configuration is working properly.

Verifying the Configured OSPFv2 Peer

Purpose

Verify the status of the OSPFv2 peer. When an OSPFv2 peer is configured for GMPLS, the Peer Name field displays the name of the LMP peer that you created for GMPLS, which is also the configured OSPFv2 peer.

Action

From operational mode, enter the show link-management command.

Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network

This example shows how to configure an OSPFv2 interface on a nonbroadcast multiaccess (NBMA) network.

Requirements

Before you begin:

Overview

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.

    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

CLI Quick Configuration

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.

Procedure

Step-by-Step Procedure

To configure an OSPFv2 interface on an NBMA network:

  1. Configure the interface.

  2. Create an OSPF area.

  3. Assign the interface to the area. In this example, include the eligible keyword to allow the neighbor to be a designated router.

  4. Configure the poll interval.

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

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

Confirm that the configuration is working properly.

Verifying the OSPF Interface

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

Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint Network

This example shows how to configure an OSPFv2 interface on a point-to-multipoint network.

Requirements

Before you begin:

Overview

When you configure OSPFv2 on a nonbroadcast multiaccess (NBMA) network, such as a multipoint Asynchronous Transfer Mode (ATM) or Frame Relay, OSPFv2 operates by default in point-to-multipoint mode. In this mode, OSPFv2 treats the network as a set of point-to-point links. Because there is no autodiscovery mechanism, you must configure each neighbor.

When you configure the interface, specify either the IP address or the interface name. Using both the IP address and the interface name produces an invalid configuration.

In this example, you configure ATM interface at-0/1/0 as an OSPFv2 interface in OSPF area 0.0.0.1, and you and specify 192.0.2.1 as the neighbor’s IP address.

Topology

Configuration

CLI Quick Configuration

To quickly configure an OSPFv2 interface on a point-to-multipoint network, copy the following commands and paste them into the CLI.

Procedure

Step-by-Step Procedure

To configure an OSPFv2 interface on a point-to-multipoint network:

  1. Configure the interface.

  2. Create an OSPF area.

  3. Assign the interface to the area and specify the neighbor.

    To configure multiple neighbors, include a neighbor statement for each neighbor.

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

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

Confirm that the configuration is working properly.

Verifying the OSPF Interface

Purpose

Verify the interface configuration. Confirm that the Type field displays P2MP.

Action

From operational mode, enter the show ospf interface detail command.

Understanding Multiple Address Families for OSPFv3

By default, OSPFv3 supports only unicast IPv6 routes. In Junos OS Release 9.2 and later, you can configure OSPFv3 to support multiple address families, including IPv4 unicast, IPv4 multicast, and IPv6 multicast. This mutliple address family support allows OSPFv3 to support both IPv6 and IPv4 nodes. Junos OS maps each address family to a separate realm as defined in RFC 5838, Support for Address Families in OSPFv3. Each realm maintains a separate set of neighbors and link-state database.

When you configure multiple address families for OSPFv3, there is a new instance ID field that allows multiple OSPFv3 protocol instances per link. This allows a single link to belong to multiple areas.

You configure each realm independently. We recommend that you configure an area and at least one interface for each realm.

These are the default import and export routing tables for each of the four address families:

  • IPv6 unicast: inet6.0

  • IPv6 multicast: inet6.2

  • IPv4 unicast: inet.0

  • IPv4 multicast: inet.2

With the exception of virtual links, all configurations supported for the default IPv6 unicast family are supported for the address families that have to be configured as realms.

Example: Configuring Multiple Address Families for OSPFv3

This example shows how to configure multiple address families for OSPFv3.

Requirements

Before you begin:

Overview

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 1 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.

Figure 1: IPv4 Unicast RealmIPv4 Unicast Realm

Topology

Configuration

CLI Quick Configuration

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

To configure multiple address families for OSPFv3:

  1. Configure the device interface participating in OSPFv3.

  2. Enter OSPFv3 configuration mode.

  3. Add the interface you configured to the OSPFv3 area.

  4. Configure an IPv4 unicast realm. This allows OSPFv3 to support both IPv4 unicast and IPv6 unicast routes.

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

    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

Confirm that the configuration is working properly.

Verifying the Link-State Database

Purpose

Verify the status of the link-state database for the configured realm, or address family.

Action

From operational mode, enter the show ospf3 database realm ipv4-unicast command.

Verifying the Status of OSPFv3 Interfaces with Multiple Address Families

Purpose

Verify the status of the interface for the specified OSPFv3 realm, or address family.

Action

From operational mode, enter the show ospf3 interface realm ipv4-unicast command.