Hello interval—How often the router sends hello packets. All routers on a shared network must use the same hello interval. Router dead interval—How long the router waits without receiving any OSPF packets from a router before declaring that router to be down. All routers on a shared network must use the same router dead interval. Neighbor—IP addresses of the routers from which valid hello packets have been received within the time specified by the router dead interval.
When initializing an adjacency, OSPF exchanges database description packets, which describe the contents of the topological database. When a router detects that portions of its topological database are out of date, it sends a link-state request packet to a neighbor requesting a precise instance of the database.
These packets consist of the OSPF header plus fields that uniquely identify the database information that the router is seeking. Link-state update packets carry one or more link-state advertisements one hop farther from their origin. The router multicasts floods these packets on physical networks that support multicast or broadcast mode.
The router acknowledges all link-state update packets and, if retransmission is necessary, sends the retransmitted advertisements unicast. The router sends link-state acknowledgment packets in response to link-state update packets to verify that the update packets have been received successfully.
A single acknowledgment packet can include responses to multiple update packets. Link-state acknowledgment packets consist of the OSPF header plus the link-state advertisement header. Link-state request, link-state update, and link-state acknowledgment packets are used to reliably flood link-state advertisement packets.
OSPF sends the following types of link-state advertisements:. These link-state advertisements are flooded throughout a single area only. Network link advertisements—Are sent by designated routers to describe all the routers attached to the network.
Summary link advertisements—Are sent by area border routers to describe the routes that they know about in other areas. There are two types of summary link advertisements: those used when the destination is an IP network, and those used when the destination is an AS boundary router.
Summary link advertisements describe interarea routes, that is, routes to destinations outside the area but within the AS. AS external link advertisement—Are sent by AS boundary routers to describe external routes that they know about. These link-state advertisements are flooded throughout the AS except for stub areas. Each link-state advertisement type describes a portion of the OSPF routing domain.
All link-state advertisements are flooded throughout the AS. When OSPF exports route information from external autonomous systems ASs , it includes a cost, or external metric , in the route. The difference between the two metrics is how OSPF calculates the cost of the route. Type 1 external metrics are equivalent to the link-state metric, where the cost is equal to the sum of the internal costs plus the external cost.
This means that Type 1 external metrics include the external cost to the destination as well as the cost metric to reach the AS boundary router. Type 2 external metrics are greater than the cost of any path internal to the AS. Type 2 external metrics use only the external cost to the destination and ignore the cost metric to reach the AS boundary router. Both Type 1 and Type 2 external metrics can be present in the AS at the same time. Using the information from its topology database.
Dijkstra in OSPF will then construct three tables to store the following information:. It means dividing routers inside a single autonomous system running OSPF, into areas where each area consists of a group of connected routers. The idea of dividing the OSPF network into areas is to simplify administration and optimize available resources. Resource optimization is especially important for large enterprise networks with a plethora of network and links.
The group pacing results in more efficient use of the router. This feature is most beneficial to large OSPF networks. For typical customers, the default group pacing interval for refreshing, checksumming, and aging is appropriate and you need not configure this feature.
Once the LSA reaches the maximum age 1 hour , it is discarded. During the aging process, the originating router sends a refresh packet every 30 minutes to refresh the LSA. Refresh packets are sent to keep the LSA from expiring, whether there has been a change in the network topology or not. Checksumming is performed on all LSAs every 10 minutes. Prior to the LSA group pacing feature, the Cisco software would perform refreshing on a single timer and checksumming and aging on another timer.
In the case of refreshing, for example, the software would scan the whole database every 30 minutes, refreshing every LSA that the router generated, no matter how old it was. The figure below illustrates all the LSAs being refreshed at once. This process wasted CPU resources because only a small portion of the database needed to be refreshed. Refreshing on a single timer resulted in the age of all LSAs becoming synchronized, which resulted in much CPU processing at once.
Furthermore, a large number of LSAs could cause a sudden increase of network traffic, consuming a large amount of network resources in a short time. So the CPU is used only when necessary. However, LSAs being refreshed at frequent, random intervals would require many packets for the few refreshed LSAs that the router must send, which would be inefficient use of bandwidth.
Therefore, the router delays the LSA refresh function for an interval of time instead of performing it when the individual timers are reached. The accumulated LSAs constitute a group, which is then refreshed and sent out in one packet or more. Thus, the refresh packets are paced, as are the checksumming and aging. The pacing interval is configurable; it defaults to 4 minutes, which is randomized to further avoid synchronization. The figure below illustrates the case of refresh packets.
The first timeline illustrates individual LSA timers; the second timeline illustrates individual LSA timers with group pacing. The group pacing interval is inversely proportional to the number of LSAs that the router is refreshing, checksumming, and aging.
For example, if you have approximately 10, LSAs, decreasing the pacing interval would benefit you. If you have a very small database 40 to LSAs , increasing the pacing interval to 10 to 20 minutes might benefit you slightly. The default value of pacing between LSA groups is seconds 4 minutes. The range is from 10 seconds to seconds 30 minutes.
Some redundancy is desirable, because it ensures robust flooding. However, too much redundancy can waste bandwidth and might destabilize the network due to excessive link and CPU usage in certain topologies.
An example would be a fully meshed topology. On broadcast, nonbroadcast, and point-to-point networks, you can block flooding over specified OSPF interfaces.
On point-to-multipoint networks, you can block flooding to a specified neighbor. Some implementations have tried to improve the flooding by reducing the frequency to refresh from 30 minutes to about 50 minutes. This solution reduces the amount of refresh traffic but requires at least one refresh before the LSA expires.
The OSPF flooding reduction solution works by reducing unnecessary refreshing and flooding of already known and unchanged information. To achieve this reduction, the LSAs are now flooded with the higher bit set. If the router is receiving many MOSPF packets, you might want to configure the router to ignore the packets and thus prevent a large number of syslog messages.
The former OSPF implementation for sending update packets needed to be more efficient. Some update packets were getting lost in cases where the link was slow, a neighbor could not receive the updates quickly enough, or the router was out of buffer space.
For example, packets might be dropped if either of the following topologies existed:. A fast router was connected to a slower router over a point-to-point link. During flooding, several neighbors sent updates to a single router at the same time. OSPF update packets are now automatically paced so they are not sent less than 33 milliseconds apart.
Pacing is also added between resends to increase efficiency and minimize lost retransmissions. Also, you can display the LSAs waiting to be sent out an interface. The benefit of pacing is that OSPF update and retransmission packets are sent more efficiently.
There are no configuration tasks for this feature; it occurs automatically. You can display specific statistics such as the contents of IP routing tables, caches, and databases. Information provided can be used to determine resource utilization and solve network problems.
You can also display information about node reachability and discover the routing path that your device packets are taking through the network. To configure OSPF, perform the tasks described in the following sections. Sets the estimated number of seconds required to send a link-state update packet on an OSPF interface.
Sets 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 values for the key-id and key arguments must match values specified for other neighbors on a network segment. Repeat this step for each neighbor if you want to specify a cost.
Otherwise, neighbors will assume the cost of the interface, based on the ip ospf cost interface configuration command. Specifies a cost for the default summary route that is sent into a stub area or not-so-stubby area NSSA. The process-id argument identifies the OSPF process. The range is from 1 to Controls the route summarization and filtering during the translation and limits the summary to NSSA areas.
Use router ospf process-id command to enable OSPFv2 routing. You can set a Type 7 default route that can be used to reach external destinations. Every device within the same area must agree that the area is NSSA; otherwise, the devices cannot communicate. You can use the optional not-advertise keyword to filter out a set of routes. The always keyword includes the following exception when a route map is used. When a route map is used, the origination of the default route by OSPF is not bound to the existence of a default route in the routing table.
Note You can prevent an interface from accepting demand-circuit requests from other routers to by specifying the ignore keyword in the ip ospf demand-circuit command. Because LSAs that include topology changes are flooded over an on-demand circuit, we recommend that you put demand circuits within OSPF stub areas or within NSSAs to isolate the demand circuits from as many topology changes as possible.
Every router within a stub area or NSSA must have this feature loaded in order to take advantage of the on-demand circuit functionality. Learn more: view the specification of our OSPF protocol stack. Skip to Content. A Microsoft Company. The protocol recalculates routes when network topology changes, using the Dijkstra algorithm, and minimises the routing protocol traffic that it generates.
It provides support for multiple paths of equal cost.
0コメント