OSPF stores its
operational data, configured parameters, and statistics in four main data
structures:
Interface table: This table lists all interfaces that
have been enabled for OSPF. All directly connected interfaces are stored into
the link state database as LSA type 1. When an interface is configured as a
passive interface, it is still listed in the OSPF interface table, but no
neighbor relationships are established on this interface.
Neighbor table: This table is used to keep track
of all active OSPF neighbors. Neighbors are added to this table based on the
reception of Hello packets, and they are removed when the OSPF dead time for a
neighbor expires or when the associated interface goes down. OSPF goes through
a number of states while establishing a neighbor relationship (also known as
adjacency), and the neighbor table lists the current state for each individual
neighbor.
Link-state database: This is the main data structure
that OSPF uses to store all its network topology information. This database
contains full topology information for the areas that a router connects to, and
information about the paths available to reach networks and subnets in other
areas or other autonomous systems. Because this database contains a wealth of
network topology information, it is one of the most important data structures
to gather information from when troubleshooting OSPF problems.
Routing Information
Base:
After executing the SPF algorithm, the results of this calculation are stored
in the RIB. This information includes the best routes to each individual prefix
in the OSPF network with their associated path costs. When the information in
the link-state database changes, only a partial recalculation might be
necessary (depending on the nature of the change), and routes might be added to
or deleted from the RIB without the need for a full SPF recalculation. From the
RIB, OSPF offers its routes to the IP routing table.
OSPF Information Flow
Within an Area
OSPF discovers
neighbors through the transmission of periodic Hello packets. Two routers will
become neighbors only if the following parameters match in the Hello packets:
·
Hello and dead timers: Two routers will
only become neighbors if they use the same Hello and dead time. The default
values for broadcast and point-to-point type networks are 10-second Hello and
40-second dead time. If these timers are changed on an interface of a router,
the timers should be configured to match on all neighboring routers on that
interface.
·
OSPF area number: Two routers will
become neighbors on a link only if they both consider that link to be in the
same area.
·
OSPF area type: Two routers will
become neighbors only if they both consider the area to be the same type of
area (normal, stub, or not-so-stubby area [NSSA]).
·
IP subnet and subnet mask: Two routers will
not become neighbors if they are not on the same subnet. The exception to this
rule is on a point-to-point link, where the subnet mask is not verified.
·
Authentication type and
authentication data: Two routers will become neighbors only if they both use the same
authentication type (null, clear text, or message digest 5 [MD5]). If they use
authentication, the authentication data (password or hash value) also needs to
match.
show
ip ospf interface: This
command is used to display the interfaces that have been activated for OSPF.
This list contains all the interfaces that have an IP address that is covered
by one of the network statements under the OSPF configuration. This command
displays a lot of detailed information for each interface. For a brief
overview, issue the command show ip ospf
interface brief.
·
show ip ospf neighbor: This command
lists all neighbors that have been discovered by this router on its active OSPF
interfaces and shows their current state.
·
show ip ospf database: This command
displays the content of the OSPF link-state database. When the command is
issued without any additional options, it will display a summary of the
database, listing only the LSA headers. Using additional command options,
specific LSAs can be selected, and the actual LSA content can be inspected.
·
show ip ospf statistics: This command can
be used to view how often and when the SPF algorithm was last executed. This
command can be helpful when diagnosing routing instability.
The following debug commands
enable you to observe the transmission and reception of packets and the
exchange of routing information:
·
debug ip routing: This command is
not specific to the OSPF protocol, but displays any changes that are made to
the routing table, such as installation or removal of routes. This can prove
useful when troubleshooting routing protocol instabilities.
·
debug ip ospf packet: This command
displays the transmission and reception of OSPF packets. Only the packet
headers are displayed, not the content of the packets. This command is useful
to verify whether Hellos are sent and received as expected.
·
debug ip ospf events: This command
displays OSPF events. This includes reception and transmission of Hellos, but
also the establishment of neighbor relationships and the reception or
transmission of LSAs. This command can also provide clues (mismatched
parameters such as timers, area number, and so on) as to why neighbor Hellos
might be ignored.
·
debug ip ospf adj: This command
displays events related to the adjacency building process and enables you to
see a neighbor relationship transition from one state to the next. During
troubleshooting, you can observe the transitions from one state to another, and
possibly the state at which the relation gets stuck.
·
debug ip ospf monitor: This command
monitors when the SPF algorithm is scheduled to run and displays the triggering
LSA and a summary of the results after the SPF algorithm has completed. During
troubleshooting, this command enables you to discover which LSA was received
and triggered an SPF computation. For example, you can easily discover a
flapping link.
OSPF
uses LSA's to exchange information between neighbours:
LSA=
Link state advertisement
There
are multiple types of LSA's:
Type 1 = router LSA (describe the source router and its OSPF paramenters (hello timers, dead timers mtu)
Type
2 =network LSA, this LSA is generated by the DR on the broadcast network.
Type
3 = summary LSA is generated by the ABR router to advertise summary routes of
adjacent areas.
Type
4 = ASBR summary (area system boarder routers) LSA are genereted by ASBR
routers to inform about its own existence to the entire network, ASBR summary
LSA's are not filtered by ABR's.
Type
5 = External LSA, external LSA's are generated by ASBR router, type 5 LSA's
advertise external routes to the entire network.
Type
6 = multicast LSA. Not supported by CISCO
Type
7 = NSSA external LSA, NSSA= not so stuby area.
OSPF
needs to establish neighbours before it exchanges routing information.
Neighbour
establishment process is as follows.
Parameters
needed to form a neighbour relationship:
Authentication
has to match
Must
be in the same subnet
Must
be in the Same OSPF area
Must
be in the same area type (either standard, nssa, stub)
Must
no have duplicated router id.
Hello
and there timers need to match.
MTU
size should match.
No comments:
Post a Comment