Generating a Default Route
You can force an autonomous system boundary router to generate a default route into an OSPF routing domain. Whenever you specifically configure redistribution of routes into an OSPF routing domain, the router automatically becomes an autonomous system boundary router. However, an autonomous system boundary router does not by default generate a default route into the OSPF routing domain.
To generate a default route, perform the following steps:
Detailed Steps
Configuring Route Summarization When Redistributing Routes into OSPF
When routes from other protocols are redistributed into OSPF, each route is advertised individually in an external LSA. However, you can configure the ASA to advertise a single route for all the redistributed routes that are covered by a specified network address and mask. This configuration decreases the size of the OSPF link-state database.
To configure the software advertisement on one summary route for all redistributed routes covered by a network address and mask, perform the following steps:
Detailed Steps
Configuring Route Summarization Between OSPF Areas
Route summarization is the consolidation of advertised addresses. This feature causes a single summary route to be advertised to other areas by an area boundary router. In OSPF, an area boundary router advertises networks in one area into another area. If the network numbers in an area are assigned in a way such that they are contiguous, you can configure the area boundary router to advertise a summary route that covers all the individual networks within the area that fall into the specified range.
To define an address range for route summarization, perform the following steps:
Detailed Steps
Configuring OSPF Interface Parameters
You can alter some interface-specific OSPF parameters as necessary. You are not required to alter any of these parameters, but the following interface parameters must be consistent across all routers in an attached network: ospf hello-interval, ospf dead-interval, and ospf authentication-key. Be sure that if you configure any of these parameters, the configurations for all routers on your network have compatible values.
To configure OSPF interface parameters, perform the following steps:
Detailed Steps
Command
|
Purpose
| |
|---|---|---|
Step 1
|
router ospf process_id Example: hostname(config)# router ospf 2
|
This creates an OSPF routing process, and the user enters router configuration mode for tfor the OSPF process you want to redistribute.
The process_id is an internally used identifier for this routing process. It can be any positive integer. This ID does not have to match the ID on any other device; it is for internal use only. You can use a maximum of two processes.
|
Step 2
| network ip_address mask area area_id Example: hostname(config)# router ospf 2
hostname(config-router)# network 10.0.0.0
255.0.0.0 area 0
|
This step defines the IP addresses on which OSPF runs and to define the area ID for that interface.
|
Step 3
|
hostname(config)# interface interface_name Example:
hostname(config)# interface my_interface
|
This allows you to enter interface configuration mode.
|
Step 4
|
Do one of the following to configure optional OSPF interface parameters:
| |
ospf authentication [message-digest |null]
Example: hostname(config-interface)# ospf
authentication message-digest
|
This specifies the authentication type for an interface.
| |
ospf authentication-key key
Example: hostname(config-interface)# ospf
authentication-key cisco
|
This allows you to assign a password to be used by neighboring OSPF routers on a network segment that is using the OSPF simple password authentication.
The key can be any continuous string of characters up to 8 bytes in length.
The password created by this command is used as a key that is inserted directly into the OSPF header when the ASA software originates routing protocol packets. A separate password can be assigned to each network on a per-interface basis. All neighboring routers on the same network must have the same password to be able to exchange OSPF information.
| |
ospf cost cost
Example:
hostname(config-interface)# ospf cost 20
|
This allows you to explicitly specify the cost of sending a packet on an OSPF interface. The cost is an integer from 1 to 65535.
In this example, the cost is set to 20.
| |
ospf dead-interval seconds
Example:
hostname(config-interface)# ospf dead-interval 40
|
This allows you to set the number of seconds that a device must wait before it declares a neighbor OSPF router down because it has not received a hello packet. The value must be the same for all nodes on the network.
In this example, the dead-interval is set to 40.
| |
ospf hello-interval seconds
Example:
hostname(config-interface)# ospf hello-interval 10
|
This allows you to specify the length of time between the hello packets that the ASA sends on an OSPF interface. The value must be the same for all nodes on the network.
In this example, the hello-interval is set to 10.
| |
ospf message-digest-key key_id md5key
Example:
hostname(config-interface)# ospf
message-digest-key 1 md5 cisco
|
This enables OSPF MD5 authentication.
The following values can be set:
•
 key_id—An identifier in the range from 1 to 255.
•
key—Alphanumeric password of up to 16 bytes.
Usually, one key per interface is used to generate authentication information when sending packets and to authenticate incoming packets. The same key identifier on the neighbor router must have the same key value.
We recommend that you not keep more than one key per interface. Every time you add a new key, you should remove the old key to prevent the local system from continuing to communicate with a hostile system that knows the old key. Removing the old key also reduces overhead during rollover.
| |
ospf priority number_value
Example: hostname(config-interface)# ospf priority
20 |
This allows you to set the priority to help determine the OSPF designated router for a network.
The number_value is between 0 to 255.
In this example, the priority number value is set to 20.
| |
ospf retransmit-interval seconds
Example: hostname(config-interface)# ospf
retransmit-interval seconds
|
This allows you to specify the number of seconds between LSA retransmissions for adjacencies belonging to an OSPF interface.
The value for seconds must be greater than the expected round-trip delay between any two routers on the attached network. The range is from 1 to 65535 seconds. The default value is 5 seconds.
In this example, the retransmit-interval value is set to 15.
| |
ospf transmit-delay seconds
Example:
hostname(config-interface)# ospf
transmit-delay 5
|
Sets the estimated number of seconds required to send a link-state update packet on an OSPF interface. The secondsvalue is from 1 to 65535 seconds. The default value is 1 second.
In this example, the transmit-delay is 5 seconds.
| |
ospf network point-to-point non-broadcast
Example: hostname(config-interface)# ospf network
point-to-point non-broadcast
|
Specifies the interface as a point-to-point, non-broadcast network.
When you designate an interface as point-to-point, non-broadcast, you must manually define the OSPF neighbor; dynamic neighbor discover is not possible. See Defining Static OSPF Neighbors, for more information. Additionally, you can only define one OSPF neighbor on that interface.
| |
Configuring OSPF Area Parameters
You can configure several area parameters. These area parameters (shown in the following task table) include setting authentication, defining stub areas, and assigning specific costs to the default summary route. Authentication provides password-based protection against unauthorized access to an area.
Stub areas are areas into which information on external routes is not sent. Instead, there is a default external route generated by the ABR, into the stub area for destinations outside the autonomous system. To take advantage of the OSPF stub area support, default routing must be used in the stub area. To further reduce the number of LSAs sent into a stub area, you can configure the no-summary keyword of the area stub command on the ABR to prevent it from sending summary link advertisement (LSA Type 3) into the stub area.
To specify area parameters for your network, perform the following steps:
Detailed Steps
Configuring OSPF NSSA
The OSPF implementation of an NSSA is similar to an OSPF stub area. NSSA does not flood type 5 external LSAs from the core into the area, but it can import autonomous system external routes in a limited way within the area.
NSSA importsType 7 autonomous system external routes within an NSSA area by redistribution. These Type 7 LSAs are translated into Type 5 LSAs by NSSA ABRs, which are flooded throughout the whole routing domain. Summarization and filtering are supported during the translation.
You can simplify administration if you are an ISP or a network administrator that must connect a central site using OSPF to a remote site that is using a different routing protocol using NSSA.
Before the implementation of NSSA, the connection between the corporate site border router and the remote router could not be run as an OSPF stub area because routes for the remote site could not be redistributed into the stub area, and two routing protocols needed to be maintained. A simple protocol such as RIP was usually run and handled the redistribution. With NSSA, you can extend OSPF to cover the remote connection by defining the area between the corporate router and the remote router as an NSSA.
Before you use this feature, consider these guidelines:
–You can set a Type 7 default route that can be used to reach external destinations. When configured, the router generates a Type 7 default into the NSSA or the NSSA area boundary router.
You can set a Type 7 default route that can be used to reach external destinations. When configured, the router generates a Type 7 default into the NSSA or the NSSA area boundary router.
–Every router within the same area must agree that the area is NSSA; otherwise, the routers will not be able to communicate.
Every router within the same area must agree that the area is NSSA; otherwise, the routers will not be able to communicate.
To specify area parameters for your network as needed to configure OSPF NSSA, perform the following steps:
Detailed Steps
Defining Static OSPF Neighbors
You need to define static OSPF neighbors to advertise OSPF routes over a point-to-point, non-broadcast network. This lets you broadcast OSPF advertisements across an existing VPN connection without having to encapsulate the advertisements in a GRE tunnel.
Before you begin, you must create a static route to the OSPF neighbor. See the chapter, `Configuring Static and Default Routes' for more information about creating static routes.
To define a static OSPF neighbor, perform the following tasks:
No comments:
Post a Comment