|
SYSTEM ADMINISTRATOR GUIDE 22/1543-CRA 119 1170/1-V1 Uen B1 | |
Copyright
© Ericsson AB 2009–2010. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.
Disclaimer
The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
Trademark List
| SmartEdge | is a registered trademark of Telefonaktiebolaget LM Ericsson. | |
| NetOp | is a trademark of Telefonaktiebolaget LM Ericsson. |
This document provides an overview of the Open Shortest Path First (OSPF) and describes the tasks and commands used to configure, monitor, troubleshoot, and administer OSPF features through the SmartEdge® router.
OSPF is an Interior Gateway Protocol (IGP) that uses link-state advertisements (LSAs) to inform other routers of the state of the sender’s links. In a link-state routing protocol, each router distributes information about its interfaces and neighbor relationships. The collection of the link states of individual routers forms a database that describes the autonomous system (AS) topology. As OSPF routers accumulate link-state information, they use the Shortest Path First (SPF) algorithm to calculate the shortest path to each node, which forms the basis for developing routing information for that autonomous system.
Redback Networks supports multiple OSPF features, including those specified in the following IETF drafts and RFCs:
In OSPF, the autonomous system can be hierarchically organized by partitioning it into areas; see Figure 1.
Externally derived routes, also called AS-external routes, are routes learned from other routing protocols that are redistributed into the OSPF routing process. These AS-external routes are advertised to all areas, except for stub areas and not-so-stubby-areas (NSSAs). AS-external routes can also be forwarded out to another AS through routers on its boundary.
In-depth information on how OSPF is structured, and how it operates, is described in the following sections.
Each area can contain a group of contiguous networks and hosts. An area border router (ABR) communicates routing information between the areas.
Because routers within the same area share the same information, they have identical topological databases. An area’s topology is invisible to entities outside the area. By keeping area topologies separate, OSPF passes less routing traffic than it would if an autonomous system were not partitioned.
Area partitioning creates two different types of OSPF routing, depending on whether the source and destination are in the same or different areas. Intra-area routing occurs when the source and destination are in the same area; inter-area routing occurs when they are in different areas.
The different area types are described in the following sections.
A normal OSPF area, including the backbone area, is distinguished by the fact that it can carry transit traffic, allowing LSAs from outside the autonomous system (type 5 AS-external-LSAs) to be flooded throughout the area. Type 5 AS-external-LSAs can be originated both by routers internal to the area or by ABRs.
Hierarchical organization of an OSPF autonomous system requires one of the areas to be configured as the backbone area. The backbone area is configured with an identity of 0 and must be contiguous, contain all area border routers, and be responsible for distributing routing information to all other nonbackbone areas.
OSPF also allows some areas to be configured as stub areas. Type 5 AS-external LSAs are not flooded into a stub area, thereby reducing the link state database size and the processor and memory usage of routers inside stub areas. While a stub area cannot propagate routes external to the autonomous system in which it resides, it can propagate a default route, intra-area routes, and inter-area routes. A stub area relies on default routing to forward traffic addressed to external destinations. The backbone area cannot be configured as a stub area.
The SmartEdge router also supports totally-stubby areas which suppress the advertisement of type 3 and 4 LSAs. To create a totally-stubby area, you must enter the area-type stub no-summary command on the border routers of an area.
Not-so-stubby-areas (NSSAs) are an extension of OSPF stub areas. Their intent is to preserve the properties of a stub area, while allowing limited import of external routes from other routing domains. These routes are imported as Type 7 NSSA-external LSAs, which are flooded only within the NSSA. For propagation of these routes to other areas, type 7 LSAs must be translated into type 5 external LSAs by the NSSA ABR. NSSA ABRs will also advertise a type 7 default route into the NSSA, and can be configured to summarize and to filter the translation of type 7 NSSA-external LSAs into Type 5 external LSAs.
Depending on its location in the OSPF hierarchy, an OSPF router can provide one or more of the following functions:
A routing table contains all the information necessary to forward an IP packet to a destination. When forwarding an IP data packet, the routing table entry providing the best match for the packet’s IP destination is located. In the case of OSPF, the best path to a destination is determined via the SPF computation performed on the link-state database.
From the link-state database, the router uses the Dijkstra algorithm to construct a tree of shortest paths with itself as root. This shortest-path tree gives the route to each destination in the autonomous system. A separate SPF computation is performed and a different tree is constructed for each area in which the router resides. Externally derived routing information appears on the tree as leaves. OSPF intra-area and inter-area paths are preferred over external paths.
OSPF runs directly on top of IP (protocol 89). There are five types of packets specified in OSPF:
Each packet includes a common header; see Figure 2.
The OSPF packet header contains the following fields:
Table 1 provides each LSA type and its description.
|
ID |
Type |
Description |
|---|---|---|
|
1 |
Router-LSA |
Originated by all routers. Describes the collected states of the router’s interfaces to an area. Flooded throughout a single area only. |
|
2 |
Network-LSA |
Originated by the designated router. Contains the list of routers connected to the network. Flooded throughout a single area only. |
|
3 |
Summary-LSA (networks) |
Flooded throughout a single area only. Describes routes to networks. Each summary LSA describes a route to a destination outside the area, but still inside the autonomous system. |
|
4 |
Summary-LSA (routers) |
Flooded throughout a single area only. Describes routes to ASBRs. Each summary LSA describes a route to a destination outside the area, but still inside the autonomous system. |
|
5 |
AS-external-LSA |
Originated by ASBRs and flooded throughout the autonomous system. Each AS-external LSA describes a route to a destination in another autonomous system. Default routes for the AS can also be described by AS-external LSAs. |
|
7 |
NSSA-external-LSA |
Flooded throughout a single area only. Type 7 LSAs are advertised only within an NSSA. When forwarded outside the NSSA to non-stub areas, Type 7 LSAs are converted into Type 5 LSAs by an ABR configured to perform translation, or by the ABR with the highest router ID. ABRs can be configured to summarize and filter Type 7 LSAs. |
|
9 |
Link local scope opaque LSA |
Type 9 Opaque LSAs are not flooded beyond the local (sub)network. |
|
10 |
Area local scope opaque LSA |
Type 10 Opaque LSAs are not flooded beyond the borders of their associated area. |
|
11 |
AS scope opaque LSA |
The flooding scope of Type 11 LSAs are equivalent to the flooding scope of AS-external (Type 5) LSAs. Specifically, Type 11 Opaque LSAs are:
|
A sham link is an OSPF adjacency tunneled over a VPN backbone. Sham links allow the VPN backbone path to be preferred when there are intra-area backdoor links between customer edge (CE) routers in the VPN.
The local connected route corresponding to the source IP address for the sham link must be redistributed into BGP and advertised over the VPN infrastructure to a provider edge (PE) router containing the other end of the sham link.
The route corresponding the remote end of the sham link must be redistributed into the corresponding OSPF instance in the VPN context. VPN routing must be enabled for the OSPF instance.
The cost of the sham link can be configured or will inherit the BGP Multi-Exit Discriminator (MED) from the VPN route.
For more information on sham links, see the Internet Draft, OSPF as the PE/CE Protocol in BGP/MPLS VPNs, draft-rosen-vpns-ospf-bgp-mpls-04.txt.
The single backbone area (0.0.0.0) cannot be disconnected, or some areas of the autonomous system will become unreachable. To establish and maintain connectivity of the backbone, virtual links can be configured through non-backbone areas. Virtual links serve to connect physically separate components of the backbone. The two endpoints of a virtual link are area border routers. The virtual link must be configured in both routers. The configuration information in each router consists of the other virtual endpoint (the other area border router), and the non-backbone area the two routers have in common, which is called the transit area. Virtual links cannot be configured through stub areas.
The virtual link is treated as if it were an unnumbered point-to-point network belonging to the backbone and joining the two area border routers. An attempt is made to establish an adjacency over the virtual link. When this adjacency is established, the virtual link is included in backbone router LSAs, and OSPF packets pertaining to the backbone area flow over the virtual adjacency.
In each endpoint router, the cost and viability of the virtual link is discovered by examining the routing table entry for the other endpoint router. An InterfaceUp event occurs for a virtual link when its corresponding routing table entry becomes reachable, and an InterfaceDown event occurs when its routing table entry becomes unreachable.
The other details concerning virtual links are as follows:
For more information on virtual links, see RFC 2328, OSPF Version 2.
Under normal operation, OSPF sends and receives OSPF packets on an interface, and advertises the interface’s IP subnet as an intra-area stub network in the OSPF routing domain. When OSPF passive mode is enabled, OSPF continues to advertise the interface’s IP subnet, but it does not send OSPF packets and drops all received OSPF packets. OSPF passive mode can be enabled for either of the following:
For more information about configuring OSPF passive mode, see the description for the passive command.
OSPF Version 3 (OSPFv3) is the version of OSPF that supports IP Version 6 (IPv6). The fundamental mechanisms of OSPF (flooding, area support, and Shortest Path First [SPF] calculations) remain unchanged in OSPFv3; however, because of changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6, the following changes have been made in OSPFv3:
OSPFv3 also supports all optional OSPF capabilities, including on-demand circuits, NSSA areas, and multicast extensions.
For a description of IPv6 addressing and the types of IPv6 addresses, see RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture.
To configure OSPF or OSPFv3, perform the tasks described in the following sections.
To configure OSPF, perform the tasks described in the sections that follow.
To configure an OSPF routing instance, perform the tasks described in Table 2. Enter all commands in OSPF router configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Create an OSPF routing instance and enter OSPF router configuration mode. |
Enter this command in context configuration mode. | |
|
Specify that the OSPF interface cost is computed automatically and to configure the reference bandwidth that is used in the interface cost computation. |
The interface cost is computed by dividing the reference bandwidth by the interface speed. A cost of one is assigned if the interface speed is greater than the reference bandwidth. You can override the automatic cost setting on individual interfaces by issuing the cost command in OSPF interface configuration mode. For more information, see Configure an OSPF Interface. | |
|
Enable the advertisement of router capabilities using OSPF opaque LSAs. |
— | |
|
Configure a default metric that is used for redistributed OSPF routes when no metric is specified. |
— | |
|
Modify the OSPF distance value of one or more of these route types. |
The distance value of a route is used to select the preferred route when there are equivalent routes from multiple protocols. When a distance comparison is made the route with the lowest distance is selected. By default, OSPF external, inter-area, and intra-area routes are set to a distance value of 110. | |
|
Enable fast convergence for the OSPF instance. |
Use the spf-delay-interval argument to set an SPF delay that is less than one second. When fast convergence is enabled, the spf-delay-interval argument provides an SPF delay with sub-second (millisecond) granularity, and the value for the delay argument of the spf-timers command (in OSPF router configuration mode) is ignored, regardless of whether it has been configured. Otherwise, under normal convergence, the delay argument value (in seconds) is used. Use the max-spf-count argument to allow additional SPF calculations within the SPF hold time specified by the spf-timers command. Specifying a value greater than zero effectively squeezes additional SPF calculations into the SPF time interval; specifying a value of zero does not allow for squeezing additional SPF calculations into the SPF hold time and returns OSPF to the standard SPF hold time behavior. | |
|
Enable OSPF fast LSA origination for an OSPF instance. |
Normally, OSPF originates an LSA every five seconds. Because there can be multiple changes to router or network LSAs during that five-second interval, the five-second LSA origination limit can slow network convergence. When fast LSA origination is enabled, up to four instances of the same LSA can be originated in the same five-second interval. Likewise, LSA reception is normally rate limited to one new LSA instance per second. LSA instances received in less than one second after the previous LSA instance are dropped. When fast LSA origination is enabled, LSA reception is not restricted to one new instance per second. | |
|
Enable graceful restart for an OSPF instance. |
— | |
|
Enables LDP-IGP synchronization between OSPF and LDP. |
ldp-igp-synchronization [timeout seconds] |
Use the optional timeout seconds construct to set the maximum number of seconds the interface waits before transporting traffic without receiving notification from LDP that label exchange is completed.(1) |
|
Log neighbor transitions to and from the full neighbor adjacency state. |
— | |
|
Enable the use of MPLS LSPs as intra-area next hops. |
— | |
|
Enable the advertisement of OSPF Traffic Engineering (TE) metrics. |
— | |
|
Originate the default route advertisement in the OSPF routing domain. |
— | |
|
Configure a fixed OSPF router ID for the SmartEdge router. |
The router ID is used by OSPF to identify the originating router for packets and link-state advertisements (LSAs). If the OSPF router ID is not configured, OSPF chooses the lowest loopback interface address. If there are no loopback interfaces, OSPF chooses the lowest interface address. The default OSPF router ID is selected when OSPF is started initially or restarted using the process restart ospf command in exec mode. | |
|
Configure the delay time between the receipt of a topology change and the start of the Shortest Path First (SPF) calculation, and to determine the hold time between two consecutive SPF calculations. |
— | |
|
Configure the SmartEdge router as an OSPF stub router. |
— | |
|
Configure the redistribution of routes into the OSPF routing instance. |
For the complete list of tasks used to configure the redistribution of routes into the OSPF routing instance, see Configure the Redistribution of Routes into OSPF. |
— |
|
Configure an OSPF area. |
For the complete list of tasks used to configure an OSPF area, see Configure an OSPF Area. |
— |
(1) Use the ldp-igp-synchronization
timeout command in LDP configuration mode to set the maximum
number of seconds LDP waits before notifying the IGP that label exchange
is completed, so that IGP can start advertising the normal metric
for the link. See Configuring LDP for more information.
You can redistribute routes learned from other protocols into the OSPF routing instance, set a limit on the number of routes that can be redistributed into the OSPF routing instance, and set a limit on the number of routes per second that can be redistributed into the OSPF routing instance.
To configure the redistribution of routes into the OSPF routing instance, perform the tasks described in Table 3. Enter all commands in OSPF router configuration mode.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Redistribute routes learned from other protocols into the OSPF routing instance. |
— | |
|
Set a maximum limit on the number of routes that can be redistributed into the specified OSPF instance. |
— | |
|
Set a maximum limit on the number of routes that can be redistributed per second into the OSPF routing instance. |
— | |
|
Summarize external routes that are redistributed into the OSPF routing instance. |
— |
To configure an OSPF area, perform the tasks described in Table 4. Enter all commands in OSPF area configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Create an OSPF area and enter OSPF area configuration mode. |
Enter this command in OSPF router configuration mode. | |
|
Define an OSPF area as a stub area or as an NSSA. |
— | |
|
Change the attributes of a default route originated into a stub area or an NSSA. |
— | |
|
Summarize NSSA routes advertised by an ABR. |
— | |
|
Set all interfaces configured in the specified OSPF area to passive mode. |
OSPF passive mode disables OSPF interfaces from sending OSPF packets. Setting all interfaces in an OSPF area to passive mode is useful for large, pure edge aggregation applications, where there may be hundreds, or perhaps thousands, of customer-facing circuits. To distribute routes for the customer-facing interfaces to the upstream routers, you can enable OSPF on the customer-facing interfaces, and then set them all to passive mode using the passive command in OSPF area configuration mode. | |
|
Summarize inter-area routes advertised by an ABR. |
— | |
|
Configure an OSPF interface. |
For the complete list of tasks used to configure an OSPF interface, see Configure an OSPF Interface. |
— |
|
Configure an OSPF sham link. |
For the complete list of tasks used to configure an OSPF sham link, see Configure an OSPF Sham Link. |
— |
|
Configure an OSPF virtual link. |
For the complete list of tasks used to configure an OSPF virtual link, see Configure an OSPF Virtual Link. |
— |
To configure an OSPF interface, perform the tasks described in Table 5. Enter all commands in OSPF interface configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Enable OSPF routing on an interface and enter OSPF interface configuration mode. |
Enter this command in OSPF area configuration mode. | |
|
Enable authentication and specify the authentication scheme for an OSPF interface. |
Routes within the same area are not required to use the same authentication scheme and key ID; however, if two routers directly exchange updates, they must have the same authentication scheme and key ID. | |
|
Block the flooding of LSAs that are not self-originated. |
Blocking flooding on an interface can result in inconsistencies between OSPF routers and their respective route tables. Exercise caution before blocking the flooding of LSAs that are not self-originated. | |
|
Configure the cost used in SPF computation for the specified OSPF-enabled interface. |
The lower the cost, the more likely the interface is to be used to forward data traffic. | |
|
Configure OSPF to treat a point-to-point (P2P) or a point-to-multipoint (P2MP) interface as a demand circuit. |
Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes or packets transmitted. OSPF routing usually requires a demand circuit’s underlying data-link connection to be constantly open, resulting in unwanted usage charges. Using the demand-circuit command enables OSPF Hello packets and the refresh of OSPF routing information to be suppressed on-demand circuits, allowing the underlying data-link connections to be closed when not carrying traffic. Hello suppression is not negotiated unless demand circuit support is enabled. | |
|
Disable Bidirectional Forwarding Detection (BFD) for an OSPF interface. |
Use the no or default form of this command to reenable BFD on an OSPF interface. | |
|
Enable the sending of more than one OSPF Hello packet per second on the interface. |
Using this command results in faster OSPF convergence. The following restrictions apply to this command:
| |
|
Suppress the periodic LSA refresh in stable topologies. |
If demand circuit operation is implicitly or explicitly enabled, LSAs are flooded as DoNotAge LSAs on the OSPF interface, and will not be reflooded until the network topology changes. | |
|
Configure the interval at which OSPF hello packets are sent on the interface. |
— | |
|
Enables or disables LDP-IGP synchronization between LDP and OSPF on this particular interface. |
When you use the ldp-igp-synchronization command in OSPF router configuration mode, LDP-IGP synchronization between LDP and OSPF is enabled for all interfaces on the router. You can then use the no ldp-igp-synchronization command in OSPF interface configuration mode to disable LDP-IGP synchronization between LDP and OSPF on an individual interface. Use the ldp-igp-synchronization command in OSPF interface configuration mode to reenable LDP-IGP synchronization between LDP and OSPF on an individual interface that has LDP-IGP synchronization between LDP and OSPF disabled. | |
|
Configure an OSPF neighbor. |
— | |
|
Configure the OSPF network type. |
You can specify any of the following network types:
| |
|
Set the OSPF interface to passive mode. |
OSPF passive mode disables OSPF interfaces from sending OSPF packets. | |
|
Modify the interval at which LSAs are retransmitted in link state update packets on an interface. |
— | |
|
Modify the amount of time the OSPF routing process waits to receive an OSPF Hello packet from a neighbor before determining that the neighbor is not operational. |
— | |
|
Modify the OSPF preference value for the SmartEdge router to act as the designated router on the network. |
— | |
|
Set a delay value, increasing the age of LSAs sent out through the OSPF interface. |
— |
To configure an OSPF sham link, perform the tasks described in Table 6. Enter all commands in OSPF sham link configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Create an OSPF adjacency tunneled over a VPN backbone (sham link). |
Enter this command in OSPF area configuration mode. | |
|
Enable authentication and specify the authentication scheme for an OSPF sham link. |
Routes within the same area are not required to use the same authentication scheme and key ID; however, if two routers directly exchange updates, they must have the same authentication scheme and key ID. | |
|
Configure the cost used in SPF computation for the an OSPF sham link. |
The lower the cost, the more likely the sham link is to be used to forward data traffic. | |
|
Configure the interval at which OSPF hello packets are sent out through an OSPF sham link. |
— | |
|
Modify the interval at which LSAs are retransmitted in link state update packets on an OSPF sham link. |
— | |
|
Modify the amount of time the OSPF routing process waits to receive an OSPF Hello packet from a neighbor before determining that the neighbor is not operational. |
— | |
|
Set a delay value, increasing the age of LSAs sent out through an OSPF sham link. |
— |
To configure an OSPF virtual link, perform the tasks described in Table 7. Enter all commands in OSPF virtual link configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Create a virtual link through the specified transit area. |
Enter this command in OSPF area configuration mode. | |
|
Enable authentication and specify the authentication scheme for an OSPF virtual link. |
Routes within the same area are not required to use the same authentication scheme and key ID; however, if two routers directly exchange updates, they must have the same authentication scheme and key ID. | |
|
Configure the interval at which OSPF hello packets are sent out through an OSPF virtual link. |
— | |
|
Modify the interval at which LSAs are retransmitted in link state update packets on an OSPF virtual link. |
— | |
|
Modify the amount of time the OSPF routing process waits to receive an OSPF Hello packet from a neighbor before determining that the neighbor is not operational. |
— | |
|
Set a delay value, increasing the age of LSAs sent out through an OSPF virtual link. |
— |
To configure OSPFv3, perform the tasks described in the following sections.
To configure an OSPFv3 routing instance, perform the tasks described in Table 8. Enter all commands in OSPF3 router configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Create an OSPFv3 routing instance and enter OSPF3 router configuration mode. |
Enter this command in context configuration mode. | |
|
Specify that the OSPFv3 interface cost is computed automatically and to configure the reference bandwidth that is used in the interface cost computation. |
The interface cost is computed by dividing the reference bandwidth by the interface speed. A cost of one is assigned if the interface speed is greater than the reference bandwidth. You can override the automatic cost setting on individual interfaces by issuing the cost command in OSPFv3 interface configuration mode. For more information, see Configure an OSPFv3 Interface. | |
|
Configure a default metric that is used for redistributed OSPFv3 routes when no metric is specified. |
— | |
|
Modify the OSPFv3 distance value of one or more of these route types. |
The distance value of a route is used to select the preferred route when there are equivalent routes from multiple protocols. When a distance comparison is made the route with the lowest distance is selected. By default, OSPFv3 external, inter-area, and intra-area routes are set to a distance value of 110. | |
|
Enable graceful restart for an OSPFv3 instance. |
— | |
|
Log neighbor transitions to and from the full neighbor adjacency state. |
— | |
|
Originate the default route advertisement in the OSPFv3 routing domain. |
— | |
|
Configure a fixed OSPFv3 router ID for the SmartEdge router. |
The router ID is used by OSPFv3 to identify the originating router for packets and link-state advertisements (LSAs). If the OSPFv3 router ID is not configured, OSPFv3 chooses the lowest loopback interface address. If there are no loopback interfaces, OSPFv3 chooses the lowest interface address. The default OSPFv3 router ID is selected when OSPFv3 is started initially or restarted using the process restart ospf command in exec mode. | |
|
Configure the delay time between the receipt of a topology change and the start of the Shortest Path First (SPF) calculation, and to determine the hold time between two consecutive SPF calculations. |
— | |
|
Configure the SmartEdge router as an OSPFv3 stub router. |
— | |
|
Configure the redistribution of routes into the OSPFv3 routing instance. |
For the complete list of tasks used to configure the redistribution of routes into the OSPFv3 routing instance, see Configure OSPFv3 Route Redistribution and Aggregation. |
— |
|
Configure an OSPFv3 area. |
For the complete list of tasks used to configure an OSPFv3 area, see Configure an OSPFv3 Area. |
— |
You can redistribute routes learned from other protocols into the OSPFv3 routing instance, set a limit on the number of routes that can be redistributed into the OSPFv3 routing instance, and set a limit on the number of routes per second that can be redistributed into the OSPFv3 routing instance.
To configure the redistribution of routes into the OSPFv3 routing instance, perform the tasks described in Table 9. Enter all commands in OSPF3 router configuration mode.
|
Task |
Root Command |
|---|---|
|
Redistribute routes learned from other protocols into the OSPFv3 routing instance. |
|
|
Set a maximum limit on the number of routes that can be redistributed into the specified OSPFv3 instance. |
|
|
Set a maximum limit on the number of routes that can be redistributed per second into the OSPFv3 routing instance. |
|
|
Summarize external routes that are redistributed into the OSPFv3 routing instance. |
To configure an OSPFv3 area, perform the tasks described in Table 10. Enter all commands in OSPF3 area configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Create an OSPFv3 area and enter OSPF3 area configuration mode. |
Enter this command in OSPF3 router configuration mode. | |
|
Define an OSPFv3 area as a stub area or as an NSSA. |
— | |
|
Change the attributes of a default route originated into a stub area or an NSSA. |
— | |
|
Summarize NSSA routes advertised by an ABR. |
— | |
|
Summarize inter-area routes advertised by an ABR. |
— | |
|
Configure an OSPFv3 interface. |
For the complete list of tasks used to configure an OSPFv3 interface, see Configure an OSPFv3 Interface. |
— |
To configure an OSPFv3 interface, perform the tasks described in Table 11. Enter all commands in OSPF3 interface configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Enable OSPFv3 routing on an interface and enter OSPF3 interface configuration mode. |
Enter this command in OSPF3 area configuration mode. | |
|
Block the flooding of LSAs that are not self-originated. |
Blocking flooding on an interface can result in inconsistencies between OSPFv3 routers and their respective route tables. Exercise caution before blocking the flooding of LSAs that are not self-originated. | |
|
Configure the cost used in SPF computation for the specified OSPFv3-enabled interface. |
The lower the cost, the more likely the interface is to be used to forward data traffic. | |
|
Configure OSPFv3 to treat a P2P or a P2MP interface as a demand circuit. |
Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes or packets transmitted. OSPFv3 routing usually requires a demand circuit’s underlying data-link connection to be constantly open, resulting in unwanted usage charges. Using the demand-circuit command enables OSPFv3 Hello packets and the refresh of OSPFv3 routing information to be suppressed on-demand circuits, allowing the underlying data-link connections to be closed when not carrying traffic. Hello suppression is not negotiated unless demand circuit support is enabled. | |
|
Suppress the periodic LSA refresh in stable topologies. |
If demand circuit operation is implicitly or explicitly enabled, LSAs are flooded as DoNotAge LSAs on the OSPFv3 interface, and will not be reflooded until the network topology changes. | |
|
Configure the interval at which OSPFv3 hello packets are sent on the interface. |
— | |
|
Configure an OSPFv3 neighbor. |
— | |
|
Configure the OSPFv3 network type. |
You can specify any of the following network types:
| |
|
Set the OSPFv3 interface to passive mode. |
OSPF passive mode disables OSPFv3 interfaces from sending OSPF packets. | |
|
Modify the interval at which LSAs are retransmitted in link-state update packets on an interface. |
— | |
|
Modify the amount of time the OSPFv3 routing process waits to receive an OSPFv3 Hello packet from a neighbor before determining that the neighbor is not operational. |
— | |
|
Modify the OSPFv3 preference value for the SmartEdge router to act as the designated router on the network. |
— | |
|
Set a delay value, increasing the age of LSAs sent out through the OSPFv3 interface. |
— |
To configure an OSPFv3 virtual link, perform the tasks described in Table 12. Enter all commands in OSPF3 virtual link configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Create an OSPFv3 virtual link through the specified transit area. |
Enter this command in OSPF3 area configuration mode. | |
|
Configure the interval at which OSPFv3 hello packets are sent out through an OSPFv3 virtual link. |
— | |
|
Modify the interval at which LSAs are retransmitted in link state update packets on an OSPFv3 virtual link. |
— | |
|
Modify the amount of time the OSPFv3 routing process waits to receive an OSPFv3 Hello packet from a neighbor before determining that the neighbor is not operational. |
— | |
|
Set a delay value, increasing the age of LSAs sent out through an OSPFv3 virtual link. |
— |
To manage OSPF and OSPFv3 functions, perform the appropriate tasks described in Table 13. Enter the show commands in any mode; enter the clear, debug, and monitor commands in exec mode.
|
Task |
Root Command |
|---|---|
|
Clear OSPF neighbor adjacencies, routes redistributed into OSPF, all routes, or statistics. |
|
|
Enable the generation of debug messages for all OSPF events. |
|
|
Enable the generation of debug messages for OSPF flooding events. |
|
|
Enable the generation of debug messages for a specific OSPF interface. |
|
|
Enable the generation of debug messages for OSPF LSDB events. |
|
|
Enable the generation of debug messages for OSPF neighbor events. |
|
|
Enable the generation of debug messages for OSPF packet events. |
|
|
Enable the generation of debug messages for interactions between OSPF and the Router Configuration Manager (RCM). |
|
|
Enable the generation of debug messages for OSPF redistribution events. |
|
|
Enable the generation of debug messages for interactions between OSPF and the Routing Information Base (RIB). |
|
|
Enable the generation of debug messages for OSPF SPF calculations. |
|
|
Display continuously updated information about OSPF interfaces. |
|
|
Display continuously updated information about OSPF neighbors. |
|
|
Display continuously updated information about the most recent OSPF SPF calculation. |
|
|
Display continuously updated information about OSPF statistics. |
|
|
Display the current OSPF configuration information for the current context. |
|
|
Display high-level information for all OSPF instances, or optionally, for a specific OSPF instance. |
|
|
Display OSPF area information. |
|
|
Display OSPF ABR and ASBR information. |
|
|
Display information stored in the OSPF link-state database (LSDB). |
|
|
Display information about OSPF advertising router LSAs. |
|
|
Display information about OSPF opaque Type 10 link-state advertisements (LSAs). |
|
|
Display information about OSPF opaque Type 11 LSAs. |
|
|
Display a count, grouped by type, of OSPF LSAs. |
|
|
Display information about OSPF Type 5 AS external LSAs. |
|
|
Display information about the OSPF interface LSD. |
|
|
Display information about OSPF opaque Type 9 Shortest Path First (SPF). |
|
|
Display information about OSPF network LSAs. |
|
|
Display information about OSPF not-so-stubby-area (NSSA) LSAs. |
|
|
Display information about OSPF router LSAs. |
|
|
Display information about OSPF Type 4 summary autonomous system boundary routers (ASBRs) and other OSPFv3 routers. |
|
|
Display information about OSPF Type 3 summary network LSAs. |
|
|
Display the OSPF debug settings that have been enabled. |
|
|
Display OSPF interface information. |
|
|
Display OSPF neighbor information. |
|
|
Display OSPF route information. |
|
|
Display OSPF SPF computation information. |
|
|
Display OSPF statistics. |
|
|
Display OSPF summary address information. |
|
|
Display high-level information for all OSPFv3 instances, or optionally, for a specific instance. |
|
|
Display information about OSPFv3 areas. |
|
|
Display routes to ASBRs and other OSPFv3 routers. |
|
|
Display information stored in the OSPFv3 LSD. |
|
|
Display information about OSPFv3 advertising router LSAs. |
|
|
Display information about OSPFv3 grace LSA database entries. |
|
|
Display information about OSPFv3 inter-area prefix LSA database entries. |
|
|
Display information about OSPFv3 inter-area router LSA database entries. |
|
|
Display information about OSPFv3 intra-area prefix LSA database entries. |
|
|
Display information about OSPFv3 link LSAs. |
|
|
Display information about OSPFv3 network LSAs. |
|
|
Display information about OSPFv3 NSSA LSAs. |
|
|
Display information about OSPFv3 router LSAs. |
|
|
Display OSPFv3 debug information. |
|
|
Display OSPFv3 interface information. |
|
|
Display OSPFv3 intra-RIB information. |
|
|
Display OSPFv3 malform log information. |
|
|
Display OSPFv3 neighbor information. |
|
|
Display OSPFv3 route information. |
|
|
Display OSPFv3 SPF calculation statistics. |
|
|
Display OSPFv3 statistics. |
|
|
Display OSPFv3 summary address information. |
The sections that follow provide OSPF configuration examples.
Figure 3 illustrates the base OSPF topology for the examples provided in this section.
This section contains the basic OSPF configuration for the three routers, SE1, SE2, and SE3, illustrated in Figure 3. Examples in proceeding sections contain only the configuration sections different from the examples here.
The basic configuration for SE1 is as follows. Because no router ID is explicitly configured, the loopback address is used as the OSPF router ID for SE1:
[local]SE1(config)#context local [local]SE1(config-ctx)#ip domain-lookup [local]SE1(config-ctx)#interface one [local]SE1(config-if)#ip address 193.4.5.2/16 [local]SE1(config-if)#exit [local]SE1(config-ctx)#interface two [local]SE1(config-if)#ip address 10.1.1.1/16 [local]SE1(config-if)#exit [local]SE1(config-ctx)#interface three [local]SE1(config-if)#ip address 10.3.1.1/16 [local]SE1(config-if)#exit [local]SE1(config-ctx)#interface lo1 loopback [local]SE1(config-if)#ip address 193.10.25.7/32 [local]SE1(config-if)#exit [local]SE1(config-ctx)#router ospf 1 [local]SE1(config-ospf)#area 0.0.0.0 [local]SE1(config-ospf-area)#interface 193.4.5.2 [local]SE1(config-ospf-if)#exit [local]SE1(config-ospf-area)#interface 193.10.25.7 [local]SE1(config-ospf-area)#exit [local]SE1(config-ospf)#area 0.0.0.1 [local]SE1(config-ospf-area)#interface two [local]SE1(config-ospf-if)#exit [local]SE1(config-ospf-area)#interface three [local]SE1(config-ospf-if)#exit [local]SE1(config-ospf-area)#exit [local]SE1(config-ospf)#exit [local]SE1(config-ctx)#exit [local]SE1(config)#port pos 5/1 [local]SE1(config-port)#bind interface one local [local]SE1(config-port)#no shutdown [local]SE1(config-port)#exit [local]SE1(config)#port pos 5/2 [local]SE1(config-port)#bind interface two local [local]SE1(config-port)#no shutdown [local]SE1(config-port)#exit [local]SE1(config)#port pos 5/3 [local]SE1(config-port)#bind interface three local [local]SE1(config-port)#no shutdown
The basic configuration for SE2 is as follows:
[local]SE2(config)#context local [local]SE2(config-ctx)#ip domain-lookup [local]SE2(config-ctx)#interface one [local]SE2(config-if)#ip address 10.1.2.2/16 [local]SE2(config-if)#exit [local]SE2(config-ctx)#interface two [local]SE2(config-if)#ip address 10.2.1.1/16 [local]SE2(config-if)#exit [local]SE2(config-ctx)#router ospf 1 [local]SE2(config-ospf)#router-id 22.22.22.22 [local]SE2(config-ospf)#area 0.0.0.1 [local]SE2(config-ospf-area)#interface 10.1.2.2 [local]SE2(config-ospf-if)#exit [local]SE2(config-ospf-area)#interface 10.2.1.1 [local]SE2(config-ospf-if)#exit [local]SE2(config-ospf-area)#exit [local]SE2(config-ospf)#exit [local]SE2(config-ctx)#exit [local]SE2(config)#port pos 3/1 [local]SE2(config-port)#bind interface one local [local]SE2(config-port)#no shutdown [local]SE2(config-port)#exit [local]SE2(config)#port ethernet 4/1 [local]SE2(config-port)#bind interface two local [local]SE2(config-port)#no shutdown
The basic configuration for SE3 is as follows:
[local]SE3(config)#context local [local]SE3(config-ctx)#ip domain-lookup [local]SE3(config-ctx)#interface one [local]SE3(config-if)#ip address 10.3.2.2/16 [local]SE3(config-if)#exit [local]SE3(config-ctx)#interface two [local]SE3(config-if)#ip address 10.2.2.2/16 [local]SE3(config-if)#exit [local]SE3(config-ctx)#interface three [local]SE3(config-if)#ip address 20.1.1.1/24 [local]SE3(config-if)#exit [local]SE3(config-ctx)#router ospf 1 [local]SE3(config-ospf)#router-id 33.33.33.33 [local]SE3(config-ospf)#area 0.0.0.0 [local]SE3(config-ospf-area)#interface 20.1.1.1 [local]SE3(config-ospf-if)#exit [local]SE3(config-ospf-area)#exit [local]SE3(config-ospf)#area 0.0.0.1 [local]SE3(config-ospf-area)#interface 10.2.2.2 [local]SE3(config-ospf-if)#exit [local]SE3(config-ospf-area)#interface 10.3.2.2 [local]SE3(config-ospf-if)#exit [local]SE3(config-ospf-area)#exit [local]SE3(config-ospf)#exit [local]SE3(config-ctx)#exit [local]SE3(config)#port pos 3/1 [local]SE3(config-port)#bind interface one local [local]SE3(config-port)#no shutdown [local]SE3(config-port)#exit [local]SE3(config)#port ethernet 1/1 [local]SE3(config-port)#bind interface two local [local]SE3(config-port)#no shutdown [local]SE3(config-port)#exit [local]SE3(config)#port pos 3/2 [local]SE3(config-port)#bind interface three local [local]SE3(config-port)#no shutdown
The following example illustrates how to configure LDP-IGP synchronization between LDP and OSPF. In this example, the user enables LDP-IGP synchronization between LDP and OSPF on all interfaces configured in the context called OSPF1. The user then disables LDP-IGP synchronization with OSPF on one particular interface, called ospf-int-1. Finally, the user sets the maximum number of seconds LDP waits before notifying OSPF that label exchange is completed to 10 seconds:
Enable LDP-IGP synchronization with OSPF on all interfaces configured on the router: [local]Redback(config)#context local [local]Redback(config-ctx)#router ospf 1 [local]Redback(config-ospf)#ldp-igp-synchronization timeout 1000 Disable LDP-IGP synchronization with OSPF on the interface ospf-int-1: [local]Redback(config-ospf)#area 0.0.0.0 [local]Redback(config-ospf-area)#interface ospf-int-1 [local]Redback(config-ospf-if)#no ldp-igp-synchronization Set the maximum number of seconds LDP waits before notifying OSPF that label exchange is completed to 10 seconds: [local]Redback(config-ospf-if)#exit [local]Redback(config-ospf-area)#exit [local]Redback(config-ospf)#exit [local]Redback(config-ctx)#ldp [local]Redback(config-ldp)#ldp-igp synchronization timeout 10
The following example illustrates how to redistribute static routes into the OSPF routing instance and how to modify the attributes of the redistributed routes. Only the routes matching the 122-nets-only IP prefix list are selected for redistribution. These routes are 122.1.1.0/24, 122.1.2.0/24, and 122.1.3.0/24. Once redistributed to OSPF, the routes are advertised with metric type 1 and metric value of 500. All modifications are accomplished by using the route map, static-to-ospf:
[local]Redback(config)#context local [local]Redback(config-ctx)#ip domain-lookup [local]Redback(config-ctx)#interface one [local]Redback(config-if)#ip address 10.1.2.2/16 [local]Redback(config-if)#exit [local]Redback(config-ctx)#interface two [local]Redback(config-if)#ip address 10.2.1.1/16 [local]Redback(config-if)#exit [local]Redback(config-ctx)#interface three [local]Redback(config-if)#ip address 10.5.1.1/30 [local]Redback(config-if)#exit [local]Redback(config-ctx)#router ospf 1 [local]Redback(config-ospf)#router-id 22.22.22.22 [local]Redback(config-ospf)#area 0.0.0.1 [local]Redback(config-ospf-area)#interface 10.1.2.2 [local]Redback(config-ospf-if)#exit [local]Redback(config-ospf-area)#interface 10.2.1.1 [local]Redback(config-ospf-if)#exit [local]Redback(config-ospf-area)#exit [local]Redback(config-ospf)#redistribute static route-map static-to-ospf [local]Redback(config-ospf)#exit [local]Redback(config-ctx)#ip prefix-list 122-nets-only [local]Redback(config-prefix-list)#seq 10 permit 122.0.0.0/8 le 24 [local]Redback(config-prefix-list)#seq 20 deny 0.0.0.0/0 [local]Redback(config-prefix-list)#exit [local]Redback(config-ctx)#route-map static-to-ospf permit 10 [local]Redback(config-route-map)#match ip address prefix-list 122-nets-only [local]Redback(config-route-map)#set metric 500 [local]Redback(config-route-map)#set metric-type type-1 [local]Redback(config-route-map)#exit [local]Redback(config-ctx)#ip route 50.0.0.0/8 three [local]Redback(config-ctx)#ip route 121.1.1.0/24 three [local]Redback(config-ctx)#ip route 121.1.2.0/24 three [local]Redback(config-ctx)#ip route 121.1.3.0/24 three [local]Redback(config-ctx)#ip route 121.1.5.0/24 three [local]Redback(config-ctx)#ip route 122.1.1.0/24 three [local]Redback(config-ctx)#ip route 122.1.2.0/24 three [local]Redback(config-ctx)#ip route 122.1.3.0/24 three [local]Redback(config-ctx)#exit [local]Redback(config)#port pos 3/1 [local]Redback(config-port)#bind interface one local [local]Redback(config-port)#no shutdown [local]Redback(config-port)#exit [local]Redback(config)#port ethernet 4/1 [local]Redback(config-port)#bind interface two local [local]Redback(config-port)#no shutdown [local]Redback(config-port)#exit [local]Redback(config)#port pos 3/2 [local]Redback(config-port)#bind interface three local [local]Redback(config-port)#no shutdown
The following example configures route redistribution and aggregation for an OSPFv3 routing instance. First, configure a list of aggregate IP prefixes:
[local]Router(config-ctx)#ipv6 prefix-list test1-aggregate [local]Router(config-ipv6-prefix-list)#seq 10 permit 4001:101:101:106::/64 ge 64 [local]Router(config-ipv6-prefix-list)#seq 20 permit 5001:101:101:106::/64 ge 64 [local]Router(config-ipv6-prefix-list)#seq 30 permit 6001:101:101:106::/64 ge 64 [local]Router(config-ipv6-prefix-list)#seq 40 permit 7001:101:101:106::/64 ge 64 [local]Router(config-ipv6-prefix-list)#seq 50 permit 2001:101:101::/48 ge 48
Next, configure a route map called test1 that aggregates the IPv6 prefixes in the aggregate prefix list called test1-aggregate:
[local]Router(config-ctx)#route-map test1 permit 10 [local]Router(config-route-map)#match ipv6 address prefix-list test1-aggregate [local]Router(config-route-map)#set ipv6 aggregate test1-aggregate
Specify that routes selected for redistribution are summarized only if they contain any of the prefixes specified in the IPv6 prefix list called test1:
[local]Redback(config-ctx)#router ospf3 1 [local]Redback(config-ospf3)#redistribute subscriber static route-map test1
Configure the static routes. In this example, the routes match the aggregate prefix 2001:101:101::/48:
[local]Redback(config-ctx)#ipv6 route 2001:101:101:303::/64 80::2 [local]Redback(config-ctx)#ipv6 route 2001:101:101:304::/64 80::2 [local]Redback(config-ctx)#ipv6 route 2001:101:101:305::/64 80::2 [local]Redback(config-ctx)#ipv6 route 2001:101:101:306::/64 80::2 [local]Redback(config-ctx)#ipv6 route 2001:101:101:307::/64 80::2
The following example shows how to use MD5 to provide authentication between two routers. Authentication is only configured at the interface level. A different type of authentication can be used on each interface and no area configuration is required.
The configuration for SE1 is as follows:
[local]SE1(config-ctx)#router ospf 1 [local]SE1(config-ospf)#area 0.0.0.0 [local]SE1(config-ospf-area)#interface 193.4.5.2 [local]SE1(config-ospf-if)#exit [local]SE1(config)#interface 193.10.25.7 [local]SE1(config-ospf-if)#exit [local]SE1(config-ospf-area)#exit [local]SE1(config-ospf)#area 0.0.0.1 [local]SE1(config-ospf-area)#interface two [local]SE1(config-ospf-if)#authentication md5 ospf-key-chain [local]SE1(config-ospf-if)#exit [local]SE1(config-ospf-area)#interface three
The configuration for SE2 is as follows:
[local]SE2(config-ctx)#router ospf 1 [local]SE2(config-ospf)#router-id 22.22.22.22 [local]SE2(config-ospf)#area 0.0.0.1 [local]SE2(config-ospf-area)#interface 10.1.2.2 [local]SE2(config-ospf-if)#authentication md5 ospf-key-chain [local]SE2(config-ospf-if)#exit [local]SE2(config-ospf-area)#interface 10.2.1.1
This example shows how key chain lifetimes can be used to non-disruptively switch from one key string to another. OSPF always sends the key with the most recent send-lifetime start time which is not greater than the current time. It accepts any key whose accept lifetime value includes the current time.
The configuration for both SE1 and SE2 is as follows:
[local]Redback(config-ctx)#key-chain ospf-key-chain key-id 1 [local]Redback(config-key-chain)#key-string secret [local]Redback(config-key-chain)#accept-lifetime 2001:09:07:00:00:00 2002:09:07:12:00:00 [local]Redback(config-key-chain)#send-lifetime 2001:09:07:00:00:00 2002:09:07:08:00:00 [local]Redback(config-key-chain)#exit [local]Redback(config-ctx)#key-chain ospf-key-chain key-id 2 [local]Redback(config-key-chain)#key-string psst [local]Redback(config-key-chain)#accept-lifetime 2002:09:07:00:00:00 2003:09:07:12:00:00 [local]Redback(config-key-chain)#send-lifetime 2002:09:07:08:00:00 2003:09:07:07:00:00
