Networks are expanding:

Driven by emerging enterprise services and a trend towards concentration of services, the
internetwork scale has enlarged continuously.

Higher network reliability is required:

Various applications require higher network reliability. When a network failure occurs, the
network needs to recover within a shorter period.

Network heterogeneity requires interconnection between multi-vendor devices:

During routine O&M, devices are continually upgraded or updated. There may be large
differences in performance between devices;
Also, link bandwidths vary to a certain degree.

An open routing protocol supported by various vendors is required.

Can RIP meet these requirements? What problems may RIP encounter?
Hop-by-hop convergence:

As shown in the preceding figure, when network N1 changes, RTA sends an Update
message to RTB. After RTB receives the Update message, it performs route
calculation and sends a route change notification to RTC. In this manner, route
convergence is performed hop by hop, slowing down network convergence.

Routing-by-rumor mechanism:

RIP route calculation completely depends on the routing information from neighbors.
For example, RTE calculates routes just depending on the routing information
obtained from RTD without any idea of information about the network between RTA,
RTB, and RTC. Namely, when calculating routes, RIP lacks the complete knowledge
of network topology.

Employing the hop count as a routing metric:

RIP uses hop count to measure the distance to a destination. Therefore, when data
packets traverse networks from N1 to N2, the links RTA->RTB->RTD->RTE are
chosen as the optimal route. Obviously, the Ethernet links RTB->RTC->RTD have
much higher bandwidths than the serial link RTB->RTD.

Is there any solution to RIP problems?

In RIP, the network convergence process involves receiving updates, calculating routes,
and sending updates. This process slows down network convergence because a router
sends route change notifications to neighbors only after it finishes route calculation. To
solve this problem, the network convergence process can be changed to: receiving updates,
sending updates, and calculating routes. That is, upon receiving route updates from a
neighbor, a router sends the updates to other neighbors and then calculates routes again.
By this means, the convergence time of the network is greatly reduced.

Because a RIP router obtains routing information just from neighbors, it cannot identify or
eliminate non-optimal or incorrect routing information. The best solution to this problem is
that it collects networkwide information and independently calculates routes on the basis of
the information.

When using hop count to measure the distance to a destination, the propagation delay is
not taken into account. If the accumulated bandwidth is used as the criterion for route
decision, the risk of selecting a suboptimal route can be eliminated.

By what means do link-state routing protocols solve all the problems mentioned above?
The term link-state refers to the status of interfaces on an OSPF router, which includes the
following information:

IP address and mask of the interface

Bandwidth of the interface

Neighbor that the interface is connected to

OSPF transmits link state information to its neighbors instead of transmitting its complete
routing table.

Each router maintains its link state database (LSDB). Neighbors synchronize their LSDBs
and then use the SPF algorithm to calculate the optimal route. This speeds up the network
convergence speed.

OSPF uses the accumulated bandwidth of the links as the criterion for route selection. This
method is more accurate than using the accumulated hop count.

OSPF can solve RIP problems in large networks. The following describes how OSPF works.
An enterprise network, often in analogy with a road map, usually consists of a large number
of devices, including routers and switches, of different models and various kinds of links,
which results in great computational complexity.

The process of OSPF route calculation can be summarized in three steps:

Routers discover neighbors and establish neighbor relationships.

Each router generates link state information and floods it to all neighbors, meanwhile
collects link state information from its neighbors until the LSDBs are synchronized
among OSPF neighbors.

On the basis of its LSDB, each router uses the SPF algorithm to calculate a Shortest
Path Tree (SPT) with itself as the root. By building an SPT, each router calculates the
optimal routes to destination. The routes form a routing table eventually.

Let's focus on the three steps mentioned to learn the principles and implementation of
OSPF.
There are several, dozens of, or even hundreds of devices on an enterprise network. Each
of these devices must be uniquely identified by a router ID.

A router ID is a 32-bit unsigned integer in the format of an IP address. An OSPF router uses
the following criteria to select the router ID:

It prefers the manually configured router ID. You are advised to manually configure a
router ID for an OSPF router.

If there is no router ID manually configured, it selects the largest IP address on any of

its loopback interface as its router ID.

If no loopback interface is present, it uses the largest IP address on any of its active
physical interfaces as its router ID.

If a router ID is reconfigured on an OSPF router, the OSPF process must be reset to apply
the new router ID.
Prior to an exchange of link state information, OSPF routers need to exchange Hello
packets to establish a neighbor relationship.

In OSPF, interconnected routers exchange Hello packets to discover neighbors and

establish neighbor relationships. This is the preparation for synchronizing reachability
information following up.

When two OSPF routers sharing a common data link successfully negotiate certain
parameters, the neighbor relationship between them is established.

After a neighbor relationship is established, routers periodically exchange Hello

packets to maintain the neighbor relationship. If a router does not receive any Hello
packet from its neighbor within a specified period, this router terminates the OSPF
neighbor relationship with this neighbor.
Description of neighbor states:
Down: This is the initial state of a neighbor relationship. It indicates that there has been no information
received from the neighbor.
Init: This state occurs when a router has received a Hello packet from its neighbor but its router ID is not
in the neighbor list contained in the received Hello packet. This means that bidirectional communication
with the neighbor has not yet been established.
2-Way: In this state, a router finds that its router ID is in the Hello packet from a neighbor. Bidirectional
communication with the neighbor is then established.
The process of establishing an OSPF neighbor relationship is as follows:
(1) RTA has a router ID 1.1.1.1 and RTB has a router ID 2.2.2.2. When the OSPF process starts on RTA,
RTA sends the first Hello packet, in which the neighbor list is empty. The neighbor state is Down.
When RTB receives the Hello packet from RTA, the neighbor state is set to Init.
(2) Likewise, almost at the same time, RTB sends a Hello packet with an empty list of active neighbor.
As what RTB does, RTA sets the neighbor state to Init, as soon as it receives this Hello packet from
RTB.
(3) RTB sends another Hello packet to RTA, saying that the router ID 1.1.1.1 is on its list of active
neighbor. Upon receiving this Hello packet, RTA finds its router ID included in the neighbor list of the
packet, and then sets the neighbor state to 2-way.
(4) Similarly, RTA sends RTB the next Hello packet with RTB’s router ID 2.2.2.2 on the list of active
neighbor. RTB sees itself in the neighbor list of the packet, then sets the neighbor state to 2-way.
Because the neighbors were unknown before an OSPF router starts its discovery of neighbors, the destination
IP address of a Hello packet is a multicast address 224.0.0.5 instead of a specific unicast address. How does
an OSPF router discover neighbors on a network that does not support multicast?
If the network does not have the multicast capability, neighbor relationships must be
manually established.

When the network scale increases or devices are frequently updated, static configurations
need to be modified on related OSPF routers. However, manually modifying configurations
is of heavy workload and error-prone.

For an OSPF router, the purpose of establishing neighbor relationships is to synchronize

LSDB by exchanging link-state information with other OSPF routers. The following
describes how OSPF routers synchronize their LSDBs.
Unlike the route exchange process between RIP routers, OSPF routers exchange link state
information to synchronize their link-state databases and then just forward the original link
state information to other neighbors. Eventually, all OSPF routers will possess the same set
of link state information.

Link state information includes the link type, interface IP address and subnet mask,
neighbors on the link, and link cost.

A router just needs to know the destination network ID/subnet mask, next hop, and cost
(interface IP address and subnet mask, neighbors on the link, and link cost). But why is the
link type included in the link state information?
The development of devices, communication media, and protocols are critical parts of the
evolution of networking technologies. Device performance increasingly improves, and
communication links have developed from serial link, ATM, and FR into Ethernet, xPON,
SDH, MSTP, and OTN. A new generation of technology never comes into being at the snap
of a finger. Instead, it is a progressive process. Different kinds of physical links have their
unique characteristics. Accordingly, a mature routing protocol must fit the characteristics of
a physical link where it is applied.

The following presents how OSPF defines network types.

Four network types are defined in OSPF protocol and are used to describe network
topologies partially.

A point-to-point network connects a pair of routers together and supports broadcast and
multicast.

An example of a point-to-point network: a network on which two routers are connected

through a Point-to-Point Protocol (PPP) link.
A broadcast network allows two or more devices to access the same shared link and
supports broadcast and multicast. It is one of the most common OSPF network types.

An example of a broadcast network: a network on which routers are connected through an

Ethernet link.

There are multiple devices on a broadcast network. As to neighbor relationship

establishment and link information synchronization, OSPF provides corresponding
functions to reduce the impact of multiple devices on the network.

Point-to-point and broadcast networks are the most common OSPF network types. Besides,
there are two more network types which are rarely found.
Unlike the broadcast network, a non-broadcast multiple access (NBMA) network does not
support broadcast and multicast by default. On an NBMA network, OSPF emulates
operations over a broadcast network. But the neighbor must be manually specified.

An example of NBMA network: a network on which routers are connected through fully-
meshed FR links.

In recent years, NBMA networks are seldom deployed.

A point-to-multipoint network, which is a special configuration of non-broadcast multi-
access networks, is treated as a group of point-to-point connections. On a point-to-
multipoint network, OSPF neighbors can be discovered through the Inverse Address
Resolution Protocol (Inverse ARP). A point-to-multipoint network can be considered as a
set of multiple point-to-point networks and supports broadcast and multicast.

No network is originally a point-to-multipoint network, no matter what kind of data link layer
protocol is being employed. That is to say, a point-to-multipoint network must be converted
from other type of network. A typical practice is changing partially-meshed FR or ATM
networks to point-to-multipoint networks.

So here comes the question: how is the cost in OSPF link state information determined?
The formula for OSPF cost calculation is: Interface cost = Reference bandwidth/Interface bandwidth,
which defines the interface cost as the reference bandwidth divided by the interface bandwidth. The
default reference bandwidth is 100Mbps. If the result is not an integer, it is truncated to a whole
number to be the cost value. If the result is less than 1, the interface has the cost of 1.
The cost can be changed in two ways:
Configure the cost under interface configuration mode. Note that the configured cost is the final
value for this interface , but is valid only on this interface.
Change the default reference bandwidth for OSPF. This modification takes effect only on all
OSPF-enabled interfaces of the local router. It is suggested that all routers in the Autonomous
System should be configured with the same reference bandwidth in order to ensure
consistency in route selection. When changing the default reference bandwidth, you should
give overall consideration on bandwidth distribution on the whole network before you decide a
new value.
OSPF metric is the cumulative cost, which is a total cost of all outbound interfaces of the routers the
packet passing through from the source to the destination. For example, if a packet routed by OSPF
from RTA destined for RTC’s interface Loopback 1 attached to subnet 192.168.3.3/24, the cost is
equal to the cost of G1 plus the cost of G3.
OSPF take both hop count and bandwidth into account in cost calculation. Hence, it is a more reliable
routing protocol than RIP.
How do OSPF routers exchange link state information and synchronize their LSDBs?
RIP operates on UDP port number 520, while OSPF is defined above IP rather than TCP or UDP,
which means OSPF packets are directly encapsulated in IP packets, with protocol number 89.

All OSPF packets have the same format of header:

Version: The value is set to 2 if OSPF version 2 is in use.

Type: indicates the type of OSPF packet.

Packet length: indicates the length of entire OSPF packet, in bytes.

Router ID: indicates the identity of the router that originates this packet.

Area ID: indicates the OSPF area into which the packet is being advertised.

Checksum: is used to verify data integrity of the entire OSPF packet, including the OSPF
packet header.

Auth Type: indicates the authentication mode being used. The value 0 indicates non-
authentication. The value 1 indicates simple password. The value 2 indicates cryptographic
(MD5) authentication.

Authentication: contains the information necessary for authentication. The content of this field
varies according to the AuType field.

OSPF packet header defines the communication standards and rules between OSPF routers. Based
on these standards, what functions need to be developed for OSPF packets?
Type 1 packets are Hello packets, which are used to establish and maintain neighbor
relationships. As discussed earlier, before establishing an OSPF neighbor relationship, two
routers must negotiate some parameters.

Type 2 packets are Database Description (DD) packets, which are used to describe the
content of local LSDB to neighbors so that the neighbors can determine whether their
LSDBs are complete.

Type 3 packets are Link State Request (LSR) packets. A router determines whether its
LSDB is complete compared with the information in DD packets from its neighbors. If its
LSDB is incomplete, it creates a list of LSAs that need to be obtained from the sender of the
DD packets and then sends.

Type 4 packets are Link State Update (LSU) packets, which are used to respond to the
LSR packets received from neighbors. According to the request list in the received LSR
packet, the router packs the required LSAs into LSU packets and sends them to the
neighbor. LSA flooding is performed by LSU packets, and as a result, the LSDB
synchronization among all routers in the area is implemented.

Type 5 packets are Link State Acknowledgment (LSAck) packets, which are used to
acknowledge received LSAs in order to ensure LSA synchronization reliability.
DD, LSR, LSU, and LSAck packets contain LSA information in varying degrees:

A DD packet contains LSA header information, including LS Type, LS ID, Advertising

Router, LS Sequence Number, and LS Checksum.

An LSR packet contains LS Type, LS ID, and Advertising Router.

Each LSU packet carries a collection of LSAs.

An LSAck packet contains LSA header information, including LS Type, LS ID,

Advertising Router, LS Sequence Number, and LS Checksum.

All these five types of OSPF packets ensure an efficient LSA synchronization process. So
how are these packets utilized to fulfill the task?
In previous parts of this series, the Hello mechanism used to dynamically discover
neighbors and maintain OSPF neighbor relationships has been explained and need not be
repeated here.

Compared with the Request and Response messages used for synchronization of routing
information bases (RIBs) in RIP, LSAs are employed to synchronize LSDBs in OSPF. One
possible way for an OSPF router is to send all its LSAs to neighbors; however, this method
is not a perfect one.

A faster and more efficient method should be like this: summary information rather than all
link-state information is sent to neighbors. On receiving it, the neighbors examine which
LSAs are new or more up-to-date to themselves, and then request detailed LSAs from the
sender. For OSPF protocol, there is necessity to employ a more efficient and reliable
method than RIP’s to synchronize link-state database between routers.
State description:

ExStart: This state occurs when two neighboring routers establish a master/slave
relationship and determine the initial DD sequence number. In this state, the
exchanged DD packets don’t include any LSAs.

Exchange: This state occurs when a router exchanges DD packets containing link
state summary information with its neighbor.

Loading: This state occurs when two routers send LSR, LSU, and LSAck packets to
each other. This state occurs when a router finds entries in its Link State Request list.
In this state, the router sends LSR packets to its neighbor, receives LSU packets from
it and answers LSAck packets as acknowledgement.

Full: This state occurs when the neighboring router’s LSDB is synchronized. In this
state, the neighboring routers are fully adjacent.

LSDB synchronization process:

RTA and RTB have router IDs 1.1.1.1 and 2.2.2.2 respectively, and a neighbor
relationship has been established between them. When the neighbor RTB’s state
becomes ExStart, RTA sends its first DD packet to RTB. The DD packet sequence
number is randomly set to X, the I-bit is set to 1, indicating that this is its first DD
packet; the M-bit is set to 1, indicating that subsequent DD packets need to be sent,
and the MS-bit is set to 1, indicating that RTA asserts itself as the master.

Similarly, when the neighbor RTA’s state becomes ExStart, RTB sends its first DD
packet, with a DD sequence number of y and three flags I-bit, M-bit and MS-bit set to 1,
1 and 1 respectively, as the same meaning as RTA’s. Because RTB has a larger router
ID, RTB will become the master. Upon receipt of the DD packet from RTB, RTA
generates a Negotiation-Done event agreeing that RTB is the master, and transitions
neighbor RTB’s state from ExStart to Exchange.

Then RTA sends a new DD packet containing summary information of its LSDB. In this
packet, the DD packet sequence number is overrode by RTB with Y in step 2, the I-bit
is set to 0, indicating that this packet is not its first DD packet, the M-bit is set to 0,
indicating that this packet is the last DD packet containing LSDB summary information,
and the MS-bit is set to 0, indicating that RTA asserts itself as the slave. When
receiving this DD packet, RTB generates a Negotiation-Done event and transitions its
neighbor RTA’s state from ExStart to Exchange.

Then RTB sends a new DD packet, which contains LSDB summary information
together with sequence number Y+1 and the MS-bit set to 1, indicating that RTB
asserts itself as the master. Suppose all its LSDB summary information is included in
this DD packet, the M-bit is now set to 0, telling RTA, "this is the last DD packet for you".

Although there is no need for RTA to sends its LSDB summary information to RTB, as
a slave, it still needs to acknowledge each DD packet from the master. Therefore, RTA
responds to RTB’s DD packet with an empty DD packet containing the sequence
number Y+1. Then RTA generates an Exchange-Done event and transitions neighbor
RTB’s state to Loading. When RTB receives this DD packet, it transitions its neighbor
state to Full. (Assume that RTB has the latest and complete LSDB and does not need
to request updates from RTA.)
 RTA sends an LSR packet to RTB to request more recent LSAs that have been
discovered in the Exchange state but have not yet been received.

RTB then provides RTA with the requested LSAs in an LSU packet. On receiving this
LSU packet, RTA transitions neighbor RTB’s state from Loading to Full.

Then RTA returns an LSAck packet to RTB as an acknowledgement for the received
LSU packet. When RTB receives the LSAck packet, a full adjacency is established
between the two routers.

The process from establishing neighbor relationship to synchronizing LSDB is complex.

Any incorrect configuration or link failures will lead to an unsuccessful LSDB
synchronization. Understanding the trigger for state transitions is the key to rapid
troubleshooting.
The series of transitions in the OSPF neighbor state machine is illustrated by the diagram
above. The transition process is described as follows:

Down: This is the initial state of a neighbor conversation. It indicates that the router
has not received any Hello packet from its neighbor in the last RouterDeadInterval.
On an NBMA network, a router can still send Hello packets at every PollInterval to its
manually configured neighbor which is in Down state. The PollInterval is often as
large as the RouterDeadInterval.

Attempt: This state only appears on NBMA networks. It indicates that the router has
not received any recent information from its manually configured neighbor, but that it
has been sending Hello packets to the neighbor at every HelloInterval. If the router
does not receive any Hello packet from its neighbor within a RouterDeadInterval, the
neighbor state transitions to Down.

Init: This state occurs when the router receives a Hello packet from a neighbor but
does not see its own Router ID in neighbor list of this Hello packet, which means they
have not established a two-way communication with each other. In this state, the
router IDs of all its known neighbors must be included in the neighbor list of the Hello
packet sent by the router.

2-way Received: This event occurs when the router sees its own Router ID in
neighbor list of the Hello packet received from the neighbor, or receives a DD packet
from the neighbor. If the router needs to establish an adjacency with a neighbor, the
neighbor state transitions to ExStart and LSDB synchronization begins. Otherwise, the
neighbor state transitions to 2-Way.

2-Way: This state occurs when the router establishes a bidirectional communication,
but does not yet form an adjacency, with its neighbor. This is the final state to which the
neighbor transition, if there is so far no need for establishing adjacency with this
neighbor.

1-Way Received: This event occurs when the router finds that its router ID is not
contained in the neighbor list of the received Hello packet. This is often due to a restart
of the neighboring router.

ExStart: This state occurs when the router starts to send DD packets to its neighbor. In
this state, the master-slave relationship is established and the initial DD sequence
number is determined. Note that the DD packets do not include any LSA summary
information in this state. This is the first step towards forming an adjacency.

Exchange: This state occurs when the router exchanges with its neighbor DD packets
containing LSA summary information to describe its entire LSDB.

Loading: This state occurs when the router sends LSR packets to its neighbor
requesting the more recent LSAs that have been discovered in the received DD
packets in the Exchange state. Subsequently, the router receives responding LSU
packets from the neighbor.

Full: This state occurs when its link state request list is empty, which means the local
LSDB is synchronized with its neighbor’s. It indicates that the neighbor is fully adjacent.
A Link State Advertisement (LSA) is the carrier of OSPF link state information between
routers. The LSA is the basic structural unit of LSDB. In other words, an LSDB is composed
of an array of LSAs.

All LSAs have the same format of header, including the following fields:

LS age: indicates the age of the LSA, in seconds.

LS type: indicates the LSA format and function. There are five types of commonly
used LSAs.

Link State ID: identifies the link described by an LSA, for example, router ID.

Advertising Router: indicates the router ID of the router that originates this LSA.

LS sequence number: is used to detect old and duplicate LSAs.

LS type, Link State ID, and Advertising Router together identify an LSA.

Aside from locally originated LSAs, there are LSAs obtained from other neighbors in LSDB.
It’s necessary for LSAs to be advertised between neighboring routers through a
passageway.
 OSPF-running MA networks include broadcast and NBMA networks, which are facing
the following problems:

 In a network with N routers, the number of adjacencies can be up to nx(n−1)/2.

 The same copies of LSAs will be flooded repeatedly among neighbors. For
example, RTA sends its LSAs with the same content to neighbors RTB, RTC and
RTD separately. And what’s more, RTB forwarded these LSAs to neighbors RTD
and RTC, and even RTA where the LSAs are from. This process is called flooding.

 Evidently, such a process is inefficient and resource-hungry. As an advanced routing

protocol, how does OSPF solve the two problems?
 Designated router (DR) is responsible for establishing and maintaining adjacencies and
flooding LSAs over an MA network.

 The DR establishes adjacencies and exchanges link state information with all the other
routers, while other routes do not directly exchange link state information with each other.
This greatly reduces the number of adjacencies in an MA network, and as a result, saves
resources used to exchange link state information.

 Once the DR becomes invalid, its adjacencies with other routers all become invalid, and
LSDB synchronization fails. A new DR needs to be elected to establish new adjacencies
with non-DR routers for LSDB synchronization. To prevent the single point of failure,
OSPF puts forward the concept of Backup Designated Router (BDR), which is a backup
for DR and elected at the same time as when DR is elected. When the current DR
becomes invalid, the BDR instantly takes over the role of DR.

 A pseudo node is a virtual device node. The following describes DR and BDR election.
 The concepts neighbor relationship and adjacency are different from each other. After
two OSPF routers establish a neighbor relationship, they synchronize their LSDBs and
eventually establish an adjacency.

 On point-to-point and point-to-multipoint networks, routers that have established a

neighbor relationship proceed to establish an adjacency.

 On broadcast and NBMA networks, non-DR/BDR routers (DRothers) establish only

neighbor relationships rather than adjacencies with each other; non-DR/BDR routers
(DRothers) establish adjacencies with the DR/BDR; the DR and BDR establish an
adjacency with each other.

 When an adjacency is established, LSDB synchronization is complete. Then OSPF

routers start to use the SPF algorithm to calculate the shortest paths to all known
destinations on the basis of the information in their LSDBs.
 Answer: ABC.

 Answer: point-to-point network, point-to-multipoint network, broadcast network, NBMA

network.
An OSPF router originates a Router-LSA for each area to which the router belongs, to
describe the states of the router's links. The three fields in the LSA header are as follows:

Type: LSA type. A Router-LSA is the Type 1 LSA.

LS id: link state ID.

Adv rtr: ID of the router that originates this Router-LSA.

One Router-LSA can describe multiple links with fields Link ID, Data, Link Type, and
Metric for each link. The meanings of keywords are as follows:

Type: link type (not the same concept as the network type mentioned in previous
sections). A Router-LSA describes the following types of links:

Point-to-Point: describes a single connection directly to the neighboring router.

The point-to-point link type is treated as topology information.

TransNet: describes a link to a transit network, to which two or more routers are
attached, such as a broadcast network and non-broadcast multi-access (NBMA)
network. The TransNet link type is treated as topology information.

StubNet: describes a link to a stub network, to which only a single router is

attached, such as a loopback interface. The StubNet link type is treated as
 routing information.

Link ID: peer ID at the other end of the link. The meaning of the Link ID field varies
according to the link type.

Data: additional information about a link. Different types of links have different
additional information.

Metric: cost of a link.

In a Router-LSA that describes a broadcast or an NBMA interface, Link ID specifies the
interface IP address of a designated router (DR), and Data specifies the IP address of the
router interface that advertises this LSA.

As shown in the figure, RTB, RTC, and RTE are attached to the same Ethernet segment.
Take the LSA originated by RTC as an example. The Link ID value is 10.1.235.2, which is
the interface IP address of the DR. The Data value is 10.1.235.3, which is the IP address of
the router interface connected to the MA network. The Link Type value is TransNet, and
the Metric value is the cost of the link to the DR.

The TransNet link described by a Router-LSA only contains information about adjacency
with the DR and the link cost, without any information about the network ID, subnet mask,
and other routers on the multi-access network.
The network-LSA describes all the routers that are attached to a broadcast or an NBMA
network with the interface IP address of the DR, the network's address mask, and a list of
IDs of all routers that are fully adjacent to the DR.

The meanings of key fields in a Network-LSA are as follows:

Type: LSA type. A Network-LSA is the Type 2 LSA.

LS id: interface IP address of the DR.

Adv rtr: ID of the router that originates this Network-LSA, i.e., the DR's router ID.

Net mask: subnet mask for this network.

Attached Router: a list of routers connected to this network, which reveals the
topology of this network.

The Ls id masked by the subnet mask yields the network ID. The cost from the DR to any
non-DR routers is 0.

As seen in the Attached Router field, routers 2.2.2.2, 3.3.3.3, and 5.5.5.5 are attached to
the same multi-access network with the network ID of 10.1.235.0 and subnet mask of
255.255.255.0, where the DR is 2.2.2.2.
LSDB stands for link-state database.

As shown in the figure, the OSPF area contains five routers. Take the LSDB of RTA as an
example. Each LSDB of five routers is identical to one another: five Router-LSAs, each of
which is originated by every router severally; two Network-LSAs, which are originated by
the DR for two broadcast networks separately.
Type 1 and Type 2 LSAs carry topology and routing information.

OSPF calculates an SPT using the SPF algorithm and various types of LSAs.

Phase 1: Create an SPT on the basis of Type 2 LSAs, as well as point-to-point and
TransNet links in Type 1 LSAs.

Phase 2: Calculate an optimal route on the basis of Type 2 LSAs and StubNet links in
Type 1 LSAs.
Each OSPF router calculates an SPT with itself as the root node.

The following example describes how RTA calculates an SPT:

First of all, RTA places itself in the root position of an SPT. Then it looks up the links
in Router-LSA it originated. All links except StubNet links described by a Router-LSA
can be selected as candidates. The ID of the selected link is put in the column
Candidate; the total cost of the candidate equals its parent's cost (that is, the sum of
Metric values along the path from the root to the parent) plus its own Metric value.

The Router-LSA from the root RTA itself describes two types of links: TransNet link
and Point-to-point link. The TransNet link 10.1.12.2 has Metric value 1, and the Point-
to-point link 3.3.3.3 has Metric value 48. They are both added to the candidate list.

RTA adds node 10.1.12.2, with the lowest total cost, to the SPT, and deletes it from
the candidate list. This TransNet link 10.1.12.2, performing the role of DR, is
considered as a "pseudonode" (or a virtual router) to represent the Transit Network. In
this sense, all the routers attached to the link are attached to that node with cost of 0.
After the DR is added to the SPT, RTA examines the DR's network-LSA and finds a list of
attached routers. If an attached router listed in the LSA has already been on the SPT, this
router is ignored.

As shown in the figure above, two attached routers are listed:

The attached router 1.1.1.1 is ignored and is not able to be added to the candidate list,
because it has already been on the SPT.

As for the other attached router 2.2.2.2, the total cost is 1, which equals the sum of its
parent's cost (1) and its Metric value (0). The router is then added to the candidate
list.

Now, there are two candidates in the candidate list. Router 2.2.2.2 whose cost is the
lowest among all candidates, is added to the SPT and removed from the list.
After node 2.2.2.2 is added to the SPT, RTA continues to examine the Router-LSA of this
node.

The first link is a TransNet link with Link ID of 10.1.12.2. However, it is ignored and
not added to the candidate list, for the reason that the node 10.1.12.2 has already
been added to the SPT in step 1.

The second link 10.1.235.2 is also a TransNet link. Its Metric value is 1 and its
parent's cost is 1. Thus, the total cost of the link is 2 (1 + 1). Node 10.1.235.2 is
added to the candidate list.

As for the third link, it is a point-to-point link with Link ID of 4.4.4.4. Given the Metric
value 48 and its parent's cost 1, its total cost is 49 (48 + 1). Node 4.4.4.4 is added to
the candidate list.

As a result, there are three candidates in the candidate list. As seen, the candidate
10.1.235.2 (the DR) has the lowest total cost and therefore is added to the SPT. Then the
candidate is removed from the candidate list.
Next, RTA examines the network-LSA from the DR 10.1.235.2 and finds a list of attached
routers.

As shown in the figure above, three attached routers are listed:

Attached router 2.2.2.2 is ignored because it has already been added to the SPT.

As mentioned earlier, all the routers attached to the "pseudonode" have the Metric
value of 0. The total cost of router 3.3.3.3 is 2 (2 + 0), the same as its parent's. This
router is now added to the candidate list. (If two candidates with the same ID appear
in the list, the total costs of both must be compared with each other. The one with the
lower cost wins and therefore remains in the list, while the loser is removed.
According to this rule, the link 3.3.3.3, whose total cost is 48, is deleted.)

Similarly, the total cost of router 5.5.5.5 is 2 and the router is added to the candidate
list.

At the moment, there are three candidates in the list. The nodes 3.3.3.3 and 5.5.5.5
are added to the SPT because they both have the lowest total costs 2, then are
deleted from the candidate list.
After the nodes 3.3.3.3 and 5.5.5.5 are added to the SPT, the examination of Router-LSAs
continues.

As to the Router-LSA from node 3.3.3.3:

Since the two nodes 10.1.235.2 and 1.1.1.1 have already been added to the SPT
before, both links are ignored.
 As to the Router-LSA from node 5.5.5.5:

 The node 10.1.235.2 has already been added to the SPT, so the TransNet link
10.1.235.2 is ignored.

 As for the point-to-point link 4.4.4.4, obviously, the same link has been in the
candidate list. The total cost of this link is 50, which is the sum of its Metric value
(48) and its parent's cost (2). Seeing that 50 is greater than 49, which means the
node whose parent is node 2.2.2.2 has the shorter path to the root than the one
whose parent is node 5.5.5.5, the current link is removed from the list. Then the
node 4.4.4.4 with the total cost of 49 is added to SPT as a child of node 2.2.2.2
and deleted from the list.

 Now, when you run the display ospf lsdb router 4.4.4.4 command to continue
exploring, you will find that all the neighbors of router 4.4.4.4 described in the Router-
LSA have been added to the SPT. No new candidate will be added to the list.

 At this time, the candidate list is empty and SPF calculation is done. Note that, the nodes
10.1.12.2 and 10.1.235.2 serve as pseudonodes.
 Second phase: Calculate the optimal route according to StubNet link information in
Router-LSAs and routing information in Network-LSAs.

 OSPF picks up the routing information from LSAs of all nodes in the SPT, starting with
the root in the same sequence as they were added to the SPT.

 In the Router-LSA from RTA (node 1.1.1.1), one StubNet link is found. The subnet
is 10.1.13.0/24 and Metric is 48.

 In the Network-LSA from the DR (node 10.1.12.2), the subnet is 10.1.12.0/24 and
Metric is 1 (1 + 0).

 In the Router-LSA from RTB (node 2.2.2.2), one StubNet link is described. The
subnet is 10.1.24.0/24 and Metric is 49 (1 + 0 + 48).

 In the Network-LSA from the DR (node 10.1.235.2), the subnet is 10.1.235.0/24

and Metric is 2 (1 + 0 + 1).

 In the Router-LSA from RTC (node 3.3.3.3), one StubNet link is found, and the
subnet is 10.1.13.0/24. The link already exists on RTA, so this link is ignored.

 In the Router-LSA from RTE (node 5.5.5.5), one StubNet link is found. The subnet
is 10.1.45.0/24 and Metric is 50 (1 + 0 + 0 + 1 + 48).

 In the Router-LSA from RTD (node 4.4.4.4), two StubNet links are found. The
subnets of the StubNet links are 10.1.24.0/24 and 10.1.45.0/24, respectively.
However, the same destination address prefixes have already been picked up from
node 2.2.2.2 and node 5.5.5.5 separately in the previous steps. They are ignored
because the path of node 4.4.4.4 is longer than node 2.2.2.2 and node 5.5.5.5.
 After two phases of SPF calculation, OSPF routes are generated on RTA, as shown in
the figure above.

 However, a route calculated by OSPF is not always installed into the system routing
table. Because the routes for the same destination may be obtained from different
routing protocols, each of which has its unique route preference value (a.k.a
administrative distance), the router needs to compare their route preferences to
determine which route to be installed or to be discarded.
 In this output, we can see that RTA has established adjacencies with RTB and RTC
separately.
 Answer: Point-to-point, TransNet, StubNet, and vlink links.

 Answer: Not always. A router may obtain multiple routes with the same destination
address prefix from other routing protocols. A comparison of route preferences must be
performed before the most preferable route is selected to the routing table.
 OSPF divides a large network into multiple interconnected smaller areas. Routers in the
same area only need to synchronize their Link-State Databases (LSDBs) in the area
rather than to flood LSAs to the entire OSPF domain, in order to reduce the consumption
of memory and CPU to some extent.

 After an OSPF domain is divided into areas, the routers are further divided into two roles
according to functions:

 Internal router: All interfaces of an internal router belong to the same OSPF area.

 Area border router (ABR): Interfaces of an ABR belong to two or more OSPF areas.

 An internal router maintains a single LSDB and calculates the routes in the area.

 How do OSPF routers residing in different areas communicate with each other?
 An ABR acts as a gateway for inter-area traffic and maintains multiple LSDBs, one for
each attached area.

 An ABR converts link state information in one of its attached areas to routing information,
and then advertise it to another area it is connected to.

 The conversion of link state information into routing information is actually the process of
converting Type 1 or Type 2 LSAs into Type 3 LSAs. Note that an ABR transmits inter-
area routing information bidirectionally.

 In the above figure, for example, RTD originates a Type 1 LSA to describe the subnet
192.168.1.0/24 and floods it throughout Area 1 for synchronization of the LSDB. As the
ABR connecting Area 0 and Area 2, RTB converts the Type 1 LSA into a Type 3 LSA,
and sends it into Area 0. Acting as the ABR between Area 0 and Area 2, RTC generates
another Type 3 LSA and sends it into Area 2. Till now, the routing information about
subnet 192.168.1.0/24 has been advertised throughout the entire OSPF domain. In the
same way, the routing information about subnet 192.168.2.0/24 has been advertised.
 A Network-Summary-LSA (Type 3 LSA) contains the following fields:

 Ls id: destination network address

 Adv rtr: ID of the ABR

 Net mask: subnet mask of the destination network

 Metric: cost of the route from the ABR to the destination network

 How does an internal router calculate the inter-area route when it receives a Type 3 LSA
describing a destination network in another area?
 A Type 3 LSA originated by an ABR is used to calculate an inter-area route.

 An ABR is determined according to the value of the field Adv rtr in a Type 3 LSA.

 A destination address prefix and the cost of the route from an ABR to that
destination can be obtained from the fields Ls id, Net mask, and Metric.

 When a router receives multiple Type 3 LSAs with the same destination address
prefix from different ABRs, the router separately adds the cost from itself to each
ABR and the metric reported in related LSA, and has them compared with each
other. The route with the lowest cost is generated. If two or more routes with the
same total cost exist, the router performs equal-cost load-balancing.

 As shown in the figure, the following describes how RTA in Area 0 calculates the inter-
area route:

 In the Type 3 LSAs describing subnets 192.168.1.0/24 and 192.168.2.0/24, the

values of the Adv rtr field are 2.2.2.2 (RTB) and 3.3.3.3 (RTC), respectively,
indicating the corresponding ABRs that originate the LSAs.

 In the Type 3 LSA that RTB originates, the route for subnet 192.168.1.0/24 has the
cost 1. The route for subnet 192.168.2.0/24 in the Type 3 LSA generated by RTC
has the same cost of 1.
 If traffic starting from RTA is destined for subnet 192.168.1.0/24, the next hop is
RTB and the cost of the route is 2. Similarly, the next hop for the traffic from RTA to
the subnet 192.168.2.0/24 is RTC, and the cost is 2.
 RTB converts a Type 1 or a Type 2 LSA in Area 1 into a Type 3 LSA, and then
advertises it to Area 0.

 RTC regenerates a Type 3 LSA describing subnet 192.168.1.0/24 and advertises the
LSA to Area 2.

 Similarly, RTE generates a Type 3 LSA describing subnet 192.168.1.0/24 and

advertises the LSA to Area 3.

 Once again, RTD then advertises the route for subnet 192.168.1.0/24 to Area 1 in a
Type 3 LSA. A routing loop then forms.
 To prevent inter-area routing loops, OSPF defines the backbone area, non-backbone
area, and transmission rules of Type 3 LSAs.

 OSPF divides an autonomous system into a backbone area (also called Area 0)
and a number of non-backbone areas. All non-backbone areas must be connected
to the backbone area, and all traffic between non-backbone areas must pass
through the backbone area.

 OSPF does not allow Type 3 LSAs from the backbone area to be injected back to
the backbone area.

 As for the ABR mentioned earlier, OSPF requires that an ABR should have at least one
interface belonging to the backbone area.

 Following the inter-area routing loop prevention rules, a new network can be deployed
free of routing loops among areas. However, due to improper network planning, the
connection between areas may not comply with the inter-area routing loop prevention
rules.
 The backbone area must be contiguous. However, it needs not be physically contiguous;
it can be logically contiguous by establishing virtual links.

 Virtual links can be set up between any two ABRs that have an interface connected to
the same non-backbone area.

 As shown in the figure, a virtual link is set up between RTB and RTC to enable Area 2 to
connect to the backbone area (Area 0) through Area 1, as if the Area 2 were directly
connected to the backbone area.
 Answer: One Network-Summary-LSA can describe only one route.

 Answer: OSPF partitions areas into the backbone area and non-backbone areas. All
non-backbone areas must be connected to the backbone area, and only one backbone
area exists. Routing information between non-backbone areas must be forwarded
through the backbone area. Type 3 LSAs from the backbone area are not be transmitted
back to the backbone area.
 In this example, a static route for destination subnet 10.1.60.0/24 is configured on RTA.
The next hop is RTF.

 RTA redistributes the static route into OSPF protocol and advertises it into Company A’s
enterprise network. An OSPF router that imports external routes is called autonomous
system boundary router (ASBR). (Communication between devices requires bidirectional
routes between them. This course only describes how an OSPF network obtains
external routes.)

 RTA originates an AS-External-LSA (Type 5 LSA), which describes a route to a

destination external to the Autonomous System via the ASBR. RTB and RTC separately
originate ASBR-Summary-LSAs (Type 4 LSAs) to describe routes from themselves to
the ASBR.

 Type 4 and Type 5 LSAs are used by routers to calculate external routes.
 The figure above illustrates a Type 5 LSA originated by RTA and is flooded to all OSPF
areas except special OSPF areas.

 A Type 5 LSA contains the following fields:

 Ls id: destination network address.

 Adv rtr: ID of an ASBR.

 Net mask: subnet mask of the destination network.

 Metric: cost of the route from an ASBR to the destination network. The default
value is 1.

 Tag: attached to each external route to carry additional information about this route,
usually for purpose of route policy. The default value is 1.
 The figure above illustrates an ASBR-Summary-LSA (Type 4 LSA) originated by RTB in
Area 1.

 When RTB floods a Type 5 LSA to Area 1, a Type 4 LSA is simultaneously originated
and flooded to that area.

 A Type 4 LSA contains the following fields:

 Ls id: ID of an ASBR.

 Adv rtr: ID of the ABR that originates the Type 4 LSA.

 Metric: cost of the route from the ABR to the ASBR.

 A Type 4 LSA can be flooded only in one area. Each time a Type 5 LSA is flooded to the
next area via an ABR, a Type 4 LSA is then originated by the ABR to describe a route to
reach the ASBR that originates the Type 5 LSA. In company with the Type 5 LSA, the
Type 4 LSA is flooded no further than the border of the area where it is originated.

 Therefore, in an autonomous system, there can be multiple Type 4 LSAs with the same
ASBR ID (indicated by Ls ID) but different ABR ID (indicated by Adv rtr) to describe the
routes to reach the same ASBR.
 Let's take RTB as an example to see how an ABR calculates an external route, which is
illustrated by the figure on the left.

 Upon receiving a Type 5 LSA, RTB finds that the ASBR is in the same area (Area 0) as
itself after examining the Adv rtr value (1.1.1.1). According to the fields Ls id, Net mask,
and Metric in the Type 5 LSA, RTB originates a route for subnet 10.1.60.0/24 with the
next-hop value of RTA's ID and the metric value of 1.

 The next example is given to explain how RTD in Area 1 calculates an external route.
When receiving a Type 5 LSA, by examining the field Adv rtr, RTD finds that the
ASBR's ID 1.1.1.1 is beyond its knowledge because the ASBR resides in a different area.
RTD then examines the Type 4 LSA for routing information about ASBR 1.1.1.1
(represented by Ls ID), and finds that the gateway to 1.1.1.1 is 2.2.2.2 (represented by
Adv rtr). According to the fields Ls id, Net mask, and Metric in the Type 5 LSA, RTD
originates a route for subnet 10.1.60.0/24, with the next-hop value of RTB's ID and the
metric value of 1.

 The costs of the routes calculated by RTB and RTD are both 1. However, as shown in
the physical topology diagram, the cost that RTD calculates obviously should be greater
than that which RTB does. It there anything goes wrong?
 OSPF can import two types of external routes:

 Type 1 external route: The metric of the Type 1 external route is equal to the sum
of the cost to the ASBR (a.k.a AS internal cost) and the cost from the ASBR to the
external destination (a.k.a AS external cost). This occurs when the AS external
cost is considered at the same level as the AS internal cost. There is equivalence
between the AS external cost and the AS internal cost, and the Type 1 external
metric is comparable directly to the link state metric of OSPF. By reason of above,
the Type 1 external route is more reliable than the Type 2 external route.

 Type 2 external route: When the AS external cost is considered far greater than the
cost of any route internal in the AS, the Type 2 external route uses only the AS
external cost as its cost, ignoring the AS internal cost. As mentioned, the Type 2
external route has lower reliability than the Type 2 external route.

 By default, OSPF uses Type 2 external routes.

 As shown in the figure above, RTA, RTB, and RTC are on the same multiple access
(MA) network. OSPF runs between RTA and RTB, and the Routing Information Protocol
(RIP) runs between RTB and RTC.

 RTB redistributes routes learned through RIP into OSPF. Through OSPF, RTA learns
the external route for destination 192.168.3.0/24 using RTB as the next hop. Therefore,
traffic from RTA to subnet 192.168.3.0/24 is first forwarded to the next hop RTB and then
to RTC. Obviously, this route is less optimal than that whose next hop is RTC.

 OSPF resolves this problem by specifying the Forwarding Address field.

 Generally, the Forwarding Address field in a Type 5 LSA describing an external route
imported by an ASBR is set to 0.0.0.0.

 In the scenario shown in the figure above, the route destined for 192.168.3.0/24 is
originated by RTB and the next hop is 10.1.123.3. OSPF runs on the subnet
10.1.123.0/24 to which the IP address 10.1.123.3 belongs. Therefore, the value of the
Forwarding Address field is set to 10.1.123.3 in the Type 5 LSA generated by RTB.

 Upon receiving the Type 5 LSA, RTA finds that the LSA has Forwarding Address set to
non-zero, then it looks up the forwarding address 10.1.123.3 in the routing table to
determine the next hop.
 Answer: An AS-External-LSA is originated by an ASBR to advertise an external route to
an OSPF network. Note that one AS-External-LSA can advertise only one external route.

 Answer: An ASBR-Summary-LSA is originated by an ABR to instruct the rest of the

OSPF domain how to get to the ASBR.

 Answer: There are two types of OSPF external routes: Type 1 and Type 2 external
routes. Type 1 external routes have a higher priority than Type 2 external routes.
 As shown in the figure above, the entire network is divided into three areas: Area 0, Area
1, Area 2, with the backbone area (namely Area 0) interconnected with an external
network.

 The two-way red arrow lines in the figure indicate all possible traffic flows among areas
and the external network.

 OSPF areas are classified into the following two types:

 Transit area: The transit area not only supports the traffic that is originated in it or
destined for it, but also supports the traffic that is just passing through it (also
known as traversing traffic). For example, Area 0 is a transit area.

 End area: The end area only supports the traffic that is originated in it or destined
for it. For example, Area 1 is an end area.

 For end areas, the following issues need to be considered:

 First, consider whether there is necessity of having all specific routes to other
areas. If there is only a single gateway to other areas or external autonomous
systems, the answer is NO, because the summarized routes is more concise and
effective than all specific routes for the outgoing traffic.

 Second, consider the device capacity for processing and storage. The cost is a
 crucial factor in network construction and maintenance. In view of this, the routers
with low capacity may have been widely deployed in the end areas.

 To calculate intra-area, inter-area, and external routes, OSPF routers need to collect a
large number of LSAs on the network, which may excessively consume the storage space
of LSDBs, and thereby put a calculation burden on the routers. On condition that routing
reliability is guaranteed, the key to solving the problem is to reduce the number of LSAs as
possible as it can be.
 An ABR does not advertise any AS external routes through Type 4 and Type 5 LSAs to
a stub area. This results in a great reduction of the size of the LSDBs and routing tables.

 To ensure the traffic originated in a stub area can reach a destination outside the AS, an
ABR of the stub area generates a default route and advertises it into the stub area
through Type 3 LSAs.

 The stub area is an optional configuration attribute. It is suggested that you should not
configure every non-backbone area to be a stub area. A stub area is a non-backbone
area located at the far end of the Autonomous System, usually with only one ABR.

 When configuring a stub area, keep in mind the following points:

 The backbone area cannot be configured as a stub area.

 If an area is configured as a stub area, all the routers in this area must be
configured as stub routers.

 An ASBR cannot be part of a stub area. That is, AS external routes cannot be
advertised in a stub area.

 Virtual links cannot be configured through stub areas.

 When a stub area is configured, a default route is injected into the stub area through
Type 3 LSAs to be substituted for all AS external routes.

 Even though the external network changes, routers in a stub area are not impacted.
Rather, the reduction of routes improves the routers' performance.
 Neither AS external routing information in Type 4 or Type 5 LSAs nor inter-area routing
information in Type 3 LSAs are allowed to be advertised in a totally stub area.

 An ABR generates a default route and injects it into the stub area where it attached
through Type 3 LSAs to instruct other routers in the stub area how to get to other OSPF
areas and even other autonomous systems.

 When configuring a totally stub area on the ABR, the no-summary parameter is
additionally appended at the end of the command stub, which is different from that for a
stub area.
 A default route is configured to guide traffic originated in a totally stub area to be
destined for other areas and destinations outside the AS.

 Any changes of link states in other OSPF areas or outside the OSPF autonomous
system do not affect the routers in totally stub area.

 OSPF solves the problems caused by oversized LSDBs in end areas, by defining stub
and totally stub area. However, in some specific scenarios, configuring stub or totally
stub areas is not the best solution.
 RTD and RTA connect to the same external network. RTA imports external routes to the
OSPF domain. Area 1, where RTD resides, is configured as a stub or totally stub area to
reduce the size of LSDB. The traffic from RTD to the external network is forwarded along
the path RTD -> RTB -> RTA to reach the external network. Obviously, however, in
comparison with the direct route to the external network, this route is suboptimal, since
RTD is just on the boundary with the external network.

 As defined in OSPF, external routes cannot be imported to stub areas. The purpose of
this mechanism is to prevent a large number of external routes from consuming device
resources in stub areas and totally stub areas.

 There is no way for a stub area and a totally stub area to support the scenario where
external routes need to be imported without excessive consumption of network
resources.
 The Not-So-Stubby Area (NSSA) was newly introduced to original OSPF RFC as a
supplement.

 An NSSA is similar to a stub area. Different from stub areas and totally stub areas,
NSSAs can import and advertise AS external routes to the entire OSPF AS without
learning external routes from the other parts of the OSPF AS.

 NSSA LSA (Type 7 LSA):

 The Type 7 LSA is introduced to support NSSAs by allowing imported external

routes to be advertised in the OSPF autonomous system.

 Type 7 LSAs are originated by the ASBR of an NSSA and are flooded only within
the NSSA.

 A default route can be advertised through a Type 7 LSA as well to guide traffic to
other ASs.

 Type 7 LSAs can be converted into Type 5 LSAs.

 When an ABR of an NSSA receives Type 7 LSAs, the ABR selectively translates
the Type 7 LSAs into Type 5 LSAs to advertise imported external routes to other
areas of the OSPF domain.

 When multiple ABRs exist in an NSSA, only the one with the greatest Router ID
 translates the Type 7 LSAs into Type 5 LSAs.

 Differences between a totally NSSA and an NSSA:

 Type 3 LSAs are not allowed to be flooded in a totally NSSA, whereas Type 3 LSAs
will pass into and out of an NSSA.

 The only difference in configuration between NSSA and totally NSSA is the
additional appending parameter no-summary for a totally NSSA.
 An ABR of an NSSA generates a default route (Type 7 LSA).

 An ABR of a totally NSSA automatically generates a default route (Type 3 LSA).

 LSAs have the following functions:

 Router-LSA (Type 1): describes collected states of the router's interfaces to an

area. It is originated by every router and flooded only throughout a single area it
belongs to.

 Network-LSA (Type 2): describes link states of a broadcast and NBMA interface. It
is originated by the DR and flooded only throughout a single area it belongs to.

 Network-Summary-LSA (Type 3): describes a route to a destination network

outside the area, yet still inside the AS. It is originated by an ABR and flooded
throughout the LSA's associated area.

 ASBR-Summary-LSA (Type 4): describes routes to an ASBR. It is originated by an

ABR and flooded throughout the areas except the area where the ASBR resides.

 AS-External-LSA (Type 5): describes routes to destinations external to the

Autonomous System. It is originated by an ASBR and flooded to all areas except
stub areas and NSSAs.

 NSSA-LSA (Type 7): describes AS external routes. It is originated by an ASBR

and only flooded in NSSAs.

 A special OSPF area is configured not only to reduce the number of LSAs in the area
and route calculation load on the routers, but also to reduce the impact of the network
faults outside the area. However, the benefits of a special OSPF area are only available
within the area. So, what methods can be applied in other areas?
 On a large-scale OSPF network, the size of the routing tables can be overlarge. This
may result in a slow lookup of a route. In order to solve the problem, route
summarization can be performed on the boundaries of the areas.

 Route summarization is the process of grouping a consecutive range of network address

prefixes into a single prefix and advertising it to the other parts of the network, without
losing any routing information of all known destinations. Even if an interface with an IP
address in the range of summarized prefixes is brought up and down frequently behind
the summarizing router, the changes will not be advertised to the rest of the network and
the destination still seems to remain valid. This process prevents route flapping by hiding
instability in the system behind the summary.

 Route summarization can only summarize routing information and an ABR is one of the
positions that can perform route summarization.

 When an ABR advertises routing information into an area, it originates Type 3

LSAs, each of which is for one individual subnet. If a range of consecutive subnet
addresses exists in this area, a command can be run to manually summarize
these subnets into one single network address prefix. In this way, the ABR
transmits only one Type 3 LSA describing a summarized route. All specific routes
belonging to the range of the summarized routes will not be advertised separately.
  All the other LSAs that belong to the summarized network segment range specified
by commands are not transmitted separately.

 As shown in the figure above, eight consecutive subnets exist in Area 1. Accordingly, eight
Type 3 LSAs are originated by RTB if no summarization is performed. When route
summarization is configured on RTB, there will be only one Type 3 LSA to be generated
and flooded into Area 0.

 Another possible summarization point is ASBR, which the external routes are imported
through.
 Route summarization on an ASBR:

 If route summarization is configured on an ASBR, the ASBR summarizes imported

external routes. An ASBR of NSSA is no exception.

 If a router is an ASBR as well as an ABR of the NSSA, the router can summarize
external routes into corresponding address prefixes while Type 7 LSAs are being
translated into Type 5 LSAs.

 As shown in the figure above, RTA in Area 0 imports eight consecutive external routes to
the area. Eight Type 5 LSAs are originated and flooded to the area.

 When external route summarization is configured on the RTA, which functions as an

ASBR, RTA originates only one Type 5 LSA by grouping the eight consecutive external
routes into one, and floods it to AS.

 Route summarization reduces impact of network faults.

 The network convergence speed after a network fault occurs is also an important
criterion for judging the performance of a routing protocol.
 The LSA reliability must be guaranteed to ensure route calculation accuracy.

 OSPF maintains an aging timer of 3600 seconds (Maxage) for each LSA. When the
incremental LS age in each LSA header reaches the Maxage, the LSA is deleted from
the LSDB.

 To prevent an LSA from being discarded due to a timeout, OSPF resends the LSA every
1800 seconds with a higher sequence number.

 An OSPF router re-originates an LSA every 1800s and advertises it to other routers.

 To speed up network convergence, OSPF provides the triggered update mechanism.

 Once link states change, a router floods update messages in the area to force other
routers to recalculate routes immediately. Hence, the fast network convergence is
accomplished.
 On the corporate network shown in the figure, OSPF is run on the corporate network.
Normally, the traffic from the Finance Department passes through RTA and RTB before
reaching the database.

 An unauthorized device accesses the corporate network and injects a false route,
causing the traffic to be abnormally forwarded along the path "Finance Department ->
RTA -> unauthorized device -> RTB -> Database." The unauthorized device sniffs and
analyzes the traffic passing through it, and obtains private financial information. This
leads to a leak of company's confidential information. This causes disclosure of the
enterprise's confidential information.

 What can be done to secure OSPF routing information?

 OSPF supports authentication. Only authenticated OSPF routers can establish
neighboring relationships and exchange routing information.

 The OSPF authentication works on one of the following bases:

 Area basis

 Per-interface basis

 Supported authentication modes: null, simple, MD5, and HMAC-MD5.

 When both area-based and per-interface-based authentication are configured, per-

interface-based authentication is preferred.
 Requirement analysis 1: The remote office C is in Area 3 and RTE connects Area 2 and
3. The reason why the remote office C cannot communicate with other areas is that the
Area 3 is not physically connected to the backbone area, which has broken the rules of
inter-area routing loop prevention. The solution is configuring a virtual link between RTE
and RTC to connect logically Area 3 and the backbone area.

 Requirement analysis 2: To reduce the load of route calculation on low-capacity devices,

the area can be configured as a stub area, a totally stub area, an NSSA, or a totally
NSSA. Especially, to minimize the load of route calculation, the choice should be the
totally stub or totally NSSA. Further, if the capability of importing external routes must be
taken into consideration, the totally NSSA would be the only choice.

 Requirement analysis 3: Authentication needs to be implemented to ensure routing

information security. In this case, the authentication mode selected is HMAC-MD5,
which is considered as the most secure OSPF authentication mode, on a per-interface
basis.

 Requirement analysis 4: If the OSPF AS internal costs need to be considered when

calculating AS external routes, routes should be imported into OSPF as Type 1 external
routes.
 Answer: OSPF defines four special areas: stub area, totally stub area, not-so-stubby
area (NSSA) and totally NSSA.

 Answer: A stub area does not allow transmission of Type 4 or Type 5 LSAs but allows
transmission of Type 3 LSAs. A totally stub area does not allow transmission of Type 4,
Type 5, or Type 3 LSAs. Only Type 3 LSAs describing default routes can be transmitted
in a totally stub area.

 Answer: Inter-area route summarization can be configured on an ABR.