route-map is added to the redistribute rip
command, as shown in Figure to prevent the route 131.108.0.0/26
from getting redistributed into OSPF, permitting only the
200.200.200.0/24 route. Figures and show the changes in the R1
routing table for the external 200.200.200.0/24 route and that
the forwarding address is now known through OSPF interarea
instead of OSPF external.
Content 5.7
Troubleshooting OSPF 5.7.6 Route summarization
problems Route summarization allows a group of contiguous
networks to be summarized as fewer addresses in order to help
reduce the size of the routing table, thus increasing the
performance of OSPF and other routing protocols. OSPF can use
two types of summarization: - Interarea route
summarization that can be done on the ABR.
- External
route summarization that can be done on the ASBR.
Figure shows a network in which a router is not summarizing
interarea routes. Debugs and Verification
Router R1
has the area range command for summarization of area 3
routes. The syntax of the command is correct, but the problem
is that R1 is not an ABR. Router R1 is included in area 0, but
it is not connected to area 3, and thus cannot summarize area 3
routes. A way to check if a router is summarizing the routes
properly is to use the show ip ospf command. The output
of show ip ospf shows that the area 3 range is passive.
Passive means that no addresses within this area fall within
this range. In fact, R1 does have the routes in this range;
however, because R1 is not connected to area 3, the range
appears as passive. Because summarization is not happening, R1
is receiving four routes in the routing table instead of one
summarized route. Solution
The solution to this
problem is to configure the area range command on the ABR,
which is R2. After changing the configuration and removing the
area range command on R1, verify that the summarization
is indeed active by using show ip ospf on R2. The
summarized route is now being installed in the routing table of
R1. Note: There are similar issues with external
summarization, which is done on the ASBR. External
summarization uses the summary-address command only on
the ASBR. The show ip ospf summary-address command can
be used to help troubleshoot external summarization issues. A
metric of infinity, shown in Figure , means that no valid
addresses belong to this range of summarization and that there
is a problem (16,777,215 equates to infinity because the
external LSA metric is 24 bits long and 224 is equal to
16,777,215). Figure shows the same show ip ospf
summary-address command, when summarization is configured
correctly on the ASBR, with a metric less than infinity.
Content 5.7 Troubleshooting OSPF
5.7.7 CPUHOG problems When OSPF forms an adjacency,
it floods all the link-state update packets to its neighbors.
Sometimes, the flooding process takes a lot of time, depending
upon the router resources. CPUHOG messages appear in the log if
the resources of the router become exhausted due to flooding.
CPUHOG messages usually appear in two significant stages:
- Neighbor formation process
- LSA refresh process
Neighbor formation process
When OSPF
forms an adjacency, it floods all of its link-state packets to
its neighbor. This flooding sometimes takes a lot of CPU
processing. Starting with Cisco IOS Software 12.0T, packet
pacing was included to help prevent CPU processing problems
from occurring. Prior to 12.0T, the IOS did not support packet
pacing. During link-state flooding a router will try to send
data as fast as it can over a link. If a link is slow or the
router on the other side is slow in responding, this results in
retransmission of the LSA and eventually leads to CPUHOG
messages. Packet pacing adds a pacing interval between the LS
updates. Instead of flooding everything at once, packet pacing
sends the packet with a gap of a few milliseconds in between.
Figure shows the log messages on a router showing CPUHOG during
adjacency formation. Packet pacing introduces a delay of 33 ms
between packets and 66 ms between retransmissions. This pacing
interval reduces the CPUHOG messages, and the adjacency is
formed more quickly. If a router is experiencing this problem
with an IOS prior to 12.0T, the solution is to upgrade to 12.0T
or higher. LSA refresh process
Starting with Cisco
IOS 12.0, the LSA group pacing feature was introduced to
eliminate a CPU processing problem that can occur every 30
minutes. Prior to IOS 12.0, all LSAs are flooded every 30
minutes to refresh the MAXAGE times in the link state database.
Without this flooding, the LSAs would expire after 60 minutes.
This flooding is also known as a paranoid update. This flooding
causes CPUHOG messages every 30 minutes, especially in cases
where a couple of thousand LSAs are all being flooded at the
same time. The CPUHOG messages appear in the router log every
30 minutes. LSA group packing looks at the LSA periodic
interval (every 4 minutes, by default) and refreshes only those
LSAs that are past their refresh time. This is an efficient way
of reducing a large flood by chopping it down to smaller LSA
floods. No extra configuration is required for this feature,
but for large numbers of LSAs (generally 10,000 or more), it is
recommended to use small intervals (for example, every 2
minutes); for a few hundred LSAs, use a large interval, such as
20 minutes. If 10,000 LSAs need to be refreshed, keeping the
refresh interval smaller will check the LSA every 2 or 4
minutes to see how many LSAs have reached the refresh interval,
which is 30 minutes. The advantage of checking this frequently
is that few LSAs would need to be refreshed every 2 or 4
minutes, and this will not cause a huge storm of LSA updates.
If the number of LSAs is small, it really does not matter
whether the refresh occurs at 2 minutes or 20 minutes. This is
why it is better to increase the timer so that all the LSAs,
which are few in number, can be refreshed at once. Figure shows
how to configure the LSA refresh interval.
Content
5.7 Troubleshooting OSPF 5.7.8
SPF calculation and route flapping Whenever there is a
change in topology, OSPF runs the SPF algorithm to compute the
Shortest Path First tree again. Unstable links existing within
the OSPF network could cause constant SPF calculations. Some of
the most common reasons for SPF running constantly are:
- Interface flaps within the area
- Neighbor
interface flaps within the area
- Duplicate router ID
Topology changes in an OSPF network cause SPF
calculations within that area. The SPF is not recalculated if
the topology change is in another area. Actually, OSPF
distributes interarea (between areas) topology information
using a distance-vector method. The ABRs forward routing
information between areas using a distance vector technique
similar to that of RIP or IGRP. The following is an example of
SPF running constantly due to an interface flap within the
network. This is a common problem in OSPF. Whenever there is a
link flap in an area, OSPF runs SPF within that area. So, if a
network has unstable links, it can cause constant SPF
calculations. SPF itself is not a problem because OSPF is just
adjusting to the change in the database through calculating
SPF. The real problem occurs if there are small routers in the
area and a constant SPF run might cause a CPU spike in a
router. Because R1 is also included in area 0, any link flap in
area 0 causes all routers in area 0 to run SPF. Debugs and
Verification
A link flap in an area causes SPF to run.
If a link is flapping constantly, this can increase the number
of SPF calculations in an area. A constant number of SPF
calculations in not a problem, but if the number is
incrementing constantly, it is an indication of a problem. The
output of show ip ospf, shows that there is a huge
counter for SPF in area 0. The easiest way to find out which