OSPF - designed to route to the node that owns the attribute that is the prefix

- find the shortest path to the node you have found the SPT to the prefix
recommended resources
books
ospf anatomy of an internet routing protocol
routing tcp/ip vol 1
standards
rfc 2328 ospfv2
rfc 5340 ospfv3
documentation
tech guides
config guide/command ref
open standards based
OSPFv3 routes both IPv4 and IPv6 there is MAF support
rfc 2328
classless link state protocol
uses dijkstra spf algorithm
maintains active adjacencies
some limits to design and traffic engineering
supports vlsm
supports both topology and nlri summarization
Guarantees loop free topology
all routers agree on overall topology
SPF for calculation
standards based
run between 2 vendors
large scalability
hierarchy through areas
topology summarization
Fast Convergence
actively tracks neighbors
event driven incremental updates
Efficient updating
IP protocol 89
uses reliable multicast and unicast updates
non ospf devices do not need to process updates
Bandwidth based cost metric
more flexible than static hop count
Control Plane security
supports multiple forms of authentication
clear text, md5, sha and ipsec
extensible
future application support through opaque lsa
MPLS traffic engineering

How ospf works

step 1
discover neighbors and exchange routing info
step 2
choose best path via spf
step 3
neighbor and topolgoy table maintenance

Step 1
Uses hello packet to discover neighbors on interface enabled to
run OSPF
transport via IP protocol 89
sent as mcast to 224.0.0.5 or .6 or unicast
hello packet contain attributes that neighbors must agree on to
form adjacency
You can form a neighbor relationship but not form an
adjacency
if you form an adjacency you also form a neighbor
relationship
once adjacency is negotiated, LSDB exchanged
Negotiating ospf adjacencies
adjacency occurs when connected neighbors agree on
unique/common attributes
not all ospf neighbors actually form adjacency
most ospf configuration problems happen at this stage
Unique OSPF adjacency attributes
Router ID
Node ID in the LS graph
Chosen based on
Manual config
highest active loopback IP
highest active interface IP
Interface IP address
for OSPFv2, the interfaces primary IP address
For OSPFv3, the interfaces link local address
Common OSPF adjacency attributes
Interface Area ID
Hello/dead interval
interface network address
interface MTU
network type
authentication
stub flags
Other optional capabilities
OSPF hello packet
routers send periodic hellos out ospf enabled links every
hello interval
hello packet contains
local router ID | area ID | interface Subnet Mask |
interface priority | hello/dead interval | authenticaton type/password |
DR/BDR addresses | Options | RIDs of other neighbors
on the link
Adjacency state machine
Down
no hellos have been received from neighbor
Attempt - unicast
unicast hello packet has been sent to neighbor, but
no hello has been received back
Init - multicast
I have received a hello packet from a neighbor, but
they have not acknowledge a hello from me
2 way -
I have received a hello packet from a neighbor and
they have ack'd a hello from me
Indicated by my router id in neighbors hello packet
A list of routers on seen on my segment: a list of
RIDs the neighbor sees
Issues at this point indicate a layer 2 issue
Exchange start
first step of actual adjacency
Master&slave relationship is formed, where master has
higher router id
master chooses the starting sequence number for the
DBD packets that are used for actual LSA exchange
Exhange
local link state database is sent through DBD packets
DBD sequence number is used for reliable
ack/retransmission
Stub flags and other options happen here
Loading
link state request packets are sent to ask for more
information about a particular LSA
Full
Neighbors are fully adjacent and databases are
synchronized

Step 2
Once data bases are synchronized, path selection begins
Each routers LSA includes a cost attribute for each described
link
best path to that is lowest end to end cost
Multiple equal cost paths are allowed ECMP
Cisco Implementation uses BW based cost, but RFC says you can use
whatever you would like
Default Cisco Cost = 100Mbps / link bandwidth
Reference bandwidth can be modified to accomodate higher
speed links

Step 3
Niehgbor and topology maintenance
Once adjacencies established and spt built, OSPF state
machine tracks neighbor and topology changes
hello packets used to track neighbor changes
LSA fields used to track topology changes
Tracking neighbor changes
Hello packets continue to be sent on each OSPF enabled link
every hello interval
10 or 30 seconds by default depending on interface
type
If hello packet is not received from a neighbor within dead
interval, the neighbor is declared down
defaults to 4 times hello interval
can be as low as 1 second for faster convergence
Tracing topology changes
when a new LSA is received it is checked against the
database for changes such as
sequence number
used to track new vs old LSAs
age
used to keep information new and withdraw old
information
periodic flooding occurs after 30 minutes
paranoid update
LSAs that reach Maxage - 60 minutes are
withdrawn
Checksum
used to avoid transmission and memory
corruption
LSA flooding
when change is detected new LSA is generated and flooded
out all links
OSPF does not use SH
 self originiated LSA s are simply dropped
Not all LSA changes require SPF to recalculate
link up/down event - re run SPF vs sequence number
change - do not re-run SPF

OSPF behaves like DV between areas, does not have topology

visibility end to end between areas

Forming adjacencies
neighbors must agree on attributes to form adjacency
not all ospf neighbors actually form adjacency
most ospf configuration problems happen at this stage
unique attributes include
local router id
local interface ip address
common attributes
interface area id
hello interval and dead interval
how often we talk to each other
how long we wait before declaring the remote neighbor down
interface network address
must be on same subnet
unless ppp unumbered link
interface mtu
network type
how updates are sent across the link
must be a compatible value
authentication
null- default, clear text, MD5/SHA, in IPv6 SPI
stub flags
other optional capabilities
opaque, extensible
non stop forwarding, graceful restart
forming adjacencies
cost value= slower bandwidth higher value, higher bandwidth lower value
if there are too many retransmissions, the will drop the adjacency
maximum metric makes the router look bad to ospf
resulting in ospf routing around that router, allowing it to be taken
out of service
the database
the link state database must be the same on all routers in order for
the SPF algorithm to work
original implementation, TOS routing was available
Cisco implementation doesn't support that
ip ospf point to point disables DR/BDR election
Media dependencies
ospf behavior changes based on media
ethernet vs. frame relay vs. PPP
different media uses different network types to control
how updates are sent
who forms adjacency
how next hop is calculated
broadcast
ip ospf network broadcast
default on multiaccess broadcast medias
ethernet token ring and fddi
sends hellos and updates as multicast
224.0.0.5 all spf routers
 224.0.0.6 all dr routers
performs designated router and backup designated router election

Troubleshooting Adjacencies
Where can problems arise
transport problems
attribute negotiation problems
Useful tshooting commands
show ip ospf neighbor
show ip ospf database
debug ip ospf adj
debug ip packet
Normal OSPF Adjacency state machine
down - all network types except non broadcast
attempt - only non broadcast
Init
transport issue
hello is sent but neighbor hasn't responded
2-way
stop here for DROthers
If you don't get to this state, there is an issue with transport
Mcast could be blocked
OSPF could be blocked
exstart
the DBD packets begin
exchange
loading
full
Duplicate router id
2 routers with the same router id
Flood war
When the correct router sends an update out to the router with
incorrect router id, the incorrect router believes it has old info
and ages it out
The advertising router ID is the node and the LSA ID is the link
Attribute issues
Broadcast/NBMA will use DR/BDR
P2P/P2MP/P2MP NB do not use a DR/BDR
BCAST/NBMA use 10/40 timers
P2P/P2MP/P2MP NB use 30/120 timers
MTU issues

OSPF Areas and LSAs

Areas overview
Areas add hierarchy and scalability to OSPF
An area defines a flooding domain
all devices in the area agree on the topology
Changes inside the area require LSA flooding and full SPF
the goal of OSPF is to solve the SPT to the node that owns
the attributes of a prefix
solve the SPT to a router LSA you have at the same time
solved the SPT to the prefix
Routing between areas hides topology details
Inter-area routing is similar to distance vector
in area 0 to route to an prefix in area 1 the following
occurs
solve the SPT from the source to the ABR that
advertises the prefix
once at the ABR solve the SPT to the node that owns
the attributes of the destination prefix
changes outside the area don't always require lsa flooding or spf
limits the impact on router resources
Two level hierarchy
backbone area
area 0
used to summarize topology info between other areas
this is not summarizing the NLRI - the topology summary is
different
LSA type 3 (ABR) network summary and LSA type 4 (ASBR)
network summary
this is not area range, which is nlri summarization
traffic from one area to another must go through area 0
must be contiguous
non backbone areas
all other area 1-2^32 or 0.0.0.1-255.255.255.255
must use connectiosn to area 0 to reach other areas
Router types
backbone
at least one link in area 0
internal
all links in non backbone area
ABR
Links in both Area 0 and in non backbone areas
It will run SPF for every area it belongs to
It will have SPF databases for each area it belongs to
connections in 2 areas, run SPF twice
Used to summarize information between area 0 and non backbone
area
ASBR
At least one link in the OSPF domain
At least one link outside the OSPF domain
EIGRP, ISIS bgp
Used to redistribute information to/from other routing domains
and OSPF
LSA Types
types sent and received depend on
router type
network type
area type
Types
Type 1 Router LSA
Type 2 DR lsa
Type 3 ABR
Type 4 ASBR
Type 5 External
Type 7 NSSA external
LSA and Route types
3 Groups
Intra area routes O
types 1 and 2
inter area routes O IA
types 3 and 4
type 3 is used to reach inter area internal
destination
 type 4 is used to reach inter area external
destinations
External routes
e1/e2 type 5
n1/n2 type 7
both are external LSA, exception is Type 7 LSAs come
from NSSAs, more on this later

LSA type 1 router lsa

generated by every router in the OSPF domain
not flooded outside the area they originiate in
area local scope
describes its directly connected links
what are my link costs
who are my neighbors
Type 1 Router LSAs are used to build the graph for intra-area SPF
LSA type 2 network lsa (DR)
generated by the DR on broadcast/non broadcast network types
not flooded outside the area they originiate in
describes who is adjacent with the dr
what is my link cost to the dr
implies my link cost to all others adjacent to that DR

The DR is a central point on the segment, if you can reach the

DR, the DR is able to reach all other routers on the segment
This means if you can reach the DR you should have
reachbility to other routers on the segment
This effects who you can form adjacencies with and exchange
routes with
All routers form adjacenies with the DR, all routers don't
form adjacencies with all other routers
the DR is used to reduce the redundant info in the
database
LSA type 3 summary lsa (ABR)
genereated by abr
flooded from area 0 into non backbone areas and vice versa
describes abrs reachability to links in other areas
includes cost, but hides ABRs actual path to destination
SPF not run for ABR advertised routes
abr can reach link a via spt in cost x
i can reach abr via spt in cost y
implies i can reach link a via spt in cost x+y
If you can solve the SPT to the ABR, and the ABR solves the
SPT to the destination then you can reach the destination
this is why inter-area routing is like distance vector
LSA type 4 (ASBR)
generated by abr
flooded from area 0 into non backbone area and vice versa
describes abrs reachability to asbrs in other areas
includes cost, but hides abrs actual path to destination
spf not run to reach inter area asbr
abr can reach asbr via spt in cost x
i can reach abr via spt in cost y
implies i can reach asbr via spt in cost x + y
Inter area external routing is also like distance vector
LSA typ 5 external lsa
genereated by asbr
flooded into all non stub areas
describes routes asbr is redistributing
 metric
metric type
type 1 = e1
type 2 = e2 default
forward address
who should i route towards to reach the link
usually the asbr itself, but could be someone else in
some designs
advertise the route to you but tell you to use
another router to reach the destination
I send you the route but tell you to use
another next hop
route tag
External type 1 and 2
external route type controls how metric for external link
is calculated
type 1
take the cost the asbr reports in plus the cost to
the asbr - cold potato
type 2
take just the cost the asbr reports in
if there is a tie, then take the cost to the asbr as
well - hot potato
type 1 is preferred over type
Hot potato routing
find the closest and fast point off the network and ship
the packet thay way
cold potato routing
find the most optimal internal route through your network
and make the forwarding decision that way
External route calculation
perform like distance vector routing similar to inter area
calculation
intra area external
asbr can reach link a in cost x
i can reach asbr via spt in cost y
i can reach link a via spt in cost x + y
Recursion works like this, a type 5 LSA (external) is
advertised to a node in the graph
If a source wants to reach the external destination
it has to recuse from type 1 to type 5 to reach the ASBR
From the ASBR you have to recurse to the external
route to reach the destination
inter area externals
asbr can reach link a in cost x
abr can reach asbr via spt in cost y
i can reach abr via spt in cost z
i can reach link a via spt in cost x + y + z
Recursion works like this, a type 5 LSA (external) is
advertised to a node in the graph
if a source want to reach the external destination it
has to route to the ABR
The ABR then has to route to the ASBR
The ASBR then routes to the external destination
Recurse from Type 1 to type 3, then to type 4 and
then to type 5
OSPF Single Area Configuration
Prereguisites
IP routing must be enabled
on catalyst switch
Must be an up/up interface running IP
used for OSFP router id
Node identifier - 32 bit number derived from IP address

Enabling OSPF
enable the global process
router ospf process id
process id locally significant
exception is MPLS L3VPN
must be an up/up interface running IP
used for the router id
enable the interface process
process level
network x.x.x.x x.x.x.x area x
interface level
ip ospf process id area x
Network statement
Useful for enabling OSPF on multiple intefaces at the same time
Wildcard mask does not relate to subnet mask
used for enabling OSPF on several interfaces at the
same time
Most specific match determines the area
Implies statements can overlap, most specific statement
determines area
all zero's/32 area 0 mean all interfaces in area 0
network 0.0.0.0 255.255.255.255 area 0
all interfaces starting with 1.x.x.x /8 in area 1
network 1.0.0.0 0.255.255.255 area 1
all interfaces starting with 1.2.x.x /16 in area 2
network 1.2.0.0 0.0.255.255 area 2
all interfaces starting with 1.2.3.x /24 in area 3
network 1.2.3.0 0.0.0.255 area 3
interface with 1.2.3.4 /32 in area 4
network 1.2.3.4 0.0.0.0 area 4
That's the benefit of the network statement, more
specific statement determines area

Interface statement
enables ospf on the primary and secondary IP addresses
secondary advertisement can be disabled
suppress the secondary prefixes, use the ip ospf [process-
id] area [area-id] secondaries none command
OSPF stay enabled even if IP address changes

Verification
verify OSPF is enabled
show ip ospf
show ip ospf interfaces
verify OSPF adjacencies
show ip ospf neighbor
debug ip ospf adj
verify ospf database
show ip ospf database
 The OSPF Database
R8#sh ip ospf database
OSPF Router with ID (150.1.8.8) (Process ID 1)
Router Link States (Area 0)
Type 1 LSA - The router LSA
Link ID ADV Router Age Seq# Checksum
Link count
150.1.8.8 150.1.8.8 281 0x80000002 0x00CE99 4
150.1.10.10 150.1.10.10 287 0x80000003 0x000639 3

Net Link States (Area 0)

Type 2 LSA - The network LSA - DR
Link ID ADV Router Age Seq# Checksum
155.1.108.10 150.1.10.10 286 0x80000001 0x000C1C

R8
my node id is 150.1.8.8
my dr is 150.1.10.10

R4#sho ip ospf database network 155.1.146.6

OSPF Router with ID (150.1.4.4) (Process ID 1)

Net Link States (Area 0)

Routing Bit Set on this LSA in topology Base with MTID 0

LS age: 1537
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 155.1.146.6 (address of Designated Router)
Advertising Router: 150.1.6.6
LS Seq Number: 8000001E
Checksum: 0xF76B
Length: 36
Network Mask: /24
Attached Router: 150.1.6.6
Attached Router: 150.1.1.1
Attached Router: 150.1.4.4

LSDB to the SPF algorithm then the best go to the RIB

OSPF Media Dependencies

OSPFs behavior changes depending on what type of media it is configured on
ethernet vs frame relay
OSPF define different network types to deal with different media
characteristics
OSPF network types control
how are hellos and updates sent
who forms adjacency
how is the next hop calculated
Network Types
 Broadcast
Non broadcast
P2P
P2MP
P2MP NB
Loopback
Network types and forming adjacencies
OSPF network type does not need to match to form adjacency
but they do need to be compatible
other attributes must still match
timers | stub flags
What makes the network types compatible
usage of type 2 lsa
OSPF type 2 lsa review
lsa type 2 network lsa
generated by the DR
describes who is adjacent with DR
not flooded outside the area they originate in
used to optimize OSPF operation on a shared segment
reduce number of ospf adjacencies
reduce LSa flooding replication
simply spf calculation
Network type compatibilities
network types that use type 2 lsa
broadcast
non broadcast
network types that do not use type 2 lsa
point to point
point to multipoint
point to multipoint non broadcast
broadcast
default on multi access broadcast medias
ethernet
token ring
sends hellos and updates as multicast
224.0.0.5 all spf routers
224.0.0.6 all dr routers
uses dr and bdr
uses type 2 lsa
nonbroadcast
ip ospf network non broadcast
default on mulitpoint NBMA medias
frame relay and atm
sends hellos as unicast
manually defined addresses with neighbor command
performs dr/bdr election
users type 2 lsa
dr/bdr operation
dr
used on broadcast/non broadcast links
forms adjacency with all routers on the link
listens for LSUs on 224.0.0.6
minimizes adjacencies
minimizes lsa replication
receives hellos, then sends updates on 224.0.0.5
does not modify next hop value
technically the DR can be the router you are on, OSPF (like IS-IS)
treats the DR as a separate pseudonode,
which it must consult before computing SPF
 Therefore, the router must ask the DR who it is adjacent with and
what its cost calculation is to its adjacent neighbors.
bdr
used for redundancy of dr
does not re flood LSUs
drothers
all other routers on the link
not the dr or bdr
form full adjacencies with dr and bdr
stop at 2 way adjacency with each other
dr/bdr chosen through election process
dr/bdr election process
election basen on the following
priority
0-255
higher the better
0=never
router id
highest loopback/interface IP
can be statically set
higher better
uses WAIT timer to stop pre emption of current dr/bdr
unlike ISIS DIS
an order of operations can preset the DR, if you want a specific
router to be the dr
you need to have the priority set to not elect a router dr/bdr
if the hellos are sent before other routers send the first router
will be dr
if there isn't full layer 2 connectivity, lsa replication will
only happen between directly connected neighbors
when ospf sends an update to it's neighbor, only that neighbor
gets it, mulitcast and unicasts for ospf have a TTL of 1
broadcast is sending updates as multicasts to 224.0.0.6 and
224.0.0.5
non broadcast is sending updates unicasts
point to point
ip ospf network point to point
default on point to point medias
hdlc/ppp
sends hellos as multicasts
224.0.0.5
no dr/bdr election
supports only two neighbors on the link
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
point to multipoint
treat network as a collection of P2P links
sends hellos as multicast
224.0.0.5
No dr/bdr election
special next hop processing
the next-hop value is updated to the interface IP address of the
hub
usually the best design option for partial mesh nbma networks
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
point to multipoint non broadcast
ip ospf network point to multipoint non broadcast
same as point to multipoint but sends hellos as unicast
manually defined addresses with neighbor command
allow for per vc ospf cost over nbma
 no dr/bdr election
special next hop processing
the next-hop value is updated to the interface IP address of the
hub
loopback
special case for loopback and looped back interfaces
advertises link as /32 stub host route
ip ospf network point to point use to disable this behavior

Virtual Links
Discontiguous area problems
SPF not run to reach an ABRs advertised inter area routes
use the intra area SPT to the ABR
add the ABRs cost to my SPT cost
What if the ABR isn't reachable via an SPT
certain states cause ABRs to be unreachable
These state are called discontiguous areas or discontiguous area 0
Repairing discontiguous areas
Broken designs are fixed by adding new area 0 links and adjacencies
links could be either physical or virtual
GRE could be used
OSPF VL are a form of virtual area 0 adjacencies
OSPF Virtual links
how OSPF virtual links work
used to form multihop unicast area adjacency
follows the already built SPT between ABRs to heal the database
The cost is the cost through the SPT to the ABR to the target
destination
DNA, do not age bit is set, if the age of the LSA goes past 1800
seconds or 30 minutes a reflood won't occur
Path selection change
The OSPF State machine prefers
Intra area over Inter area routes
For external routes
Intra area external over an Inter area external
Transit capability
Normal operation has traffic go through the area 0 connection
VL is an adjacency that might be farther away to the ABR using
the SPT
Transit capability gives you the ability to use shorter paths to
the ABR if available rather than following the area 0 path
VL Caveats
endpoints must be reachable via a normal area
not stub area
transit area must not have filtering appled
LSA 3 filters, distribute lists
Inherits cost from SPT cost between endpoints
cost must be below 65535
Runs as a demand circuit
errors in config could be hidden until flooding occurs
VLs must be configured on ABRs, ABR is a router that borders 2 areas
ABRs are routers that have at least 1 link in area 0 and other
links in other non backbone areas
The RIDs are used to form the adjacency

Config
R1:
router ospf 1
 area 1 virtual-link 150.1.6.6

R6:
router ospf 1
area 1 virtual-link 150.1.1.1

Verification
If your primary path to reach an inter area route is through an
ABR, which it should be, goes down for some reason, you need to be able
to route around the failure if there is another path that can be
used.
One way to accomplish this goal is use a Virtual link to bridge
the gap over another area that may not be area 0, a non backbone area
can be used to form a virtual link to a router may be connected
to the now unreachable area and with the use of a VL, you could bridge
area 0 over the non backbone area to connect to the router that
may be connected to the unreachable area.
One key point is that the a VL needs an ABR, a router with at
least one link active in area 0, to connect itself to area 0 and bridge the
gap between area 0 and the non backbone area to the router that
may have connectivity to the unreachable area.
The VL is a unicast adjacency that utilizes the ABR to connect
area 0 with the other router in the non backbone area.
The first important point to note about the virtual-link is that
the neighbor value specified in the virtual-link syntax is the router-id
of the neighbor in the transit area.
This means that if for some reason the router-id changes (for
example, if a new higher Loopback interface is added) or the router-id
command is changed, the virtual-link will fail.
Additionally, the neighbors forming adjacency over the virtual-
link do not have to be directly connected; they simply need to know how
to recurse toward each other's LSA 1 advertisements.
This means that the traffic flow via the virtual-link should
naturally follow the Intra-Area SPF calculation between the routers’
LSA 1 advertisements.
The VL also runs as a demand circuit, meaning it doesn't send
hellos across the link.
The VL also suppresses periodic LSA refresh, the paranoid updates
that occur every 30 minutes by default. The only time an update is sent
is when there a change in the network topology that
requires and LSA update.
These are indicated by the demand circuit keyword and the
DoNotAge LSA allowed.
The cost value associated with the VL is the cost the VL endpoint
uses to reach the ABR. This is calculated via LSA 1 recursion.
If the VL is running over an network type broadcast, then a type
2 LSA lookup will be done to find out what the VL endpoint is connected to
and what the associated cost is to the neighbor.
Now that there is an ABR connecting to the previously unreachable
area, issue the show ip ospf border routers command and the new VL
endpoint should appear in the output.
If the previous ABR that failed is still active, you may see it
advertising type 3 LSAs but the age will increment and a type 1 LSA
recursion should fail.
If the previous ABR comes back up it will advertise Type 3 LSAs
back into area 0, the VL will still be preferred as it is advertising type 1
LSAs and it's an extension of area 0, there fore the VL intra
area connection will be preferred over the inter area connection to the ABR
even if the cost to the ABR is 1, intra area is preferred over
inter area in the OSPF stat machine process.

OSPF Demand Circuit

R9:
interface GigabitEthernet1.79
ip ospf demand-circuit

Per RFC 1793, Extending OSPF to Support Demand Circuits, “OSPF Hellos
and the refresh of OSPF routing information are suppressed on
demand circuits, allowing the underlying data-link connections to be
closed when not carrying application traffic.”
This feature allows low-speed and pay-per-use links, such as analog
dial and ISDN, to run OSPF without the need for periodic hellos and
LSA flooding. Periodic hellos are only suppressed for point-to-point
and point-to-multipoint OSPF network types.
This feature is enabled with the interface-level command ip ospf
demand-circuit and is negotiated as part of the neighbor adjacency
establishment, thus only one OSPF router on the segmment requires to
have the feature enabled.
If routers on the segment do not support it, it will just ignore the
option inthe HELLO packet, but OSPF neighbors will still be established

When a link is configured as a demand circuit, the do not age lsa is

allowed, if the suppress hello for neighbors is zero, the network type is
broadcast, this indicates that periodic hellos are still sent and the
paranoid flooding of LSAs is disabled.
Normally, when an LSA reaches an age of 30 minutes, it must be re-
flooded, regardless of whether the network is stable and has not changed.
To verify that LSA flooding is stopped, note that advertising router
generated LSAs over the configured link have the DNA bit set.
This is not visible in the advertising routers OSPF database however,
as it may have other OSPF adjacencies with this feature not-configured,
thus the DNA bit is set only when LSAs are sent over links configured
as demand circuits
In order to suppress HELLO packets, let's change the OSPF network type.

The lack of periodic hello exchange will be visible also in the show ip
ospf neighbor output, where the Dead Time field for the adjacency is null

OSPF Flooding Reduction

R5:
interface GigabitEthernet1.58
ip ospf flood-reduction

Per RFC 2328, OSPF Version 2, “an LSA's LS age is never incremented
past the value MaxAge." When the Link State Age reaches MaxAge,
"the router must attempt to flush the LSA... by reflooding the MaxAge
LSA just as if it was a newly originated LSA".
In Cisco’s IOS implementation of OSPF, the MaxAge value is 3600
seconds, or 60 minutes.
To ensure the an LSA is not aged out, which means it will be flushed
from the OSPF database, each LSA is reflooded after 30 minutes,
regardless of whether the topology is stable or not. This periodic
flooding behavior is commonly referred to as the “paranoid update.”
The ip ospf flood-reduction feature stops unnecessary LSA flooding by
setting the DoNotAge (DNA) bit in the LSA,
removing the requirement for the periodic refresh. This needs to be
enabled on links with OSPF neighbors attached, as on the other links,
as there are no neighbors, no LSAs are sent anyways
Path selection
once databases are synchronized, path selection begins
each router lsas include a cost attribute for each described link
best path to that link is lowest end to end cost
cisco implementation uses bandwidth based cost, but per rfc it is arbitrary
default cisco cost = 100Mbps / link bandwidth
reference bandwidth can be modified to accomodate higher speed links
Per RFC, ospf path selection state machine
intra area routes
inter area routes
external type 1
external type 2
nssa type 1
nssa type 2
cannot be modified with metric or distance
ospf uses bandwidth based cost
cost = reference-bw / interface bw
cost can be modified with
interface bandwidth
interface ip ospf cost
used for traffic engineering on a per hop basis
it effects outgoing traffic
process auto cost
is reference bandwidth
needs to be configured on all routers
process neighbor x.x.x.x cost - point to multipoint neighbors
Modifying the cost effects other things like QoS
Auto cost reference bandwidth does not need to match for neighbors to form
adjacency, but if there are differences throughout the topology
it is possible for loops to occur by varying cost.

router ospf 1
auto-cost reference-bandwidth 30000

This means that a 100Mbps Fast Ethernet interface will have a cost of
1, and furthermore all interfaces with higher bandwidth values
are also 1.
The result of this is that OSPF routers in the topology cannot make an
accurate path calculation when comparing an OC-48 POS interface
to a Gigabit Ethernet interface, because both interfaces revert
to a cost of 1.
To resolve this, the reference bandwidth value is typically modified to
allow these higher-bandwidth interfaces to have separate,
more granular cost values

Path Selection with Cost

R4:
interface GigabitEthernet1.146
ip ospf cost 2

R5:
interface GigabitEthernet1.45
ip ospf cost 1001

SPF calculations are only performed for Intra-Area routing, whereas the
Area Border Routers’ (ABRs)
advertised information is trusted for Inter-Area and External
calculations.

The idea is to modify the traffic flow so that packets coming from a
particular source are routed to a specific destination a certain way.
It is important to understand how OSPF will route traffic by it's
default SPF algorithm and default calculation, then we can modify to see the
results.
Starting from the source, note the direction that traffic will be
forwarded. If the route is intra area, by looking at the "from" part of the
show ip route x.x.x.x will determine how the route will be
forwarded.

Intra area forwarding, all routers are in the same area, therefore have
identical copies of the LSDB.
By entering a show ip ospf database router x.x.x.x for intra area LSAs
will indicate where you need to forward it to, the advertising router
field in the LSDB output is the key indicator as to who
originated it.
If the Routing bit is set, then you know that SPF was able to solve the
SPT to the originating router
Routing Bit Set on this LSA in topology Base with MTID 0
The nice thing about a singe area, the LSDBs are the same, anywhere
there are 2 or more interfaces to choose a path on is a TE point.

Inter area forwarding, the common point of attachment, the area border
router, is the router that would advertise the Type 3 LSA into the area
The important point to remember with this is the advertising
router will be the ABR.
If you look in the LSDB for the Type 3 LSA, the summary network, and
the routing bit is set, you can successfully solve the SPT to the ABR.
If you look on the ABR, the LSA that it was advertising, the Type
1 LSA, the router LSA, if the routing bit is set on the ABR for the area
that originated the route, you can solve the SPT to the router
that originated the route.
The metric value indicated in the ospf database output is the metric to
reach the ABR advertising the route.
The ABR is where you would make your path selection changes. Depending
on which was you choose to have the traffic go would determine which interface
gets the change done to it.

Path Selection with Bandwidth

R1:
interface Tunnel0
bandwidth 100000

R4:
interface GigabitEthernet1.45
bandwidth 10000

Bandwidth is the one and only calculation metric OSPF uses, it directly
relates a cost to a bandwidth value. If you modify the bandwidth for
a given interface, this will affect the cost used to reach
destinations on that given interface. Sometimes not using it at all after the
change
Before modifying anything, determine how OSPF will forward traffic to a
given destination without modifying anything.
Once you know how OSPF will forward traffic, you can then determine on
what router(s) the change needs to occur on and what interface(s) you need to
make the change on.
The reason we may need to modify 2 or more routers is because you may
be learning information multiple points in the network. If you are trying to reach
an inter area destination, you will choose, by default an intra
area route first as intra area is preferred over inter area regardless of
the cost or metric.
The idea is to find out how you route after you make your first
change, is it the way you need to route traffic?
If not, from the place you made the change, see how the routing
decision is made and based on traffic forwarding need, make the determination
where you need to make the next change. Once you have
determined and made the change, verify this is correct.

Path Selection with Per-Neighbor Cost

R5:
router ospf 1
neighbor 155.1.0.1 cost 50
neighbor 155.1.0.4 cost 40

OSPF cost calculation for a segment is based on the bandwidth value of

the outgoing interface. In certain network topologies, this can be
an issue if the underlying layer 2 network does not map directly
to the bandwidth value of the interface connecting to it.
This is true of DMVPN networks where the physical interface has a set
bandwidth of X, the individual VPNs themselves may not be provisioned
at this rate.
The bandwidth can be changed per interface or per sub-interface but
that will affect all the VPNs.
To have different OSPF cost per neighbor, the network type’s point-to-
multipoint and point-to-multipoint non-broadcast support the
setting of the OSPF cost value on a per-neighbor basis.
Use the ip ospf database self-orginate command to see what the cost
will be for each prefix.
After you use the neighbor x.x.x.x cost x, re issue the ip ospf
database self-originate command to see the new cost per config'd prefix.

Path Selection with Non-Backbone Transit Areas

R1:
router ospf 1
area 1 virtual-link 150.1.6.6
no capability transit

R6:
router ospf 1
area 1 virtual-link 150.1.1.1
no capability transit

Capability transit
OSPF area capability transit is enabled by default, allowing the OSPF
Area Border Router to install better-cost
routes to the backbone area through the transit area instead of the
virtual links. If you want to retain a traffic
pattern through the virtual-link path, you can disable capability
transit by entering the no capability transit
command. If paths through the transit area are discovered, they are
most likely to be more optimal paths, or
at least equal to, the virtual-link path.
 Basically, if a router connected via a VL to an ABR that connects to
area 0 to reach a particular destination, If that same router
connected via a VL has a better cost path over a non backbone
connection, this is not the desired way to forward.
The desired path is to use the area 0 path, through the backbone area
to reach the destination.
Technically, the router connected via the VL is connected via a virtual
connection over a non backbone area to reach an ABR that is
connected to the back bone area that maybe a higher cost path.
Normal OSPF selection is to use the O, intra area path. But since the
design is broken, the router connected via the VL can choose the
path to the ABR that is not the VL.
The no capability transit command forces the path selection process to
use the VL to route towards area 0 to reach the destination.

Path selection with VLs

R2:
interface Loopback100
ip address 150.1.22.22 255.255.255.255
ip ospf 1 area 22
!
router ospf 1
area 5 virtual-link 150.1.3.3

R3:
router ospf 1
area 5 virtual-link 150.1.2.2
default path for the traffic, which will follows OSPF design rules,
thus for inter-area traffic we cannot transit a non-backbone area
Basically what happens is the reverse path back to the backbone area
using a VL
If traffic is coming from a discontiguous area and needs to reach a
destination it would by default need to route to an ABR that connects to
the backbone area, this may not be the optimal way to route the
traffic.
By using a VL you are connecting the backbone area over a non backbone
area in order to reach a discontiguous area, by using the VL this gives
you the ability to use the correct forwarding design, the backbone to
reach the destination.

Convergence timers
convergence based on hello and dead timer
supports sub second timers
different timer for different network types
sho ip ospf interface
changing hello time automatically adjusts the dead timers
ip ospf hello interval
ip ospf dead interval
bidirectional forwarding detection
acts as a keepalive that will detect a neighbor down by monitoring the
layer 2

OSPF Update Packet-Pacing Configurable Timers

Functionality of the OSPF Update Packet-Pacing Timers
In rare situations, you might need to change Open Shortest Path First
(OSPF) packet-pacing default timers to
mitigate CPU or buffer utilization issues associated with flooding very
large numbers of link-state
 advertisements (LSAs). The OSPF Update Packet-Pacing Configurable
Timers feature allows you to configure
the rate at which OSPF LSA flood pacing, retransmission pacing, and
group pacing updates occur.

Configuring OSPF flood pacing timers allows you to control interpacket

spacing between consecutive link-state
update packets in the OSPF transmission queue. Configuring OSPF
retransmission pacing timers allows you
to control interpacket spacing between consecutive link-state update
packets in the OSPF retransmission
queue. Cisco IOS software groups the periodic refresh of LSAs to
improve the LSA packing density for the
refreshes in large topologies. The group timer controls the interval
used for group LSA refreshment; however,
this timer does not change the frequency that individual LSAs are
refreshed (the default refresh occurs every
30 minutes).

Configuring OSPF Packet-Pacing Timers

SUMMARY STEPS
1. Router(config)# router ospf process-id
2. Router(config-router)# timers pacing flood milliseconds

Configuring a Group Packet Pacing Timer

SUMMARY STEPS
To configure a retransmission packet pacing timer, use the
following commands beginning in router
configuration mode:
1. Router(config)# router ospf process-id
2. Router(config-router)# timers pacing lsa-group seconds

OSPF Retransmissions Limit

Feature Overview
Cisco IOS Release 12.2(4)T added a limit to the number of
retransmissions of database exchange and update
packets for both demand and non-demand circuits. The retransmission of
these packets stops once this retry
limit is reached, thus preventing unnecessary use of the link in
continual retransmission of the packets if, for
some reason, a neighbor is not responding during adjacency forming.
The limit for both demand circuit and non-demand circuit
retransmissions is 24.

The limit-retransmissions command allows you to either remove (disable)

the limit or change the maximum
number of retransmissions to be a number from 1 to 255.

Benefits
The limit-retransmissions command provides for backward compatibility
for previous or other releases of
Cisco IOS or other routers that do not have this feature.

Setting OSPF Retransmission Limits

SUMMARY STEPS
1. Router(config)# router ospfprocess-id
2. Router(config-router)# limit retransmissions{[dc {max-
number | disable}] [non-dc {max-number |
disable}]}
 OSPF Flooding
You already know that OSPF's basic unit of topological information
comprising its link state database is an LSA. OSPF uses an Update packet
to send LSAs from one router to another during the flooding process.
Whereas LSAs are flooded throughout an area, Update packets are exchanged
only between directly connected routers. That is, their scope is the
local link. If an LSA received in an Update packet must be forwarded to
another router, it is put into a new Update packet for the next hop.
This is in keeping with the fact that none of the five OSPF message types
are forwarded beyond the local link.

the Update (OSPF message type 4) payload is one or more LSAs, preceded
by a field specifying how many LSAs are contained in the packet. Any one of the
following events causes a router to send an LSA to one or more
neighbors:

A new, previously unknown LSA is received from a neighbor.

A more recent copy (determined by the LSA age and/or sequence number)
of a known LSA is received from a neighbor.
The refresh timer associated with a locally originated LSA expires.
An adjacency or link changes state.
The metric associated with a link or reachable address changes.
The router's RID changes.
The router is elected or removed as DR.
The AID associated with one of the router's interfaces changes.
A Link State Request message is received from a neighbor asking for a
copy of a known LSA.

The first three events are a part of routine maintenance of the link
state database
The fourth event is the normal routing protocol procedure of
communicating network information.
The last event, sending an LSA in response to a Link State Request
message, is part of the database synchronization process

The manner in which the Update is sent depends on the type of network
link over which it is transmitted:

If the OSPF network type is a point-to-point, point-to-multipoint, or

virtual link, the Update packet is unicast to the neighbor.
If the OSPF network type is broadcast, and the OSPF interface state is
DROther or Backup, the Update is sent to the multicast destination
address AllDRouters (224.0.0.6). If the OSPF interface state is DR, the
Update is sent to the multicast destination address AllSPFRouters (
224.0.0.5). Using these multicast addresses enforces the designated
router mechanism by ensuring that only the DR and BDR receive all LSAs
flooded on the link by a non-DR router, and that only the DR refloods
the LSA to the other routers on the link.
If the network type is NBMA, the designated router mechanism is still
observed, but the nonbroadcast nature of the network means that
non-DR routers must uni-cast their Updates to the DR. The DR then
unicasts its own Updates to all non-DR routers to complete the flooding
process on the NBMA network.

Acknowledgment of LSAs
Whenever an Update message is sent, the LSAs it contains must be
acknowledged by the receiving neighbors to ensure reliable flooding.
 So when a router floods an LSA on a link, it adds the LSA to a
retransmit list and sets a retransmit timer. Every time the retransmit timer
expires, the router retransmits the LSA. When the LSA is
acknowledged, it is removed from the retransmit list. The retransmit timer is
configurable to between 1 and 65,535 seconds, with a typical
default of 5 seconds. This is a long enough interval that on normal networks
an LSA should almost always be acknowledged and removed from the
retransmit list before the retransmit timer expires. A good OSPF
implementation might also include a mechanism for "windowing" the
retransmission rate so as not to overwhelm a slow neighbor, and a
mechanism for handling a case where a neighbor never acknowledges
an LSA, such as removing the LSA from the retransmit list and logging a
flooding error message.

If an LSA is flooded on a broadcast link, and all the neighbors

except one acknowledge the LSA, you do not want to retransmit the LSA to
every neighbor. Rather, you want to retransmit only to the
neighbor that did not acknowledge its receipt. Therefore Update messages
carrying retransmitted LSAs are always unicast, regardless of the
network type.

There are two things to know about the way OSPF acknowledges the
receipt of an LSA:
The acknowledgment can be explicit or implicit.
The acknowledgment can be delayed or direct.

An explicit acknowledgment of an LSA is accomplished by sending

an OSPF Acknowledgment message to the neighbor that sent the Update.
The Acknowledgment message carries the headers of one or more
LSAs.
The LSA header contains all the information needed to acknowledge
a specific LSA and a specific instance of that LSA.

An implicit acknowledgment occurs when a router that sent an LSA

to a neighbor receives an Update from that same neighbor, containing the
same instance of the same LSA. In this situation the router knows
the neighbor has a copy of the LSA, and removes the LSA from its
retransmit list just as it would if an explicit acknowledgment
had been made. Implicit acknowledgments are most likely to occur during
the database synchronization process when Update packets are
being sent between neighbors simultaneously, or during flooding where two
neighbors each receive a copy of the LSA from other neighbors and
then send Updates to each other more or less simultaneously.

A delayed acknowledgment means that an OSPF router waits some

specified amount of time before sending an Acknowledgment message.
There are several benefits to delaying an acknowledgment:

It allows for more LSAs to be included in a single

acknowledgment, reducing the amount of acknowledgment traffic on a link and
protocol message processing on the routers.

On broadcast networks, a single Acknowledge message can

acknowledge LSAs to multiple attached routers by multicasting the message.

On multi-access networks where several routers might be trying to

send acknowledgments at the same time, delaying helps randomize the
transmission of the messages.
 If an acknowledgment is delayed too long, however, the neighbor's
retransmit timer will expire and retransmits will occur unnecessarily.
Therefore, the acknowledgment delay should be less than the
typical retransmit period.

A direct acknowledgment means an LSA is acknowledged immediately

upon receipt, and the Acknowledgment packet is unicast directly
to the sender. Delayed acknowledgments are preferred, but there
are two cases in which a direct acknowledgment must be sent as soon as
an LSA is received:

A duplicate LSA is received from a neighbor. Although there might

be other causes for this happening, it must be assumed that the
neighbor retransmitted the LSA because its retransmission timer
expired.

A router somewhere in the area wants to flush a self-originated

LSA from the link state databases. It sends the LSA with its Age
field set to the maximum value (3,600 seconds). Routers receiving
such an "aged-out" LSA acknowledge it directly.

The LSA Header Format

An Acknowledgment message carries just the LSA header, rather
than the entire LSA, because everything needed to completely identify
an LSA is in the header. All OSPF LSAs use the same header format
The Type, Link State ID, and Advertising Router fields together
identify a specific LSA. The Age, Sequence Number, and Checksum
fields together identify a specific instance of that LSA, so that
when multiple instances exist in a network the most recent can be
determined. The Length field specifies the length, including the
header length, of the LSA.

Options is a set of flags indicating optional capabilities of the

originating router.
This is the same Options field carried in OSPF Hello messages

Type specifies the type of LSA

Common OSPFv2 LSA Types
Type Number LSA
1 Router LSA
2 Network LSA
3 Network Summary LSA
4 ASBR Summary LSA
5 AS External LSA
6 Group Membership LSA
7 NSSA External LSA
8 External Attributes LSA
9 Opaque LSA (link-local scope)
10 Opaque LSA (area-local scope)
11 Opaque LSA (AS scope)

The Link State ID field of the LSA header is a 32-bit field that
carries some IP address by which the LSA is identified.
The derivation of this IP address varies from one LSA type to
another

Link State IDs for Individual OSPFv2 LSA Types

Type Number LSA Link
State ID
 1 Router LSA
Originating router's RID
2 Network LSA
IP interface address of the network's DR
3 Network Summary LSA
Destination network's IP address
4 ASBR Summary LSA RID of
the described AS boundary router
5 AS-External LSA
Destination network's IP address
6 Group Membership LSA
Destination multicast group address
7 NSSA External LSA
Destination network's IP address
8 External Attributes LSA
Encoded BGP path attributes
9 Opaque LSA (link-local scope) 8-bit
opaque type + 24-bit opaque ID
10 Opaque LSA (area-local scope) 8-bit
opaque type + 24-bit Opaque ID
11 Opaque LSA (AS scope) 8-bit
opaque type + 24-bit Opaque ID

Advertising Router is always the RID of the router that

originated the LSA.

Sequence Number is a signed 32-bit integer. OSPF uses a linear

sequence number. When a router first originates an LSA,
it sets the value of the Sequence Number field to 0x80000001,
which is the OSPF constant InitialSequenceNumber. The router then
increments the sequence number for each subsequent instance of
the LSA it originates, up to a maximum value of 0x7fffffff. When a
new instance of an LSA is to be originated, and the existing LSA
has this maximum sequence number, the existing LSA must be flushed
from the databases through premature aging. The new LSA can be
flooded as soon as all adjacent neighbors have acknowledged the aged-out
LSA.

There is a situation in which the sequence number needs to be

incremented by more than 1. After an OSPF router restarts, it might
find that there are LSAs still in the area databases that it
originated before the restart. If the router wants to keep a previously
originated LSA in the databases, it sets the sequence number of
the LSA to one more than the existing number and refloods the LSA.

Checksum is a 16-bit IP-style checksum calculated over the entire

LSA except for the Age field, to ensure that the LSA is not
corrupted during flooding. The age is not included, because if it
were, the checksum would have to be recalculated every time the
age changed. In addition to being checked by every receiving
router before the LSA is placed into the link state database, the
checksum is revalidated every five minutes as the LSA resides in
the database.

Age indicates the age of the LSA in seconds. It is an unsigned

16-bit integer, and can range from 0 to 3,600 seconds (1 hour).
Every OSPF interface data structure has a parameter called
InfTransDelay, which is configurable in most OSPF implementations but
typically defaults to 1 second. When a router originates an LSA,
it sets the value of the Age field to 0. Every time a router floods
the LSA, it increments the age by the InfTransDelay value of the
interface out which the LSA is flooded. The age is also incremented
as the LSA resides in the link state database. The upper limit of
3,600, which is an OSPF constant called MaxAge, signifies that the
LSA is expired and is no longer valid. What this tells you is
that the router which originated the LSA must refresh itthat is, flood
a new copy of the LSAon some periodic basis less than 3,600
seconds. For OSPF, this refresh period (LSRefreshTime) is half of the
MaxAge, or 1,800 seconds (30 minutes).

The age is also used when a router wants to flush a self-

originated LSA from the area databases. It does this by prematurely
"aging out" the LSAthat is, setting the age of the LSA to MaxAge
and then flooding the LSA. Receiving routers, seeing the MaxAge
value, do a direct acknowledgment and immediately reflood the
LSA.

Multiple Copies of an LSA

As a single instance of an LSA is flooded throughout an area, a
router might receive multiple copies of the LSA with different age values.
After an LSA is received by R1, it is replicated and flooded to
two neighbors. The two copies of the LSA both reach R5; because there
are a different number of router hops along the two paths,
however, the age is incremented differently. As a result, the two copies
of the LSA have the same sequence number but different ages.
Assuming the router has already accepted one of the copies, it would be
inefficient for it to assume incorrectly that the second copy is
newer. To remedy such a situation, OSPF defines a constant called
MaxAgeDiff, which is 15 minutes. If two copies of an LSA have
ages that differ by less than MaxAgeDiff, but are otherwise identical,
they are assumed to be the same instance.

When multiple LSAs are received with identical Type, Link State
ID, and Advertising Router values, the Age, Sequence Number, and
Checksum fields of the LSAs are compared to determine which of
the LSAs is the most recentand hence, the one that should be accepted.
The steps for comparing these three fields is as follows:

1. The LSA with the newer sequence number is more recent.

2. If the sequence numbers are the same, but the checksums
differ, the LSA with the larger checksum is more recent.
3. If the sequence numbers and checksums are the same, and only
one LSA has an age of MaxAge, that LSA is more recent.
4. If the sequence numbers and checksums are the same and
neither age is MaxAge, and the ages differ by more than MaxAgeDiff,
the LSA with the lower age is more recent.
5. If the sequence numbers and checksums are the same and
neither age is MaxAge, and the ages differ by less than MaxAgeDiff,
the LSAs are considered identical.

Limitations on OSPF Flooding

When an LSA is received, its checksum indicates that it is valid,
and the LSA is either new or a more recent instance of a
known LSA, the router must determine which interfaces the LSA
must be flooded out. Essentially, the LSA is flooded out the same
interface from which it was received only if the connected
network is broadcast or NBMA and the router is the DR. Otherwise, the
LSA is not sent on the same interface from which it was received.
Another limitation on flooding is the area to which the interface
belongs. If the scope of the LSA type is limited to a single
area, it is not flooded out interfaces belonging to a different area
from the area of the interface from which it was received. With
these rules, the flooding of the LSA will, even in complex
topologies, end when the LSA has reached all routers within the
flooding scope.

OSPF Areas and Router Types

In basic OSPF area structure, with lower-level areas attached to
a single upper-level area. OSPF calls the upper-level area the
backbone area, and this area is always identified by the AID
0.0.0.0 (or just area 0). Nonbackbone areas can have any 32-bit
identifier except 0.0.0.0. Architecturally, area borders are
defined by the routers that connect areas called, logically enough,
area border routers (ABRs). A router becomes an ABR, and an area
border is created, when at least one of its interfaces is connected
to a different area than at least one other interface. That is,
an OPSF router is not an ABR if all of its interfaces connect
to the same area. At least one of the ABR interfaces must connect
to the backbone area. This enforces the rule that traffic
between two nonbackbone areas cannot transit a third nonbackbone
area.

In any network design, two general principles will always serve

you well: (1) Always have a backup, and (2) get the most out of what
you have.

ABRs can adhere to those principles: (1) An area can be connected

to the backbone by more than one ABR, and (2) a single ABR can
connect more than one area to the backbone.

Some IP networks are completely self-contained and never speak to

the "outside world." OSPF serves such a network just fine.
But the great majority of networks need connectivity outside
their own IGP domainwhether to the worldwide Internet or just to
another private routing domain. When such connectivity is
necessary, external routesroutes to destination prefixes outside of the
local domainmust be advertised into the domain. This might be a
single default route or it might be a subset of the global Internet
routing table.[6] The route might be learned from another routing
protocol, or it might be a statically configured route. The routers
that advertise external prefixes into an OSPF domain are called
autonomous system boundary routers (ASBRs). ASBR can be located
anywhere within an OSPF domain. An ASBR can be in the backbone
area or in a nonbackbone area,[7] and an ABR can also be an ASBR.

OSPF Metrics
RFC 2328 and its predecessors do not specify or suggest a default
interface cost for OSPF, other than that it must be greater than 0.
That leaves the potential for implementations to vary widely in
their default value. Fortunately, many vendors have copied Cisco
Systems' method for determining default costs, thereby creating a
reasonable consistency across vendors.

This method, rather than having a single default for all

interfaces, calculates the cost by dividing 100Mbps by the interface bandwidth.
So, for example, a 10Mbps Ethernet interface will have a cost of
100/10 = 10, and a 56kbps link will have a cost of
 100000/56 = 1,785 (fractional values are ignored). This 100Mbps
constant is called the reference bandwidth.

The problem with the costing algorithm is that it was invented in

the days when 100Mbps was a very high-bandwidth link.
Any interface bandwidth of 100Mbps yields a cost of 1, the lowest
cost possible. When a bandwidth greater than 100Mbps is used,
the result of this calculation is rounded up to 1. But modern
large-scale networks routinely use links with greater bandwidth,
and even in smaller networks it is not unusual to find 1G
Ethernet links. To compensate for the realities of modern networks,
the reference bandwidth is configurable to a higher value.

You can set the interface manually rather than use the automatic
costing algorithm. If your network is large, it is usually wise
to develop a well thought-out costing plan that realistically
reflects your ideas about traffic behavior, and use this plan to
administratively assign interface costs. Manually assigned costs
might be based, for example, on line-of-sight or wire/fiber
distance between sites.

The metric assigned to prefixes within an area is 16 bits long.

Prefixes that are outside of an area either somewhere else within
the OSPF domain or external to the OSPF domain are given a 24-bit
metric when they are advertised into the area. The rationale for
this is that the path to an external destination is likely to be
longer, and therefore of a higher cost, and can require a larger
size metric.

When an external prefix is advertised into the OSPF domain, there

can be no assumption that any metric externally assigned to it
will be meaningful to OSPF. So the prefix is assigned a metric by
the ASBR that advertises it into the domain. This metric assignment
is specified as a part of the routing policy configuration on the
ASBR that redistributes the prefix.

The metric assigned to external prefixes can be one of two types:

Type 1 External (E1) metrics take into account both the cost
assigned by the ASBR and the cost to the ASBR.

Type 2 External (E2) metrics remain just the cost assigned by the
ASBR, and do not change as the prefix is advertised through the
OSPF domain.

The availability of these two external metric types gives you

flexibility in choosing how to reach external destinations. If you
always want to choose the closest exit out of the OSPF domain,
use E1. However, in most cases, choosing the ASBR that is "closest"
to the external destination is more important, either for
financial or performance reasons. In this case, E2 metrics are used.

E1 and E2 metrics can both exist in an OSPF domain, and can even
be assigned to the same prefix by different ASBRs. Therefore,
there are two rules for managing conflicts:

If one ASBR advertises a prefix with an E1 metric and another

ASBR advertises the same prefix with an E2 metric,
the E1 metric takes precedence.
 If two ASBRs advertise the same prefix with the same E2 cost, the
cost of the internal paths to the ASBRs is considered and
the route through the lowest-cost ASBR is chosen.

Stub areas
Scaling ospf is a function of two variables
how complex is the topology graph?
how many routers are in the area
large flooding domain means lots of spf runs
how much reachability information is there
how many routers are being advertised
large routing tables means it takes longer to flood
scalability through reducing the two above

Topology vs NLRI summarization

topology summarization achieved through OSPF areas
hide the details of how the graph looks in other areas
only run spf for intra area destinations
areas dont hide reachability information
NLRI summarization reduces the number of routes
take multiple longer match prefixes and combine them into smaller
shorter matches
ospf summarization is implemented two ways
per prefix summarization
two routes of 10.0.0.0/16 can become a single 10.0.0.0/15
per lsa summarization
remove all inter area routes and replace them with the
shortest match possible, a default route
this is what stub areas do

How Stubs work

filtering is enforced at a common transit point if the ospf topology
the abr
ABR controls which lsas enter the area
type 3/4 and or5 are filtered depending on the stub type
Reachability information removed and is then replaced with a default route
still allows reachbility to removed routes, in most cases
all routers in the area must agree on the stub flag
part of the adjacency negotiation

Stub area types

four stub area types control which routes, lsas can enter the area
stub area
stops external routes, type 5 lsas
totally stubby areas
stops inter area and external routes, type 3 and/or 4 and
type 5
not so stubby areas
stops external routes but allows local redistribution, type
7 at asbr, type 5 at ABR
not so totally stubby area
stops inter area and external routes, but allows local
redistribution

Stub area logic

 i know how to get to my abr
my abr knows how to get to the asbrs
the asbrs knows how to get to the external routes
if I default to the abr, I don't need to the specific external
routes
stub area result
abr removes lsas 4 and 5
abr originates default route

Totally stubby area

i know how to get to my abr
my abr knows how to get to other areas and to the asbrs
the asbrs knows how to get to the external routes
if I default to the abr, I don't need to the specific external
routes
totally stubby area result
abr removes lsas 3/4/5
abr originates default route

NSSA logic
stub areas block external routes, but what if I need to
redistribute into the stub area
filter like a stub area, but make an exception for local
redistribution
NSSA result
redist router generates NSSA external, type 7
abr changes NSSA external into external in area 0
abr removes lsas 4 and 5
abr does not automatically originate default route

Hot potato routing

if the abr does not originate a default you can default to
external protocol in the NSSA
cold potato routing
send the packet to the core and forward it on it's best
path

Totally NSSA
totally stubby areas block inter area and external routes, but
what if you need to redist into the totally stub area
combine totally stubby and nssa behaviors
result
redist router generates nssa external, type 7
abr changes nssa external into external into area 0
abr removes lsa 3/4 and 5
abr originates a default route

Configuring stub areas

all routers in the non backbone area need to agree on the stub flag
the ABR is the one that controls the advertisement of the summary or not
area X stub is stubby area, all routers get this
area X stub no-summary is configured on the ABR, no Type 3 network
summary will be advertised
Only a default route will be advertised with the next hop IP of the ABR

Stubby Area
When an OSPF router redistributes a route into the domain, it
originates a Type-5 External LSA representing the route and its attributes.
Inside this LSA, the originating router sets the advertising router
field to its local router-id and, generally, the forward address field to
0.0.0.0.

When an OSPF router in the same area as the originator looks up the
Type-5 LSA, it looks at the forward address. If the forward address is set
to 0.0.0.0, it means that the traffic should be sent toward the
advertising router to reach the destination. To find out how to reach the
advertising router, the advertising router’s Type-1 Router LSA is
consulted, and intra-area SPF is performed. This is similar to inter-area
routing logic, because the router doing the lookup does not compute SPF
to the final destination, only the intermediary advertising router.
For external routing between areas, the logic is modified slightly.

When an Area Border Router receives a Type-5 External LSA from a device
in its own area and passes it into a different area, a Type-4 ASBR
Summary LSA is generated. The Type-4 LSA tells devices in the new area
how to forward toward the ASBR, which in turn tells them how to forward
toward the external route.

Totally Stubby Area

Recall that in the previous case for external routes we saw that every
Type-4 ASBR Summary LSA inside of area 3 always recursed back to the ABR,
because the ABR connects area 3 to area 0. By configuring area 3 as
stub, this information was replaced with a default route that recursed to the
ABR. The same connectivity resulted, but space was saved in the routing
table and OSPF database. The next logical step in further optimizing the
database is to summarize the redundant Type-3 Summary LSAs that
represent the inter-area routes. This is where configuring the area as totally
stubby can be advantageous.

Where a stub area optimizes the database by removing external routes

and replacing it with a default route, a totally stubby area will optimize
the database further by removing the inter-area and external routes,
replacing them both with a default route. This is accomplished by telling
the area border router not to inject Type-3 Summary Network LSAs from
area 0, hence the no-summary argument used in conjunction with the stub
command.

Note that only the ABR(s) connecting the stub area to area 0 need the
no-summary argument on the stub command, because they are the only devices
that are allowed to originate Type-3 LSAs. Although it won’t break the
OSPF design to add the command to other routers inside the totally stubby
area, it is technically incorrect to configure the option this way. As
long as all devices in the area agree on the stub flag in the first place,
it is the ABR’s duty to determine whether the area is totally stubby or
not.

Traffic engineering with Stub areas

longest match routing
use a leak map for more specific route
area default route
cost of the default route out
ECMP only works if the cost of the default route to the ABR is equal
You can modify the stubs default cost using the default cost arguement
Cost based TE
Raise the cost to the ABR
Raise the cost of the default the ABR advertises
Longest match based TE
using the no summary keyword issues just a default route, which
suppresses longer matches
not issuing the no summary keyword, you still receive the summary lsa,
type 3 which is a longer match than the default

Not so stubby area

The OSPF Not-So-Stubby Area (NSSA) Option, as defined in RFC 3101, extends
the functionality of a stub area to allow the
importing of a subset of external routes into the area.
Recall that with the stub area, Type-5 External LSA information is suppressed
from entering the database and
is replaced with a default route originated by the ABR(s).
Because all Type-5 LSAs are suppressed, this also implies that redistribution
cannot
occur within the area as well.

The OSPF NSSA option changes this behavior by allowing redistribution to

occur within the stub area,
while still blocking external routes from entering the area through the
ABR(s).
Specifically, this is implemented through the introduction of a new link-
state advertisement type, the Type-7 NSSA External LSA.

Routes that are redistributed directly into the NSSA are generated as Type-7
NSSA External LSAs.
Like Type-5 External LSAs, two subtypes of Type-7 NSSA External LSAs exist,
type 1 (N1) and type 2 (N2).
N1, similar to E1, considers the metric that the ASBR reports into the OSPF
domain along with the metric needed to reach the ABSR.
N2, similar to E2, separates the metric into the flat value that the ASBR
reports into
the OSPF domain, which is installed in the routing table, and the value
needed to reach the ASBR,
known as the forwarding metric.

When the Type-7 NSSA External LSA is received by the ABR and is moved into
area 0, the information contained in the
Type-7 LSA is translated to a normal Type-5 External LSA.
If multiple ABRs exist, only one of them performs the translation through an
election process, which is
discussed in depth in a later task.
In this fashion, OSPF devices outside of the NSSA do not know that the NSSA
exists, which is analogous
to how a Confederation works in BGP.

Pitfall
The other key difference between stub and NSSA areas is how default
routing works.
The stub area removes external LSAs and replaces them with a default
route.
The totally stubby area extends this by replacing external LSAs and
inter-area LSAs with a default route.
However, with the NSSA, a default route is not automatically originated
by the ABR.
This means that devices within the NSSA will have reachability
to their own area and to other areas, but not to destinations outside
of the OSPF domain

If you skip from type 3 lsa to type 5 lsa this means this is an intra area
external route
 you have solved the SPT to the ASBR which can be an ABR at the same
time

If the ASBR is in our area and the SPT is correct, the routing bit is set,
then we will use the cost the ASBR is advertising
to the external route
you would do this by looking at the ospf database external and the
route being advertised

If the ASBR is not in our area then we would have to recurse to a lsa 4
lookup which would recurse to an lsa 3 which would
recurse to the lsa 1

LSA 1 would follow the SPT to the LSA 3, ABR then the from the LSA 3 would
follow the SPT to the LSA 4 which would lead
to the external route

NSSA will advertise a type 7 lsa

If the NSSA external lsa has the forward address as non zero value,
this is the address that the rest of the OSPF domain will solve the SPT to
type 7 lsa is area local scope,
just to the ABRs in the area, when it hits an ABR, a 7 to 5 translation is
possible

Type 7 to 5 translation means the ABR is allowed to advertise the route to

the other area
If the forward address is the advertising router, the same address the ASBR
is telling the
area to solve the SPT to the ASBR, query lsa 1 this is an intra area external
lookup since the
forward address has a non zero value

The forward address is an actual route not a node identifier. This is the key
distinction when going from:
lsa 5 to 4 as opposed to lsa 5 to 3
lsa 4 is I have the short path to the node in the graph
lsa 3 is I have the actual route to the destination

NSSA does not by default advertise a default route, use the default-
information orginiate to do this,

Controlling NSSA redistribution

If you have an ABR that is redistributing connected links into ospf and
you advertise it into area 0 it gets advertised
as a type 5 lsa if the connected route is advertised into the NSSA then
it is advertised as a type 7 lsa
The ABR will advertise it into both the backbone and NSSA areas
Any other routers in the NSSA won't be able to translate it back into
the backbone unless you use the nssa only option
If you have two asbrs, one of them being an nssa asbr, and you
advertise the same route to both asbrs the router that
is not the nssa asbr will forward the traffic
Reason is the nssa external is an inter area external translating from
type 7 to 5 and the FA is the a type 3
recursion to get to the destination
the normal asbr external is an intra area external translating type 5
to a type 1 and the FA is the type 5
intra area lookup
 Default routing with NSSA
NSSA filters type 4 and 5 lsas
by using the nssa no summary you are withdrawing the type 3 lsas.
Instead a default route is advertised into the area to
reach the ABRthis is used to produce a totally no so stubby area
The ABR will advertise a default route to reach area 0 and the
ASBR will be able to redistribute routes into the NSSA
the default information originate this keeps the path selection as
intra area as the ABR
Default information originate advertises a default route into the NSSA
area but keeps all the inter area routes
allowing for longer match routing
nssa no-summary advertises a default route into the NSSA area but
removes all the inter area routes
this removes the Type 3 LSAs from the routing table, placing a
default route to the ABR/ASBR

OSPF NSSA Translator election and forwarding address

The P or propagate bit needs to be set in order to allow type 7 to 5
translation
You can remove the P bit by using the nssa only arguement with the
summary address and use the nssa only at the end of it
if the ABR is also an ASBR, if it is redistributing into area 0 and the
nssa it will remove the p bit because it doesn't
want someone else to do the translation of a route advertised
into area 0
The idea is if you have 2 routers advertising the ability to reach an
external destination use the forward address to be
the value for a decision used to forward traffic
The forward address is an actual route, this is not the router id or
node identifier
how do we route to reach the forward address advertising the
external route
The forward metric is what is used to determine how routing will
forward traffic to the ASBR
the nssa translate type 7 always
this forces a router to win the translator election
if the forward address is all zeros, route to the router that
advertised the route

OSPF Stub Router Advertisement Functionality

The OSPF Stub Router Advertisement feature allows you to bring a
new router into a network without
immediately routing traffic through the new router and allows you
to gracefully shut down or reload a router
without dropping packets that are destined for other networks.
This feature introduces three configuration
to calculate indentical short path tree everyone must have the
same input to spf, the lsdb
implies that filtering cannot be configured within an area
Allowing Routing Tables to Converge
Two configuration options introduced by the OSPF Stub Router
Advertisement feature allow you to bring a

new router into a network without immediately routing traffic through

the new router. These configuration
 options are useful because Interior Gateway Protocols (IGPs) converge
very quickly upon a router during
startup or after a reload, often before Border Gateway Protocol (BGP)
routing tables have completely converged.
If neighbor routers forward traffic through a router while that router
is building BGP routing tables, packets
that have been received for other destinations may be dropped.
Advertising a maximum metric during startup
will allow routing tables to converge before traffic that is destined
for other networks is sent through the
router. The following two configuration options enable a router to
advertise a maximum metric at startup:

• You can configure a timer to advertise a maximum metric

when the router is started or reloaded. When
this option is configured, the router will advertise a maximum
metric, which forces neighbor routers to
select alternate paths until the timer expires. When the timer
expires, the router will advertise accurate
(normal) metrics, and other routers will send traffic to this
router depending on the cost. The configurable
range of the timer is from 5 to 86,400 seconds.
• You can configure a router to advertise a maximum metric at
startup until BGP routing tables converge
or until the default timer expires (600 seconds). Once BGP
routing tables converge or the default timer
expires, the router will advertise accurate (normal) metrics and
other routers will send traffic to this
router, depending on the cost.

Configuring a Graceful Shutdown

The third configuration option introduced by the OSPF Stub Router
Advertisement feature allows you to
gracefully remove a router from the network by advertising a
maximum metric through all links, which allows
other routers to select alternate paths for transit traffic to
follow before the router is shut down. There are
many situations where you may need to remove a router from the
network. If a router is removed from a
network and neighbor routers cannot detect that the physical
interface is down, neighbors will need to wait
for dead timers to expire before the neighbors will remove the
adjacency and routing tables will reconverge.
This situation may occur when there is a switch between other
routers and the router that is shut down. Packets
may be dropped while the neighbor routing tables reconverge.

When this third option is configured, the router advertises a

maximum metric, which allows neighbor routers
to select alternate paths before the router is shut down. This
configuration option could also be used to remove
a router that is in a critical condition from the network without
affecting traffic that is destined for other
networks.
You should not save the running configuration of a router when it
is configured for a graceful shutdown
because the router will continue to advertise a maximum metric
after it is reloaded.
 Benefits of OSPF Stub Router Advertisement
Improved Stability and Availability
Advertising a maximum metric through all links at startup or
during a reload will prevent neighbor routers
from using a path through the router as a transit path, thereby
reducing the number of packets that are dropped
and improving the stability and availability of the network.

Graceful Removal from the Network

Advertising a maximum metric before shutdown allows other routers
to select alternate paths before the transit
path through a router becomes inaccessible.

Configuring Advertisement on Startup

SUMMARY STEPS
1. Router(config)# router ospf process-id
2. Router(config-router)# max-metric router-lsa on-startup
announce-time

Configuring Advertisement Until Routing Tables Converge

SUMMARY STEPS
1. Router(config)# router ospf process-id
2. Router(config-router)# max-metric router-lsa on-startup
wait-for-bgp

Configuring Advertisement for a Graceful Shutdown

SUMMARY STEPS
1. Router(config)# router ospf process-id
2. Router(config-router)# max-metric router-lsa
3. Router(config-router)# exit
4. Router(config)# exit
5. Router# show ip ospf

The OSPF ABR Type 3 LSA Filtering feature gives the administrator
improved control of route distribution
between OSPF areas.
Only type 3 LSAs that originate from an ABR are filtered.
Configuring OSPF ABR Type 3 LSA Filtering
SUMMARY STEPS
1. Router(config)# router ospf process-id
2. Router(config-router)# area area-id filter-list prefix
prefix-list-name in
3. Router(config-router)# exit
4. Router(config)# ip prefix-list list-name [seq seq-value]
deny | permit network/len [ge ge-value] [le le-value]

suppress forward address

zero's out the forward address and points to the router doing the
translation
area # nssa type7 translate suppress-fa

Authentication
supports adjacency authentication to protect control plane
prevent against routing injection attacks
OSPF packet header included authentication information
 hello, lsu, lsr
Authentication does not mean encryption
v2 payload is clear text
v3 supports ipsec encryption
1 hop IPsec tunnel with ESP or AH
ospf supports 3 types of authentication
0=null - no authentication
1=clear text - simple password
2=md5/sha
key of zero means no key is used
Enabled by
OSPF process level
Link level
link level overrides process level
key is always applied at the link level
key numbers must match on both ends
lowest active key used
can be enabled
if enabled under the process all links in the process are authenticated
if enabled under the interface only that link gets it
on all links in the area
on a per link basis
virtual links are area 0 interfaces
implies same inheritance rules of authentication just like other area 0
interfaces
key goes at the interface
type can be configured globally or at the interface
VL runs as a DC
always clear the VL after authentication

The way the crypto works is:

I have a password and I run the hashing algorithm and get the result
I do the same thing on the remote side
I send my hash to you and you compare it to yours, if they match then
forms the adjacency, they don't - dont form the adjacency
D.4.3 for reference

OSPF now uses key chains

allows for multiple enhancements
multiple keys
auto time based key rotation
single key chain for multiple interfaces
still backwards compatibile with interface level MD5
key numbers must still match

Null Authentication
By default this is the authentication, no authentication. Type 0 in the
debug output.

Clear Text Authentication

With clear text authentication the password is sent clear text in the
IP header for every packet. This means if you sniff the wire you'll
see the password. This is not the recommended authentication method to
use. The ability is still available because you may peer with older
routers with older IOS images that don't support newer features.
Remember that clear text authentication is type 1 authentication, in a debug
output the auth type field would be type 1
 MD5 Authentication
This is type 2 authentication. It uses a cryptographic algorithm to
take a clear text password and run it through a complex math equation to
produce a hash. This hash is what is sent across the wire to the
neighbor, who if configured with the same cleartext password that it to has
been run through the same complex math equation will produce the same
hash. If the received hash matches that of the local hash the
authentication passes.

MD5 Authentication with multiple keys

OSPF supports multiple MD5 keys applied to a single interface to allow
for key rotation. The normal application of this would be that all
neighbors are configured with key 1. Key 2 is then added on all
neighbors, and key 1 is removed afterwards. Because both keys are temporarily
sent (baiscally the sending router will duplicate all OSPF packets it
needs to send over the outgoing interface, sending the same packet
authenticated with each configured key), there is no loss of adjacency
while the old key is being removed. In this design, multiple keys are
used to authenticate different neighbors on the same interface.

SHA Authentication
Type 2 OSPF authentication was extended to offer support for HMAC-SHA
based authentication, and this is defined in RFC 5709.
Cisco implemented support for all variants of HMAC-SHA although per the
RFC, only HMAC-SHA-256 is mandatory.
HMAC-SHA-1 uses the first version of SHA, while all the other methods
use SHA-2, the second version of the function:
HMAC-SHA-1 (160 bits digest)
HMAC-SHA-256 (256 bits digest)
HMAC-SHA-384 (384 bits digest)
HMAC-SHA-512 (512 bits digest)
So far, IOS does not allow you to enable SHA authentication at the area
level, only at the interface level.
To configure SHA authentication, you first need to define the key ID
and key string by using a key-chain, jut like for RIP or EIGRP,
and afterwards apply the key-chain at the interface using command ip
ospf authentication key-chain <NAME>.
By using a key-chain, which allows defining several keys with specific
lifetimes, the whole process of key rotation becomes simpled and
more efficient, just like in EIGRP, as OSPF will always send OSPF
packets authenticated with the first valid key from the key-chain, but
received OSPF packets will be matched against all valid configured
keys.

With the current IOS code, SHA authentication is not supported for
virtual-links. In case of a mismatch between key ID, key string or
authentication type, the debug messages are identical with the case
when using MD5 authentication. With the addition of SHA to Type 2
authentication, this is now called a "Cryptographic Authentication" for
both MD5 and SHA, which is also visible from the outputs

Pitfall for authentication

Remember that a virtual-link is an interface in area 0. This means that
if the area 0 authentication [message-digest] command is enabled,
authentication is also enabled on the virtual-link. If MD5
authentication is enabled on the virtual-link with the area 0 authentication
message-digest command, the password must still be assigned on the
virtual-link interface itself with the area <NR> virtual-link <RID>
message-digest-key <NR> md5 <STRING> command. Alternatively,
authentication can be enabled at the virtual-link interface level with the area
<NR> virtual-link <RID> authentication message-digest command, and the
key is applied with the area <NR> virtual-link <RID>
message-digest-key <NR> md5 <STRING> command. In some versions, these
two commands are combined automatically in the running config to the
single statement area <NR> virtual-link <RID> authentication message-
digest message-digest-key <NR> md5 <STRING>, but the result of either
syntax is the same. After authentication is enabled on the virtual-
link, make sure to issue the clear ip ospf process command, because the
virtual-link does not support periodic hellos. This means that if the
authentication is wrong the virtual-link interface will not
immediately go down, but if there is a change in the topology it won’t
actually be propagated across the virtual-link.

Pitfall
A failure in authentication can occur for two reasons: a mismatch in
authentication type or a mismatch involving the authentication key.
An authentication type mismatch occurs when one neighbor is configured
with clear text while the other is running MD5, or one is running MD5
and the other is running null, etc. A key mismatch is simply when the
routers are using different passwords.

OSPF Summarization
summarize the topology graph
achieved through ospf areas
hides the details of how the graph looks in other areas
find the SPT to the node that owns the route
only run spf for intra area destinations
Summarize the NLRI
achieved through stub areas and per prefix summaries
Summarize type 5 lsa to a default route
replace multiple longer matches with a shorter match
NLRI summarization
all devices in the same area must have same LSDB
summarization can't be performed at arbitrary points in the
topology
ospf summarization can only occur:
between internal areas - ABRs
between external domains - ASBRs
EIGRP & BGP win over OSPF & IS-IS here
EIGRP/BGP hierarchy is arbitrary
OSPF and ISIS is strict leaf - spine - leaf
Internal vs External Summaries
internal summaries
summarizes Type 1 into Type 3 lsas
take a group of individual routes and summarize into a type
3 LSA
performed on ABRs
the area range command is used here
External summarizations
summarizes type 5 into type 5 lsas
summarizes type 7 into type 7 lsas
performed on ASBRs
Summary Discard Route
When summarizing, the OSPF process automatically creates a local
discard rotue
a route to Null0
Goal of it is to drop traffic if the longest match is the summary
 if you are summarizing it, you should always have a more specific
route to it
you shouldn't be routing to a destination you don't have a
longer match for
End result is that summary router cannot fallback to default
Can be disabled with the no discard route
Where OSPF can summarize
Internal summaries
only at the ABR who knows the LSA 1
you can summarize lsa 1 to lsa 3 but not lsa 3 to lsa 3
if you take a group of Type 1 LSAs and summarize them into
an area on an ABR, you can't summarize them again as they are
being advertised as a Type 3 LSA
External summaries
only at the ASBR who is the originator
ASBR performing Type 5 or Type 7 redistribution
ASBR/ABR performing Type 5 to Type 7 translation
Who ever did the summarization to reach the external
network, the forwarding address will be set to that routers RID
When the LSA is flooded from the ASBR to the ABRs, it will
flood type 5 external LSAs everywhere except a Stub area

Internal summaries
between areas
area X range x.x.x.x mask x.x.x.x
X is the source area
External summaries
only at the ASBR who is the originator
ASBR performing Type 5 or Type 7 redistribution
ASBR/ABR performing Type 5 to Type 7 translation
during redistribution
summary address x.x.x.x x.x.x.x
automatically generates discard route
disabled with no discard route [internal | external]
if a route in the summary fails, any traffic destined for that route is
dropped instead of being
forwarded to a shorter match route
if a packet comes in and the destination is the summary itself you
should drop that packet
Other summary applications
can be used for traffic engineering via longest match routing
prefer longer match over shorter match
internal summarization
summarizes type 3 lsas
network summary lsas, area range command on abr
summarizing as routes come into area 0 or as they go out to
another non transit area
external summarization
summarizes type 7 lsa
summary address command, done on asbr

TEST SUMMARY ADDRESS TO STOP P BIT, USE AREA RANGE TO

SPECIFICALLY USE ONE ABR OVER ANOTHER

automatically generates a discard route

if a subnet in a summary fails, it will be discarded
By using the summary address command, you use longest match to engineer which
path traffic will take
it genereates a discard route to null 0 for routes that don't exist
 on int null0
no ip unreachable stops icmp messages showing there isn't a route

area X range prefix and length

advertise - the default
cost - set the cost specific to this summary route
not advertise - do not advertise the summary route
no discard-route

Enforce area local scope for NSSA route

summary address nssa-only
done on the ASBR, this withdraws the P bit so that none of the ABRs
will be able to translate to the ASBR

O 155.1.8.0/22 is a summary, 00:00:03, Null0

ospf database
type 5 as external
advertising router is the router doing the redistribution
adv router: x.x.x.x
network mask: /whatever
metric type 2 is an E2, external type 2, no
incrementing the cost through the network
metric is: 20 is the default for redistribution
forward address:0.0.0.0 means use the router doing
the redistribution
the forward metric is the total cost in an intra area to get to
the redistributing router
if there are 2 equal cost paths, two routes with 20 as the
metric, the lowest forward metric would be used
LSA types
intra area routes O
lsa 1 and 2
lsa 1 is the router lsa, router ID
lsa 2 is the network lsa, generated by the DR
inter area routes O IA
lsa 3 and 4
lsa 3 is the summary lsa, area border router, abr
lsa 4 is the summary lsa for ospf to non ospf networks
external routes E1 and E2
lsa 5
lsa 5 is the redistribution lsa, when routes are sent into
ospf from other protocols
nssa external routes N1 and N2
lsa 7
lsa 7 is the redistribution lsa, when routes are sent into
ospf from other protocols
this "n" is only seen with the nssa command applied
to an ABR and ASBR
Essential LSAs
The five essential LSAs are:
Router LSAs
Network LSAs
Network Summary LSAs
ASBR Summary LSAs
AS-External LSAs
 Router LSAs
The purpose of the LSA is to advertise the originating router,
the router's attached links, the cost of those links, and its
adjacent neighbors. The Router LSA has an area flooding scope: It
is flooded throughout the area in which it is originated,
but never to other areas.

The Router LSA type is 1, and the Link State ID is the

originating router's RID.

V (Virtual Link), when set, indicates that the originating router

is a virtual link end-point.
E (External), when set, indicates that the router is an ASBR.
B (Border), when set, indicates that the router is an ABR.
Number of Links specifies how many router links are listed in
this LSA. The remaining fields in the LSA repeat the number of
times specified here.

Type indicates the type of link described by the fields to follow

Type Description
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link

Link ID varies according to the link type. Link ID field contains

for various link types. If the link connects to another router
(type 1, 2, or 4), the value shown is also the value of the
neighbor's LSA Link State ID. This is how the two routers' LSAs are
related during the SPF calculation.

Type Link ID
1 Neighboring router's RID
2 IP address of DR
3 Network IP address
4 Neighboring router's RID

Link Data also varies according to the link type. This

information is used to derive the next-hop address for routes passing over the
link.
Type Link Data
1 For numbered point-to-point links: the IP
address of the originating router's interface to the link
For unnumbered links: the MIB-II ifIndex value
of the router's interface to the link
2 IP address of the originating router's
interface to the link
3 Stub network's IP address mask (Note that host
routes are type 3 links, and this field contains a mask of 255.255.255.255.)
4 The MIB-II ifIndex value of the originating
router's interface to the virtual link

Number of ToS Metrics is included for backward compatibility with

earlier OSPFv2 specifications (RFC 1583 and before).
If this field is non-zero, a matching number of 32-bit fields
containing various ToS metrics and their type numbers follow the
metric field for this link. However, modern OSPF implementations
do not utilize these ToS metrics, and so this field is always 0
 Network LSAs
generated by the DR to represent a pseudonode. Like the Router
LSA, it has an area flooding scope. The LSA type is 2, and the Link
State ID is the IP address of the DR's interface attaching to the
pseudonode (broadcast or NBMA network).
no Metric field in the LSA. This is because, as you learned
earlier, the cost from the pseudonode to all attached routers is 0.

Network Mask is the IP address mask for the network.

Attached Router is the RID of one of the routers attached to the

pseudonode network. This field repeats to include all attached
routers that are fully adjacent to the DR, and the DR itself. The
number of Attached Router fields in the LSA can be deduced from
the value of the LSA's Length field.

Network Summary LSAs

Network Summary LSAs are originated by ABRs and are flooded into
an area to advertise prefixes that are in other areas.
This LSA is the key to understanding why OSPF is "distancevector-
like" in its inter-area behavior. When an ABR learns a route to
a prefix in another areaeither because the prefix is in an
attached area or because another ABR has advertised the prefix in its
own Network Summary LSAthe ABR uses the Network Summary LSA to
tell routers in an area, "I am a next hop to this prefix, at a cost
of X." The routers within the area know from their shortest-path
trees how to reach the ABR, but the trees to not reach outside of
the area to the actual prefix. This is distance vector behavior.

Its type is 3, and it has area flooding scope. The inter-area

prefix being advertised is carried in the Link State ID field.
Because there is only one Link State ID field in an LSA, an ABR
must originate a separate Network Summary LSA for each prefix it
wants to advertise into an area. The ABR can also originate a
Network Summary LSA to advertise a default route (0.0.0.0/0) into an area.

Network Mask is the IP address mask of the prefix.

Metric is the cost from the ABR to the destination. Notice that
unlike the 16-bit intra-area metric, this one is 24 bits to
accommodate presumably longer paths to the destination.

ToS and ToS Metric are, as with the Router LSA, for backward
compatibility with earlier OSPFv2 incarnations.
ToS is not used in modern OSPFv2, and so the ToS type is always
0, and the ToS Metric is all 0s.

ASBR Summary LSAs

is identical to the Network Summary LSA, but it advertises an
ASBR that is outside of the area rather than a prefix.
When an ASBR floods an external prefix throughout an OSPF
domain, the advertised prefix shows the ASBR as the next hop.
This LSA is necessary for routers in different areas from the
ASBR to learn how to reach the ASBR and hence the external destinations.
Like the Network Summary LSA, the ASBR Summary LSA is originated
by an ABR and flooded into an area, and has area flooding scope.
 The ABR learns about the advertised ASBR the same way it does
inter-area prefixes: The ASBR is either in a connected area and thus
learned from the ABR's shortest-path tree for the area, or it is
learned from an ASBR Summary LSA originated by another ABR attached
to another area.

The LSA type of the ASBR Summary LSA is 4, and the Link State ID
is the ASBR's RID. An ABR must originate a separate
ASBR Summary LSA for each ASBR it wants to advertise into an
area.

Network Mask has no meaning in ASBR Summary LSAs, and is set to

all 0s.

Metric is the cost of the path from the ABR to the ASBR.

AS-External LSAs
An ASBR originates a single AS-External LSA for each external
prefix it wants to advertise to the OSPF domain.
Unlike the previous four LSAs examined, this LSA has autonomous
system (domain) flooding scope.
That is, it is flooded to all nonstub areas in the OSPF domain.
AS-External LSAs are also used to advertise a default
route (0.0.0.0/0) out of the OSPF domain.

AS-External LSAs are type 5, and the Link State ID is the IP

prefix of the external destination being advertised.
An ASBR originates a separate AS-External LSA for every external
prefix that it wants to advertise. In this lies a
fundamental danger to OSPF. If a large number of prefixes is
advertised into the domain, a corresponding large number of
AS-External LSAs is flooded throughout the domain. The result can
be undue stress on the OSPF routers trying to store and
process all these LSAs. In some cases such as the all-too-common
mistake of redistributing all of the prefixes of the
Internet routing table into OSPFthis stress can cause a domain-
wide crash of routers.

Network Mask is the IP address mask of the advertised prefix.

E specifies whether the metric type of the advertised prefix is

E1 (E = 0) or E2 (E = 1).

Metric is the cost to the prefix from the ASBR, and is assigned
by the ASBR based on an arbitrary
configuration or on the value (as specified by a configured
routing policy) of the metric of the protocol
from which the prefix was learned. Like the metric in the Network
Summary LSAs, this metric is 24 bits.

Forwarding Address is the address that packets destined to the

prefix should be forwarded to. Note that this field does
not specify a next-hop address for the prefix, just an address
that must be used to reach the prefix. When set to 0.0.0.0,
packets to the prefix are forwarded to the originating ASBR.
However, this field also gives the ASBR the capability of
advertising a different forwarding address than itself.
 External Route Tag allows information that has no relevance to
OSPF to be carried across the OSPF domain.
Typically, this information would be BGP route attributes but can
be anything that an external routing protocol adds at
one ASBR and extracts from another ASBR. The OSPF process itself
ignores the contents of this field.

Internal Summarization
Because devices in an OSPF area require the same copy of the database
to compute correct SPF, filtering or summarization of routes in the
database can only occur between areas or domains, not within an area.
The below configuration illustrates how an Intra-Area Summary Network
LSA (LSA 3) can be summarized as it is originated by an ABR.
If a router is receiving an LSA for a route that it must use an ABR to
reach and there are multiple Type 3 LSAs that the ABR is originating,
this implies that all the LSAs that the ABR is originating that the
router looking to send traffic to is the type 3 LSA that the sending router
must recurse to, to reach the inter area route, this also means that
the ABR is the place where summarization must occur.
If you were to look in the OSPF LSDB for the summary route and the
advertising router it would point you to the ABR.
By replacing a longer match, in this case several longer matches with a
single shorter match, the routers in other areas will only have to
install a single LSA to reach all the inter area routes, using the Type
3 LSA to recurse to the ABR to solve the SPT to the Type 1 router LSA.

Path Selection with Summarization

To enable the path selection to failover in the event of a link
failure, using the area range command to advertise a shorter match to be
installed into the routing table in the event of a link failure.
Because the area range command will advertise a shorter match, the longer
that already exists will take preference, if the longer match route is
withdrawn from the routing table the shorter match will be installed.

External Summarization
External OSPF summarization is configured at the redistribution point
between routing domains with the summary-address command. These summaries
inherit their attributes from the subnets that make them up. For
example, a summary comprised of External Type-1 routes will result in an
External Type-1 summary. This means that on the orginiating router in
this configuration, the metric-type 1 command is set at the time of redistribution
instead
of on the summary itself. External Type-2 OSPF routes, which are the
default, do not install the end-to-end metric in the routing table.
Instead, only the metric that was reported via the ASBR is installed.
The actual routing path is determined by the addition of the reported
metric and the metric toward the ASBR, which is called the forward
metric

Basically what the forward metric does is it points you towards a

router that has solved the SPT to the router that owns the route your trying
to reach. If the forward address is 0.0.0.0 then you will need to solve
the SPT to the IP in the advertising router field. If there are multiple
paths to advertising router, and the forward address is 0.0.0.0, you
would use the forward metric to reach it.

From a recursion standpoint, you are learning a type 5 lsa in from the
ASBR, this means you need to know how to recurse to the router originating the Type
5 LSA.
Once you reach the router generating the type 5 lsa, you'll need to
solve the SPT to the router generating the type 4 ASBR network summary. Get to that
box, then
figure out the oringinating router for the Type 1 LSA.

OSPF Database Synchronization

Everything you have seen about OSPF so far shows that it is a
highly structured protocol. Knowing the importance of reliable and
accurate database synchronization, it is no surprise that a
rather complex state machine, called the neighbor state machine,
manages the OSPF synchronization procedure. In a nutshell, the
neighbor state machine drives the following steps in the
synchronization process:

1. When two neighbors decide to become adjacent, one of the

neighbors becomes the master and the other the slave. The master controls
the rest of the synchronization process, called database
exchange.

2. Each neighbor describes all of the LSAs in its database to

the other.

3. If a router finds, during the description process, that its

neighbor has an LSA that it does not, or has a more recent
copy of an LSA that it has, it requests a full copy of the LSA
from the neighbor.

4. When all necessary LSAs have been exchanged and both

neighbors are satisfied that their databases are identical,
they end the exchange process and are fully adjacent. Only then
can the link between them be used for forwarding packets.

Again, this is only relevant to broadcast and NBMA links.

OSPF Packets Used in Database Synchronization

Four of the five OSPF packet types are used for database
exchange:

Database Description (type 2) packets

Link State Request (type 3) packets
Link State Update (type 4) packets
Link State Acknowledgment (type 5) packets

Update packets are used to send complete LSAs from one neighbor
to another, and how Acknowledgment packets carry LSA headers to
explicitly acknowledge the receipt of LSAs for reliable flooding.

Database Description packet, like the Acknowledgment packet, carries

only the headers of the LSAs that completely describe
both the LSA and the instance of the LSA. An OSPF router can
describe all of the LSAs in its database by originating DD packets.

Interface MTU specifies the largest unfragmented packet that can

be sent from the originating interface. If the MTUs do not match, the neighbors do
not become adjacent. Otherwise, one neighbor might send messages larger than the
other neighbor can receive.
 Options is the same Options field that is included in Hello
packets and all LSAs to describe the originator's optional capabilities.
This field has already been mentioned briefly in previous
chapters; its format and use are described fully in the next section.

LS databases are often too large for all of their LSAs to be

described by a single DD packet. Therefore, two bits indicate to the
receiving neighbor whether the DD packet is one of a sequence:

I (Init) indicates, when set to 1, that this DD packet is the

first in a series.
M (More) indicates, when set to 1, that there are more DD packets
to follow.
So the I and M bits are used as follows:
If a single DD packet describes all LSAs, the two bit values are
I=1, M=0.
If there is a series of DD packets, the first in the series has
I=1, M=1; the last DD packet has I=0, M=0; and any packets between
the first and last have I=0, M=1.
MS (Master/Slave) indicates whether the originating neighbor is
the Master (MS =1) or Slave (MS = 0) during the database exchange.
DD Sequence Number is used, along with the I and M bits, when a
series of DD packets describes a database.

If during database exchange an OSPF router sees, in the received

DD packets, that its neighbor has an unknown LSA or a more recent
copy of a known LSA, the router sends a Link State Request packet
to ask for a full copy of the LSA. More than one LSA
can be requested in a single LS Request packet, and more than one
LS Request packet can be sent if a large number of LSAs are needed.
The neighbor then sends an Update packet containing the requested
LSAs.

The Options Field

The OSPF Options field is an 8-bit collection of flags specifying
optional capabilities of the originating router. With the
introduction of the Database Description packet in the previous
section, you have now encountered all of the OSPF entities in which
the Options field appears:
Hello packets
Database Description packets
The LSA header

Seven of the bits are currently used as flags; the eighth bit,
marked with an asterisk (*) is unused
The originating router only sets bits representing capabilities
it supports. Any bit representing an option that the router does not
support is considered unknown by the router, and the router sets
that bit to 0 in all Options fields it originates.

O indicates support for Opaque LSAs

DC indicates, when set, that the originating router supports the
Demand Circuit capability and its associated DoNotAge LSAs
This capability is designed for use when a link between two
neighbors incurs some usagebased cost. By configuring the OSPF interface
to treat the link as a demand circuit, Hello packets and
refreshed LSAs are suppressed across the link to avoid keeping the link up
and incurring unnecessary charges. A router supporting
DoNotAge LSAs sets the DC bit in all of the LSAs it originates. It also sets
the DC bit in Hellos and DD packets sent across the link
designated as a demand circuit. If the router receives Hellos or DD packets
with the bit cleared, indicating that the neighbor either
does not support the option or is not configured for it, the router reverts
to normal Hello and refresh procedures. If a router that
does not support Demand Circuit capability receives an Options field with the
DC bit set, it ignores the bit.
N/P is used to support Not-So-Stubby Areas
In Hello packets, this bit is the N bit and indicates, when
set, support for NSSA (type 7) LSAs. If the N bit is set, the E bit
(indicating support for type 5 LSAs) must be cleared. If
neighbors do not agree on the setting of these bits, Hellos are dropped
and no adjacency is formed. In NSSA LSA headers, the bit is
the P bit and tells the NSSA ABR to translate the type 7 LSA into a
type 5 LSA.
E indicates, when set, that the originating router supports
external routing capability.
When the bit is cleared, the originating router does not
accept AS-External (type 5) LSAs. This capability is used in the
configuration of stub areas. The bit is always set in AS-
External LSAs, and is always set in DD packets and LSAs associated with
area 0 and with nonstub areas. However, it is set in these
LSAs and DD packets for informational purposes only. Where the flag
has effect is in the Hello packet. If the value of the E
bits conflict between neighborsthat is, one neighbor is sending Hellos
with the bit set and the other neighbor sends Hellos with
the bit clearedthe Hellos are not accepted and an adjacency is not formed.

The OSPF Neighbor Data Structure

When an OSPF router first discovers a neighbor on a link
through receipt of a Hello, it initializes a neighbor data structure for
this neighbor. The neighbor data structure, or neighbor
table, contains all of the information the router needs to know about the
neighbor. Some of the information is gleaned from the
neighbor's received Hellos and DD packets, and some of the information
comes from the router's own internal processes concerning
the neighbor. The specific entries in the neighbor data table are as follows:

State records the router's view of the state of the

neighbor, according to its own neighbor state machine
this is not the same as the "state" entry of the interface
data structure, which indicates only the interface state and its relation
to other OSPF interfaces

Inactivity Timer is a timer whose period is

RouterDeadInterval, as defined for the interface connecting to the link on which
the
neighbor resides. Whenever a Hello is received from the
neighbor, the timer is reset. Expiration of the timer triggers an event
in the neighbor state machine that causes the neighbor
state to be changed to Down.

Master/Slave specifies the results of the master/slave

selection

DD Sequence Number is the sequence number of the DD packet

currently being sent to the neighbor, for database exchange.
 Last Received Database Description Packet is used to
determine, during database exchanges with the neighbor, whether a DD packet
received from the neighbor is a duplicate. It records the
values of the Sequence Number and Options fields and the settings of
the I, M, and MS flags of the last DD packet received from
the neighbor.

Neighbor ID is the RID of the neighbor, learned from the

neighbor's Hello packets or in some cases manually configured
(such as with NBMA or virtual networks).

Neighbor Priority is the value of the Router Priority field

of Hellos received from the neighbor, and is used for DR/BDR election.

Neighbor IP Address is the IP address of the neighbor's

interface to the attached network, and is learned from the source IP address
of Hellos received from the neighbor.
This address is used when OSPF packets must be unicast to
the neighbor.
If the neighbor is the DR for the attached network, this
address is used as the Link ID in Router LSAs for the attached network.

Neighbor Options are the neighbor's optional capabilities,

learned from its Hellos and from the DD packets during database exchange.

Neighbor's Designated Router is the address of the DR (from

the neighbor's perspective) carried in the neighbor's Hellos, and is
only relevant on broadcast and NBMA networks.

Neighbor's Backup Designated Router is the address of the

BDR (from the neighbor's perspective) carried in the neighbor's Hellos.

OSPFv3 for IPv6 support

Prerequisites for IPv6 Routing: OSPFv3
•Complete the OSPFv3 network strategy and planning for your IPv6
network. For example, you must
decide whether multiple areas are required.
•Enable IPv6 unicast routing.
•Enable IPv6 on the interface.

Restrictions for IPv6 Routing: OSPFv3

When running a dual-stack IP network with OSPF version 2 for IPv4 and
OSPFv3, be careful when changing
the defaults for commands used to enable OSPFv3. Changing these
defaults may affect your OSPFv3 network,
possibly adversely.

How OSPFv3 Works

OSPFv3 is a routing protocol for IPv4 and IPv6. It is a link-state
protocol, as opposed to a distance-vector
protocol. Think of a link as being an interface on a networking device.
A link-state protocol makes its routing
decisions based on the states of the links that connect source and
destination machines. The state of a link is
a description of that interface and its relationship to its neighboring
networking devices. The interface
information includes the IPv6 prefix of the interface, the network
mask, the type of network it is connected
to, the devices connected to that network, and so on. This information
is propagated in various type of link-state
advertisements (LSAs).

A device’s collection of LSA data is stored in a link-state database.

The contents of the database, when subjected
to the Dijkstra algorithm, result in the creation of the OSPF routing
table. The difference between the database
and the routing table is that the database contains a complete
collection of raw data; the routing table contains
a list of shortest paths to known destinations via specific device
interface ports.
OSPFv3, which is described in RFC 5340, supports IPv6 and IPv4 unicast
AFs.

Comparison of OSPFv3 and OSPF Version 2

Much of OSPF version 3 is the same as in OSPF version 2. OSPFv3, which
is described in RFC 5340, expands
on OSPF version 2 to provide support for IPv6 routing prefixes and the
larger size of IPv6 addresses.

In OSPFv3, a routing process does not need to be explicitly created.

Enabling OSPFv3 on an interface will
cause a routing process, and its associated configuration, to be
created.

In OSPFv3, each interface must be enabled using commands in interface

configuration mode. This feature is
different from OSPF version 2, in which interfaces are indirectly
enabled using the device configuration mode.

When using a nonbroadcast multiaccess (NBMA) interface in OSPFv3, you

must manually configure the
device with the list of neighbors. Neighboring devices are identified
by their device ID.

In IPv6, you can configure many address prefixes on an interface. In

OSPFv3, all address prefixes on an
interface are included by default. You cannot select some address
prefixes to be imported into OSPFv3; either
all address prefixes on an interface are imported, or no address
prefixes on an interface are imported.

Unlike OSPF version 2, multiple instances of OSPFv3 can be run on a

link.

OSPF automatically prefers a loopback interface over any other kind,

and it chooses the highest IP address
among all loopback interfaces. If no loopback interfaces are present,
the highest IP address in the device is
chosen. You cannot tell OSPF to use any particular interface.

LSA Types for OSPFv3

The following list describes LSA types, each of which has a different
purpose:
• Device LSAs (Type 1)—Describes the link state and costs of a device’s
links to the area. These LSAs
are flooded within an area only. The LSA indicates if the device
is an Area Border Router (ABR) or
Autonomous System Boundary Router (ASBR), and if it is one end of
a virtual link. Type 1 LSAs are
also used to advertise stub networks. In OSPFv3, these LSAs have
no address information and are
network-protocol-independent. In OSPFv3, device interface
information may be spread across multiple
device LSAs. Receivers must concatenate all device LSAs
originated by a given device when running
the SPF calculation.
• Network LSAs (Type 2)—Describes the link-state and cost information
for all devices attached to the
network. This LSA is an aggregation of all the link-state and
cost information in the network. Only a
designated device tracks this information and can generate a
network LSA. In OSPFv3, network LSAs
have no address information and are network-protocol-independent.
• Interarea-prefix LSAs for ABRs (Type 3)—Advertises internal networks
to devices in other areas
(interarea routes). Type 3 LSAs may represent a single network or
a set of networks summarized into
one advertisement. Only ABRs generate summary LSAs. In OSPFv3,
addresses for these LSAs are
expressed as prefix, prefix length instead of address, mask. The
default route is expressed as a prefix
with length 0.
• Interarea-device LSAs for ASBRs (Type 4)—Advertises the location of
an ASBR. Devices that are
trying to reach an external network use these advertisements to
determine the best path to the next hop.
Type 4 LSAs are generated by ABRs on behalf of ASBRs.
• Autonomous system external LSAs (Type 5)—Redistributes routes from
another autonomous system,
usually from a different routing protocol into OSPFv3. In OSPFv3,
addresses for these LSAs are expressed
as prefix, prefix length instead of address, mask. The default
route is expressed as a prefix with length
0.
• Link LSAs (Type 8)—Have local-link flooding scope and are never
flooded beyond the link with which
they are associated. Link LSAs provide the link-local address of
the device to all other devices attached
to the link, inform other devices attached to the link of a list
of prefixes to associate with the link, and
allow the device to assert a collection of Options bits to
associate with the network LSA that will be
originated for the link.
• Intra-Area-Prefix LSAs (Type 9)—A device can originate multiple
intra-area-prefix LSAs for each
device or transit network, each with a unique link-state ID. The
link-state ID for each intra-area-prefix
LSA describes its association to either the device LSA or the
network LSA and contains prefixes for
stub and transit networks.

An address prefix occurs in almost all newly defined LSAs. The prefix
is represented by three fields:
PrefixLength, PrefixOptions, and Address Prefix. In OSPFv3, addresses
for these LSAs are expressed as
 prefix, prefix length instead of address, mask. The default route is
expressed as a prefix with length 0. Type
3 and Type 9 LSAs carry all prefix (subnet) information that, in
OSPFv2, is included in device LSAs and
network LSAs. The Options field in certain LSAs (device LSAs, network
LSAs, interarea-device LSAs, and
link LSAs) has been expanded to 24 bits to provide support for OSPFv3.
In OSPFv3, the sole function of the link-state ID in interarea-prefix
LSAs, interarea-device LSAs, and
autonomous-system external LSAs is to identify individual pieces of the
link-state database. All addresses or
device IDs that are expressed by the link-state ID in OSPF version 2
are carried in the body of the LSA in
OSPFv3.

The link-state ID in network LSAs and link LSAs is always the interface
ID of the originating device on the
link being described. For this reason, network LSAs and link LSAs are
now the only LSAs whose size cannot
be limited. A network LSA must list all devices connected to the link,
and a link LSA must list all of the
address prefixes of a device on the link.

NBMA in OSPFv3
On NBMA networks, the designated router (DR) or backup DR (BDR)
performs the LSA flooding. On
point-to-point networks, flooding simply goes out an interface directly
to a neighbor.
Devices that share a common segment (Layer 2 link between two
interfaces) become neighbors on that segment.
OSPFv3 uses the Hello protocol, periodically sending hello packets out
each interface. Devices become
neighbors when they see themselves listed in the neighbor’s hello
packet. After two devices become neighbors,
they may proceed to exchange and synchronize their databases, which
creates an adjacency. Not all neighboring
devices have an adjacency.

On point-to-point and point-to-multipoint networks, the software floods

routing updates to immediate neighbors.
There is no DR or BDR; all routing information is flooded to each
networking device.
On broadcast or NBMA segments only, OSPFv3 minimizes the amount of
information being exchanged on
a segment by choosing one device to be a DR and one device to be a BDR.
Thus, the devices on the segment
have a central point of contact for information exchange. Instead of
each device exchanging routing updates
with every other device on the segment, each device exchanges
information with the DR and BDR. The DR
and BDR relay the information to the other devices.

The software looks at the priority of the devices on the segment to

determine which devices will be the DR
and BDR. The device with the highest priority is elected the DR. If
there is a tie, then the device with the
higher device ID takes precedence. After the DR is elected, the BDR is
elected the same way. A device with
a device priority set to zero is ineligible to become the DR or BDR.
 When using NBMA in OSPFv3, you cannot automatically detect neighbors.
On an NBMA interface, you
must configure your neighbors manually using interface configuration
mode.
Load Balancing in OSPFv3
When a device learns multiple routes to a specific network via multiple
routing processes (or routing protocols),
it installs the route with the lowest administrative distance in the
routing table. Sometimes the device must
select a route from among many learned via the same routing process
with the same administrative distance.
In this case, the device chooses the path with the lowest cost (or
metric) to the destination. Each routing process
calculates its cost differently and the costs may need to be
manipulated in order to achieve load balancing.

OSPFv3 performs load balancing automatically in the following way. If

OSPFv3 finds that it can reach a
destination through more than one interface and each path has the same
cost, it installs each path in the routing
table. The only restriction on the number of paths to the same
destination is controlled by the maximum-paths
command. The default maximum paths is 16, and the range is from 1 to
64.
Addresses Imported into OSPFv3
When importing the set of addresses specified on an interface on which
OSPFv3 is running into OSPFv3, you
cannot select specific addresses to be imported. Either all addresses
are imported, or no addresses are imported.

How to Configure Load Balancing in OSPFv3

Configuring the OSPFv3 Device Process
Once you have completed step 3 and entered OSPFv3 router
configuration mode, you can perform any of the
subsequent steps in this task as needed to configure OSPFv3
Device configuration.
SUMMARY STEPS
1. enable
2. configure terminal
3. router ospfv3 [process-id]
4. area area-ID [default-cost | nssa | stub]
5. auto-cost reference-bandwidth Mbps
6. bfd all-interfaces
7. default {area area-ID [range ipv6-prefix | virtual-link router-id]}
[default-information originate
[always | metric | metric-type | route-map] | distance | distribute-
list prefix-list prefix-list-name {in |
out} [interface] | maximum-paths paths | redistribute protocol |
summary-prefix ipv6-prefix]
8. ignore lsa mospf
9. interface-id snmp-if-index
10. log-adjacency-changes [detail]
11. passive-interface [default | interface-type interface-number]
12. queue-depth {hello | update} {queue-size | unlimited}
13. router-id router-id

Forcing an SPF Calculation

SUMMARY STEPS
1. enable
 2. clear ospfv3 [process-id] force-spf
3. clear ospfv3 [process-id] process
4. clear ospfv3 [process-id] redistribution
5. clear ipv6 ospf [process-id] {process | force-spf | redistribution}

Verifying OSPFv3 Configuration and Operation

SUMMARY STEPS
1. enable
2. show ospfv3 [process-id] [address-family] border-routers
3. show ospfv3 [process-id [area-id]] [address-family] database
[database-summary | internal | external
[ipv6-prefix ] [link-state-id] | grace | inter-area prefix [ipv6-prefix
| link-state-id] | inter-area router
[destination-router-id | link-state-id] | link [interface interface-
name | link-state-id] | network [link-state-id]
| nssa-external [ipv6-prefix] [link-state-id] | prefix [ref-lsa {router
| network} | link-state-id] |
promiscuous | router [link-state-id] | unknown [{area | as | link}
[link-state-id]] [adv-router router-id]
[self-originate]
4. show ospfv3 [process-id] [address-family] events [generic |
interface | lsa | neighbor | reverse | rib |
spf]
5. show ospfv3 [process-id] [area-id] [address-family] flood-list
interface-type interface-number
6. show ospfv3 [process-id] [address-family] graceful-restart
7. show ospfv3 [process-id] [area-id] [address-family] interface [type
number] [brief]
8. show ospfv3 [process-id] [area-id] [address-family] neighbor
[interface-type interface-number]
[neighbor-id] [detail]
9. show ospfv3 [process-id] [area-id] [address-family] request-
list[neighbor] [interface] [interface-neighbor]
10. show ospfv3 [process-id] [area-id] [address-family] retransmission-
list [neighbor] [interface]
[interface-neighbor]
11. show ospfv3 [process-id] [address-family] statistic [detail]
12. show ospfv3 [process-id] [address-family] summary-prefix
13. show ospfv3 [process-id] [address-family] timers rate-limit
14. show ospfv3 [process-id] [address-family] traffic[interface-type
interface-number]
15. show ospfv3 [process-id] [address-family] virtual-links

OSPFv3 Authentication Support with IPsec

In order to ensure that OSPFv3 packets are not altered and re-sent to
the device, causing the device to behave
in a way not desired by its system administrators, OSPFv3 packets must
be authenticated. OSPFv3 uses the
IPsec secure socket API to add authentication to OSPFv3 packets. This
API supports IPv6.
OSPFv3 requires the use of IPsec to enable authentication. Crypto
images are required to use authentication,
because only crypto images include the IPsec API needed for use with
OSPFv3.

In OSPFv3, authentication fields have been removed from OSPFv3 packet

headers. When OSPFv3 runs on
IPv6, OSPFv3 requires the IPv6 authentication header (AH) or IPv6 ESP
header to ensure integrity,
 authentication, and confidentiality of routing exchanges. IPv6 AH and
ESP extension headers can be used to
provide authentication and confidentiality to OSPFv3.

To use the IPsec AH, you must enable the ipv6 ospf authentication
command. To use the IPsec ESP header,
you must enable the ipv6 ospf encryption command. The ESP header may be
applied alone or in combination
with the AH, and when ESP is used, both encryption and authentication
are provided. Security services can
be provided between a pair of communicating hosts, between a pair of
communicating security gateways, or
between a security gateway and a host.

To configure IPsec, you configure a security policy, which is a

combination of the security policy index (SPI)
and the key (the key is used to create and validate the hash value).
IPsec for OSPFv3 can be configured on
an interface or on an OSPFv3 area. For higher security, you should
configure a different policy on each
interface configured with IPsec. If you configure IPsec for an OSPFv3
area, the policy is applied to all of the
interfaces in that area, except for the interfaces that have IPsec
configured directly. Once IPsec is configured
for OSPFv3, IPsec is invisible to you.

The secure socket API is used by applications to secure traffic. The

API needs to allow the application to
open, listen, and close secure sockets. The binding between the
application and the secure socket layer also
allows the secure socket layer to inform the application of changes to
the socket, such as connection open and
close events. The secure socket API is able to identify the socket;
that is, it can identify the local and remote
addresses, masks, ports, and protocol that carry the traffic requiring
security.
Each interface has a secure socket state, which can be one of the
following:
• NULL: Do not create a secure socket for the interface if
authentication is configured for the area.
• DOWN: IPsec has been configured for the interface (or the area that
contains the interface), but OSPFv3
either has not requested IPsec to create a secure socket for this
interface, or there is an error condition.
• GOING UP: OSPFv3 has requested a secure socket from IPsec and is
waiting for a
CRYPTO_SS_SOCKET_UP message from IPsec.
• UP: OSPFv3 has received a CRYPTO_SS_SOCKET_UP message from IPsec.
• CLOSING: The secure socket for the interface has been closed. A new
socket may be opened for the
interface, in which case the current secure socket makes the transition
to the DOWN state. Otherwise,
the interface will become UNCONFIGURED.
• UNCONFIGURED: Authentication is not configured on the interface.
OSPFv3 will not send or accept packets while in the DOWN state.

Configuring IPsec on OSPFv3

Once you have configured OSPFv3 and decided on your authentication, you
must define the security policy
 on each of the devices within the group. The security policy consists
of the combination of the key and the
SPI. To define a security policy, you must define an SPI and a key.
You can configure an authentication or encryption policy either on an
interface or for an OSPFv3 area. When
you configure for an area, the security policy is applied to all of the
interfaces in the area. For higher security,
use a different policy on each interface.
You can configure authentication and encryption on virtual links.
Defining Authentication on an Interface
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. Do one of the following:
• ospfv3 authentication {ipsec spi} {md5 | sha1}{ key-encryption-type
key} | null
• ipv6 ospf authentication {null | ipsec spi spi authentication-
algorithm [key-encryption-type] [key]}
Defining Authentication in an OSPFv3 Area
SUMMARY STEPS
1. enable
2. configure terminal
3. ipv6 router ospf process-id
4. area area-id authentication ipsec spi spi authentication-algorithm
[key-encryption-type] key

OSPFv3 IPSec ESP Encryption and Authentication

Prerequisites for OSPFv3 IPSec ESP Encryption and Authentication
Configure the IP Security (IPsec) secure socket application program
interface (API) on OSPFv3 in order to
enable authentication and encryption.
OSPFv3 Authentication Support with IPsec
In order to ensure that OSPFv3 packets are not altered and re-sent to
the device, causing the device to behave
in a way not desired by its system administrators, OSPFv3 packets must
be authenticated. OSPFv3 uses the
IPsec secure socket API to add authentication to OSPFv3 packets. This
API supports IPv6.
OSPFv3 requires the use of IPsec to enable authentication. Crypto
images are required to use authentication,
because only crypto images include the IPsec API needed for use with
OSPFv3.

In OSPFv3, authentication fields have been removed from OSPFv3 packet

headers. When OSPFv3 runs on
IPv6, OSPFv3 requires the IPv6 authentication header (AH) or IPv6 ESP
header to ensure integrity,
authentication, and confidentiality of routing exchanges. IPv6 AH and
ESP extension headers can be used to
provide authentication and confidentiality to OSPFv3.

To use the IPsec AH, you must enable the ipv6 ospf authentication
command. To use the IPsec ESP header,
you must enable the ipv6 ospf encryption command. The ESP header may be
applied alone or in combination
with the AH, and when ESP is used, both encryption and authentication
are provided. Security services can
be provided between a pair of communicating hosts, between a pair of
communicating security gateways, or
between a security gateway and a host.

To configure IPsec, you configure a security policy, which is a

combination of the security policy index (SPI)
and the key (the key is used to create and validate the hash value).
IPsec for OSPFv3 can be configured on
an interface or on an OSPFv3 area. For higher security, you should
configure a different policy on each
interface configured with IPsec. If you configure IPsec for an OSPFv3
area, the policy is applied to all of the
interfaces in that area, except for the interfaces that have IPsec
configured directly. Once IPsec is configured
for OSPFv3, IPsec is invisible to you.

The secure socket API is used by applications to secure traffic. The

API needs to allow the application to
open, listen, and close secure sockets. The binding between the
application and the secure socket layer also
allows the secure socket layer to inform the application of changes to
the socket, such as connection open and
close events. The secure socket API is able to identify the socket;
that is, it can identify the local and remote
addresses, masks, ports, and protocol that carry the traffic requiring
security.

Each interface has a secure socket state, which can be one of the
following:
• NULL: Do not create a secure socket for the interface if
authentication is configured for the area.
• DOWN: IPsec has been configured for the interface (or the area that
contains the interface), but OSPFv3
either has not requested IPsec to create a secure socket for this
interface, or there is an error condition.
• GOING UP: OSPFv3 has requested a secure socket from IPsec and is
waiting for a
CRYPTO_SS_SOCKET_UP message from IPsec.
• UP: OSPFv3 has received a CRYPTO_SS_SOCKET_UP message from IPsec.
• CLOSING: The secure socket for the interface has been closed. A new
socket may be opened for the
interface, in which case the current secure socket makes the transition
to the DOWN state. Otherwise,
the interface will become UNCONFIGURED.
• UNCONFIGURED: Authentication is not configured on the interface.
OSPFv3 will not send or accept packets while in the DOWN state.
Defining Encryption on an Interface
SUMMARY STEPS
1.enable
2.configure terminal
3.interface type number
4.Do one of the following:
•ospfv3 encryption {ipsec spi spi esp encryption-algorithm key-
encryption-type key
authentication-algorithm key-encryption-type key | null}
•ipv6 ospf encryption {ipsec spi spi esp {encryption-algorithm [[key-
encryption-type] key] | null}
authentication-algorithm [key-encryption-type] key | null}

Defining Encryption in an OSPFv3 Area

 SUMMARY STEPS
1.enable
2.configure terminal
3.ipv6 router ospf process-id
4.area area-id encryption ipsec spi spi esp { encryption-algorithm [ | key-
encryption-type] key
| null} authentication-algorithm [ | key-encryption-type] key

Defining Authentication and Encryption for a Virtual Link in an OSPFv3 Area

SUMMARY STEPS
1.enable
2.configure terminal
3.ipv6 router ospf process-id
4.area area-id virtual-link router-id authentication ipsec spi spi
authentication-algorithm [
key-encryption-type] key
5.area area-id virtual-link router-id encryption ipsec spi spi esp
{encryption-algorithm
[key-encryption-type] key | null} authentication-algorithm [key-encryption-
type] key