- CCNP Route - OSPF part 1: Concept/RID/Auth/Neighbors/LSA/DBD/Cost
 - CCNP Route - OSPF part 2: Filtering/summarization/stub/default route/virt link
 - CCNP Route - OSPF part 3: Network type/Frame-Relay
 - CCNP Route - OSPF part 4: Commands, Labs, FAQs and Memory Tables

 - OSPF allows to link discontinuous parts of the backbone area using virtual links. (area0-area1-area0)
 - DR - Designated Router, chosen router to minimize the number of adjacencies formed. Option is used in broadcast networks.
- BDR -Backup Designated Router, hot standby for the DR. BDR receives all routing updates from adjacent routers, but it does not flood LSA updates,
- If we do not have any ASBR, there´s no LSA Types 4 and 5 in the network.

Open Shortest Path First (OSPF) routing protocol, which is one of the most commonly used interior gateway protocols in IP networking. OSPF is an open-standard protocol based primarily on RFC 2328.
Routers running link-state routing protocols collect routing information from all other routers in the network (or from within a defined area of the network), and then each router independently calculates its best paths to all destinations in the network, using Dijkstra’s (SPF) algorithm.

OSPF will choose routes in the following order:
Intra-Area (O)
Inter-Area (O IA)
External Type 1 (E1)
External Type 2 (E2) *
NSSA Type 1 (N1)
NSSA Type 2 (N2)

* - “OSPF routers do not add any internal OSPF cost to the metric for an E2 route”, both the intra-area and inter-area cost is still considered in the OSPF path selection state machine for these routes.
details:  E1 vs E2 explanation

Example:   (R1)--OSPF--(R2)<-EIGPR,
R1 have 2 links with R2: fast0/0 in T1. R2 is redistributing EIGRP routes in OSPF.
R1 will know O E2 routes (EIGRP) via both links, but will add only best even metric is the same.
1) assume only Serial link is up is subnetted, 1 subnets
O E2 [110/20] via, 00:09:42, Serial2/0

Routing entry for
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
2) now,  fast0/0 came up is subnetted, 1 subnets
O E2 [110/20] via, 00:00:01, FastEthernet0/0
Routing entry for
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1

 even both LSA Type 5 are is LSDB
R5#sh ip ospf data external | exc Tag|TOS|age|Seq|Checksum|Addre|Type|Length
            OSPF Router with ID ( (Process ID 1)
  Routing Bit Set on this LSA
  Link State ID: (External Network Number )
  Advertising Router:
  Network Mask: /24
        Metric: 20
  Link State ID: (External Network Number )
  Advertising Router:
  Network Mask: /24
        Metric: 20

OSPF Terms
Link state database (LSDB) - OSPF completed topology database
Shortest Path First (SPF) - algorithm OSPF uses to analyze the LSDB and determines the best (lowest cost) route for each prefix/length.
Link State Update (LSU) - OSPF packet that holds the detailed topology information, specifically LSAs
Link State Advertisement (LSA) - each router originates one or more LSAs to send routing information about itself, or to receive routing information from neighbors. This information is used to build the link-state database.

Area - A contiguous grouping of routers and router interfaces. Routers in an area strive to learn all topology information about the area, but they do not learn topology information about areas to which they do not connect.
Area Border Router (ABR) - A router that has interfaces connected to at least two different OSPF areas, including the backbone area.
Backbone router - Any router that has at least one interface connected to the backbone area.
Internal routers - A router that has interfaces connected to only one area, making the router completely internal to that one area.
Designated Router (DR) - On multiaccess data links like LANs, an OSPF router elected by the routers on that data link to perform special functions (generation of LSAs representing the subnet, and playing a key role in the database exchange process)
Backup Designated Router (BDR) - A router on a multiaccess data link that monitors the DR
and becomes prepared to take over for the DR, should the DR fail.

Backbone area — interconnect with other OSPF area types. Generally, end users are not found within a backbone area. The backbone area is also called OSPF area 0. 

Regular (nonbackbone) area—An OSPF area whose primary function is to connect users and resources. Regular areas (also called normal areas) are usually set up along functional or geographic groupings.
By default, a regular area does not allow traffic from another area to use its links to reach other areas. By default, all traffic from other areas must cross backbone area 0. 
Regular areas can have several subtypes, including standard area, stub area, totally stubby area, not-so-stubby area (NSSA), and totally stubby NSSA.

Multiple Area feature is important comparing with other IGPs:
 - all copmutation is kept within the Area (less frequent SPF calculations),
 - minimum inter-area communications (reduced LSU overhead), 
 - smaller routing tables,
 - allowing the network to scale to large size. 
 - all interarea (different areas) traffic must pass through the backbone area 0. 

The memory resources required to maintain these tables can be a drawback to link-state protocols. However, because the topology table (LSDB) is identical in all OSPF routers in an area and contains full information about all the routers and links in an area, each router can independently select a loop-free and efficient path, based on cost (as described in the “OSPF Metric Calculation” section, later in this chapter), to reach every network in the area. This benefit overcomes the “routing by rumor” limitations of distance vector routing.

Using multiple OSPF areas has several important advantages:
 - Reduced frequency of SPF calculations,
 - Smaller routing tables,
 - Reduced LSU overhead.

Area Terminology
OSPF routers of different types control the traffic that goes in and out of areas.
1) Internal router — Routers that have all of their interfaces in the same area. All routers within the same area have identical LSDBs.
2) Backbone router — Routers that sit in the perimeter of the backbone area 0 and that have at least one  interface connected to area 0. Backbone routers maintain OSPF routing information using the same procedures and algorithms as internal routers.
3) Area Border Router (ABR) — Routers that have interfaces attached to multiple areas, maintain separate LSDBs for each area to which they connect, and route traffic destined for or arriving from  other areas. ABRs connect area 0 to a nonbackbone area and are exit points for the area, which means that routing information destined for another area can get there only via the ABR of the local area. ABRs distribute this routing information into the backbone. The backbone routers then forward the information to the other ABRs. ABRs are the only point where area address summarization can be  configured (to summarize the routing information from the LSDBs of their attached areas). ABRs separate LSA flooding zones, and may function as the source of default routes. An area can have one or more ABRs.
The ideal design is to have each ABR connected to two areas only, the backbone and another area. As mentioned, the recommended upper limit is three areas.
4) Autonomous System Boundary Router (ASBR) — Routers that have at least one interface attached to a different routing domain (such as another OSPF autonomous system or a domain using the Enhanced Interior Gateway Protocol [EIGRP]). An OSPF autonomous system consists of all the OSPF areas and the routers within them. ASBRs can redistribute external routes into the OSPF domain and vice versa.

Cisco recommends the following guidelines:
■ An area should have no more than 50 routers.
■ A router should not be in more than three areas.

OSPF Propeties
VLSM/classless - OSPF includes the mask with each route, also allowing it to support discontiguous networks and VLSM
Transport - IP, protocol type 89 (does not use UDP or TCP)
Metric - cumulative cost (bandwidth) of all outgoing interfaces in a route
Update destination address - Normally sent to (All SPF Routers) and (All Designated Routers).
Authentication - Supports None or MD5 or clear-text authentication.
Manual route summarization - Allows route summarization at ABR routers only

OSPF Functions
OPSF uses link state (LS) logic:
 1) neighbor discovery (stored in neighbor table), has the same overall goal as EIGRP’s neighbor discovery process:
to find the neighboring routers, and exchange enough information so that the two routers
know whether they should exchange topology data.
2) topology database exchange (stored in topology database aka link state database -LSDB)
 - The existence of, and an identifier for, each router (router ID)
 - Each router interface, IP address, mask, and subnet
 - The list of routers reachable by each router on each interface
3) route computation, means that each router independently analyzes the topology data to choose the best routes from their perspective.
OSPF use a Shortest Path First (SPF) algorithm to analyze the data, choose the shortest (best) route for each reachable subnet, and add the correct next-hop/outgoing interface information for those routes to the IP routing table.

OSPF Neighbors and Adjacencies on LANs
OSPF neighborship is more complex (comparing EIGRP)
Two classes of neighborships exist: neighbors and fully adjacent neighbors.
OSPF Finite State Machine (FSM) have eight neighbor states.

OSPF sends multicast OSPF Hello messages on LAN interfaces, attempting to discover OSPF neighbor

Enable OSPF interfaces

[interface]ip ospf <process-id> area <area-id>
(config-if)#    ip ospf 1 area 999
The interface has not been made passive by the passive-interface router sub-command.
Hello itself contains several parameters that must be checked, including the OSPF RID of the router sending the Hello, and the OSPF area that router has assigned to that LAN.

OSPF router command
[Router] network <A.B.C.D>  <E.F.G.H> area <area-id>
# network area 0
A.B.C.D    Network number
E.F.G.H  OSPF wild card bits
area  - Set the OSPF area ID
area-id -   <0-4294967295>  OSPF area ID as a decimal value     OR
                 A.B.C.D         OSPF area ID in IP address format
If one uses multiple and overlapping networks statements in order to assign interfaces into different:
more specific network statement is processed first:
router ospf 1
 network area 1
 network area 2

R6#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0        YES manual up                    up
FastEthernet0/1        YES manual up                    up

R6#sh ip ospf int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0        1     1           1     WAIT  0/0
Fa0/1        1     2           1     WAIT  0/0

Settings That Must Match for OSPF Neighborship

Hello interval - how often the router sends a Hello on the interface
Dead interval - how long a router should wait, without hearing any Hello messages from that neighbor, before deciding that the neighbor failed.

Default interface Broadcast (LAN ) and point-to-point uses setting of Hello of 10 (every 10 seconds), and Dead of 40.
 NBMA, point-to-multipoint uses 30/120 second timers.

The debug ip ospf events output shown might appear if any of the following situations occurs:
 - The IP subnet masks for routers on the same network do not match.
 - The OSPF hello interval for the router does not match that configured for a neighbor.
 - The OSPF dead interval for the router does not match that configured for a neighbor.

RouterA#debug ip ospf events
OSPF events debugging is on
04:43:16: OSPF: Rcv hello from area 0 from Serial0/0
04:43:16: OSPF: Mismatched hello parameters from
04:43:16: OSPF: Dead R 120 C 10, Hello R 30 C 30
04:43:16: OSPF: Rcv hello from area 0 from Serial0/0
04:43:16: OSPF: Mismatched hello parameters from
04:43:16: OSPF: Dead R 120 C 10, Hello R 30 C 30

Dead R 120 C 10, Hello R 30 C 30  
The Dead R (recv) is the Dead Timer of the neighbor that in this case is 120 seconds,
the Dead C (configured) is the local Dead Timer.

RouterA serial0/0 interface has the OSPF dead timer set to 10 seconds.

To tune for faster convergence:
 - set a lower Hello and Dead timers
 - if the interface fails, OSPF will immediately realize that all neighbors reached through that interface have also failed and not wait on the Dead timer to count down to zero

R4(config)#interface fastethernet0/0
R4(config-if)#ip ospf hello-interval 9
ip ospf hello-interval <value>
ip ospf  dead-interval <value>
ip ospf dead-interval minimal hello-multiplier  <multiplier>
ip ospf dead-interval minimal hello-multiplier 4   (sets the dead interval to one second)
show ip ospf interface fa0/0
show ip ospf neighbors
Router ID
In OSPF for IPv4, an interface can be a part of a single OSPF process only.
Two OSPF processes on the same box don't talk to each other unless you redistribute between them. 

Unique Router Identifier (RID)
Each OSPF router assigns itself a router ID:
1) router-id <rid-value>  (OSPF subcommand)
2) highest IP address of any up/up loopback interface;
3) highest IP address of any up/up non-loopback interface.

By design, all OSPF RIDs in a domain should be unique; to avoid such issues, OSPF prevents neighborships between routers with duplicate RIDs.

Sometimes a router ID needs to be changed, for example, when a network administrator establishes a new router ID scheme for the network. However, after a router selects a router ID, an active OSPF router does not allow the router ID to be changed until the router is reloaded or the OSPF process cleared.
Clearing the OSPF process is the preferred method to reset the router ID.
clear ip ospf process
! verify RID with
show ip protocols
Troubleshooting duplicate RIDs:  - link @
 - OSPF route appearing and disappearing constantly
 - high CPU utilization
 - routers perfoms SPF constantly
 - content of LSA changing every few seconds.

Note that the OSPF process will not start without an RID. (Error will appear if trying to run OSPF with there are no single interface in UP/UP state).

The maximum transmission unit (MTU) of an interface tells IOS the largest IP packet that can be forwarded out the interface.

From a design perspective, the MTU used by all devices attached to the same data link ought to be the same value. However, routers have no dynamic mechanism to prevent the misconfiguration of MTU on neighboring routers.

From a data plane perspective, when a router needs to forward a packet larger than the outgoing interface’s MTU, the router either fragments the packet or discards it. If the IP header’s don’t fragment (DF) bit is set, the router discards the packet. If the DF bit is not set, the router can perform Layer 3 fragmentation on the packet, creating two (or more) IP packets with mostly identical IP headers, spreading the data that follows the original IP packet header out among the fragments. The fragments can then be forwarded, with the reassembly process being performed by the receiving host.

MTU mismatch occurs between two OSPF neighbors, one router will attempt to become neighbors with the other router whose MTU differs. The other router will be listed in the list of neighbors (show ip ospf neighbor). However, the two routers will not exchange topology information, and the two routers will not calculate routes that use this neighbor as the next-hop router.
The IP MTU can be set on an interface using the ip mtu value interface subcommand and for all Layer 3 protocols with the mtu value interface subcommand.

OSPF Authentication
OSPF authentication causes routers to authenticate every OSPF message.
When authentication fails, two routers cannot become OSPF neighbors, because they ignore the inauthentic OSPF Hello messages

Configuration steps:
1) Authentication must be enabled:
 - Enabling per interface using the interface subcommand "ip ospf authentication [message-digest]"
 - Enabling on all interfaces in an area by router ospf command "area area-no authentication [message-digest]"
2) The authentication keys must be configured per interface.

Authentication types can be seen in the messages generated by the "debug ip ospf adjacency"
The max key length is 8 (clear text) or 16 (MD5) characters.
0    None        ip ospf authentication null
1    Clear_text  ip ospf authentication
                 ip ospf authentication-key <key-value>
2    MD5         ip ospf authentication message-digest
                 ip ospf message-digest-key <key-number> md5 <key-value>

Although IOS defaults to use type 0 authentication (no authentication), you can override this default using the area authentication command in OSPF configuration mode.               
default; no configuration required            Type 0
area <num> authentication                     Type 1
area <num> authentication message-digest    Type 2

Note that if the area-wide default and the interface subcommand have both been configured, the interface setting takes precedence.
For example, if the interface has been configured with the ip ospf authentication subcommand (type 1, clear text), and the area authentication command sets MD5 authentication,
that particular interface uses clear text authentication.

Unlike EIGRP authentication, OSPF authentication does not allow the configuration of a key chain with time-based authentication keys.

show ip ospf interface
show ip ospf neighbor
debug ip ospf adj
*Mar  1 00:12:05.771: OSPF: Rcv pkt from, Serial0/1.201 : Mismatch Authentication Key - Clear Text

OSPF Neighbors and Adjacencies on WANs
OSPF still must meet the same requirements as on LANs.

The operation of OSPF on WAN links of various types requires some additional configuration:
- OSPF will discover neighbors via multicast /unicast or do the neighbors require predefinition?
- Will the routers try to elect a DR, and if so, which router should be allowed to be the DR?
- With which other routers should each router become an OSPF neighbor?

The first two of these items depend in part on the setting of the OSPF network type, and the third question depends on the WAN service.

OSPF Network Type
The OSPF network type–a per-interface setting–directs OSPF in regard to three important facts:
■ Whether the router can expect to discover neighbors using multicast Hello messages
■ Whether only two or more than two OSPF routers can exist in the subnet attached to the interface
■ Whether the router should attempt to elect an OSPF DR on that interface

Per-interface or per-subinterface setting is configured with the interface subcommand
ip ospf network <type>

1. OSPF Neighborship over Point-to-Point Links
Configure IP addresses on either end, configure the clock rate if using a back-to-back serial cable in a lab, and no shutdown the interfaces.
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 0 FULL/ - 00:00:31 Serial0/0/0

FULL/ -  
This notation means that no attempt was made to elect a DR

2. OSPF Neighborship over Frame Relay Point-to-Point Subinterfaces
Frame Relay design allows several options for IP addressing and subnetting:
1) treats each pair of routers on the ends of each PVC as a point-to-point topology, with one subnet assigned to each pair of routers,
2) treats more than two routers as a group, whether connected with a full mesh or partial mesh of PVCs, with a single subnet assigned to that group. (point-to-multipoint)

point-to-point subinterfaces
IOS point-to-point subinterfaces unsurprisingly default to use OSPF network type point-to-point.
The two routers discover each other using multicast OSPF Hellos, they do not bother to elect a DR, and everything works well.

3. OSPF Neighborship on MPLS VPN (L3)
The service uses routers at the edge of the service provider cloud–generically called provider edge (PE) routers–and these routers are Layer 3-aware. That Layer 3 awareness means that the customer edge (CE) routers form an OSPF neighborship with the PE router on the other end of their local access link.
The central site router will not have an OSPF neighborship with each branch office router but will have a neighborship with the MPLS VPN provider’s PE router.

4. OSPF Neighborship on Metro Ethernet (L2)
Metro Ethernet include VPWS, a point-topoint service, and VPLS, a multipoint service.
Because MetroE services provide Layer 2 connectivity, customer routers do not form OSPF neighborships with routers inside the service provider’s network.
Instead, the OSPF neighborships forms between customer routers, essentially as if the service were a large WAN.

OSPF LSAs and the OSPF Link State Database

Limiting the Number of LSAs
By default, Cisco IOS does not limit the number of LSAs a router can learn.
However, it may be useful to protect a router from learning too many LSAs to protect router memory.
Also, with a large number of LSAs, the router may be unable to process the LSDB with SPF well enough to converge in a reasonable amount of time.
The maximum number of LSAs learned from other routers can be limited by a router using the OSPF subcommand
max-lsa <number>
If is over:
- first reaction is to issue log messages.
- the router ignores the event for a time period, after which the router repeats the warning message.

LSA Types
With LSA's, routers communicates routing topology to all other local routers in the same OSPF area.
OSPF is designed for scalability, so some LSAs are not flooded out on all interfaces, but only on those that belong to the appropriate area.
In this way detailed information can be kept localized, while summary information is flooded to the rest of the network.

Each router link is defined as one of four types: type 1, 2, 3, or 4.
The LSA includes a link ID field that identifies, by the network number and mask, the object that this link connects to.
Depending on the type, the link ID has different meanings.
Link type Description Link ID Link Data
1 point-to-point connection to another router neighboring router ID IP address of the originating's interface to the network
2 connection to a transit network IP address of Designated Router IP address of the originating's interface to the network
3 connection to a stub network IP network/subnet number Subnet mask of the interface
4 virtual link neighboring router ID IP address of the originating's interface to the network

Diamond#sh ip ospf data

            OSPF Router with ID ( (Process ID 23423)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count   1673        0x80000005 0x004F5A 1    152         0x80000008 0x0084C8 2    1595        0x80000005 0x0050EB 1    587         0x80000005 0x00ED17 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum    1667        0x80000003 0x005647    664         0x80000003 0x00979C

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum    587         0x80000003 0x008C7C

0x2001Router LSA1Router LSA
0x2002Network LSA2Network LSA
0x2003Inter-area Prefix LSA3Network Summary LSA
0x2004Inter-area Router LSA4ASBR Summary LSA
0x4005AS-External LSA5AS-External LSA
0x2006Group Membership LSA6Group Membership LSA
0x2007Type-7 LSA7NSSA External LSA
0x0008Link LSA
0x2009Intra-area Prefix LSA

Type 1 (ROUTER)
Each router creates its own Type 1 LSA to represent itself for each area to which it connects.
The LSDB for one area contains one Type 1 LSA per router per area, listing the RID and all interface IP addresses on that router that are in that area:
 - for each interface on which no DR has been elected, it lists the router’s interface subnet number/mask and interface OSPF cost. (OSPF refers to these subnets as stub networks.)
 - for each interface with no DR, but for which a neighbor is reachable, it lists the neighbor’s RID.
 - for each interface on which a DR has been elected, it lists the IP address of the DR and a notation that the link attaches to a transit network(meaning a type 2 LSA exists for that network).
Represents stub networks as well.
Shows how many routers in one area (listing LSID wich is RID = highest loopback-IP/real-IP).

Type 2 (NETWORK)
One per transit network (broadcast domain). Created by the DR on the subnet, and represents the subnet and the router interfaces connected to the subnet.
OSPF defines the Type 2 network LSA, used as a pseudonode. Each router’s Type 1 router LSA lists a connection this pseudonode, often called a transit network, which is then modeled by a Type 2 network LSA. pag 187
The elected DR in a subnet creates the Type 2 LSA for that subnet.

Created by ABRs to represent subnets listed in one area’s  type 1 and 2 LSAs when being advertised into another area. Defines the links (subnets) in the origin area, and cost, but no topology data.
ABRs do not flood Type 1 and Type 2 LSAs into other areas, but routers still need to learn about subnets in other areas.  OSPF advertises these interarea routes using the Type 3 summary LSA. ABRs generate a Type 3 LSA for each subnet in one area, and advertises each Type 3 LSA into the other areas.

Like a type 3 LSA, except it advertises a host route used to reach an ASBR.

Type 5 (AS External)
Created by ASBRs for external routes injected into OSPF.

Type 6 (Group Membership)
Defined for MOSPF; not supported by Cisco IOS.

Type 7 (NSSA External)
Created by ASBRs inside an NSSA area, instead of a type 5 LSA.

Type 8 (External Attributes)
Not implemented in Cisco routers.

Type 9–11 (Opaque)
Used as generic LSAs to allow for easy future extension of OSPF; for example, type 10 has been adapted for MPLS traffic engineering.

The Database Exchange Process

Every router that connects to a given OSPF area should learn the exact same topology data.
Each router stores the data, composed of individual link state advertisements (LSA), in their own copy of the link state database (LSDB). Then, the router applies the Shortest Path First (SPF) algorithm to the LSDB to determine the best (lowest cost) route for each reachable subnet (prefix/length).

A router’s SPF process must examine the individual LSAs and see how they fit together, based on their characteristics.

OSPF routers flood both the LSAs they create, and the LSAs they learn from their neighbors, until all routers in the area have a copy of each of the most recent LSAs for that area. To manage and control this process, OSPF defines several messages, processes, and neighbor states that indicate the progress when flooding LSAs to each neighbor.

OSPF RFC: Section 13.  The Flooding Procedure
A Link State Update packet may contain several distinct LSAs, and floods each LSA one hop further from its point of origination.
The flooding procedure starts when a Link State Update packet has been received.
Many consistency checks have been made on the received packet before being handed to the flooding procedure (LSA's LS checksum, Examine the LSA's LS type).
(5) Otherwise, find the instance of this LSA that is currently contained in the router's link state database. 
If there is no database copy, or the received LSA is more recent than the database copy the following steps must be performed:
 (a) If there is already a database copy, and if the database copy was received via flooding and installed less than  MinLSArrival seconds ago,
 discard the new LSA (without acknowledging it) and examine the next LSA (if any) listed in the Link State Update packet.
 (b) Otherwise immediately flood the new LSA out some subset of   the router's interfaces.
    In some cases the LSA will be flooded back out the receiving interface.
 (c) Remove the current database copy from all neighbors' Link  state retransmission lists.
 (d) Install the new LSA in the link state database (replacing  the current database copy). 
    This may cause the routing  table calculation to be scheduled.
 (e) Possibly acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back out the receiving interface.
 (f) If this new LSA indicates that it was originated by the receiving router itself (i.e., is considered a self-originated LSA),
    the router must take special action, either updating the LSA or in some cases flushing it from the routing domain. 

OSPF Message Types and Functions
All five OSPF packets are encapsulated directly in an IP payload. The OSPF packet does not use Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). OSPF requires a reliable packet transport scheme, and because TCP is not used, OSPF defines its own acknowledgment routine using an acknowledgment packet (OSPF packet type 5).
Message Name/number
1) Hello (type 1) - Used to discover neighbors, supply information used to confirm two routers should be allowed to become neighbors, to bring a neighbor relationship to a 2-way state, and to monitor a neighbor’s responsiveness in case it fails.
2) Database Description (DD or DBD) (type 2) - Used to exchange brief versions of each LSA, typically on initial topology exchange, so that a router knows a list of that neighbor’s known LSAs
3) Link-State Request (LSR) (type 3) - A packet that lists the LSIDs of LSAs the sender of the LSR would like the receiver of the LSR to supply during database exchange
4) Link-State Update (LSU) (type 4) - A packet that contains fully detailed LSAs, typically sent in response to an LSR message
5) Link-State Acknowledgment (LSAck) (type 5) - Sent to confirm receipt of an LSU message

OSPF packet Header + Hello Packet

OSPF packet fields:
Version Number - 2 for OSPF ver2 (IPv4), 3 for OSPF ver3 (IPv6)
Type - Differentiates the five OSPF packet types
Packet Length - The length of the OSPF packet in bytes
Router ID - Defines which router is the packet’s source.
Area ID - Defines the area in which the packet originated.
Checksum - Used for packet header error detection to ensure that the OSPF packet
was not corrupted during transmission.
Authentication Type - Optional (no authentication/clear-text passwords/encrypted MD5 router authentication.
Authentication—Used with authentication type.
Data - Contains different information, depending on the OSPF packet type:
    - Hello packet - Contains a list of known neighbors.
    - DBD packet - Contains a summary of the LSDB, which includes all known RIDs and their last sequence number, among several other fields.
    - LSR packet - Contains the type of LSU needed and the RID ofthe router that has the needed LSU.
    - LSU packet - Contains the full LSA entries. Multiple LSA entries can fit in one OSPF update packet.
    - For the LSAck packet—This data field is empty.

hello packet
Two routers must agree on following to became Neighbors (and after adjacencies):
Neighbors Requirements OSPF Where
Routers MUST be able to send/receive IP packets to one another YES L1/L2
Interfaces MUST be in UP/UP state YES L1/L2
Interfaces PRIMARY IP MUST be in SAME subnet YES L3
Interfaces MUST not be Passive on the connected interface YES OSPF Config
MUST pass authentication (if configured) YES OSPF Config

Router IDs MUST be unique YES OSPF Config
SAME  ASN  / Process ID NO OSPF Config
SAME  Hello / Dead intervals YES Every OSPF Packets (usually first packets)
SAME 'Stub' Area Flag
SAME  Area
YES Every OSPF Packets

Specifically this problem stems from the issue that the OSPF Hello, Database Description (DBD), Link-State Request (LSR), and Link-State Acknowledgement (LSAck) packets are generally small, but the Link-State Update (LSU) packets are generally not.
When establishing a new OSPF adjacency, the DBD packet is used to tell new neighbors what LSAs are in the database, but not to give the details about them. Specifically the DBD contains the LSA Header information, but not the actual LSA payload. The idea behind this is to optimize flooding in the case that the receiving router already received the LSA from another neighbor, in which case flooding does not need to occur during adjacency establishment.

When Router receive an LSU (LSA) it does
 - if LSA entry doesnt exist:
   1) R add entry is LSDB  2) send back LSAck   3) floods info to other R's 4) run SPF  5) update routing table
- if LSA entry exists and includes newer info (higher Seq num):
   1) R add entry is LSDB  2) send back LSAck   3) floods info to other R's 4) run SPF  5) update routing table
- if LSA entry exists and includes older info (lower Seq num):
   1) send LSU with its newer info

OSPF Neighbor States
OSPF States
Down - No Hellos have been received from this neighbor for more than the dead interval.
Attempt - Used when the neighbor is defined with the neighbor command, after sending a Hello, but before receiving a Hello from that neighbor.
Init - A Hello has been received from the neighbor, but it did not have the local router’s RID in it or lists parameters that do not pass the neighbor verification checks. This is a permanent state when Hello parameters do not match.
2Way - A Hello has been received from the neighbor, it has the router’s RID in it, and all neighbor verification checks passed.
ExStart - Currently negotiating the DD sequence numbers and master/slave logic used for DD packets.
Exchange - Finished negotiating the DD process particulars, and currently exchanging DD packets.
Loading - All DD packets are exchanged, and the routers are currently sending LSR, LSU, and LSAck packets to exchange full LSAs.
Full - Neighbors are fully adjacent, meaning they believe that their LSDBs for that area are identical. Routing table (re)calculations can begin.

OSPF Sample Database exchange (packets)
< unicast
<<< multicast
R1                R3
                    ===no  shutdown int (routes: and       
                <DBD seq 8248
seq 6901 DBD>
seq 8248 DBD>
      LS REQ>
seq 8249 DBD>    
                <LS Update (routes and
                <LS REQ
    LS Update>>>               
    LS Update>
                <LS Ack (explicit acknowledgment)
                <<<LS Update multicast (routes and
       LS Ack>
                <<<<LS Ack (implicit acknowledgment)      
       LS Ack>>>   

In general, the following are the flooding process steps in a multiaccess network
1) Topology change
A router notices a change in a link state and multicasts an LSU packet, which includes the updated LSA entry with the sequence number incremented, to This address goes to all OSPF DRs and BDRs. (On point-to-point links, the LSU is multicast to An LSU packet might contain several distinct LSAs.

2) DR send updates to all routers with ACK
The DR receives the LSU, processes it, ACKnowledges the receipt of the change and floods the LSU to other routers on the network using the OSPF multicast address After receiving the LSU, each router responds to the DR with an LSAck. To make the flooding procedure reliable, each LSA must be acknowledged separately.

3) Each router send updates to others
If a router is connected to other networks, it floods the LSU to those other networks by forwarding the LSU to the DR of the multiaccess network (or to the adjacent router if in a point-to-point network). That DR, in turn, multicasts the LSU to the other routers in the network.

4) Each router updates his routing table
The router updates its LSDB using the LSU that includes the changed LSA. It then recomputes the SPF algorithm against the updated database after a short delay and updates the routing table as necessary.

An SPF calculation is performed separately for each area in the topology database. goes to all OSPF routers on the link. goes to the DR and BDR on the link.

Exchange Without a Designated Route

OSPF interface network type tells that router whether to attempt to elect a DR on that interface.
Routers do not elect a DR occur on point-to-point topologies:
 - true point-to-point serial links
 - point-to-point subinterfaces.

1) Hello
When a router receives a Hello that lists its own RID as having been seen by the other router, the router can transition to 2-Way state.
Next: the router decides whether it should exchange its LSDB entries.
Step 1. Discover the LSAs known to the neighbor but unknown to me.
Step 2. Discover the LSAs known by both routers, but the neighbor’s LSA is more up to date.
Step 3. Ask the neighbor for a copy of all the LSAs identified in the first two steps.

2) DD
To learn the list of LSAs known by the neighbor, the neighboring routers follow these steps:
Step 1. Multicast database description (DD) packets to,(all OSPF routers multicast address).
Step 2. Transition to the ExStart (sending the first DD message), until one router, the one with the higher RID, becomes master in a master/slave relationship.
Step 3. After electing a master, transition the neighbor to the Exchange state.
Step 4. Continue multicasting DD messages to each other until both routers have the same shared view of the LSIDs known collectively by both routers, in that area.

Note that the DD messages themselves do not list the entire LSAs, but rather LSA headers.
Highest RID becomes master and starts DBD exchange (controls the flow of DD messages).
These headers include the LSIDs of the LSAs and the LSA sequence number. The LS sequence number for an LSA begins at value 0x80000001 (hex) when initially created; the router creating the LSA increments the sequence number, and refloods the LSA, whenever the LSA changes. For example, if an interface moves from up to down state, that router changes its Type 1 LSA to list that interface state as down, increments the LSA sequence number, and refloods the LSA.

This exchange of DD messages ends with each router knowing a list of LSAs that it does not have in its LSDB, but that the other router does have those LSAs.

3) full LSA
When the two neighbors realize that they have a shared view of the list of LSIDs, they transition to the Loading state and start exchanging the full LSAs–but only those that they do not yet know about or those that have changed.

The mechanics work like this:
Step 1. Transition the neighbor state to Loading.
Step 2. For any missing LSAs, send a Link State Request(LSR) message, listing the LSID of the requested LSA.
Step 3. Respond to any LSR messages with an Link State Update(LSU), listing one or more LSAs in each message.
Step 4. Acknowledge receipt by either sending a LSAck message (called explicit acknowledgment), or by sending the same LSA that was received back to the other router in an LSU message (implicit
Step 5. When all LSAs have been sent, received, and acknowledged, transition the neighborship to the FULL state (fully adjacent).
Note: Because this section examines the case without a DR, all these messages flow as multicasts to, the all SPF routers multicast address, unless the neighbors have been defined with an OSPF neighbor command.

Exchange with a Designated Router
Database exchange with a DR differs slightly than database exchange when no DR exists (difference is the overriding choice of with whom each router chooses to perform database exchange).
Non-DR routers do not exchange their databases directly with all neighbors on a subnet.
Instead, they exchange their database with the DR and BDR only (sends these messages to the and not any other DROther routers in the subnet.
The DR performs database exchange with the same messages but sends the messages to the all-SPF-routers multicast address.

R3#show ip ospf interface fa0/0
Neighbor Count is 3, Adjacent neighbor count is 2   (Adj is only with DR and BDR)
Adjacent with neighbor (Designated Router)
Adjacent with neighbor (Backup Designated Router)

Periodic Flooding
Although OSPF does not send routing updates on a periodic interval, as do distance vector protocols, OSPF does reflood each LSA every 30 minutes based on each LSA’s age variable.

R1#sh ip ospf data
            OSPF Router with ID ( (Process ID 2)

                Router Link States (Area 0)

Link ID      ADV Router   Age         Seq#       Checksum Link count     1422        0x80003025 0x00631D 1   558         0x80010E6A 0x0009FD 2   504         0x800026C4 0x00BA1D 1
Over time the sequence number should increment once per every 30 minutes, with the LSAge cycle upward toward 1800 and then back to 0 when the LSA is reflooded. (counting from 0 to 1800, when 1800, reflood LSA and set Age=0)

Note also that when a router realizes it needs to flush an LSA from the LSDB for an area, it actually sets the age of the LSA to the MaxAge setting (3600) and refloods the LSA. All the other routers receive the LSA, see the age is already at the maximum, causing those routers to also remove the LSA from their LSDBs.

Choosing the Best OSPF Routes (Metric Calculation)
LSAs flooding has one goal in mind: to allow all routers in that area to calculate the best, loop-free routes for all known subnets.

Best route for a given subnet (calculated by a particular router), can be summarized as follows:
1) Analyze the LSDB to find all possible routes to reach the subnet.
2) For each possible route, add the OSPF interface cost (show ip ospf interface) for all outgoing interfaces in that route.
3) Pick the route with the lowest total cost.

Calculating the Cost of Intra-Area Routes
1) Finds all subnets inside the area (LSA Type1 and Type2)
2) Runs SPF to find all possible paths through the area’s topology, from itself to each subnet
3) Calculates the OSPF interface costs for all outgoing interfaces in each route (lowest total cost route for each subnet is the best route)

If the metrics tie, with a default setting of maximum-paths 4, OSPF adds up to 4 equal-cost routes to its routing table.

OSPF supports equal-cost load balancing, but it does not support unequal-cost load balancing.
Modern IOS versions typically support from 1 up to 16 or 32 concurrent routes to one destination (maximum).

Calculating the Cost of Interarea Routes
Interarea routes, do not have topological data–LSA Types 1 and 2–for other areas.
Instead, ABRs create and flood Type 3 summary LSAs into an area, listing the subnet number and mask, but not listing details about routers and links in the other areas.

The SPF algorithm has to calculate all possible routes and options inside an area to the ABR.

For routers in one area to calculate the cost of an interarea route
1) Calculate the intra-area cost from that router to the ABR listed in the type 3 LSA.
2) Add the cost value listed in the Type 3 LSA. (This cost represents the cost from the ABR to the destination subnet.)

Special Rules Concerning Intra-area and Interarea Routes on ABRs
The issue exists when more than one ABR connects to the same two areas (redundancy).
OSPF rules prevent unoptimal routing by:
1)  intra-area (direct connection to another area) route > interarea (same area + another area) route
When choosing the best route, an intra-area route is always better than a competing interarea route, regardless of metric.

Intra (SAME AREA) Area routes "O" - routes that are are originated and learned in the same area (OSPF uses pure link state logic)
Inter (between)-area routes "O IA" - routes that originated in some other OSPF area and are advertised into your area (OSPF uses distance vector logic)

2) router is ignoring LSA for interarea route for the purposes of choosing its own best IP routes.
If an ABR learns a Type 3 LSA inside a nonbackbone area, the ABR ignores that LSA when calculating its own routes.

3) External routes
The following external cost types can be configured:
 - E1—Type O E1 external routes calculate the cost by adding the external cost to the internal cost of each link the packet crosses. Use this type when multiple ASBRs are advertising an external route to the same autonomous system, to avoid suboptimal routing.
 - E2 (default)—The external cost of O E2 packet routes is always the external cost only. Use this type if only one ASBR is advertising an external route to the autonomous system.

The E2 cost to the route in the external AS is always the same. For example, if there were multiple paths to the external route, and E2 costs were used, there would be no distinction between the paths.
If E1 costs are used, so the cost increases at each router as the internal cost is added to the external cost. This allows the optimal path to be selected if multiple paths are available.

Metric and SPF Calculations
Edsger Dijkstra designed the mathematical algorithm used by link-state routing protocols for calculating the best paths through complex networks.

For OSPF, the default behavior on Cisco routers is that the interface cost is calculated based on its configured bandwidth. The higher the bandwidth, the lower the cost.Only one cost can be assigned per interface.

Default OSPF costs are as follows:
■ 56-kbps serial link—Default cost is 1785.
■ 64-kbps serial link—Default cost is 1562.
■ T1 (1.544-Mbps serial link)—Default cost is 64.
■ E1 (2.048-Mbps serial link)—Default cost is 48.
■ Ethernet—Default cost is 10.
■ Fast Ethernet—Default cost is 1.
■ FDDI—Default cost is 1.
■ ATM—Default cost is 1.

Only changes to Type 1 and 2 LSAs require an SPF calculation.
Changes to Type 3 LSAs do not drive a recalculation of the SPF algorithm, because the Type 3 LSAs do not actually describe the topology (counter does not increment).

You can see the number of SPF runs, and the elapsed time since the last SPF run, using several variations on the
Diamond#  sh ip ospf
 Routing Process "ospf 23423" with ID
 Start time: 00:03:53.224, Time elapsed: 1w3d
    Area BACKBONE(0)
        Number of interfaces in this area is 2
        SPF algorithm last executed 1w3d ago
        SPF algorithm executed 8 times

1. Metric Tuning

Engineers have a couple of commands available that allow them to tune the values of the OSPF interface cost, thereby influencing the choice of best OSPF route.

The primary motivation for changing the reference bandwidth is to accommodate good defaults for higher-speed links.
Although Cisco recommends that all routers use the same reference bandwidth, the setting is local to each router.

Changing the Reference Bandwidth
OSPF Cost= reference_bandwidth / interface_bandwidth

Default reference bandwidth
Interface Type      Interface Bandwidth    OSPF Cost    Calculations (100 mbps = 100'000 kbps)
Serial              56 kbps                1785        100'000k/56k
T1                  1'544 kbps             64          100'000k/1544k
E1                  2'048 kbps             48          100'000k/2048k
Ethernet            10'000 kbps            10          100'000k/10'000k
Fast Ethernet       100'000 kbps           1           100'000k/100'000k
Gigabit Ethernet    1'000'000 kbps         1           100'000k/1'000'000k =0.1  <- OSPF always rounds down when results <1
10 Giga Ethernet    10'000'000 kbps        1
OC48 (STM16)        2'500'000 kbps         1
Loopback            8'000'000 kbps         1
Change reference_bandwidth with router command   :  
auto-cost reference-bandwidth <bandwidth>
! used on each router to allow different costs for FastEthernet and Gigabit interfaces.
auto-cost reference-bandwidth 1000
The reference bandwidth defaults to 100, meaning 100 Mbps.
Serial interfaces default to a bandwidth setting of 1544, meaning 1544 Kbps
OSPF cost = 100'000 / 1544 = 64

Note: OSPF always rounds down when the calculation results in a fraction 

2. Setting Bandwidth
You can indirectly set the OSPF cost by configuring the bandwidth speed interface subcommand.
 - On serial links, the bandwidth defaults to 1544. On subinterfaces of those serial interfaces, the same bandwidth default is used.
 - On Ethernet interfaces, if not configured with the bandwidth command, the interface bandwidth matches the actual speed.

3. Configuring Cost Directly
The most controllable method to configure OSPF costs, but the most laborious, is to configure the interface cost directly with interface sub-command ip ospf cost <value>

4. Verifying OSPF Cost Settings
R3#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se0/0/0.2  3 34 647 P2P
Se0/0/0.1  3 34 1000 P2P 1/1
Fa0/0      3 34 17 BDR 1/1
R3#show ip ospf interface fa0/0
Process ID 3, Router ID, Network Type BROADCAST, Cost: 17

OSPF neighbor relationships are formed
1. Determine the Router-ID (Highest physical IP address/Highest Loopback address, Loopback will always beat the physical interface. You should always hard code the Router-ID)

2. Add interface to the Link State Database (LSD)

3. Send Hello Packets out of chosen interfaces based on the Network command. ** DOWN STATE**

4. If connected to a Non-broadcast Multi Access Network (NBMA) e.g. ATM/Frame-Relay send unicast packets **ATTEMPT STATE**

5. Neighbors receive Hello packets and check certain criteria to make sure they match. **INNIT STATE**
Area-ID must match
Hello/dead timers must match
Subnet mask must match
Authentication must match
Stub flags much match
MTU values must match

6. If the neighbor already exists reset the dead time. If the neighbor does not exist move onto step 7. **2-WAY STATE**

7. Master/Slave determination on who sends the Database Description (DBD) first. Highest priority wins. If there is a tie highest Router-ID wins **EXSTART STATE**

8. Master sends the DBD to the Slave then Slave sends DBD to the Master. **EXCHANGE STATE**

9. DBD are received & acknowledged. **LOADING STATE**
Slave requests further details to Master Link State Request (LSR)
Master responses by sending the Link State Update (LSU)
Master requests further details to Master Link State Request (LSR)
Slave responses by sending the Link State Update (LSU)

10. Neighbors are formed and are now ready to run the Shortest Path First Algorithm  **FULL**

Electing a DR and BDR and Setting Priority
To elect a DR and BDR, the routers view the OSPF priority value of the other routers during the hello packet exchange process and then use the following conditions to determine which router to select:
1. The router with the highest priority value is the DR.
2. The router with the second-highest priority value is the BDR.
3. The default for the interface OSPF priority is 1. In case of a tie, the router ID is used.
The router with the highest router ID becomes the DR. The router with the second highest router ID becomes the BDR.
4. A router with a priority of 0 cannot become the DR or BDR. A router that is not the DR or BDR is a DROTHER.
5. If a router with a higher priority value gets added to the network, it does not preempt the DR and BDR. The only time a DR or BDR changes is if one of them goes out of service. If the DR is out of service, the BDR becomes the DR, and a new BDR is selected. If the BDR is out of service, a new BDR is elected.

The BDR does not perform any DR functions when the DR is operating. Instead, the BDR receives all the information, but the DR performs the LSA forwarding and LSDB synchronization tasks. The BDR performs the DR tasks only if the DR fails.

 To determine whether the DR is out of service, the BDR uses the wait timer. This timer is a reliability feature.

It is important to remember that the DR concept is at the link level (each broadcast domain has is own DR/BDR).
Router(config)#interface FastEthernet 0/0
Router(config-if)# ip ospf priority 10
affect which router interfaces on a multiaccess link are the DR and the BDR. The default priority is 1, and the range is from 0 to 255. The highest priority interface becomes the DR, and the secondhighest priority interface becomes the BDR. Any interfaces set to 0 priority cannot be involved in the DR or BDR election process.

Configuring and Verifying Advanced OSPF Features
1. Passive interface
R(config-router)# passive-interface <type> <number> [default]
Prevents routing updates from being sent through the specified router
interface. This command can be used with all IP-based routing protocols except BGP.

passive-interface default
Set all interfaces to passive by default. To enable routing on individual interfaces where you require adjacencies to be established, use the no passive-interface command.

2. Propagating an OSPF Default Route
OSPF routers do not, by default, generate a default route into the OSPF domain.
For OSPF to generate a default route, you must use the command
! router already has a default route
default-information originate

! advertise regardless of whether the advertising router already has a default route
default-information originate
Whenever the default-information originate command (or redistribution into OSPF) is configured on an OSPF router, the router becomes an ASBR.

default-information originate [always] [metric metric-value] [metric-type type-value] [route-map map-name]
always (optional) - advertises the default route regardless of whether the router has a default route in the routing table
metric - if you omit a value and do not specify a value using the default-metric router configuration command, the default metric value is 1.
metric type - 1—Type 1 external route, 2—Type 2 external route (default)
3. Configuring OSPF Route Summarization
Route summarization can be configured so that only summarized routes propagate into the backbone (area 0).
 Route summarization helps to solve two OSPF issues: large routing tables and frequent LSA flooding throughout the autonomous system.

The two types of summarization are as follows:
■ Interarea route summarization— occurs on ABRs and applies to routes from within each area. It does not apply to external routes injected into OSPF via redistribution. Network numbers within areas should be assigned contiguously so that these addresses can be summarized into a minimal number of summary addresses.
area <area-id> range <address> <mask> [advertise| not-advertise] [cost cost]

R1(config)#router ospf 100
R1(config-router)# network area 1
R1(config-router)# area 1 range
Area 1 range—Identifies area 1 as the area containing
the range of networks to be summarized.
■ External route summarization—is specific to external routes that are injected into OSPF via route redistribution. Again, it is important to ensure the contiguity of the external address ranges that are being summarized. Generally, only ASBRs summarize external routes.
summary-address <ip-address mask> [not-advertise] [tagtag]
router ospf 100