OSPF

The OSPF backbone area, area 0.0.0.0, must be contiguous, and all other areas must be connected to the backbone area. The following figure shows the OSPF backbone area. The backbone distributes routing information between areas. If it is not practical to connect an area to the backbone (see area 0.0.0.5), the ABRs (such as routers Y and Z) must be connected via a virtual link. The two ABRs form a point-to-point-like adjacency across the transit area (see area 0.0.0.4).

A stub area is a designated area that does not allow external route advertisements. Routers in a stub area do not maintain external routes. A single default route to an ABR replaces all external routes. This OSPF implementation supports the optional summary route (type-3) advertisement suppression from other areas into a stub area. This feature further reduces topological database sizes and OSPF protocol traffic, memory usage, and CPU route calculation time.

Backbone area shows that areas 0.0.0.1, 0.0.0.2, and 0.0.0.5 could be configured as stub areas. A stub area cannot be designated as the transit area of a virtual link and a stub area cannot contain an ASBR. An ASBR exchanges routing information with routers in other ASs.

Another OSPF area type is called a Not-So-Stubby Area (NSSA). NSSAs are similar to stub areas in that no external routes are imported into the area from other OSPF areas. External routes learned by OSPF routers in the NSSA are advertised as type-7 LSAs within the NSSA and are translated by ABRs into type-5 external route advertisements for distribution into other areas of the OSPF domain. An NSSA cannot be designated as the transit area of a virtual link.

In Backbone area, area 0.0.0.3 could be configured as an NSSA.

If the SR OS router is providing a grace period to an adjacent neighbor and the BFD session associated with that neighbor fails, the behavior is determined by the C-bit values sent by each neighbor as follows:

• If both BFD endpoints have set their C-bit value, the GR helper mode is canceled and any routes from that neighbor that are marked as stale are removed from the forwarding table.

• If either of the BFD endpoints has not set their C-bit value, the graceful restart helper mode continues.

This feature extends the graceful restart helper function supported under other protocols to OSPFv3.

The primary difference between graceful restart helper for OSPFv2 and OSPFv3 is in OSPFv3 a different grace-LSA format is used.

As SR OS platforms can support a fully non-stop routing model for control plane high availability, SR OSs have no need for graceful restart as defined by the IETF in various RFCs for each routing protocol. However, because the router does need to coexist in multivendor networks and other routers do not always support a true non-stop routing model with stateful failover between routing control planes, there is a need to support a graceful restart helper function.

Graceful restart helper mode allows SR OS-based systems to provide a grace period to other routers which have requested it, during which the SR OS systems continue to use routes authored by or transiting the router requesting the grace period. This is typically used when another router is rebooting the control plane but the forwarding plane is expected to continue to forward traffic based on the previously available FIB.

The format of the graceful OSPF restart (GRACE) LSA format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           LS age              |0|0|0|          11             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Link State ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Advertising Router                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    LS sequence number                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        LS checksum            |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                            TLVs                             -+
       |                             ...                               |

For more information, see section 2.2 of RFC 5187, OSPFv3 Graceful Restart.

The Link State ID of a grace-LSA in OSPFv3 is the Interface ID of the interface originating the LSA.

The format of each TLV is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type             |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Value...                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                TLV Format

Grace-LSA TLVs are formatted according to section 2.3.2 of RFC 3630, Traffic Engineering (TE) Extensions to OSPF Version 2. The Grace-LSA TLVs are used to carry the Grace period (type 1) and the reason the router initiated the graceful restart process (type 2).

Other information in RFC 5187 is directed to routers that require the full graceful restart mechanism as they do not support a stateful transition from primary or backup control plane module (CPM).

A router uses the OSPF Hello protocol to discover neighbors. The router sends hello packets to a multicast address and receives hello packets in return.

In broadcast networks, a designated router and a backup designated router are elected. The designated router is responsible for sending link-state advertisements (LSAs) describing the network, which reduces the amount of network traffic.

The routers attempt to form adjacencies. An adjacency is a relationship formed between a router and the designated or backup designated router. For point-to-point networks, no designated or backup designated router is elected. An adjacency must be formed with the neighbor.

To significantly improve adjacency forming and network convergence, a network should be configured as point-to-point if only two routers are connected, even if the network is a broadcast medium such as Ethernet.

When the link-state databases of two neighbors are synchronized, the routers are considered to be fully adjacent. When adjacencies are established, pairs of adjacent routers synchronize their topological databases. Not every neighboring router forms an adjacency. Routing protocol updates are only sent to and received from adjacencies. Routers that do not become fully adjacent remain in the two-way neighbor state.

In addition to point-to-point and broadcast networks, OSPF can operate in non-broadcast multi-access (NBMA) mode.

An NBMA segment emulates the function of a broadcast network. Every router on the segment must be configured with the IP addresses of each of its neighbors, and may need to be configured with the MAC address of its neighbor if the network does not support Layer 2 broadcast. OSPF Hello packets are transmitted individually as unicast packets to each adjacent neighbor. Because an NBMA network has no broadcast or multicast capabilities, the routing device cannot discover its neighbors dynamically, so all neighbors must be configured statically.

As in a broadcast network, a designated router and a backup designated router are elected when OSPF is operating in NBMA mode. The designated router is similarly responsible for sending link-state advertisements (LSAs) for the network.

OSPF does not support NBMA interfaces that are part of a multi-area adjacency. An interface can either be in multiple areas or in NBMA mode.

When configuring route policies, you can specify the source OSPF name or instance ID using the command options in the following context:

• MD-CLI

  configure policy-options policy-statement entry from protocol

• classic CLI

  configure router policy-options policy-statement entry from protocol

The following apply for the instance ID:

When announcing internal (intra/inter-area) OSPF routes from another process, the default type should be type-1, and metric set to the route metric in RTM. For AS-external routes, by default the route type (type-1/2) should be preserved in the originated LSA, and metric set to the route metric in RTM. By default, the tag value should be preserved when an external OSPF route is announced by another process. All these can be changed with explicit action statements.

Export policy should allow match criteria based on the OSPF route hierarchy (for example, only intra-area, only inter-area, only external, only internal (intra/inter-area)). There must also be a possibility to filter based on existing tag values.

The legacy method for preventing route redistribution loops was to assign a tag value to each OSPF process and mark each external route originating within that domain with that value. However, because the tag value must be preserved throughout different OSPF domains, this only catches loops that go back to the originating domain, and not where looping occurs in a remote set of domains. To prevent this type of loop, the route propagation information in the LSA must be accumulative. The following method has been implemented:

• The OSPF tag field in the AS-external LSAs is treated as a bit mask, instead of a scalar value. That is, each bit in the tag value can be independently checked, set, or reset as part of the routing policy.

• When a set of OSPF domains are provisioned in a network, each domain is assigned a specific bit value in the 32-bit tag mask. When an external route is originated by an ASBR using an internal OSPF route in a domain, a corresponding bit is set in the AS-external LSA. As the route gets redistributed from one domain to another, more bits are set in the tag mask, each corresponding to the OSPF domain that the route visited. Route redistribution looping is prevented by checking the corresponding bit as part of the export policy; if the bit corresponding to the announcing OSPF process is already set, the route is not exported there.

  From the CLI perspective, this involves adding a set of from tag and action tag commands that allow for bit operations.

First, the user enables LFA computation by SPF under the OSPF (or IS-IS) routing protocol instance level using the following commands:

• MD-CLI

  configure router ospf loopfree-alternate

• classic CLI

  configure router ospf loopfree-alternates

The preceding commands instruct the IGP SPF to attempt to precompute both a primary next hop and an LFA next hop for every learned prefix. When found, the LFA next hop is populated into the RTM along with the primary next hop for the prefix.

After enabling LFA computation, the user enables IP FRR using the following commands to cause RTM to download to the IOM or the forwarding engine an LFA next hop, when found by SPF, in addition to the primary next hop for each prefix in the FIB.

• MD-CLI

  configure routing-options ip-fast-reroute

• classic CLI

  configure router ip-fast-reroute

When the SPF calculates more than one primary next hop for a prefix, it does not program an LFA next hop.

IP prefixes resolve to the multiple primary next hops, providing the required protection.

When both IP FRR and RSVP shortcut (IGP shortcut) and LFA are enabled in IS-IS or OSPF, and IP FRR is also enabled, the following additional IP FRR are supported.

• A prefix that is resolved to a direct primary next hop can be backed up by a tunneled LFA next hop.

• A prefix that is resolved to a tunneled primary next hop does not have an LFA next hop. It relies on RSVP FRR for protection.

The LFA SPF is extended to use IGP shortcuts as LFA next hops as described in OSPF and IS-IS support for LFA calculation.

The LFA backup next-hop can protect the primary next-hop to reach a prefix advertised by a BGP neighbor. The BGP next-hop remains up when the FIB switches from the primary IGP next-hop to the LFA IGP next-hop.

SPF computation in IS-IS and OSPF is enhanced to compute LFA alternate routes for each learned prefix and populate it in RTM.

The following figure shows a simple network topology with point-to-point (P2P) interfaces and highlights three routes to reach router R5 from router R1.

The primary route is via R3. The LFA route via R2 has two equal cost paths to reach R5. The path by way of R3 protects against failure of link R1-R3. R1 computes this route by checking that the cost for R2 to reach R5 by way of R3 is lower than the cost by way of routes R1 and R3. This condition is referred to as the Loop-free Criterion (LFC).

The path by way of R2 and R4 can be used to protect against the failure of router R3. However, with the link R2-R3 metric set to 5, R2 sees the same cost to forward a packet to R5 by way of R3 and R4. Therefore, R1 cannot guarantee that enabling the LFA next-hop R2 protects against R3 node failure. This means that the LFA next-hop R2 provides link protection only for prefix R5. If the metric of link R2-R3 is changed to 8, the LFA next-hop R2 provides node protection because a packet to R5 always goes over R4. That is, it is required that R2 become loop-free with respect to both the source node R1 and the protected node R3.

The following figure shows an example where the primary next hop uses a broadcast interface.

For the next-hop R2 to be a link-protect LFA for route R5 from R1, it must be loop-free with respect to the R1-R3 link Pseudo-Node (PN). However, because R2 also has a link to that PN, its cost to reach R5 by way of the PN or router R4 is the same. Therefore, R1 cannot guarantee that enabling the LFA next-hop R2 protects against a failure impacting link R1-PN, because this may cause the entire subnet represented by the PN to go down. If the metric of link R2-PN is changed to 8, R2 next-hop is an LFA providing link protection.

The following are the detailed equations for this criterion, as described in RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates:

• Rule 1

  Link-protect LFA backup next-hop (primary next hop R1-R3 is a P2P interface):

  Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)

  Distance_opt(R2, R5) >= Distance_opt(R2, R3) + Distance_opt(R3, R5)

• Rule 2

  Node-protect LFA backup next-hop (primary next-hop R1-R3 is a P2P interface):

  Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)

  Distance_opt(R2, R5) < Distance_opt(R2, R3) + Distance_opt(R3, R5)

• Rule 3

  Link-protect LFA backup next-hop (primary next-hop R1-R3 is a broadcast interface):

  Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)

  Distance_opt(R2, R5) < Distance_opt(R2, PN) + Distance_opt(PN, R5), where PN stands for the R1-R3 link PN.

For a P2P interface, if SPF finds multiple LFA next-hops for a specified primary next-hop, it uses the following selection algorithm.

1. SPF picks the node-protect type in favor of the link-protect type.

2. If there is more than one LFA next-hop within the selected type, SPF picks one based on the least cost.

3. If more than one LFA next-hop with the same cost results from step 2, SPF selects the first one. This is not a deterministic selection and varies following each SPF calculation.

For a broadcast interface, a node-protect LFA is not necessarily a link-protect LFA if the path to the LFA next-hop goes over the same PN as the primary next-hop. Similarly, a link-protect LFA may not guarantee link protection if it goes over the same PN as the primary next-hop. The selection algorithm when SPF finds multiple LFA next-hops for a specified primary next-hop is modified as follows.

1. The algorithm splits the LFA next-hops into two sets.

   • The first set consists of LFA next-hops that do not go over the PN used by the primary next-hop.

   • The second set consists of LFA next-hops that go over the PN used by the primary next-hop.

2. If there is more than one LFA next-hop in the first set, SPF picks the node-protect type in favor of the link-protect type.

3. If there is more than one LFA next-hop within the selected type, SPF picks one based on the least cost.

4. If more than one LFA next-hop with equal cost results from step 3, SPF selects the first one from the remaining set. This is not a deterministic selection and varies following each SPF calculation.

5. If no LFA next-hop results from step D, SPF reruns steps 2 through 4 using the second set.

This algorithm is more flexible than strictly applying the preceding Rule 3; that is, the link-protect rule in the presence of a PN and specified in RFC 5286. A node-protect LFA that does not avoid the PN, that is, does not guarantee link protection, can still be selected as a last resort. Similarly, a link-protect LFA that does not avoid the PN can still be selected as a last resort.

Both the computed primary next-hop and LFA next-hop for a specified prefix are programmed into RTM.

Administrative groups (admin groups), also known as affinity, are used to tag IP interfaces which share a specific characteristic with the same identifier. For example, an admin group identifier could represent all links which connect to core routers, or all links which have bandwidth higher than 10G, or all links which are dedicated to a specific service.

Use the following command to configure locally the admin group name on each router.

configure router interface if-attribute admin-group

A maximum of 32 admin groups can be configured per system.

Next use the following commands to configure the admin group membership of the IP interfaces used in LFA. You can apply admin groups to IES, VPRN, or network IP interface. You can configure a maximum of five groups for each of the IES, VPRN or network IP interfaces.

configure router interface if-attribute admin-group
configure service ies interface if-attribute admin-group 
configure service vprn interface if-attribute admin-group 

The user can add as many admin groups as configured to a specified IP interface. The same above command can be applied multiple times.

You can delete specific admin groups under the interface or delete all memberships:

• MD-CLI

  The delete command with the admin-group interface under the interface deletes one or more of the admin-group memberships of the interface. It deletes all memberships if you do not specify a group name.

• classic CLI

  The no form of the admin-group command under the interface deletes one or more of the admin-group memberships of the interface. It deletes all memberships if no group name is specified.

Use the following commands to add the admin group constraints into the route next hop policy template and specify the preference order number for the included group option:

• MD-CLI

  configure routing-options route-next-hop-policy template include-group preference pref-number
  configure routing-options route-next-hop-policy template exclude-group preference

• classic CLI

  configure router route-next-hop-policy template include-group [pref pref-number]
  configure router route-next-hop-policy template exclude-group 

Each group is entered individually. The include-group statement instructs the LFA SPF selection algorithm to pick up a subset of LFA next hops among the links which belong to one or more of the specified admin groups. A link which does not belong to at least one of the admin-groups is excluded. However, a link can still be selected if it belongs to one of the groups in a include-group statement but also belongs to other groups which are not part of any include-group statement in the route next hop policy.

The option to specify a preference provides a relative preference for the admin group to select. A lower preference value means that LFA SPF first attempts to select a LFA backup next hop which is a member of the corresponding admin group. If none is found, then the admin group with the next higher preference value is evaluated. If no preference is configured for a specified admin group name, then it is supposed to be the least preferred (for example, numerically the highest preference value).

When evaluating multiple include-group statements within the same preference, any link which belongs to one or more of the included admin groups can be selected as an LFA next hop. There is no relative preference based on how many of those included admin groups the link is a member of.

The exclude-group statement simply prunes all links belonging to the specified admin group before making the LFA backup next hop selection for a prefix.

If the same group name is part of both include and exclude statements, the exclude statement wins. It other words, the exclude statement can be viewed as having an implicit preference value of 0.

Shared Risk Loss Group (SRLG) is used to tag IP interfaces which share a specific fate with the same identifier. For example, an SRLG group identifier could represent all links which use separate fibers but are carried in the same fiber conduit. If the conduit is accidentally cut, all the fiber links are cut which means all IP interfaces using these fiber links fail. The user can enable the SRLG constraint to select a LFA next hop for a prefix which avoids all interfaces that share fate with the primary next.

Use the command options in the following context to configure each SRLG group locally on each router:

• MD-CLI

  configure routing-options if-attribute srlg-group

• classic CLI

  configure router if-attribute srlg-group

Configure a maximum of 1024 SRLGs per system.

Next use the following commands to configure the admin group membership of the IP interfaces used in LFA. You can apply SRLG groups to IES, VPRN, or network IP interfaces.

configure router interface if-attribute srlg-group
configure service ies interface if-attribute srlg-group 
configure service vprn interface if-attribute srlg-group 

Add as many admin groups as configured to a specified IP

Add a maximum of 64 SRLG groups to a specified IP interface. The same above command can be applied multiple times.

You can delete specific SRLG groups under the interface or delete all memberships:

• MD-CLI

  The delete command with the SRLG-group interface under the interface deletes one or more of the SRLG-group memberships of the interface. It deletes all memberships if you do not specify a group name.

• classic CLI

  The no form of the srlg-group command under the interface deletes one or more of the admin-group memberships of the interface. It deletes all memberships if no group name is specified.

Finally, use the following command to add the SRLG constraint into the route next hop policy template.

• MD-CLI

  configure routing-options route-next-hop-policy template srlg

• classic CLI

  configure router route-next-hop-policy template srlg-enable

When this command is applied to a prefix, the LFA SPF selects a LFA next hop, among the computed ones, which uses an outgoing interface that does not participate in any of the SRLGs of the outgoing interface used by the primary next hop.

The LFA SPF policy feature generalizes the use of admin-group and SRLG to other types of interfaces. To that end, it is important that the IP admin groups and SRLGs be compatible with the ones already supported in MPLS. The following rules are implemented.

• Perform the binding of an MPLS interface to a group, that is, configure membership of an MPLS interface in a group under the following context.

  configure router mpls interface

• Perform the binding of a local or remote MPLS interface to an SRLG in the SRLG database under the following context.

  configure router mpls srlg-database 

• Perform the binding of an IS-IS/OSPF interface to a group in the following router or services contexts, to be used by IS-IS or OSPF in route next hop policies.

  configure router interface if-attribute
  configure service vprn interface if-attribute
  configure service ies interface if-attribute

• Only the admin groups and SRLGs bound to an MPLS interface context or the SRLG database context are advertised in TE link TLVs and sub-TLVs when the traffic-engineering command option is enabled in IS-IS or OSPF. IES and VPRN interfaces do not have their attributes advertised in TE TLVs.

You can select if link protection or node protection is preferred in the selection of a LFA next hop for all IP prefixes and LDP FEC prefixes to which a route next hop policy template is applied. The default in SR OS implementation is node protection. The implementation falls back to the other type if no LFA next hop of the preferred type is found.

You can also select if tunnel backup next hop or IP backup next hop is preferred. The default in SR OS implementation is to prefer IP next hop over tunnel next hop. The implementation falls back to the other type if no LFA next hop of the preferred type is found.

The following options are added into the route next hop policy template:

• MD-CLI

  configure routing-options route-next-hop-policy template nh-type
  configure routing-options route-next-hop-policy template protection-type

• classic CLI

  configure router route-nh-template template nh-type
  configure router route-nh-template template protection-type

When the route next-hop policy template is applied to an IP interface, all prefixes using this interface as a primary next hop follows the protection type and next hop type preference specified in the template.

The following list summarizes the OSPF configuration defaults:

• By default, a router has no configured areas.

• An OSPF instance is created in the administratively enabled state.

The router ID uniquely identifies the router within an AS. In OSPF, routing information is exchanged between autonomous systems, groups of networks that share routing information. It can be set to be the same as the loopback (system interface) address. Subscriber services also use this address as far-end router identifiers when service distribution paths (SDPs) are created.

You can define the router ID as follows:

• Define the value using the following command.

  configure router router-id

• If the router ID is not specified in the configure router router-id context, define the system interface and specify it for the router interface.

  configure router interface

  A system interface requires an IP address with a 32-bit subnet mask. The system interface is used as the router identifier by higher-level protocols such as OSPF and IS-IS. The system interface is assigned during the primary router configuration process when the interface is created in the logical IP interface context.

• inheriting the last four bytes of the MAC address

• Define the router ID when creating the OSPF or OSPF3 instance:
  • MD-CLI

    configure router ospf ospf-instance [router-id]

  • classic CLI

    configure router ospf ospf-instance [router-id]

• For the BGP protocol, you can use the following command to configure a BGP router ID for use within BGP.

  configure router bgp router-id

When configuring a new router ID, protocols are not automatically restarted with the new router ID. The next time a protocol is (re) initialized the new router ID is used. An interim period of time can occur when different protocols use different router IDs. To force the new router ID, issue the shutdown and no shutdown commands for each protocol that uses the router ID or restart the entire router.

It is possible to configure an SR OS to operate with an IPv6 only BOF and no IPv4 system interface address. When configured in this manner, the operator must explicitly define IPv4 router IDs for protocols such as OSPF and BGP as there is no mechanism to derive the router ID from an IPv6 system interface address.

The following example shows a router ID configuration.

[ex:/configure router "Base"]
A:admin@node-2# info
    autonomous-system 100
    router-id 10.10.10.104
    interface "system" {
        ipv4 {
            primary {
                address 10.10.10.104
                prefix-length 32
            }
        }
    }
    interface "to-103" {
        port 1/1/1
        ipv4 {
            primary {
                address 10.0.0.104
                prefix-length 24
            }
        }
    }

A:node-2>config>router# info
------------------------------------------ 
    ...
        interface "system"
            address 10.10.10.104/32
        exit
        interface "to-103"
            address 10.0.0.104/24
            port 1/1/1
        exit
        autonomous-system 100
        router-id 10.10.10.104
    ...
------------------------------------------

The following displays a basic OSPF configuration example.

[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
    export-policy ["OSPF-Export"]
    overload true
    traffic-engineering true
    overload-on-boot {
        timeout 60
    }
    asbr {
    }

A:node-2>config>router>ospf# info
----------------------------------------------
            asbr
            overload
            overload-on-boot timeout 60
            traffic-engineering
            export "OSPF-Export"
            exit
----------------------------------------------

Use commands in the following contexts configure OSPFv3 for routers or VPRN services, including export policies, external preferences, overload, router ID, timers, and so on.

configure router ospf3
configure service vprn ospf3

OSPF supports the creation of multiple OSPFv2 and OSPFv3 instances, to allow separate instances of the OSPF protocols to run independently within SR OS. To create separate instances you can specify a different optional instance ID to the configure router ospf and configure router ospf3 commands. This creates unique OSPF instances for which separate link-state databases are maintained.

The following example shows an OSPFv3 configuration.

ex:/configure router "Base" ospf3 0]
A:admin@node-2# info
    export-policy ["OSPF-Export"]
    overload true
    timers {
        lsa-arrival 50000
    }
    asbr 
    }

A:node-2>config>router>ospf3# info
----------------------------------------------
            asbr
            overload
            timers
                lsa-arrival 50000
            exit
            export "OSPF-Export"
----------------------------------------------

An OSPF area consists of routers configured with the same area ID. To include a router in a specific area, the common area ID must be assigned and an interface identified.

If your network consists of multiple areas you must also configure a backbone area (0.0.0.0) on at least one router. The backbone consists of the area border routers and other routers not included in other areas. The backbone distributes routing information between areas. The backbone is considered to be a participating area within the autonomous system. To maintain backbone connectivity, there must be at least one interface in the backbone area or have a virtual link configured to another router in the backbone area.

The minimal configuration must include an area ID and an interface. Modifying other command options are optional.

Use commands in the following contexts to configure an OSPF or OSPFv3 area, including the area ID, area range with IP prefix and mask, blackhole-aggregate, interface, and so on.

configure router ospf area
configure router ospf3 area

The following example displays a basic OSPF area configuration.

[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
    area 0.0.0.0 {
        interface "system" {
        }
    }
    area 0.0.0.20 {
        interface "to-104" {
            priority 10
        }
    }
    area 0.0.1.1 {
    }

A:node-2>config>router>ospf# info
----------------------------------------------
        area 0.0.0.0
            interface "system"
            exit
        exit
        area 0.0.0.20
            interface "to-104"
                priority 10
                no shutdown
            exit
        exit
        area 0.0.1.1
        exit
----------------------------------------------

Configure stub areas to control external advertisements flooding and to minimize the size of the topological databases on an area's routers. A stub area cannot also be configured as an NSSA.

By default, summary route advertisements are sent into stub areas. The no form of the summary command disables sending summary route advertisements and only the default route is advertised by the ABR. This example retains the default so the command is not entered.

If this area is configured as a transit area for a virtual link, then existing virtual links of a non-stub or NSSA area are removed when its designation is changed to NSSA or stub.

Stub areas for OSPF3 are configured the same as OSPF stub areas. Stub areas for VPRN services can also be configured the same as for OSPF stub areas. Use the commands in the following contexts to configure stub areas.

configure router ospf area stub
configure router ospf3 area stub
configure service vprn ospf area stub
configure service vprn ospf3 area stub

[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
    ...  
    }
    area 0.0.0.20 {
        stub {
            default-metric 5000
        }
    }
    ...
----------------------------------------------

A:node-2>config>router>ospf# info
----------------------------------------------
    ...
            area 0.0.0.20
                stub
                    default-metric 5000
                exit
            exit  
    ...
----------------------------------------------

You must explicitly configure an area to be a Not-So-Stubby Area (NSSA) area. NSSAs are similar to stub areas in that no external routes are imported into the area from other OSPF areas. The major difference between a stub area and an NSSA is an NSSA has the capability to flood external routes it learns throughout its area and by an area border router to the entire OSPF domain. An area cannot be both a stub area and an NSSA.

If this area is configured as a transit area for a virtual link, then existing virtual links of a non-stub or NSSA area are removed when its designation is changed to NSSA or stub.

Use the commands in the following contexts to configure the NSSA, including the area range, default originating routes, external redistribution of routes into the NSSA, and sending of summary LSAs to the NSSA on an ABR.

configure router ospf area nssa
configure router ospf3 area nssa
configure service vprn ospf area nssa
configure service vprn ospf3 area nssa

[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
    export-policy ["OSPF-Export"]
    overload true
    traffic-engineering true
    overload-on-boot {
        timeout 60
    }
    asbr {
    }
    area 0.0.0.0 {
    }
    area 0.0.0.20 {
        stub {
        }
    }
    area 0.0.0.25 
        nssa {
    }

A:node-2>config>router>ospf# info
----------------------------------------------
            asbr
            overload
            overload-on-boot timeout 60
            traffic-engineering
            export "OSPF-Export"
            exit
            area 0.0.0.0
            exit
            area 0.0.0.20
                stub
                exit
            exit
            area 0.0.0.25
                nssa
                exit
            exit
----------------------------------------------

The OSPF backbone area, area 0.0.0.0, must be contiguous and all other areas must be connected to the backbone area. The backbone distributes routing information between areas. If it is not practical to connect an area to the backbone (see Area 0.0.0.5 in OSPF areas) then the area border routers (such as routers Y and Z) must be connected via a virtual link. The two area border routers form a point-to-point-like adjacency across the transit area (see Area 0.0.0.4). A virtual link can only be configured while in the area 0.0.0.0 context.

The router ID specified in the virtual-link command must be associated with the virtual neighbor, that is, enter the virtual neighbor’s router ID, not the local router ID. The transit area cannot be a stub area or an NSSA.

Use the commands in the following contexts to configure a virtual link.

configure router ospf area virtual-link
configure router ospf3 area virtual-link
configure service vprn ospf area virtual-link 
configure service vprn ospf3 area virtual-link

[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
    export-policy ["OSPF-Export"]
    overload true
    traffic-engineering true
    overload-on-boot {
        timeout 60
    }
    timers {
        lsa-arrival 50000
    }
    asbr 
    }
    area 0.0.0.0 {
        virtual-link 1.2.3.4 transit-area 1.2.3.4 {
            hello-interval 9
            dead-interval 40
        }
    }
    area 0.0.0.20 {
        stub {
            default-metric 5000
        }
    }
    area 0.0.0.25 {
        nssa
    }
    area 1.2.3.4 
    }

A:node-2>config>router>ospf# info
----------------------------------------------
            asbr
            overload
            timers
                lsa-arrival 50000
            exit
            overload-on-boot timeout 60
            traffic-engineering
            export "OSPF-Export"
            exit
            area 0.0.0.0
                virtual-link 1.2.3.4 transit-area 1.2.3.4
                    hello-interval 9
                    dead-interval 40
                exit
            exit
            area 0.0.0.20
                stub
                   default-metric 5000
                exit
            exit
            area 0.0.0.25
                nssa
                exit
            exit
            area 1.2.3.4
            exit
----------------------------------------------

In OSPF, an interface can be configured to act as a connection between a router and one of its attached networks. An interface includes state information obtained from underlying lower level protocols and from the routing protocol itself. An interface to a network is associated with a single IP address and mask (unless the network is an unnumbered point-to-point network). If the address is merely changed, the OSPF configuration is preserved.

By default, only interfaces that are configured under the OSPF interface context are advertised as OSPF interfaces. The passive command allows an interface to be advertised as an OSPF interface without running the OSPF protocol. When enabled, the interface ignores ingress OSPF protocol packets and does not transmit any OSPF protocol packets.

An interface can be part of more than one area, as specified in RFC 5185. This allows multiple secondary adjacencies, in addition to the primary adjacency, to be established over a single IP interface. To do this, add the keyword secondary when creating the interface. The keyword secondary can also be applied to the system interface and to loopback interfaces to allow them to participate in multiple areas, although no adjacencies are formed over these types of interfaces.

Use the commands in the following contexts to configure an OSPF interface, including authentication, hello and dead intervals, interface type, metrics, MTU, priority, retransmit intervals, and so on.

configure router ospf area interface
configure router ospf3 area interface
configure service vprn ospf area interface
configure service vprn ospf3 area interface

The following example shows some interfaces configured for OSPF.

[ex:/configure router "Base" ospf 0]
A:admin@Dut-AC# info
    export-policy ["OSPF-Export"]
    overload true
    overload-on-boot {
        timeout 60
    }
    traffic-engineering true
    timers {
        lsa-arrival 50000
    }
    asbr {
    }
    area 0.0.0.0 {
        nssa {
        }
        interface "system" {
        }
        virtual-link 1.2.3.4 transit-area 1.2.3.4 {
            hello-interval 9
            dead-interval 40
        }
    }
    area 0.0.0.20 {
        stub {
            default-metric 5000
        }
        interface "to-103" {
        }
    }
    area 0.0.0.25 {
        nssa
    }
    area 1.2.3.4 
    }
    area 4.3.2.1 {
        interface "SR1-3" {
        }
    }

A:node-2>config>router>ospf# info
----------------------------------------------
            asbr
            overload
            overload-on-boot timeout 60
            traffic-engineering
            timers
                lsa-arrival 50000
            exit
            export "OSPF-Export"
            exit
            area 0.0.0.0
                virtual-link 1.2.3.4 transit-area 1.2.3.4
                    hello-interval 9
                    dead-interval 40
                exit
                interface "system"
                exit
            exit
            area 0.0.0.20
                stub
                    default-metric 5000
                exit
                interface "to-103"
                exit
            exit
            area 0.0.0.25
                nssa
                exit
            exit
            area 1.2.3.4
            exit 
            area 4.3.2.1
                interface "SR1-3"
                exit
            exit
---------------------------------------------

A designated router is elected according to the priority number advertised by the routers. When a router starts up, it checks for a current designated router. If a designated router is present, then the router accepts that designated router, regardless of its own priority designation. When a router fails, then new designated and backup routers are elected according their priority numbers.

Use the priority command in the following contexts to configure the priority for the OSPF or OSPF3 area interface.

configure router ospf area interface
configure router ospf3 area interface
configure service vprn ospf area interface
configure service vprn ospf3 area interface

[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
    ...
    area 0.0.0.25 {
        nssa {
        }
        interface "if2" {
            priority 100 
        }
    }
    ...

A:node-2>config>router>ospf# info
----------------------------------------------
            ...
            area 0.0.0.25
                nssa
                exit
                interface "if2"
                    priority 100
                exit
            exit
            ...
----------------------------------------------

Area border routers send summary (type 3) advertisements into a stub area or NSSA to describe the routes to other areas. This command is particularly useful to reduce the size of the routing and Link State Database (LSDB) tables within the stub or NSSA.

By default, summary route advertisements are sent into the stub area or NSSA. The no form of the summaries command disables sending summary route advertisements and, in stub areas, the default route is advertised by the area border router.

Use the summaries command in the following contexts to configure route summary features. These command options can be defined at the same time when stub areas and NSSAs are configured. See Configuring a stub area and Configuring a not-so-stubby area.

Use the following commands to configure a route summary.

configure router ospf area stub summaries
configure router ospf3 area stub summaries
configure service vprn ospf area stub summaries
configure service vprn ospf3 area stub summaries
configure router ospf area nssa summaries
configure router ospf3 area nssa summaries
configure service vprn ospf area nssa summaries
configure service vprn ospf3 area nssa summaries

[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
    export-policy ["OSPF-Export"]
    overload true
    traffic-engineering true
    overload-on-boot {
        timeout 60
    }
    asbr {
    }
    area 0.0.0.0 {
        virtual-link 1.2.3.4 transit-area 1.2.3.4 {
            hello-interval 9
            dead-interval 40
        }
        virtual-link 10.0.0.1 transit-area 0.0.0.1 {
            authentication-type message-digest 
            message-digest-key 2 md5 "Mi6BQAFi3MI hash" 
        }
    }
    area 0.0.0.20 {
        stub {
        interface "to-103" {
        }
    }
    area 0.0.0.25 {
        interface "if2" {
            priority 100
        }
        nssa {
        }
    }
    area 0.0.0.40 {
        interface "test1" {
            authentication-key "fBgGq1uSV4L9CTRfb2dINH8S72U4f8wT hash"
            authentication-type password
        }
    }
    area 1.2.3.4 {
    } 

A:node-2>config>router>ospf# info
----------------------------------------------
            asbr
            overload
            overload-on-boot timeout 60
            traffic-engineering
            export "OSPF-Export"
            exit
            area 0.0.0.0
                virtual-link 10.0.0.1 transit-area 0.0.0.1
                    authentication-type message-digest
                    message-digest-key 2 md5 "Mi6BQAFi3MI" hash
                exit
                virtual-link 1.2.3.4 transit-area 1.2.3.4
                    hello-interval 9
                    dead-interval 40
                exit
                interface "system"
                exit
            exit
            area 0.0.0.20
                stub
                exit
                interface "to-103"
                exit
            exit
            area 0.0.0.25
                nssa
                exit
                interface "if2"
                    priority 100
                exit
            exit
            area 0.0.0.40
                interface "test1"
                    authentication-type password
                    authentication-key "3WErEDozxyQ" hash
                exit
            exit
            area 1.2.3.4
            exit
----------------------------------------------

A route can be learned by the router from different protocols, in which case, the costs are not comparable. When this occurs, the preference value is used to decide which route is installed in the forwarding table if several protocols calculate routes to the same destination. The route with the lowest preference value is selected.

Different protocols should not be configured with the same preference, if this occurs the tiebreaker is per the default preference table as defined in Route preference defaults by route type. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used.

If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, the decision of what route to use is determined by the configuration of the ecmp command in the configure router or configure service vprn context.

Use the commands in the following contexts to configure route-preference features. The command options can be defined at the same time you configure OSPF. See Configuring OSPF components.

Use the following commands to configure route preferences and external preferences for OSPF and OSPF3.

configure router ospf external-preference 
configure router ospf preference 
configure router ospf3 external-preference
configure router ospf3 preference 
configure service vprn ospf external-preference
configure service vprn ospf preference
configure service vprn ospf3 external-preference
configure service vprn ospf3 preference

The following example displays a route preference and external-preference configuration for OSPF.

[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
    export-policy ["OSPF-Export"]
    overload true
    preference 9
    external-preference 140
    traffic-engineering true
    overload-on-boot {
        timeout 60
    }
    asbr {
    }
    area 0.0.0.0 {
        virtual-link 1.2.3.4 transit-area 1.2.3.4 {
            hello-interval 9
            dead-interval 40
        }
        virtual-link 10.0.0.1 transit-area 0.0.0.1 {
            authentication-type message-digest 
            message-digest-key 2 md5 "Mi6BQAFi3MI" hash 
        }
    }
    area 0.0.0.20 {
        stub {
        interface "to-103" {
        }
    }
    area 0.0.0.25 {
        interface "if2" {
            priority 100
        }
        nssa {
        }
    }
    area 0.0.0.40 {
        interface "test1" {
            authentication-key "fBgGq1uSV4L9CTRfb2dINH8S72U4f8wT hash2"
            authentication-type password
        }
    }
    area 1.2.3.4 {
    } 

A:node-2>config>router>ospf# info
----------------------------------------------
            asbr
            overload
            overload-on-boot timeout 60
            timers
                lsa-arrival 50000
            exit
            traffic-engineering
            preference 9
            external-preference 140
            export "OSPF-Export"
            exit
            area 0.0.0.0
                virtual-link 10.0.0.1 transit-area 0.0.0.1
                    authentication-type message-digest
                    message-digest-key 2 md5 "Mi6BQAFi3MI" hash
                exit
                virtual-link 1.2.3.4 transit-area 1.2.3.4
                    hello-interval 9
                    dead-interval 40
                exit
                interface "system"
                exit
            exit
            area 0.0.0.20
                stub
                exit
                interface "to-103"
                exit
            exit
            area 0.0.0.25
                nssa
                exit
                interface "if2"
                    priority 100
                exit
            exit
            area 0.0.0.40
                interface "test1"
                    authentication-type password
                    authentication-key "3WErEDozxyQ" hash
                exit
            exit
            area 1.2.3.4
            exit
----------------------------------------------