OSPF is classified as an Interior Gateway Protocol routing within a single
autonomous system. As a link state routing protocol, a router running OSPF
compiles a database of all the links in the domain, the OSPF routers on those
links and the cost of the links. This database is the same on all routers in an OSPF area.
Each router independently determines their best path to the destinations in this
database.
OSPF runs Dijkstra's algorithm to calculate the shortest path to any
destination network in the OSPF domain. Dijkstra's algorithm is used by all
link state routing alogrithms to calculate the shortest path to a destination.
OSPF uses IP protocol number 89 and provides its own transport layer services.
The current versions of OSPF are OSPFv2 that supports IPv4 and OSPFv3 that supports
IPv4 and IPv6. The two versions of OSPF are not compatible i.e., routers running OSPFv3 cannot form an
IPv4 adjacency with routers running OSPFv2.
For a router to learn and exchange routes with other OSPF routers in
the OSPF domain, the OSPF process transitions through
various stages before presenting accurate routing information to the global/VRF routing
information base (RIB) or routing table. These stages include:
The routing table (RIB) receives routing information from various sources. If a routing device is being informed about a route from
various sources such as EIGRP, OSPF, IS-IS, BGP etc it uses the concept of administrative distance to rank the routing
information from each source.
The admininstrative distance (AD) can be considered as the level of trustworthiness of routing information from a given
source.
The lower the AD, the more trustworthy the routing information and the more likely that that routing
information will be installed in the RIB in preference over other sources with higher AD. An AD of 255 represents an untrustworthy route.
OSPF has an administrative distance of 110 for intra-area, inter-area OSPF
originated routes and 110 for routes that have been redistributed into OSPF from
other sources such as BGP, EIGRP (external routes).
The following table shows the ADs of some common routing protocols.
For OSPF routers to exchange route information, they need to form an adjacency.
The following are the adjacency preconditions:
For OSPF to advertise local networks, it has to be enabled on the directly
connected interfaces with configured IP addresses. The area that the
network will be resident has to be explicitly defined.
A network can only reside in one area. This can be done in two ways: using the
OSPF network command or using the interface command
ip ospf <process-id> area <area-id>.
When advertising the network of a loopback interface, these are usually advertised
into OSPF as a host route i.e., with a subnet mask of /32. To advertise the correct
mask of a loopback interface, the OSPF network type should be changed to
point-to-point.
To view the OSPF configuration including which networks are being advertised and
how they were added to OSPF, use the command show ip protocols:
The hello packet is used to communicate adjacency parameters during neighborship
formation and to maintain the neighborship. The other packet types are used to exchange
link state database information. Together, these packets ensure that the
information in the neighbor table and the LSDB is accurate and regularly updated.
OSPF routers exchange prefix information using unicast packets, multicast packets or both
depending on the OSPF network type. If multicast packets are used, the OSPF
multicast destination addresses used are:
In networks where multicast packets are permitted, it is possible to determine
if OSPF has been enabled on an interface by viewing the multicast groups that have
been joined by the interface using the command show ip interface.
From the above output, the OSPF device has the role of DROther on network segment
connected through interface FastEthernet0/0, and DR or BDR on the segment connected
through interface GigabitEthernet4/0.
All OSPF packet types have an OSPF header. This header contains information
that is common to all OSPF packet types and is communicated between devices.
The following output shows a Wireshark
capture of an OSPF Hello packet displaying only the OSPF header of the packet.
Of the values in the OSPF packet header, the OSPF version, area ID, authentication
type, and authentication data must match to satisfy some of the adjacency
preconditions.
When OSPF devices are forming neighbor relationships with each other, the adjacency
state transitions through up to nine phases depending on the OSPF network type;
these include DOWN, ATTEMPT, WAIT, INIT,
2-WAY, EXSTART, EXCHANGE, LOADING, FULL. In some OSPF network types, the number of stages may be less:
To view the OSPF adjacency stages in real-time, run the privileged-exec command
debug ip ospf adj:
It is important to note that once the routers in an area have converged i.e.,
they have the same LSDB, by default, the LSDB is flooded by OSPF every 30 minutes.
This process can the modified or disabled completely if so desired.
A router running OSPF builds and maintains two data structures or databases from
which it develops an accurate picture of the network: neighbor table and
link state database (LSDB).
The OSPF neighbor table contains directly connected neighbors that share network information.
To view the neighbor table, issue the commands in the following sections.
Below are the interface IP addresses of the local OSPF device:
From the above output, the following information can be learned about the neighborship:
The above command is used to view the neighborships formed through the specified
interface. The optional detail keyword can be appended to the
command to view detailed OSPF related information regarding the neighbor.
OSPF defines different network types to handle packet exchange with neighbors
connected through different types of network media and their different
associated characteristics.
OSPF network types control:
By default, adjacency formation criteria requires that OSPF neighbors be connected
through the same OSPF network type. Technically, the OSPF network type
does not need to match to form an adjacency but it does
need to be compatible such as;
The use of Type 2 LSA packets determines whether OSPF network types can be compatible or not.
Network types that use Type 2 LSAs include: broadcast and non-broadcast.
Others do not support Type 2 LSA packets.
The OSPF network type of an interface can be changed from its default using the
interface mode command: ip ospf network <network-type>
where network-type can be any of these values: broadcast,
non-broadcast, point-to-point, point-to-multipoint.
Broadcast networks with only two OSPF peers can be converted to point-to-point network type.
This makes the adjacency complete faster eliminating the unnecessary DR/BDR
election and OSPF Type 2 LSA advertisements.
To view interfaces on which OSPF has been activated i.e., interfaces whose
IP addresses or networks are being advertised by OSPF, issue the following
commands:
The following can be learned about the configuration and operational mode of
OSPF interfaces:
If multiple routers in multi-access networks are to form adjacencies with every
other router in the network, the total number of
adjacencies established is determined by the formula:
Total Adjacencies = n * (n - 1)/2
All these routers will be sending hello and update packets to each and every one of them.
In order to reduce the number of adjacencies (and OSPF packets) on a segment in a multi-access network,
OSPF elects one router to be a designated router and another to act as a backup designated router
to replace the designated router in the event of its failure.
A router initialising OSPF on an interface waits the duration of the wait timer
listening for the presence of other OSPF routers announcing their DR status before
declaring its DR status (if more favourable). In broadcast networks, the wait
timer is 40 seconds, nonbroadcast networks 120 seconds.
DR election is based on interface priority and router ID (RID). Usually, the first
router to initialize OSPF on an interface within a given number of seconds on a segment
becomes the DR regardless of its interface priority or RID.
OSPF deems a router more preferrable for DR election if:
The DR and BDR roles can not be preempted by a router with higher interface
priority or RID values. The election of a DR/BDR can be forced by clearing the
OSPF process of the DR and BDR. This can be done using the following command:
A DR is used in broadcast and non-broadcast networks and its primary role
consists of the following:
The DR acts as a pseudonode in the network segment. This pseudonode is a virtual
network node that forms point-to-point relationships with all the other devices
on that node. It acts as a central point forming multiple virtual point-to-point
links with all the OSPF peers on that node. These virtual links have a cost of
zero(0) so that they do not alter the cost of the physical link.
The SPF algorithm calculates paths based on the point-to-point links.
A Designated Router forms a FULL adjacency with all routers on the link.
The other routers (DROthers) form 2-WAY adjacencies with each other.
The BDR forms FULL adjacencies with all other routers as well.
The DR (and BDR) listens for LSUs on the multicast address 224.0.0.6. A router (DROther)
with an update sends it to the multicast address 224.0.0.6.
After receiving an LSU, the DR sends a unicast LSAck to that router to acknowledge receiving the update.
The DR then floods the LSU(s) to the segment using AllSPFRouters address 224.0.0.5.
The DR does not modify the next-hop value of this LSU.
The BDR is used for redundancy; if the DR fails, the BDR becomes the DR and a
new BDR is elected from the available DROther routers. The election of a new BDR from
the DROthers follows the same pattern as the election of the DR. The BDR does
not flood any updates but receives all updates sent to the DR.
The operation of a DR can be inefficient if only two devices are connected in a segment.
On networks that require DR operation (such as broadcast) and only two devices
are present, it may be more efficient to statically configure the interfaces with
a network type that does not require a DR for example a point-to-point network type.
This reduces the time to form an adjacency as well as elimination of the Type 2
LSA resulting in a smaller LSDB.
Multiple types of LSAs exist and the ones used depend on the design of the network.
LSAs are used to share link state information in an OSPF domain.
LSAs contain a sequence number as a form of version control to overcome problems that might be caused during
LSA propagation.
All LSAs are stored in the link state database (LSDB). A summary of the LSAs
in the LSDB and can be viewed by running the command
The originating router floods an LSA after every 1800 seconds (30 minutes).
OSPF continually monitors the LSDB; LSAs with LSAge of 3600 seconds (1hr) are
deemed invalid and purged from the LSDB. OSPF, also, uses this as a method of route withdrawal.
Every OSPF device has a link state database (LSDB). OSPF devices inside the same area
have the same LSDB.
The LSDB stores LSAs with the link state information in the local area and
summary information about the link states in other areas and external networks.
LSDBs are populated by LSAs of different types:
Type 1, Type 2, Type 3, Type 4, Type 5 and Type 7 LSAs.
An OSPF router receiving an LSA, checks its integrity
before placing it into the LSDB. This process continues
domain-wide until the LSDB of all routers in the same area are the same i.e.,
are synchronized.
The ultimate goal of any OSPF network design is to make the LSDB as stable as possible.
If a router has interfaces in more than one area, it will maintain separate LSDBs
for each area. All routers in an area must have identical LSDBs. To create a
loop-free domain, OSPF requires a synchronised LSDB and a loop-free calculation;
this calculation is implemented by SPF using Dijkstra's algorithm.
The LSDB contains a lot of information that can be used to gain insights into
the OSPF domain. Most of the commands used for querying the LSDB involve viewing stored
LSA information. A few other commands provide an overview of the state of the
LSDB.
When viewing the details of the LSAs in the LSDB, the phrase "Routing Bit Set" on
an LSA indicates that the route information learned from that LSA has been
installed in the routing table from the LSDB. This can be observed in the
following output where both paths are installed into the routing table:
LSA types 1, 3, 5 and 7 are used to advertise prefixes while LSA types 2 and 4
advertise router IDs.
Which LSA types are present on a network segment depends on the router's type,
OSPF network type and area type.
LSA types 1,2 are intra-area LSAs while LSA 3, 4 are inter-area LSAs. LSA Type 5,
7 advertise external routes. In single area topologies, Type 1, 2 and 5 are utilized.
Regardless of the type of LSA used, some fields are common to all LSAs such as
the following:
If the network contains multiple versions/copies of an LSA, the link state age
and sequence number are used to determine the version of LSA with the
most up-to-date link state information. If multiple copies of the same LSA exist,
the one with the newest information is used.
A Type 1 LSA contains networks of all OSPF-enabled interfaces on a router and their
associated cost. It is originated by all OSPF devices in the network. It is used
to describe the networks that a device is attached to and the device's placement
in the network.
Links advertised in a Type 1 LSA include stub links, point-to-point links, transit links.
Type 1 LSAs can be used to describe one or many interfaces and networks.
A Type 1 LSA is capable of advertising multiple links in one LSA.
The originator of Type 1 LSAs is all OSPF routers and flooding scope is an area.
The type of connection is indicated in the Type field. The type field contains one
of four different values: Link Type 1, Link Type 2, Link Type 3 and Link Type 4.
This represents a connection to a point to point link such as a serial connection.
A point-to-point link, is represented by two entries in the LSDB:
The following shows how point-to-point link state information is stored in the
LSDB:
Point-to-point links do not necessarily require IP addressing. IP unnumbered can
be used. With IP unnumbered configuration, the IP address is borrowed from another
interface of the router to represent the point-to-point link in the LSDB. In this
scenario, the point-to-point link is represented in the LSDB with a single entry.
The following output shows an LSA of a point-to-point interface configured as IP
unnumbered.
Link Type 2 defines a transit network.
For a transit network, neither the source nor the destination of the packets is
on the link. Traffic on this link is in transit. A transit network indicates the
presence of a Designated Router (DR) on the segment/link.
If the link ID and link data values are the same, then the advertising router is the DR.
The subnet mask of a transit link is contained in a Type 2 LSA that is advertised
by the DR in that segment.
If the transit link has one neighbor and that neighbor becomes unavailable, the
local router changes the type of link from transit to stub. Transit links imply
the existence of a neighbor and that the network type is broadcast or non-broadcast.
Link Type 3 indicates a connection to a stub network. These are networks that
have no other OSPF device such as an access LAN. With a stub network, the
traffic in this segment is either originating from this segment or has its
destination in this segment.
In addition, stub networks along with a point-to-point router LSA
describe the subnet that the point-to-point links occupy (Link Type 1 LSA).
Link Type 4 indicates a virtual link. Virtual links are used to
connect OSPF areas that are unable to connect to the backbone area.
The following is the output of the LSDB showing an entry of the Type 1 LSA with
link Type 4:
A Type 1 LSA link Type 4 is sent in a unicast LSU with the source and destination IP
addresses being the IP addresses of the virtual-link end points.
The Link ID value identifies the object that the link connects to, which could be: the router ID,
IP address of the interface of the DR, network address.
Type 1 LSAs can be viewed by running the command
show ip ospf database router.
The router LSA contains three different flags that indicate the role that a router
has in a network:
In multi-area OSPF domains, the ABRs and ASBRs flip a bit in the OSPF packet (hello) to indicate their role as an ABR
and/or ASBR.
In the global/VRF routing table, Type 1 LSAs received from other routers in the same area appear as intra-area routers
with the code "O"
The DR is the only router on a multi-access segment that advertises the Type 2 LSA.
A Type 2 LSA identifies all the routers attached to that network segment. This
shared network segment is of broadcast and non-broadcast type. The flooding
scope for a Type 2 LSA is the local area.
The Type 2 LSA lists the routers that are adjacent to the DR. When a DR is not used, this
type of information is listed in a Type 1 LSA. It is important to note that
Type 2 LSA does not propagate prefix information.
It is used to reduce redundant information in database and flooding scalability issues.
Type 1 LSAs Link Type 2 advertise transit networks without subnet mask information. Type 2
LSAs include subnet mask information for transit links. The DR advertises its
IP address, subnet mask and attached routers including itself.
If a DR is not elected, a Type 2 LSA is not present.
Type 1 and Type 2 LSAs are used for building the routing topology within an area.
Type 3 LSAs are generated by an area border router(ABR) and flooded into another
area. ABRs act as a sort of default gateway between the backbone area and a neighboring
non-backbone area. Type 3 LSAs contain networks that are reachable in other areas
through the ABR based on info from Type 1, Type 2, and Type 3 LSAs. Type 3
LSAs include the route cost but hide the ABR's actual path to the destination.
One Type 3 LSA is generated per prefix. If a Type 1 LSA contains five
prefixes, the ABR will create five Type 3 LSAs with one for each prefix.
When a network change occurs in an area, SPF is not run for ABR advertised type
3 LSA routes. This is because the ABR has already run SPF for those routes
(in their area of origin) from itself to the originating routers when they were received
as Type 1 LSAs. Additionally, the local routers have already run SPF for the route
from themselves to the ABR. LSA Type 3 are used to advertise summaries of link
state information to other areas.
The advertising router of a Type 3 LSA is the last ABR that advertises the prefix.
LSA types 1,2 do not cross borders to other areas. An ABR extracts prefix information
from Type 1 and Type 2 LSAs and inserts them into a Type 3 LSA for advertisement
into another area.
If an ABR receives a Type 3 LSA (sourced from a non-backbone area and injected to
the backbone area), it changes the advertising router to itself and forwards the
LSA to the second non-backbone area.
A Type 3 LSA is advertised into the neighboring area by the ABR. If a second ABR
is to advertise the Type 3 LSA into
a third area (after receiving it through the backbone), only the advertising
router field is updated by the second ABR.
To view Type 3 LSAs, issue the following command:
show ip ospf database summary.
R2#show ip ospf database summary
OSPF Router with ID (2.2.2.2) (Process ID 2)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 69
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.7.7.0 (summary Network Number)
Advertising Router: 6.6.6.6
LS Seq Number: 80000002
Checksum: 0xE820
Length: 28
Network Mask: /29
MTID: 0 Metric: 10
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 172
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.10.13.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000003
Checksum: 0xD443
Length: 28
Network Mask: /30
MTID: 0 Metric: 1
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1571
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.10.31.1 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x24DE
Length: 28
Network Mask: /32
MTID: 0 Metric: 2
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1571
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.10.34.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0xFA09
Length: 28
Network Mask: /30
MTID: 0 Metric: 2
The following is a Wireshark packet capture of a Type 3 LSA:
⋄LSA-Type 3 (Summary-LSA (IP network)), len 28
.000 0000 1010 1110 = LS Age (seconds): 174
0... .... .... .... = Do Not Age Flag: 0
Options: 0x22, (DC) Demand Circuits, (E) External Routing
0... .... = DN: Not set
.0.. .... = O: Not set
..1. .... = (DC) Demand Circuits: Supported
...0 .... = (L) LLS Data block: Not Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
LS Type: Summary-LSA (IP network) (3)
Link State ID: 10.255.1.24
Advertising Router: 1.1.1.1
Sequence Number: 0x80000005
Checksum: 0xce48
Length: 28
Netmask: 255.255.255.248
TOS: 0
Metric: 2
A Type 3 LSA contains the following information:
- Link state ID: the advertised summary network
- Advertising Router: RID of the last ABR advertising the LSA.
- Netmask: subnet mask value for the summary network.
Type 3 LSAs appear as inter-area routes with the code "O IA" in the global /
VRF RIB.
R2#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external Type 1, N2 - OSPF NSSA external Type 2
E1 - OSPF external Type 1, E2 - OSPF external Type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 11 subnets, 4 masks
O 10.0.16.0/30 [110/101] via 10.0.12.1, 00:57:46, GigabitEthernet0/0
O IA 10.7.7.0/29 [110/20] via 10.0.26.2, 00:47:06, GigabitEthernet1/0
O IA 10.10.13.0/30 [110/101] via 10.0.12.1, 00:57:46, GigabitEthernet0/0
O IA 10.10.31.1/32 [110/102] via 10.0.12.1, 00:42:34, GigabitEthernet0/0
O IA 10.10.34.0/30 [110/102] via 10.0.12.1, 00:42:34, GigabitEthernet0/0
172.30.0.0/30 is subnetted, 1 subnets
O E2 172.30.45.0 [110/20] via 10.0.12.1, 00:19:44, GigabitEthernet0/0
172.31.0.0/24 is subnetted, 3 subnets
O E2 172.31.10.0 [110/20] via 10.0.12.1, 00:19:35, GigabitEthernet0/0
O E2 172.31.11.0 [110/20] via 10.0.12.1, 00:19:35, GigabitEthernet0/0
O E2 172.31.12.0 [110/20] via 10.0.12.1, 00:19:35, GigabitEthernet0/0
O 192.168.6.0/24 [110/20] via 10.0.26.2, 00:47:06, GigabitEthernet1/0
Type 5 External LSA
Type 5 LSAs are used to advertise prefixes that were redistributed from another
routing domain i.e., redistributed external routes.
Type 5 LSAs are generated by an Autonomous-System Boundary Router (ASBR) to advertise
the routes that the ASBR is redistributing. Type 5 LSAs are flooded
throughout the OSPF domain to non-stubby areas. Only the LSAge parameter is
modified during this flooding.
Type 5 LSAs do not belong to any specific area. In the LSDB, Type 5 LSAs are listed at
the bottom of the output and are not associated with any area.
Fields included with an external LSA:
- Network mask: subnet mask of external network.
- Metric: Indicates the cost to reach the destination. Its calculation
and use is determined by the external metric type bit.
- External metric type: determines metric interpretation and calculation;
two available types include:
- Type 1: advertises a route with a seed metric. As the LSA is
propagated in the network, OSPF then adds additional path metric to it.
- Type 2: advertises a route with a static cost. This cost does
not change within the OSPF network. This metric type is the default Type 5
LSA with most vendors. It often works fine with a single connection
to the OSPF domain. If there are multiple connection points, the Type 1 external metric
type is preferred.
- Forwarding address: indicates where traffic is forwarded to reach
the advertised destination. Often set to 0.0.0.0 indicating that traffic to the
external network should be forwarded to the advertising router.
Type 5 LSAs can be viewed in greater detail using the privileged mode command:
show ip ospf database external.
R8#show ip ospf database external
OSPF Router with ID (8.8.8.8) (Process ID 8)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1218
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 172.30.0.0 (External Network Number )
Advertising Router: 11.11.11.11
LS Seq Number: 80000002
Checksum: 0x6C3C
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1218
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 172.30.1.0 (External Network Number )
Advertising Router: 11.11.11.11
LS Seq Number: 80000002
Checksum: 0x6146
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1218
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 172.30.2.0 (External Network Number )
Advertising Router: 11.11.11.11
LS Seq Number: 80000002
Checksum: 0x5650
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1218
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 172.30.3.0 (External Network Number )
Advertising Router: 11.11.11.11
LS Seq Number: 80000002
Checksum: 0x4B5A
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1218
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 172.255.255.0 (External Network Number )
Advertising Router: 11.11.11.11
LS Seq Number: 80000002
Checksum: 0xC306
Length: 36
Network Mask: /30
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
R8#
By default, external routes are redistributed as Type 2 external routes (with
code "O E2" in the routing table) with a metric of 20.
A Type 5 LSA includes a forwarding address field that directs where traffic
should be routed towards to reach the advertised link. Usually, this is the ASBR
but it could be set to another router in some network designs. A route tag is included in this LSA.
A forwarding address of 0.0.0.0 implies that traffic to the external routes should be forwarded to the ASBR that is
the advertising router for the external routes. If the forwarding address is not 0.0.0.0,
and this address is not configured on the advertising router, then one implication
is that the advertising router is implementing Type 7 to Type 5 LSA translation and
is there an ABR to an NSSA area. In this case, this ABR will double as an ASBR because of the Type 7/Type 5 LSA translation.
From the routing table, Type 5 LSAs have the code "O E1" or "O E2" to denote
OSPF external Type 1 LSA and external Type 2 LSAs respectively.
R8#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external Type 1, N2 - OSPF NSSA external Type 2
E1 - OSPF external Type 1, E2 - OSPF external Type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 36 subnets, 6 masks
O IA 10.1.1.0/24 [110/4] via 10.255.2.9, 01:34:59, GigabitEthernet1/0
O IA 10.1.2.0/24 [110/4] via 10.255.2.9, 01:15:26, GigabitEthernet1/0
O IA 10.1.3.0/24 [110/4] via 10.255.2.9, 01:15:16, GigabitEthernet1/0
O IA 10.1.4.0/24 [110/4] via 10.255.2.9, 01:15:16, GigabitEthernet1/0
O 10.2.8.0/24 [110/2] via 10.255.2.9, 01:12:44, GigabitEthernet1/0
O 10.2.9.0/24 [110/2] via 10.255.2.9, 01:12:44, GigabitEthernet1/0
O 10.2.10.0/24 [110/2] via 10.255.2.9, 01:12:34, GigabitEthernet1/0
O IA 10.3.1.0/24 [110/6] via 10.255.2.9, 01:11:59, GigabitEthernet1/0
O IA 10.3.2.0/24 [110/6] via 10.255.2.9, 01:11:55, GigabitEthernet1/0
O IA 10.3.3.1/32 [110/6] via 10.255.2.9, 01:30:32, GigabitEthernet1/0
O IA 10.3.4.0/23 [110/6] via 10.255.2.9, 01:11:06, GigabitEthernet1/0
O IA 10.255.1.0/30 [110/3] via 10.255.2.9, 01:34:59, GigabitEthernet1/0
O IA 10.255.1.4/30 [110/4] via 10.255.2.9, 01:34:59, GigabitEthernet1/0
O IA 10.255.1.8/30 [110/3] via 10.255.2.9, 01:34:59, GigabitEthernet1/0
O IA 10.255.1.16/30 [110/4] via 10.255.2.9, 01:34:59, GigabitEthernet1/0
O IA 10.255.1.24/29 [110/3] via 10.255.2.9, 01:34:59, GigabitEthernet1/0
O IA 10.255.1.28/30 [110/4] via 10.255.2.9, 01:34:59, GigabitEthernet1/0
O IA 10.255.1.32/29 [110/3] via 10.255.2.9, 01:34:59, GigabitEthernet1/0
O 10.255.2.0/30 [110/2] via 10.255.2.9, 01:50:45, GigabitEthernet1/0
O IA 10.255.3.0/30 [110/5] via 10.255.2.9, 01:30:32, GigabitEthernet1/0
O 10.255.254.0/30 [110/11] via 10.255.2.5, 01:50:40, GigabitEthernet0/0
O 10.255.254.4/30
[110/1563] via 10.255.2.5, 01:50:40, GigabitEthernet0/0
O IA 10.255.254.8/30 [110/4] via 10.255.2.9, 01:34:59, GigabitEthernet1/0
O 10.255.254.12/30 [110/2] via 10.255.2.9, 03:50:43, GigabitEthernet1/0
172.30.0.0/24 is subnetted, 4 subnets
O E2 172.30.0.0 [110/20] via 10.255.2.9, 01:00:46, GigabitEthernet1/0
O E2 172.30.1.0 [110/20] via 10.255.2.9, 01:00:46, GigabitEthernet1/0
O E2 172.30.2.0 [110/20] via 10.255.2.9, 01:00:46, GigabitEthernet1/0
O E2 172.30.3.0 [110/20] via 10.255.2.9, 01:00:46, GigabitEthernet1/0
172.255.0.0/30 is subnetted, 1 subnets
O E2 172.255.255.0 [110/20] via 10.255.2.9, 01:00:46, GigabitEthernet1/0
External Type 1 vs Type 2
External routes are classified as Type 1 or Type 2. The main differences between
Type 1 and Type 2 external OSPF routes are as follows:
- The Type 1 metric equals the redistribution metric plus the total path metric to the ASBR. In other
words, as the LSA propagates away from the originating ASBR, the metric increases.
- The Type 2 metric equals only the redistribution metric (by default 20). The metric is the same for the router next to
the ASBR as the router 30 hops away from the originating ASBR. This is the default external metric
type used by OSPF.
When making a path selection decision, an external Type 1 path is preferred to
an external Type 2 path. If there's a tie in Type 2 routes, then the cost
to reach the ASBR (forwarding metric) is the tie-breaker.
When making design considerations on whether to configure external routes as
external Type 1 or Type 2 routes:
- If the external metric is more important than the internal metric, then
choose Type 2 metric.
- External Type 2 metric can also be used if there is only one redistribution
point for the specific redistributed prefixes.
- Use external Type 1 metric if the internal metric is more important to the
external redistribution metric.
Type 4 LSA (ASBR-Summary)
Type 4 LSAs are generated by the ABR of the area with ASBR(s). Type 4 LSAs
provide a way for routers to locate the ASBR when the router is in a different
area from the ASBR. They provide information on the ABR's reachability to the
ASBR in other areas. It includes the cost but does not include the ABR's actual
path to the destination. SPF is not run for Type 4 LSAs when a network change
occurs.
It is created by the first ABR in the area where the ASBR is resident and provides
a summary route strictly for the ASBR of a Type 5 LSA.
The ASBR generates a Type 1 LSA with a flipped E-bit to identify as an ASBR. ABRs
in the same area as the ASBR will notice the flipped bit triggering the
generation of Type 4 LSA to enable routers forward traffic to external networks
towards the ASBR. Type 4 LSAs have the advertising router field updated by the
ABR as the advertising router.
The structure of Type 3 and Type 4 LSAs are identical. The only difference is
how the information is populated. The LS ID is set to the ASBR router-ID. The
network mask is set to 0.0.0.0 indicating that a single address is being advertised.
To view Type 4 LSAs: show ip ospf database asbr-summary
R8#show ip ospf database asbr-summary
OSPF Router with ID (8.8.8.8) (Process ID 8)
Summary ASB Link States (Area 7)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 3345
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 11.11.11.11 (AS Boundary Router address)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x7594
Length: 28
Network Mask: /0
MTID: 0 Metric: 2
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1399
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 11.11.11.11 (AS Boundary Router address)
Advertising Router: 2.2.2.2
LS Seq Number: 80000002
Checksum: 0x5FA4
Length: 28
Network Mask: /0
MTID: 0 Metric: 3
LS age: 1461
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 11.11.11.11 (AS Boundary Router address)
Advertising Router: 9.9.9.9
LS Seq Number: 80000002
Checksum: 0x8266
Length: 28
Network Mask: /0
MTID: 0 Metric: 2
R8#
The following output shows a Wireshark packet capture of an LSU containing a
Type 4 LSA.
» Frame 9166: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on interface -, id 0
» Ethernet II, Src: ca:05:06:30:00:38 (ca:05:06:30:00:38), Dst: IPv4mcast_05 (01:00:5e:00:00:05)
» Internet Protocol Version 4, Src: 10.255.254.14, Dst: 224.0.0.5
⋄ Open Shortest Path First
OSPF Header
Version: 2
Message Type: LS Update (4)
Packet Length: 56
Source OSPF Router: 6.6.6.6
Area ID: 0.0.0.7
Checksum: 0xa4f9 [correct]
Auth Type: Null (0)
Auth Data (none): 0000000000000000
LS Update Packet
Number of LSAs: 1
LSA-Type 4 (Summary-LSA (ASBR)), len 28
.000 0000 0000 0011 = LS Age (seconds): 3
0... .... .... .... = Do Not Age Flag: 0
Options: 0x22, (DC) Demand Circuits, (E) External Routing
0... .... = DN: Not set
.0.. .... = O: Not set
..1. .... = (DC) Demand Circuits: Supported
...0 .... = (L) LLS Data block: Not Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
LS Type: Summary-LSA (ASBR) (4)
Link State ID: 11.11.11.11
Advertising Router: 9.9.9.9
Sequence Number: 0x80000002
Checksum: 0x8266
Length: 28
Netmask: 0.0.0.0
TOS: 0
Metric: 2
The Type 4 LSA does not contain prefix information but router ID information on how the ASBR
can be accessed from another area. Therefore, Type 4 LSA information does not appear in the RIB.
Type 7 LSA NSSA
Stubby areas prevent Type 5 LSA propagation. Route redistribution is therefore
not possible in a stubby area.
However, local redistribution can be implemented in a not-so-stubby area (NSSA)
while still preventing Type 5 LSAs from being propagated into the NSSA. An NSSA
is a stubby area that is tweaked to permit redistribution through a Type 7 LSA
while still enforcing the filtering of Type 5 LSAs.
An ASBR advertises networks external to OSPF into NSSA as Type 7 LSAs. Type 7
LSAs cannnot be advertised outside the NSSA. This LSA includes a route tag.
The ASBR advertises the Type 7 LSA with the P-bit set. This P-bit instructs the
ABR of the NSSA to convert the Type 7 LSA to a Type 5 LSA. This makes the ABR have dual
role of ABR and ASBR for other areas. This second ABR generates a Type 4 LSA.
To view Type 7 LSAs: show ip ospf database nssa-external
R3#show ip ospf database nssa-external
OSPF Router with ID (3.3.3.3) (Process ID 3)
Type-7 AS External Link States (Area 10)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 415
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 172.30.45.0 (External Network Number )
Advertising Router: 4.4.4.4
LS Seq Number: 80000006
Checksum: 0x5EF5
Length: 36
Network Mask: /30
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.10.34.2
External Route Tag: 0
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 414
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 172.31.10.0 (External Network Number )
Advertising Router: 4.4.4.4
LS Seq Number: 80000006
Checksum: 0xE68C
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.10.34.2
External Route Tag: 0
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 414
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 172.31.11.0 (External Network Number )
Advertising Router: 4.4.4.4
LS Seq Number: 80000006
Checksum: 0xDB96
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.10.34.2
External Route Tag: 0
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 415
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 172.31.12.0 (External Network Number )
Advertising Router: 4.4.4.4
LS Seq Number: 80000006
Checksum: 0xD0A0
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.10.34.2
External Route Tag: 0
R3#
The default NSSA route type advertisement is NSSA LSA Type 2 and appear in the RIB as "O N2" routes.
R3#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external Type 1, N2 - OSPF NSSA external Type 2
E1 - OSPF external Type 1, E2 - OSPF external Type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 11 subnets, 4 masks
O IA 10.0.12.0/30 [110/2] via 10.10.13.1, 04:39:36, GigabitEthernet1/0
O IA 10.0.16.0/30 [110/2] via 10.10.13.1, 04:39:36, GigabitEthernet1/0
O IA 10.0.26.0/30 [110/12] via 10.10.13.1, 04:39:36, GigabitEthernet1/0
O IA 10.0.210.1/32 [110/3] via 10.10.13.1, 04:39:36, GigabitEthernet1/0
O IA 10.7.7.0/29 [110/12] via 10.10.13.1, 04:38:30, GigabitEthernet1/0
172.30.0.0/30 is subnetted, 1 subnets
O N2 172.30.45.0 [110/20] via 10.10.34.2, 00:16:51, GigabitEthernet0/0
172.31.0.0/24 is subnetted, 3 subnets
O N2 172.31.10.0 [110/20] via 10.10.34.2, 00:16:51, GigabitEthernet0/0
O N2 172.31.11.0 [110/20] via 10.10.34.2, 00:16:51, GigabitEthernet0/0
O N2 172.31.12.0 [110/20] via 10.10.34.2, 00:16:51, GigabitEthernet0/0
O IA 192.168.6.0/24 [110/12] via 10.10.13.1, 04:38:30, GigabitEthernet1/0
R3#
Other LSAs include:
- Type 6 LSA - Group membership: Not supported by IOS. can be gracefully ignored
using the command
router ospf 1
ignore lsa mospf
- Type 9 LSA - Link-local Opaque: used by NSF extensions
- Type 10 LSA - Area-local Opaque: used by MPLS-TE for constrained SPF in service
provider networks. In metric calculation it includes: Link attributes
(affinity or "color"), and bandwidth.
- Type 11 LSA - Domain-local opaque:
OSPF Hierarchy
OSPF Areas
An OSPF area is used to segment a large OSPF domain.
An area defines a flooding domain. All devices in the area agree on the topology
with features such as authentication type, area ID, area type i.e. normal, stubby,
not-so-stubby area (NSSA). Changes inside the area require LSA flooding and
full SPF execution.
All routers in an area execute SPF algorithm when the network changes for
example; when links fail, when failed links are restored, new routes added,
existing routes withdrawn.
It is important to note that a router becomes a member of an area if any one of
its interfaces is participating in the area.
To determine the OSPF areas that a router is participating in, issue the commands
show ip ospf interface brief and show ip ospf:
R1#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi0/0 1 0 10.0.12.1/30 1 DR 1/1
Fa3/0 1 0 10.0.16.1/30 1 P2P 0/0
Gi1/0 1 10 10.10.13.1/30 1 P2P 0/0
R1#
R1#show ip ospf
Routing Process "ospf 1" with ID 1.1.1.1
Start time: 00:00:32.764, Time elapsed: 01:57:36.228
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 3101)
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
It is an area border and autonomous system boundary router
Redistributing External Routes from,
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 2. 1 normal 0 stub 1 nssa
Number of areas transit capable is 0
External flood list length 0
IETF NSF helper support enabled
Cisco NSF helper support enabled
Reference bandwidth unit is 100 mbps
Area BACKBONE(0)
Number of interfaces in this area is 2
Area has message digest authentication
SPF algorithm last executed 00:58:20.520 ago
SPF algorithm executed 3 times
Area ranges are
Number of LSA 4. Checksum Sum 0x03233A
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 10
Number of interfaces in this area is 1
It is a NSSA area
Perform type-7/type-5 LSA translation
Area has no authentication
SPF algorithm last executed 01:57:24.284 ago
SPF algorithm executed 2 times
Area ranges are
Number of LSA 5. Checksum Sum 0x035534
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
R1(config-if)#
If the output of the command show ip ospf shows that the router is
participating in more than one area, then the router is an ABR.
As more routers are added to the OSPF domain, the flooding domain
increases along with the size of the LSDB. To control the size of the OSPF
flood domain, it is necessary to modify the flat OSPF topology (referred to as
single-area OSPF), into a two hierarchical topology (usually referred to as multi-area OSPF).
Multi-area OSPF
Multi-area OSPF involves the deployment of a two-tier hierarchical topology
that consists of the backbone area (area 0) and non-backbone area(s).
Multi-area OSPF topology is usually deployed to cater for network scalability
geographically as well was increasing numbers of routers, prefixes. A combination of the
following factors may influence the decision to deploy a multi-area OSPF topology:
- High processor utilization in routers in the OSPF area.
- High number of SPF executions.
- Large number of prefixes in the RIB.
- Large number of routers in the OSPF domain.
- Presence of low-capacity routers i.e., low memory, processing power,
in the OSPF domain.
- Inherent challenges with optimizing OSPF when using single area topology
such as inability to implement route summarization and filtering.
OSPF Design Decisions
Scaling is determined by the utilization of three router resources: memory, CPU,
and interface bandwidth. The workload that
OSPF imposes on a router depends on these factors:
- Number of adjacent neighbors for any one router: OSPF floods all link state
changes to all routers in an area. Routers with many neighbors have the most work
to do when link state changes occur. In general, any one router should have no more than 60 neighbors.
- Number of adjacent routers in an area: OSPF uses a CPU-intensive algorithm.
The number of calculations that must be performed given
n link state packets
is proportional to n log n. As a result, the larger and more unstable the area,
the greater the likelihood for performance problems associated with routing
protocol recalculation. Generally, an area should have no more than 50 routers.
Areas that suffer with unstable links should be smaller.
- Number of areas supported by any one router: A router must run the
link state algorithm for each link state change that occurs for every area in
which the router resides. Every ABR is in at least two areas (the backbone
and one adjacent area). In general, to maximize stability, one router should
not be in more than three areas.
- Designated router (DR) selection: In general, the DR and backup
designated router (BDR) on a multiaccess link (for example, Ethernet) have
the most OSPF work to do. It is a good idea to select routers that are not
already heavily loaded with CPU-intensive activities to be the DR and BDR.
In addition, it is generally not a good idea to select the same router to be
the DR on many multiaccess links simultaneously.
The first and most important decision when designing an OSPF network is to
determine which routers and links are to be included in the backbone area and
which are to be included in each adjacent area.
When configuring single area OSPF, any area ID can be used and prefix exchange
will take place. In multi-area OSPF networks, area zero (0) must be configured with
inter-area traffic transiting area 0.
Inter-area routing is similar to distance vector because routers in another area
do not have a detailed view of the local area. So they rely on the Type 3 network
summary LSAs. Changes such as the addition of a new network, link flapping/failure
outside the area don't always require LSA flooding or SPF limiting the impact on
router resources.
Backbone Area (Area 0)
At the center of an OSPF hierarchy is area 0 also known as the backbone area.
It is used to summarize topology information from other areas. Traffic from
one area to another must transit area 0. Area 0 must be contiguous. The only
exception to this is the use of a virtual link.
Multi-area OSPF domains are governed by the following OSPF design guides:
- In any multi-area OSPF domain, a backbone area must exist.
- All other areas must connect to the backbone area.
- The backbone area must be contiguous; there must be one single OSPF area zero.
Non-backbone Area
Non-backbone areas are OSPF areas that connect to the backbone area. There are
two types of non-backbone areas: normal areas and stub areas. All non-backbone
areas must connect to the backbone area which can act as a sort of transit hub
area interconnecting non-backbone areas.
If a scenario occurs where a non-backbone area cannot connect directly to the
backbone area, then a virtual link must be configured to connect the
non-backbone area to the backbone area.
Non-backbone areas configured
as stub areas affect the way link state information is shared between the different
areas and the types of LSAs used. The types of stub areas include: stubby
area, not-so-stubby-area (NSSA), totally stubby area and totally NSSA.
To configure a stub area, every router in the stub area needs to be configured as a stub.
Stub areas are identified by the stub area flag in the hello packet.
Stubby areas and not-so-stubby-areas are based on
RFC 2328 while totally
stubby and totally NSSA are non-standard (vendor specific) area types.
Stubby Area
Stubby areas prohibit Type 5 LSAs and thereby preventing Type 4 LSAs from being propagated.
When a Type 5 LSA reaches the ABR of a stubby area, it generates a Type 3 default route for the
stubby area. All external routes (originated from outside the stubby area) are replaced
with a single entry, a default route.
Configuration of stubby areas reduces the processing and memory load on low-end
or heavily-loaded routers as the number of SPF executions reduces as well as the
size of the LSDB.
Stub areas are often used when there is a single exit point from an area into
the backbone. If multiple exit points exist, suboptimal routing may result if
an area is configured as a stub area.
The three rules of stubby areas:
- Area 0 cannot be a stubby area.
- A stubby area can not be transit area for a virtual link.
- An ASBR can not be present in a stubby area.
Configuration of a stubby area is accomplished using the OSPF mode command
area <area-id> stub. As the stub area flag must match on all routers
in the area; all routers in the stub area should have the above command configured.
When troubleshooting stubby area mismatches, use the debugging commands debug ip
ospf hello and debug ip ospf adjacencies.
Totally Stubby Area
A totally stubby area is similar to a stubby area. However, in addition to prohibiting
Type 4 and Type 5 LSAs, totally stubby areas prohibit Type 3 LSAs. The ABR
generates a Type 3 default route after receiving Type 3 and 5 LSAs.
Totally stubby areas do not allow redistribution inside of them implying that
ASBRs are not allowed in stub or totally stubby areas.
To configure a totally stubby area, on the ABR of the totally stubby area, enter
the following configuration;
area <area-id> stub no-summary. The other routers in the totally
stubby area can be configured with the stub area
command area <area-id> stub and the adjacency will still be formed.
However, to ensure consistency in configuration, it may be preferrable to enter
the same totally stubby area configuration command on all the routers in the
totally stubby area.
Totally stubby areas are suitable for areas with a single exit point to the
backbone i.e., one ABR. Multiple ABRs for a totally stubby area runs the risk
of introducing suboptimal external and inter-area route paths.
Not-So-Stubby Area (NSSA)
NSSAs provide a way to get around the restriction of redistribution in stubby areas and totally
stubby areas. Like stubby areas, NSSA areas apply stub area rules such as
prohibiting Type 5 LSA from entering the area at the ABR. However, NSSAs allow for local
redistribution. The ASBR advertises external networks with Type 7 LSAs (NSSA
LSA). Type 7 LSAs carry information common to Type 5 LSAs. The format of a Type
7 LSA is almost identical to a Type 5 LSA. The only exceptions are:
- Link state type is different
- Additional propagate(P) flag is added. The P bit tells the ABR to translate
Type 7 LSA to Type 5 LSA (Type 7/5 translation) and advertise it to the rest of
the OSPF domain. This effectively makes this ABR have the dual role of ABR and
ASBR from the perspective of the routers in the other OSPF areas.
-
For propagation, the forwarding address must be set in this type of LSA. If it
is not set, the ABR does not process the translation. If this happens, then
the Type 7 LSA link state information is limited to being advertised only
within the NSSA.
To configure an area as NSSA the command is area <area-id> nssa.
The ABR does not automatically advertise a default route when a Type 5 LSA is
blocked. The ABR of an NSSA area can be configured to advertise a default route
using the command:
area <area-id> nssa default-information-originate.
The optional default-information-originate keyword triggers
the ABR to generate a Type 7 default route into the NSSA.
Verification
The commands to verify the configuration of an NSSA area are:
show ip ospf
show ip protocols
A Type 7 LSA can only be flooded in its source area. A Type 7 LSA is conceptually
similar to LSA Types 1 and 2 in terms of how it is flooded.
The ABR of an NSSA translates a Type 7 LSA to Type 5 LSA for area 0.
While an NSSA cannot be a transit area, it can host an ASBR.
NSSAs are often seen with service providers.
Totally Not-So-Stubby Area (Totally NSSA)
NSSAs prohibit Type 4 and Type 5 LSAs. Totally NSSAs prohibit LSA type 3, 4, and, 5 but
allow for local redistribution. When the ABR in a totally NSSA receives a Type 3 or 5 LSA, it
generates a default route automatically on Cisco devices. Not all implementations
of OSPF generate this default route automatically. This default route is
a Type 3 LSA route. The Type 7 LSA arriving at the ABR of a totally NSSA is
translated into a Type 5 LSA.
To configure a totally NSSA, on the ABR, enter the following command:
area <area-id> nssa no-summary. Other routers in the totally NSSA
area can be configured with the command area <area-id> nssa and
adjacency will be formed. However, to maintain consistency in the configuration,
some prefer to configure the same command across all routers in the totally NSSA
area with the same command area <area-id> nssa no-summary.
OSPF Virtual Links
Discontiguous areas arise when a non-backbone area is not directly connected to
the backbone. Another scenario where discontiguous areas exist is where the
backbone area is split-up into two or more sections with each section separated by a non-backbone area.
Discontiguous areas cause the ABR of the discontiguous area not to be reachable
via SPT. An ABR can only advertise routes between areas when one of the areas it
is connected to is the backbone(area 0).
Some preconditions of virtual-links include the following:
- End-points must be reachable via a normal area (not a stub area).
OSPF stubby areas cannot be a transit area for a virtual-link.
- Transit area must not have filtering applied i.e. LSA Type 3 filters, distribute-lists.
- The virtual link end-points are members of the transit area.
Discontiguous areas are eliminated by adding new area 0 links and adjacencies. The links could be either physical
or virtual for example GRE.
OSPF virtual-links are a form of virtual area 0 adjacencies. They are used to
form multi-hop unicast area 0 adjacency. Virtual-links follow the already built shortest path first tree (SPT)
between ABRs to connect to the backbone.
As part of a two-tier hierarchy, area zero (0) must be contiguous. As indicated earlier, ABRs follow three fundamental rules when creating
Type 3 LSAs:
- Type 1 LSAs received from any area, the ABR creates a Type 3 LSA for the backbone area and non-backbone area.
- Type 3 LSAs received from area 0, the ABR creates a new Type 3 LSA for only non-backbone areas.
- Type 3 LSAs received from a non-backbone area are only inserted into the LSDB of the source area. ABRs do not create
a Type 3 LSA for the other areas (including a segmented area 0).
A virtual link is characterized by the following features:
- It is considered as a point-to-point unnumbered interface; it will not
have an IP address.
- Virtual link interfaces are part of area 0 or backbone area.
- Only OSPF overhead traffic transits the virtual link; this includes OSPF
packets such as Hello, DBD, LSR, LSU and LSAck. OSPF adjacencies can therefore
be formed through the virtual link.
- The virtual-link terminal end-points (routers where the virtual terminal is
configured):
- Virtual terminal endpoints become ABRs.
- belong to the same non-backbone area.
The tunnel (of a virtual-link) belongs to the backbone area and therefore the
router terminating the virtual link becomes an ABR. The area in which the
virtual-link endpoints are established is known as the transit area. Each router
identifies the remote router by its RID. The virtual-link can span one hop or
multiple hops from the remote virtual-link endpoint.
The virtual link is built using Type 1 LSAs with link-Type 4.
A virtual-link inherits costs from SPT cost between end-points. The cost must be below 65535
otherwise the virtual link will enter a down state.
A virtual-link runs as a demand circuit so errors in configuration could be hidden until flooding
occurs. As a demand circuit, when making configurations to the virtual link such
as authentication, the virtual link will have to be cleared first before the
configurations take effect.
The following configurations illustrate how to configure virtual-link endpoints:
R8(config)#router ospf 8
R8(config-router)#area 7 virtual-link 1.1.1.1
R8(config-router)#end
------------------------------------
R1(config)#router ospf 1
R1(config-router)#area 7 virtual-link 8.8.8.8
R1(config-router)#end
*Aug 15 14:59:34.035: %SYS-5-CONFIG_I: Configured from console by console
R1#
R1#show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 1.1.1.1 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 7, via interface GigabitEthernet0/0
Topology-MTID Cost Disabled Shutdown Topology Name
0 2 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:03
Adjacency State FULL (Hello suppressed)
Index 1/2, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
Message digest authentication enabled
Youngest key id is 1
The commands show ip ospf virtual-link and show ip
ospf interface can be used to verify the operational state of the virtual-link.
Virtual Link Interfaces
When a virtual link is configured, a virtual link interface is created through
which the virtual link is maintained.
R1#show ip ospf interface
OSPF_VL0 is up, line protocol is up
Internet Address 10.255.2.6/30, Area 0, Attached via Not Attached
Process ID 1, Router ID 1.1.1.1, Network Type VIRTUAL_LINK, Cost: 2
Topology-MTID Cost Disabled Shutdown Topology Name
0 2 no no Base
Configured as demand circuit
Run as demand circuit
DoNotAge LSA allowed
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:02
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 8.8.8.8 (Hello suppressed)
Suppress hello for 1 neighbor(s)
Message digest authentication enabled
Youngest key id is 1
The following are the characteristics of a
virtual link interface:
- The IP address of the virtual link is referenced from the IP address of
the exit interface of the local router through which the router at the remote
end of the virtual link is reached.
- The OSPF network type of the virtual link is virtual link but the operational
state is point-to-point.
- Hello packets are suppressed for virtual-links.
OSPF Router Types
- Internal Routers: all links of the router exist in one non-backbone
area.
- Backbone Router: these are routers that have at least one interface in
area 0 (backbone). It can be an internal router as well as an ABR
- Area Border Router (ABR): router has links in the backbone area and
a non-backbone area. The ABR interconnects the two areas. The ABR is the point
at which summarization and filtering is implemented in an OSPF domain.
- Autonomous System Boundary Router (ASBR): has at least one link in
the OSPF domain and another link in a non-OSPF domain for example IS-IS, EIGRP,
BGP, RIP domain. The ASBR redistributes routes to and/or from other routing
domains and OSPF. ASBRs can be connected to any OSPF area except the stubby
and totally stubby area.
The router type can be verified by using the following commands:
show ip protocolsshow ip ospfshow ip ospf border-routers
R1#show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 1.1.1.1
It is an area border and autonomous system boundary router
Redistributing External Routes from,
Number of areas in this router is 2. 1 normal 0 stub 1 nssa
Maximum path: 4
Routing for Networks:
10.0.12.1 0.0.0.0 area 0
...
To view all ABRs and ASBRs in the OSPF domain,
run the command show ip ospf border-routers with the optional
keyword detail appended for additional information.
R1#show ip ospf border-routers
OSPF Router with ID (1.1.1.1) (Process ID 1)
Base Topology (MTID 0)
Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 9.9.9.9 [1] via 10.255.1.36, FastEthernet3/0, ABR, Area 0.0.0.0, SPF 8
i 9.9.9.9 [1] via 10.255.1.6, GigabitEthernet0/0, ABR, Area 0.0.0.0, SPF 8
i 9.9.9.9 [2] via 10.255.254.14, GigabitEthernet4/0, ABR, Area 10, SPF 8
i 9.9.9.9 [2] via 10.255.254.2, GigabitEthernet1/0, ABR, Area 0.0.0.7, SPF 6
i 2.2.2.2 [1] via 10.255.1.34, FastEthernet3/0, ABR, Area 0.0.0.0, SPF 8
i 2.2.2.2 [1] via 10.255.1.2, GigabitEthernet2/0, ABR, Area 0.0.0.0, SPF 8
i 2.2.2.2 [3] via 10.255.254.2, GigabitEthernet1/0, ABR, Area 0.0.0.7, SPF 6
i 11.11.11.11 [2] via 10.255.254.14, GigabitEthernet4/0, ASBR, Area 10, SPF 8
R1#show ip ospf border-routers detail
OSPF Router with ID (1.1.1.1) (Process ID 1)
Base Topology (MTID 0)
Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 9.9.9.9 [1] via 10.255.1.36, FastEthernet3/0, ABR, Area 0.0.0.0, SPF 10
Source 9.9.9.9, PDB SPF 31, path flag: none
Flags: PathList
i 9.9.9.9 [1] via 10.255.1.6, GigabitEthernet0/0, ABR, Area 0.0.0.0, SPF 10
Source 9.9.9.9, PDB SPF 31, path flag: none
Flags: PathList
i 9.9.9.9 [2] via 10.255.254.14, GigabitEthernet4/0, ABR, Area 10, SPF 8
Source 9.9.9.9, PDB SPF 25, path flag: none
Flags: PathList
i 9.9.9.9 [2] via 10.255.254.2, GigabitEthernet1/0, ABR, Area 0.0.0.7, SPF 6
Source 9.9.9.9, PDB SPF 25, path flag: none
Flags: PathList
i 2.2.2.2 [1] via 10.255.1.34, FastEthernet3/0, ABR, Area 0.0.0.0, SPF 10
Source 2.2.2.2, PDB SPF 31, path flag: none
Flags: PathList
i 2.2.2.2 [1] via 10.255.1.2, GigabitEthernet2/0, ABR, Area 0.0.0.0, SPF 10
Source 2.2.2.2, PDB SPF 31, path flag: none
Flags: PathList
i 2.2.2.2 [3] via 10.255.254.2, GigabitEthernet1/0, ABR, Area 0.0.0.7, SPF 6
Source 2.2.2.2, PDB SPF 25, path flag: none
Flags: PathList
i 11.11.11.11 [2] via 10.255.254.14, GigabitEthernet4/0, ASBR, Area 10, SPF 8
Source 11.11.11.11, PDB SPF 25, path flag: none
Flags: PathList
R1#
Area Border Routers (ABRs)
An area border router connects the backbone area to one or more non-backbone areas.
This definition is extremely important; a router that connects two non-backbone
areas and is not connected to the backone area will have separate LSDBs for each
area but will not allow traffic from one non-backbone area to cross to the other
non-backbone area.
ABRs have the following features:
- ABR is a suitable point for filtering and summarization of inter-area
routes.
- ABRs maintain separate LSDBs for each area that their interfaces are part of. The
number of LSDBs maintained by an ABR is equal to the number of distinct areas
that it is participating in.
- In the Type 1 LSA header of an ABR, the B-bit is set to 1. This is how other
routers know that a router is an ABR.
Assuming that an ABR, R2, is connected to the backbone area and another area
(say Area 2); when this ABR, R2, receives Type 1 and Type 2 LSAs from Area 2, it
generates a Type 3 LSA which is a summary of the Type 1 and Type 2 LSA information
from Area 2. The cost of this Type 3 LSA will be the cost of the path from the
ABR to the originating router in Area 2. This Type 3 LSA is then flooded into
the backbone area with the cost being the cost from the ABR to the
originating router in Area 2.
If another ABR, R3, in the backbone area receives this Type 3 LSA flooded by R2,
it floods this Type 3 LSA into the non-backbone area, Area 3. R3 will calculate
the cost of its path to R2 and add this cost to the cost of the Type 3 LSA that
was calculated by R2. R3 will then flood this Type 3 LSA into non-backbone area
Area 3 with this new cummulative cost.
In a multi-area OSPF topology where a non-backbone area is connected to the
backbone area through two or more ABRs, if a Type 3 LSA is flooded into the
non-backbone area of ABR R1, ABR R2 which is connected to the same non-backbone
area will receive this Type 3 LSA from its interface(s) in the non-backbone area.
R2 will install these Type 3 LSAs into its LSDB but will not transfer the route
information from these LSAs to the routing table.
Autonomous System Boundary Router
An ASBR is a router that connects the OSPF domain to a non-OSPF domain. It
redistributes routes from the non-OSPF domain into the OSPF domain.
An ABR that is connected to an NSSA by default also becomes an ASBR as it generates
a Type 5 LSA and floods it into the backbone area.
OSPF Route Types and Preferences
OSPF routes are classified based on how they are sourced. These OSPF route types
include: intra-area routes, inter-area routes and external routes.
- Intra-area: these are routes that are sourced within an area.
In OSPF, the LSDB of single-area networks contain only intra-area routes.
- Inter-area: route sourced from one area X that appears in another
area Y.
- External routes: routes redistributed into OSPF from another
routing protocol or static routes. These are advertised
as Type 5 LSAs and appear as external Type 1 and external Type 2 routes.
Shortest Path First (SPF) Operation
Shortest path first (SPF) uses Dijkstra's algorithm; it takes the link state
database as input to generate
the loop-free shortest path tree (SPT) which is the shortest path to any destination
in the network. During a change in the network topology,
the SPT is rebuilt and the SPF algorithm runs again to calculate new shortest
paths from the changed network topology. These shortest paths are then presented
to the routing table for installation. If the path presented by OSPF is the most
specific or has the lowest administrative distance, they are installed
into the routing table. If multiple paths are discovered and there is a tie in cost,
then these paths are installed
into the routing table, a concept known as Equal Cost Multiple Paths (ECMP).
The SPF algorithm runs many complex
calculations which may be recursive. These calculations are resource intensive
consuming more processor time and memory. In OSPF areas that experience many
network changes such as flapping links, a significant amount of processor time is
spent on SPF execution. This may affect other functions of the router.
If the number of SPF calculations for an area is high, then it is a sign of an unstable network.
Care should be taken to ensure a proper design of the OSPF domain and configuration
of OSPF optimization features to ensure a stable network with few SPF executions.
Neighbor and Topology Maintenance
Once adjacencies have been established and SPT built, the OSPF state machine
tracks neighbor and topology changes. Hello packets are used to monitor the
availability of neighbors. LSUs are used to update neighbors of network changes.
Tracking Topology Changes
When a new LSA is received, it is checked against the LSDB for changes such as:
- Sequence number: used to differentiate same LSAs containing same network
information. The sequence number is usally used to differentiate LSAs containing
new topology information from the LSAs containing previous topology information.
- Age: used to keep information updated and withdraw old information. Periodic
flooding occurs every 30 minutes (1800 secs). LSAs whose LSA age
is equal to the MaxAge value of 3600 seconds are purged from the LSDB as they
are considered invalid.
- Checksum: used to verify that transmission and memory corruption have not
affected the integrity of the packet.
LSA Flooding
When a change is detected in the network, a new LSA is generated and flooded out
all OSPF links in the area. OSPF does not use split-horizon. Self-originated LSAs are simply
dropped.
The method used for flooding will depend on the following factors:
- The state of a device's LSDB.
- Specific network types used on a device's network interfaces
If new information is found within the contents of a database descriptor packet,
the local device sends an LSR requesting for the missing updates. The
determination of whether information should be updated if a copy already
exists in the LSDB is primarily based on the link state sequence number. The
sequence number of an LSA is updated when new information is received through
an LSU.
It is this sequence number that is used for comparison by OSPF where multiple
copies of the same LSA exist. If OSPF finds an LSA that is up-to-date
compared to the same LSA in its LSDB, then the local OSPF device includes it in the LSR
sent to the originator of the LSA.
If multiple devices use the same sequence number when flooding an LSA:
- First, the checksum is verified.
- The link state age is used to break any tie.
Flooding method depends on the network type:
- Multicast is used if multiple devices are being updated at the same time.
This is often seen on broadcast and non-broadcast networks that use a DR.
The DR sends the update to the address 224.0.0.5.
- For OSPF network types where multicast is not supported, OSPF packets are
transmitted in unicast. Here, OSPF adjacencies are usually configured statically
using the
neighbor command.
OSPF Path Selection
Metrics
The decision on the path to the destination for traffic is based on the path metric.
Metric is the cumulative OSPF cost along the path.
The OSPF metric is called cost. The cost is calculated based on the bandwidth of
the exit interface. The cost is calculated as follows;
cost = reference bandwidth ÷ interface bandwidth
The default OSPF reference bandwidth is 100mbps. With this default reference
bandwidth, OSPF is unable to differentiate the cost of Fast Ethernet (100mbps),
Gigabit Ethernet (1000mbps), Ten Gigabit Ethernet (10000mbps) interfaces.
All interfaces from Fast Ethernet or higher will have an OSPF cost of one (1). It is
imperative to modify the default reference bandwidth in network environments with interfaces
having Gigabit Ethernet or higher capacity interfaces so that OSPF can make more accurate path selection decisions.
This default reference bandwidth can be modified with the OSPF router mode command:
auto-cost reference-bandwidth <1-4294967>.
The bandwidth value is in megabits per second. It is recommended that the reference
bandwidth be an order of magnitude higher than the largest bandwidth link in the
OSPF domain. If the network has Ten Gigabit Ethernet links,
then set the reference bandwidth to 100Gbps.
R8(config-router)#auto-cost reference-bandwidth 10000
% OSPF: Reference bandwidth is changed.
Please ensure reference bandwidth is consistent across all routers.
R8(config-router)#do show ip ospf
Routing Process "ospf 8" with ID 8.8.8.8
Start time: 00:00:40.364, Time elapsed: 01:49:26.920
Supports only single TOS(TOS0) routes
.......
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 2. 2 normal 0 stub 0 nssa
Number of areas transit capable is 1
External flood list length 0
IETF NSF helper support enabled
Cisco NSF helper support enabled
Reference bandwidth unit is 10000 mbps
Area BACKBONE(0)
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 01:49:00.076 ago
SPF algorithm executed 2 times
........
The reference bandwidth should be set to the same value for all routers in the OSPF domain,
otherwise the risk of introducing suboptimal routing to the OSPF domain may be high.
Type 1 LSAs include the cost of each link which is in the range 1 - 65535.
The OSPF cost of a path is calculated based on the outgoing interface of a router.
Best Path Selection
When an OSPF device receives an LSA with the same link state information but different
properties, the best path selection process determines which path is selected
for installation into the routing table. OSPF uses the following criteria
for selecting the best path (in order of preference);
- Intra-area path with the lowest metric
- Inter-area path with the lowest metric
- External Type 1 path with the lowest metric
- NSSA Type 1 path with the lowest metric
- External Type 2 paths with the lowest metric
- External Type 2 paths with the lowest forwarding metric
- NSSA Type 2 path with the lowest metric.
It is important to note that the existence of N1 or N2 routes implies that E1
and E2 routes will not be existent in that area.
The above listed best path selection criteria supersedes the path metric; an
intra-area route will always be preferred to an inter-area route regardless of
the route cost of the intra-area route. This is OSPF's loop-prevention technique
in addition to the hub and spoke topology of the OSPF hierarchy which inherently
creates a loop-free topology.
In a proper network design, the above mentioned path criteria should not be used
in path selection. Ideally, routes should only be advertised from a single source.
The path selection criteria should only be used as a tie-breaker in a network
with extraordinary design considerations.
Virtual-Link Costs
Virtual-links inherit their cost from cost between the virtual-link endpoints.
A virtual-link must have a cost below 65535 (maximum metric) to initialize.
Link costs higher than 65535 could occur if reference bandwidth is higher and
virtual-link transits legacy links.
OSPF Optimization
OSPF optimization aims to achieve the following objectives:
- To reduce convergence time
- To minimise SPF executions
- To improve traffic patterns
- To reduce LSDB size
The default settings of OSPF work. However, network conditions may require tweaking
OSPF to improve performance while minimizing the load on the routers.
There are a variety of configurations that can improve the performance of OSPF.
These can be categorized into the following:
- Accelerating OSPF convergence through:
- Modifying default dead-interval and hello interval timers
- BFD
- Controlling LSA generation and propagation through:
- LSA throttling
- LSA flood pacing
- LSA group pacing
- LSA retransmission pacing
- Altering Shortest Path First behaviour through:
- SPF throttling
- Enabling incremental SPF (iSPF)
- Reducing the size of the LSDB through:
- Prefix summarization
- Creation of OSPF areas
- Filtering
- Reducing the effects of restarts on OSPF through:
- Traffic engineering through:
- Altering the administrative distance
- Interface bandwidth and link cost
- Default route propagation
Accelerating OSPF Convergence
The process of network convergence can be categorized into a set of
discreet events:
- Failure detection: the speed at which a device on the network can
detect and react to a failure of one of its own components, or the failure of
a peer.
- Information dissemination: the speed at which a detected failure
can be communicated to all OSPF devices in an area.
- Recovery: the speed at which all devices on the network having been
notified of the failure calculate an alternate path through which network traffic
can flow.
An improvement in any one of these stages lowers the convergence time. The
first of these stages, failure detection, can be the most problematic and
inconsistent:
- Different routing protocols use varying methods and timers to detect the
loss of a routing adjacency with a peer.
- Link-layer failure detection times can vary widely depending on the
physical media and the Layer 2 encapsulation used.
- Intervening devices (eg. layer 2 switch) can hide link-layer failures
from routing protocol peers.
OSPF failure detection time can be decreased through:
- Modification of default hello and dead interval timer values
- Use of Bi-Directional Forward Detection (BFD)
Hello and Dead Interval Timers
In today's converged high-bandwidth networks, the 40 second dead
interval timer to detect a failed neighbor are considered unacceptable.
Default OSPF timer values are not often the best method to rely on for failure
detection. The hello and dead-interval timers
can be modified to lower values to increase the speed of failure detection.
To modify the hello interval, use the interface mode command
ip ospf hello-interval <seconds> and the dead interval
ip ospf dead-interval <seconds>.
Modifying the default hello interval timer, results in the dead interval timer
being automatically modified to four times the value of the hello-interval.
The following configuration sets the hello interval timer value to 5
seconds and dead interval to 20 seconds:
R1(config)#interface Te3/0
R1(config-if)#ip ospf hello-interval 5
R1(config-if)#ip ospf dead-interval 20
An interface can be configured to send hello packets in sub-second intervals using the
interface command ip ospf dead-interval minimal hello-multiplier
<3-20>.
The multiplier value is the number of hello packets sent per second;
R1(config)#interface fa3/0
R1(config-if)#ip ospf dead-interval minimal hello-multiplier 4
R1(config-if)#end
R1#show ip ospf interface fa3/0
FastEthernet3/0 is up, line protocol is up
Internet Address 10.0.16.1/30, Area 0, Attached via Interface Enable
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST , Cost: 1
. . . .
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 1.1.1.1, Interface address 10.0.16.1
No backup designated router on this network
Timer intervals configured, Hello 250 msec, Dead 1, Wait 1, Retransmit 5
oob-resync timeout 40
Hello due in 58 msec
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
.....
R1#
Where 4 implies four hello packets are to be sent per second.
Configuration of a lower hello interval timer value to detect neighbor failure considerably
improves neighbor failure detection. However, it increases OSPF overhead traffic considerably
particularly if many OSPF devices exist on the network segment.
BFD is a preferred option for failure detection.
BFD
BFD is a light-weight protocol designed for rapid failure detection while
maintaining low overhead. BFD is not specific to OSPF and can be used as a single
failure detection mechanism by other IP routing protocols that support it such as
BGP. BFD operates at the line-card level with little involvement of the processor.
This implies that BFD operates primarily at the data plane and not at the control
plane.
BFD operates at layer 1 and layer 2 of the OSI model.
For BFD to be used for failure detection in OSPF domains, OSPF must first be configured with
adjacencies established.
Client protocols such as OSPF register with BFD to receive notifications when
failures are detected. Failure detection takes place usually in sub-seconds.
BFD supports two operating modes: asynchronous and demand modes.
- Asynchronous mode: supporting systems send packets back and forth
to one another. If BFD control packets are not detected, then client protocol
is notified and the session drops. Asynchronous mode is generally used in
production networks.
- Demand Mode: BFD assumes that another method is used to verify
connectivity.
Echo Function
Echo function can be used in either BFD demand mode or asynchronous mode. If the
BFD echo function is enabled, devices are configured to send echo packets towards
a remote system with the expectation of having them loopback.
This verifies the path to the remote system as well as the forwarding path of the
remote system. BFD sessions can be configured independently in both directions.
Configuration
Configuration of BFD takes two steps: enabling BFD on the interface and registering
failure detection using BFD in OSPF.
- BFD Configuration:
BFD is configured on the interface through which the OSPF adjacency is formed
using the interface command
bfd interval <50-999> min_rx
<50-999> multiplier <3-50>:
- interval: determines how frequently (in milliseconds) BFD packets will
be sent to BFD peers.
- min_rx: determines how frequently (in milliseconds) BFD packets
will be expected to be received from BFD peers.
- multiplier: The number of consecutive BFD packets which must be missed
from a BFD peer before declaring that peer unavailable, and informing the
higher-layer protocols of the failure.
- OSPF BFD Configuration:
- All OSPF-enabled interfaces: In the OSPF process, register BFD
as the failure detection mechanism using the command
bfd all-interfaces
to configure BFD on all OSPF enabled interfaces.
- Specific interfaces: To configure BFD on individual
interfaces, use the interface configuration command
ip ospf bfd.
Verification
BFD operation and statistics can be verified using the commands: show bfd summary
Controlling LSA Generation and Propagation
LSA generation and propagation in OSPF are controlled by the following features:
- LSA throttling
- LSA Pacing
- LSA flood pacing
- LSA group pacing
- LSA retransmisssion pacing
LSA Throttling
LSA throttling provides a way of limiting the generation of LSAs specifically the generation of
repeat same LSAs (with same LSA ID, LSA type and advertising router ID) during
network instability. Prior to LSA throttling, LSA generation was rate-limited to
5 seconds because of the default LSA wait timer interval.
When an initial LSU is sent, it is rate limited and can't be
resent for another five seconds. A similar condition occurs on received updates.
Waiting for 5 seconds slows convergence and sub-second network convergence was not possible.
LSA throttling alters how OSPF handles the generation of OSPF update packets.
This is done through the modification of the LSA start-interval, LSA
hold-interval and LSA max-interval:
- LSA start-interval: initial wait interval for LSA generation. The default
value is 0 milliseconds resulting in the first LSA being generated immediately.
- LSA hold-interval: minimum interval between the generation of another
same LSA. The default value is 5000 milliseconds. This value doubles every
time the same LSA is regenerated.
- LSA max-interval: the maximum wait time interval between LSA generation.
The LSA hold-interval cannot become greater than the max-interval. The default
value is 5000 milliseconds. If the max-interval is the same as the hold-interval,
then the hold-interval cannot double when an LSA is regenerated.
An initial LSA is sent immediately a network change is detected. The generation of the
second LSA is determined by the LSA start-interval. If an event occurs and OSPF
needs to send an additional update packet, it waits until the OSPF start
interval expires. At this point, the OSPF hold interval begins. If an event occurs
during this hold interval, the device waits to send that update packet till that
hold interval expires. If this happens, the next LSA hold interval is doubled.
This means that at the end of the initial hold interval, the update is sent but
the next update packet is held until the twice the hold interval unless the
LSA max-interval is reached. The LSA max-interval in this case is used as a
ceiling controlling how long the hold-interval could eventually become. This
doubling happens everytime an additional event occurs within the current hold
interval. When the max-interval is reached, it is used as the hold-interval to
delay LSA update packet generation until it expires. This remains true until
no events occur within two hold-intervals or max-intervals depending on the
situation. At this point, the process repeats and the start interval is used
if an event occurs.
LSA throttling sub-second values improves convergence and slows down update
generation time during periods of instability in the network.
Configuration
LSA throttling is enabled by default. The default LSA start-interval, hold-interval
and max-interval can be modified using the command timers throttle lsa
<0-600000> <0-600000> <0-600000>. These values are
in milliseconds. The following
example sets the LSA start-interval, hold-interval and max-interval to 0, 5 seconds
and 60 seconds respectively:
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#timers throttle lsa 0 5000 60000
R1(config-router)#end
*Nov 5 11:18:30.007: %SYS-5-CONFIG_I: Configured from console by console
R1#show ip ospf
Routing Process "ospf 1" with ID 1.1.1.1
Start time: 00:00:52.732, Time elapsed: 01:06:26.896
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 3101)
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
It is an area border and autonomous system boundary router
Redistributing External Routes from,
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Initial LSA throttle delay 0 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 60000 msecs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
It is recommended to set the minimum interval for accepting the same LSA.
If the same LSA is received earlier than the configured interval, it is dropped.
It is recommended that the arrival interval be less than or equal to the LSA
hold interval timer. To control the receipt of the same LSA packets, use the
command timers lsa arrival <0-600000>.
Update Packet Pacing
This is different from LSA throttling because it affects the behaviour of OSPF
packets that are not locally generated. Three different update timers that can
be modified include: flood pacing, retransmission pacing, group pacing.
- Flood pacing: controls the packet spacing between consecutive update packets in the
OSPF transmission queue. By default, on Cisco equipment, if multiple packets
exist in the transmission queue, they are sent every 33ms. This can be modified
using the command
timers pacing flood <5-100>. The value
is in milliseconds.
- Retransmission pacing: feature is similar to flood pacing feature but it affects
the retransmission queue. By default, on Cisco equipment, if multiple packets
exist in the retransmission queue, they are sent every 66ms. The retransmission
pacing can be configured using the OSPF command
timers pacing retransmission
<5-200>. The value is in milliseconds.
- Group pacing: controls how LSAs are refreshed by an OSPF device. The typical
LSA refresh rate is 30 minutes. If each individual LSA works on its own independent
timer, then packets could be transmitted all the time especially in large networks.
To mitigate this, LSA group pacing was introduced. Group pacing allows LSAs that
are expiring within the same general time to be sent simultaneously. On Cisco
equipment, the default is set to 240 seconds. All LSAs expiring within 240 seconds
are updated at the same time. This increases efficiency and lowers demand. To
configure group pacing value, use the OSPF command
timers pacing lsa-group
<1-1800>. The value is in seconds.
The default values of the pacing timers generally work well; it is not recommended
to modify them.
Modification will require extensive testing to ensure that the intended result is
accomplished. To view the LSA pacing values, use the command show ip
ospf:
R1#show ip ospf
Routing Process "ospf 1" with ID 1.1.1.1
Start time: 00:00:52.732, Time elapsed: 03:02:31.124
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 3101)
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
It is an area border and autonomous system boundary router
Redistributing External Routes from,
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Initial LSA throttle delay 0 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 60000 msecs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 1. Checksum Sum 0x007B7D
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 3. 3 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
IETF NSF helper support enabled
Cisco NSF helper support enabled
Reference bandwidth unit is 100 mbps
Area BACKBONE(0.0.0.0)
Altering SPF Algorithm Behaviour
Processing of SPF algorithm can be altered using SFP throttling and incremental SPF.
Altering the SPF behaviour may lower the processor load. However, it may result
in an increase in convergence time.
SPF Throttling
SPF throttling operates similar to LSA throttling. It controls when SPF is run
after an event occurs. This is done through the configuration of three parameters:
SPF start-interval, SPF hold-interval and SPF max-interval.
- SPF start-interval: the initial SPF schedule delay. By
default, the SPF-start timer is 5000 milliseconds.
- SPF hold-interval: the minimum hold time between two
consecutive SPF calculations. By default, the SPF-hold timer is 10000 milliseconds.
- SPF max-interval: the maximum wait time between two consecutive SPF
calculations. By default, the SPF-maximum timer is 10000 milliseconds.
When an event initially
occurs, the start-interval begins, once it expires, SPF is run using the new
information. At this point, the hold-interval starts to count down. If any new
event occurs during this hold-interval, then the SPF process is run once it expires.
A new hold-interval begins but with twice the configured hold-interval time. If
no event occurs within two hold-intervals, then the process resets and is governed
by the start-interval. The process of doubling the hold-interval when additional
events occur continues until the hold-interval timer reaches the max-interval time.
The max-interval acts as a timer ceiling. Once it is reached, SPF runs every
max-interval as long as additional events continue to occur. If no events occur
within two max-intervals, then the process resets. By default, on Cisco equipment,
the start-interval is 5 seconds and max-interval 10 seconds.
SPF throttling can be configured using the command timers throttle spf
<start-interval> <hold-interval> <max-interval>
. The three interval values range from 1-600000 milliseconds.
R1(config-router)#timers throttle spf 10000 20000 60000
R1(config-router)#do show ip ospf
Routing Process "ospf 1" with ID 1.1.1.1
Start time: 00:00:52.732, Time elapsed: 03:45:13.896
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 3101)
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
It is an area border and autonomous system boundary router
Redistributing External Routes from,
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 10000 msecs
Minimum hold time between two consecutive SPFs 20000 msecs
Maximum wait time between two consecutive SPFs 60000 msecs
Incremental-SPF disabled
Initial LSA throttle delay 0 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 60000 msecs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 1. Checksum Sum 0x00797E
Incremental SPF (iSPF)
When enabled, iSPF changes when and how SPF is run. Normally, when a Type 1 or
Type 2 LSA is generated due to a topology change, all devices within an area process it and SPF is run. Often
this is not required as it may not affect the SPT for every device. This results
in many nodes running SPF when they do not need to.
iSPF changes the rules making the running of SPF conditional based on three
conditions:
- Addition of a new leaf node:
Events such as the addition of a new leaf node do not affect SPT on existing
devices. Additional full SPF run is not needed. iSPF prevents full SPF run on
non-local devices. On local devices however, a full SPF run is still required.
- Change alters the SPT of a device: If a link failure occurs on
a path that is not the shortest path, then full SPF run is not required. iSPF
steps in and limits it.
- Whether a limited change happens to the current SPT: iSPF limits
the devices that fully run SPF to only the local devices and devices that are
downstream from the failure. Upstream devices do not need to run SPF.
To configure iSPF, use the command ispf in OSPF router mode.
R1(config)#router ospf 1
R1(config-router)#ispf
R1(config-router)#do show ip ospf
Routing Process "ospf 1" with ID 1.1.1.1
Start time: 00:00:52.732, Time elapsed: 04:01:26.532
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 3101)
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
It is an area border and autonomous system boundary router
Redistributing External Routes from,
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 10000 msecs
Minimum hold time between two consecutive SPFs 20000 msecs
Maximum wait time between two consecutive SPFs 60000 msecs
Incremental-SPF enabled
Initial LSA throttle delay 0 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 60000 msecs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 1. Checksum Sum 0x00777F
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
iSPF reduces the load on the router processor.
Reducing the Size of the LSDB
Reducing the size of the LSDB can be accomplished through the following features:
- Stub areas
- Summarization
- Filtering
- Prefix suppression
Stub Areas
Stub areas limit Type 4 and 5 LSAs. These are
replaced with a summary Type 3 LSA. Totally stubby areas extend this restriction
to include Type 3 LSAs. These features reduce the size of the LSAs. Stub areas
need to be configured for areas that have a single exit to the backbone area.
Network layer reachability information removed is replaced with a default route.
All routers in the area must agree on the stub area flag.
Summarization
OSPF scalability is achieved by minimising the number of routers (topology
summarization) and number of prefixes (prefix summarization). Topology
summarization is achieved through implementation of OSPF areas.
Prefix summarization reduces the number of routes in the RIB.
OSPF prefix summarization can only occur at the border between areas and at the
OSPF domain boundary with an external domain.
The two types of prefix summarization in OSPF are: area summarization and
external summarization.
Area Summarization
Area summarization is configured between areas on the ABR. Area summarization
filters Type 3 LSAs containing component routes and only the Type 3 LSA containing
the summary route is permitted across the ABR. When performing area summarization;
- Only intra-area routes are summarized. Inter-area routes in the area are
regenerated as normal.
- Summarization is configured on the ABR connected to the area with the
source component routes. An ABR must be part of the area where the component
prefixes to be summarised are sourced.
- The metric of the summary route is the lowest metric of the component
routes of the summary. In some circumstances, it may be better to
configure a static summary metric to reduce SPF executions if the metric of the
lowest cost component route changes.
- If multiple ABRs exist to a given area, summarization should be implemented
on all the ABRs that connect to the area whose routes are to be summarized.
Area summarization performed by ABR summarizes Type 1 LSAs into a Type 3 LSA.
Area summarization reduces the number of Type 3 LSAs in the LSDB. This provides
protection from processing remote network changes as they occur in other
areas. Link flaps in aggregate prefixes do not trigger SPF calculations in other areas.
Area summarization can be configured using the command
area <area-id> range <summary-address> <netmask>
R9(config-router)#area 0 range 10.1.32.0 255.255.252.0
A summary discard route is installed in the RIB of the ABR as a loop prevention mechanism.
The default metric for the summary LSA is the smallest metric associated with any
component prefix in the summary route. The summary route can have a static metric
configured to reduce CPU load or as part of traffic engineering by appending the
keyword cost <metric> to the area summarization command.
R9(config-router)#area 0 range 10.1.32.0 255.255.252.0 cost 10
External summarization
External summarization is configured on the ASBR for external routes
being redistributed into the OSPF domain. It is a good idea to limit the number
of individual routes being redistributed. This summary can be configured at the
ASBR. If the IP addressing of the external routes is not contiguous, external
summarization may introduce suboptimal routing problems.
External summarization summarizes Type 5 into Type 5 and Type 7 into Type 7 LSAs
by ASBR.
External summarization is performed on the redistributing ASBR. In the OSPF process
summary-address <network-address> <subnet-mask>.
A discard route is installed.
R11(config-router)#summary-address 172.30.0.0 255.255.252.0 tag 172300
The summary-address command includes the following options:
not-advertise: filter external prefixes from being redistributed.nssa-only: limit the summary route to NSSA area only.tag: to add a route-tag, advertise the summary address. This tag can be
matched in a route-map in a downstream router.
Summary Discard Route
When creating a summary route using the area range and
summary-address commands, a discard route is installed into
the routing table with an exit interface of Null0. The goal is to
drop traffic if longest match is summary or the destination network is a
component prefix of the summary address but matches no specific network.
The idea is that the router carrying out the summarization should not fall back to default route if
a component network is not found in the routing table. The administrative distance
of the discard route for redistributed routes and internal routes can be modified
using the OSPF discard-route command.
The following configuration modifies the administrative distance of the discard
route to 30 for intra-area routes and 40 for redistributed routes.
R11(config-router)#discard-route internal 30 external 40
Discard route can be disabled with the command:
no discard-route
Filtering
OSPF filtering can be implemented at the following locations:
- Internal i.e., between the LSDB and the routing table.
- Inter-area filtering: inter-area filtering is implemented at the Area
border router. Inter-area filtering can also be implemented by changing the area
type to one of the stub types.
- External filtering: this can be implemented at the ASBR. Changing the
area type can also apply filtering.
Type 3 LSA Filtering
Type 3 LSA filtering provides for granular control of the Type 3 LSAs that can
be advertised into an area or advertised out of an area at the ABR. The commands
to filter Type 3 LSAs are area ... filter-list and
area ... range.
area ... filter-list command
An ABR is able to filter Type 3 LSAs from areas that it is not directly connected
to using the filter-list keyword to the area
command.
Using the filter list, Type 3 LSAs can be filtered as they leave an area or as they
enter an area.
Filtering routes using a filter list at the ABR is a two-step process that
involves creation of a prefix list and referencing the prefix-list using
filter-list keyword of the area command.
R9(config)#ip prefix-list PL_10.255.1.0 deny 10.255.1.0/24 le 32
R9(config)#ip prefix-list PL_10.255.1.0 permit 0.0.0.0/0 le 32
R9(config)#router ospf 9
R9(config-router)#area 10 filter-list prefix PL_10.255.1.0 in
area ... range command
Type 3 LSAs can be filtered using the area summarization command by preventing Type 3
LSAs from being advertised into another
area by appending the not-advertise keyword. The above filtering
can alternatively be accomplished using the following configuration:
R9(config-router)#area 0 range 10.255.1.0 255.255.255.0 not-advertise
Unlike filtering using the area ... filter-list command,
filtering routes using the not-advertise keyword only works
on ABRs that are directly connected to the area whose networks are to the filtered.
Prefix Suppression
Implemented in Cisco's version of OSPF, prefix suppression provides for the
suppression of all connected prefixes. This can be implemented globally using
the OSPF mode command prefix-suppression or at the interface
using the command ip ospf prefix-suppression. When
configured globally, all connected prefixes that are not configured on loopback
interfaces, configured as secondary, or configured on passive interfaces are
suppressed. When configured this way, individual interfaces can have prefix
suppression disabled to allow their configured prefixes advertised. When
prefix suppression is configured on a local interface, all addresses configured
are suppressed including secondary addresses.
Prefix suppression is very handy especially on large networks to reduce the size
of the LSDB with a large number of transit links whose addresses are not often
used. The suppression of these addresses domain-wide can considerably reduce the
size of the LSDB. Such prefix suppression, though, does complicate troubleshooting
because these intermediate links cannot be accessed.
Local OSPF Route Filtering
Local OSPF route filtering involves preventing a router from installing a network
from the LSDB into the RIB. This involves two steps:
- Identification of the route (using an ACL, prefix-list, route-map)
- Applying the filtering using the
distribute-list command
R7(config)#ip access-list standard ACL_10.3.4.0
R7(config-std-nacl)#deny 10.3.4.0 0.0.0.255
R7(config-std-nacl)#permit any
R7(config-std-nacl)#exit
R7(config)#router ospf 7
R7(config-router)#distribute-list ACL_10.3.4.0 in
The filtered route still exists in the LSDB. It is advertised to other routers in
LSUs. However, it is not installed into the global/VRF RIB from the LSDB.
OSPF Network Types
Some OSPF network types utilize additional LSAs. It is a good idea to comprehensively
assess whether, it is efficient from a network design perspective, to maintain
the OSPF network type defaults. This is often seen with Ethernet used to connect
only two devices. Broadcast networks require the use of Type 2 LSAs, perform a
master/slave election; processes which increase the duration of the neighbor
adjacency formation and
also increase the size of the LSDB. In such cases, a broadcast network type can
be replaced with a point-to-point link to reduce the LSDB size and reduce the
number of stages in the neighbor formation process.
External Filtering: Filtering at ASBR
Filtering can be applied on the ASBR during redistribution or "special treatment"
of routes can be implemented such as configuration of a seed metric, metric type
for specific routes using a route-map. It involves the following steps:
- Step 1: Identify the "interesting prefixes" using an ACL or prefix list.
access-list 1 permit 10.1.1.0
- Step 2: Create a route-map:
route-map no16 deny 10
match ip address 1
route-map no16 permit 20
set metric 6789
set metric-type type-1
- Step 3: Apply the route-map
redistribute static subnets route-map no16
Filtering of redistributed routes can also be implemented using the command
summary-address with the keyword no-advertise.
Troubleshooting Filtering
When troubleshooting filtering errors, beware of the following:
- Type 3 LSA Filtering:
- Check that the prefix-list is correct.
- Be sure that the filtering is applied to the correct area.
- Ensure that the filtering is applied in the right direction.
- Ensure that filtering is applied to the appropriate ABRs. If an area
has more than one ABR, then filtering may need to be applied to all
ABRs unless traffic engineering is being applied.
Reducing the Effects of Restarts on OSPF
Graceful restart
allows for the restarting of OSPF without affecting the forwarding of traffic.
This is done by tweaking normal OSPF operation.
These actions are covered in RFC 3623 through graceful restart.
In normal operation, a device is restarted through a hard restart (powered off
and on using the power switch) or a soft restart (through software). In a hard
restart, there is no way to avoid dropping adjacencies as no Hello packets will
be received. This type of restart is not recommended in production networks.
In a soft restart, the OSPF devices alert neighbors of an impending restart by
flushing all LSAs that it originated and sending out empty Hello packets that
result in neighborships being dropped immediately. With this type of shutdown,
neighbors know immediately that a device is going to become unavailable and are
able to make the appropriate adjustments to the link state database and eventually
the routing table. Regardless of the restart option selected, traffic is interrupted especially
if the routing device does not separately implement duties of the control plane
and data plane. Many routing devices offload data-plane functions to the line cards
and the processor handles the control-plane functions.
With graceful restart, the control-plane can be restarted without affecting
the data plane (traffic). For this to function, the data-plane and control-plane functions must be
separated. The device must modify the normal behaviour of OSPF when a restart
occurs.
Normally, a device notifies its neighbors of a shutdown by advertising LSAs
with a max age. The neighbors re-run SPF affecting normal traffic. With graceful restart:
- The restarting device communicates with its neighbors and lets them know
that a restart is imminent.
- If the neighbors support this, they lock the neighborship between them
and the restarting device and maintain the appearance of a full adjacency.
- The neighbors continue to send traffic to the device as normal even though
the normal OSPF messages expected to be received are not.
- The communications between the restarting device and its neighbors are
made possible through the use of the Grace LSA. This LSA is sent out
all the OSPF interfaces with a link-local scope and lets its neighbors prepare
for a restart. It also includes an expected grace period. This period indicates
the amount of time that these neighboring devices should expect to maintain the
illusion of a full adjacency.
- Grace LSAs continue to be sent until they are acknowledged. If no
acknowledgement is received, then the restarting device terminates the
graceful restart and restarts normally.
- On restart, the restarting device does not originate or flush any LSAs. It
continues to use its re-restart routing tables until all neighborships come
back into normal operation. Part of this process is similar to a device
coming up normally. When successful, the data-path through the device remains
uninterrupted.
- Once this process is complete, the restarting router flushes the Grace LSA,
runs through the normal SPF process and re-originates its LSAs.
The graceful restart feature defines duties for two modes of operation: one for
the restarting device and another for the neighboring devices (helper devices).
The mode for these devices is typically referred to as helper mode. On Cisco
devices, the functions of graceful restart are referred to as non-stop
forwarding (NSF). Devices that support NSF directly are referrred to as
NSF-capable. Those devices that support helper mode are referred to as
NSF-aware
OSPF Traffic Engineering
Traffic engineering involves modification of OSPF default settings to affect traffic
patterns. Traffic engineering involves making the following configurations:
- Interface cost
- Administrative distance
- Default route propagation
Interface Cost
The link cost considered in the metric calculation is always of the exit
interface. This cost can be modified using the interface command bandwidth
or ip ospf cost:
- Interface bandwidth: using the interface command
bandwidth <value>
with the bandwidth value in kilobits per second:
R8(config)#interface g0/0
R8(config-if)#bandwidth 10000
R8(config-if)#do show interface g0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is i82543 (Livengood), address is ca08.05b3.0008 (bia ca08.05b3.0008)
Internet address is 10.7.7.3/29
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, link type is auto, media type is SX
...
However, it is not recommended to modify the OSPF interface cost by modifying the interface bandwidth as this modification
affects not only OSPF metric calculation but potentially the metric calculations
of other routing protocols.
- Interface cost: the OSPF cost can be modified using the interface mode command:
ip ospf cost <1 - 65535>.
R8(config-if)#do show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
VL0 8 0 10.7.7.3/29 1000 P2P 1/1
Gi0/0 8 7 10.7.7.3/29 1000 BDR 1/1
R8(config-if)#ip ospf cost ?
<1-65535> Cost
R8(config-if)#ip ospf cost 1
R8(config-if)#do show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
VL0 8 0 10.7.7.3/29 1000 P2P 1/1
Gi0/0 8 7 10.7.7.3/29 1 BDR 1/1
R8(config-if)#
- Process
auto-cost: Modification of the default reference bandwidth implicitly changes the OSPF cost.
- Process
neighbor cost: In NBMA networks, neighbors are statically configured using the OSPF router mode command
neighbor <x.x.x.x> cost <cost>. A static cost can be assigned to the link to this neighbor.
Administrative Distance
The default administrative distance of OSPF is 110. When implementing traffic engineering, some scenarios may
require the modification of the default AD of OSPF so that paths through
OSPF are preferred to paths from other routing protocols or paths from other
routing protocols are preferred to OSPF sourced routes.
This is particularly critical during route redistribution between OSPF and other
routing protocols.
To change the default AD of OSPF, use the router OSPF mode command
distance <1 - 255>.
R1(config)#router ospf 1
R1(config-router)#distance 80
To modify the AD of routes from a specific router use the OSPF command
distance <AD> <RID> <wildcard> where:
<AD>: is the administrative distance<RID>: is the router ID of the originating
router<wildcard> is the wildcard mask
R1(config-router)#distance 89 11.11.11.11 0.0.0.0
The AD of specific routes from a specific router can be modified by appending an
access control list (ACL) to the command.
R1(config)#ip access-list standard ACL_172.30.3.0
R1(config-std-nacl)#10 permit 172.30.3.0 0.0.0.255
R1(config-std-nacl)#20 deny any
R1(config-std-nacl)#exit
R1(config)#router ospf 1
R1(config-router)#distance 60 11.11.11.11 0.0.0.0 ACL_172.30.3.0
Verification of the modification of the AD of the routes identified by the ACL:
R1#show ip route 172.30.3.0
Routing entry for 172.30.3.0/24
Known via "ospf 1", distance 60, metric 20, type extern 2, forward metric 2
Last update from 10.255.254.14 on GigabitEthernet4/0, 00:05:49 ago
Routing Descriptor Blocks:
* 10.255.254.14, from 11.11.11.11, 00:05:49 ago, via GigabitEthernet4/0
Route metric is 20, traffic share count is 1
R1#
The command show ip protocols can also be used to verify
modification of the AD:
R1#show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 1.1.1.1
It is an area border and autonomous system boundary router
Redistributing External Routes from,
Number of areas in this router is 3. 3 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.255.1.0 0.0.0.3 area 0.0.0.0
10.255.1.5 0.0.0.0 area 0.0.0.0
10.255.1.33 0.0.0.0 area 0.0.0.0
10.255.254.0 0.0.0.3 area 0.0.0.7
Routing on Interfaces Configured Explicitly (Area 0.0.0.0):
GigabitEthernet0/0
Routing on Interfaces Configured Explicitly (Area 10):
GigabitEthernet4/0
Routing Information Sources:
Gateway Distance Last Update
2.2.2.2 80 00:02:44
5.5.5.5 80 00:02:44
4.4.4.4 80 00:02:44
9.9.9.9 80 00:02:44
10.10.10.10 80 00:02:44
11.11.11.11 60 00:02:44
8.8.8.8 80 00:02:44
7.7.7.7 80 00:02:44
6.6.6.6 80 00:02:44
Distance: (default is 80)
Address Wild mask Distance List
11.11.11.11 0.0.0.0 60 ACL_172.30.3.0
Default Route Propagation
On a router with a default route (usually static), the default route can be propagated
through OSPF using the command:
R1(config)#router ospf 1
R1(config-router)#default-information originate
The above command only works if the local router has a default route. To
propagate a default route regardless of whether the local router has a default
route;
R1(config-router)#default-information originate always
By default, the default route gets propagated as a Type 5 external route with
metric Type 2 LSA. This makes the router an ASBR.
R2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external Type 1, N2 - OSPF NSSA external Type 2
E1 - OSPF external Type 1, E2 - OSPF external Type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 10.255.1.33 to network 0.0.0.0
O*E2 0.0.0.0/0 [110/1] via 10.255.1.33, 00:00:14, GigabitEthernet4/0
[110/1] via 10.255.1.1, 00:00:14, GigabitEthernet1/0
10.0.0.0/8 is variably subnetted, 35 subnets, 6 masks
O 10.1.1.0/24 [110/2] via 10.255.1.27, 01:00:42, FastEthernet3/0
[110/2] via 10.255.1.10, 01:00:42, GigabitEthernet2/0
O 10.1.2.0/24 [110/2] via 10.255.1.27, 01:00:42, FastEthernet3/0
[110/2] via 10.255.1.10, 01:00:42, GigabitEthernet2/0
O 10.1.3.0/24 [110/2] via 10.255.1.27, 01:00:42, FastEthernet3/0
[110/2] via 10.255.1.10, 01:00:42, GigabitEthernet2/0
O 10.1.4.0/24 [110/2] via 10.255.1.27, 01:00:42, FastEthernet3/0
[110/2] via 10.255.1.10, 01:00:42, GigabitEthernet2/0
R2#show ip ospf database external 0.0.0.0
OSPF Router with ID (2.2.2.2) (Process ID 2)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 38
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x1D91
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 1
R2#
To modify characteristics of the default route;
R1(config-router)#default-information originate metric 50 metric-Type 1
where 50 is the seed OSPF cost of the default route and the metric type is set to
external Type 1.
In the various stub area types, the default route is propagated as a Type 3 LSA
by default by the ABR.
In NSSA areas, the default route is not generated by default. To generate the
default route, use the command area 10 nssa
default-information-originate. This command does not require a default
route to exist. Also, this command is entered after the command area 10
nssa. In a totally NSSA, default route is installed by default as a
Type 3 LSA.
OSPF Security
Security Threat Vectors and Motivations
A threat vector is a method or mechanism used to attack a specific system. There
are ways that OSPF is attacked.
OSPF is an interior gateway protocol and therefore not directly exposed to the insecure
public Internet. In the design of an OSPF network, OSPF devices should not be
allowed to communicate directly with devices in the public Internet. Because of this, a
layer of security is created that protects the OSPF domain from the Internet.
Therefore for an attack on OSPF, some kind of internal access may be required.
OSPF attacks involve listening to OSPF traffic to understand network traffic patterns and
provides the opportunity to modify how this traffic is forwarded. Listening to
OSPF traffic can be carried out through packet capture. OSPFv2 traffic does not
encrypt traffic. Based on packet captures, it is possible to determine the
network design as it offers a comprehensive network view. Through the packet
capture, it is possible to determine some of the security mechanisms used to
secure OSPF.
The threats to unauthorized access to OSPF could result in the introduction of
false link state information that could affect performance and network traffic
in a number of different ways:
- Traffic re-routing:
- To overwhelm sections of the OSPF domain with link
congestion.
- Traffic could be re-routed to a longer path to add additional delay.
- Traffic to nowhere to cause traffic to never reach its destination.
- Introduce constant recalculations to reduce performance of the
routing devices themselves through constant changing of link state information
being advertised.
OSPF Security Mechanisms
OSPF requires neighborship formation with multiple matching parameters. RFC 7474
introduced possibilities to lower risks of replay attacks. Some OSPF security
mechanisms include passive interfaces and authentication.
Passive Interfaces
Passive interfaces can be configured on leaf-node OSPF routers and particularly
on interfaces that connect to end-user devices such as access points, printers.
Configuring these interfaces as passive interfaces prevents the transmission of
Hello packets and therefore adjacency formation. This measure also prevents
threat actors from sniffing OSPF traffic and learning some information from the
hello packets.
Another additional benefit from passive interfaces is that an OSPF device does
not respond to hello packets transmitted to passive interfaces. This prevents
the injection of unauthorised OSPF traffic into the OSPF domain.
Passive interfaces can be configured in two ways:
- Passive interface: an interface is configured as passive individually
using the command
passive-interface <interface-id>
where <interface-id> is the interface to be configured
as passive.
- Passive interface default: all interfaces are configured as
passive interfaces using the OSPF mode command
passive-interface
default.
Each interface through which an adjacency is to be formed
should then be made an active interface using the OSPF command
no passive-interface <interface-id> where
<interface-id> is the interface to be made active.
OSPF Authentication
OSPF supports adjacency authentication to protect the control-plane from routing
injection attacks. The OSPF packet header includes the authentication method and
password for Type 1 authentication and hash for Type 2 authentication.
OSPF supports three types of authentication:
- Type 0 null: offers no authentication at all
- Type 1: Simple password with clear text password
- Type 2: Cryptographic MD5 or SHA; RFC 5709 introduced SHA authentication
which uses SHA-1, SHA-256, SHA-384 and SHA-512.
The OSPF authentication type can be configured in two different locations;
OSPF area and on the interface.:
- Area Authentication:
area authentication can be configured so that all router interfaces in an area
comply with the same type of authentication configured for that area. This is
done using the OSPF router mode command
area <area-id>
authentication . When configuring area level authentication, it is
important to note the following:
- The link level configuration overrides the process level authentication
configuration.
- The password is always configured on the link.
- Setting area authentication for area zero will require all virtual links
to configure that type of authentication as a virtual-link is a member of area
zero.
- Interface Authentication: this is configured at the interface using the
interface mode command
ip ospf authentication.
The adjacent routers need to be configured with the same authentication type and password
for them to maintain the adjacency.
Type 0 Authentication (Null)
Type 0 authentication is also referred to as null authentication. This is the
default type of authentication on all OSPF interfaces. Type 0 authentication is
similar to no authentication.
Type 1 Authentication (Plain-text)
Type 1 authentication sends the password in plain text in the OSPF header.
- Type 1 authentication can be configured for an OSPF area using the OSPF process command
area <area-id> authentication.
- At the interface, Type 1 authentication is configured using the interface
mode command
ip ospf authentication.
The authentication key is always configured on the
interface regardless of whether Type 1 authentication was enabled for the area.
This is done using the interface mode command ip ospf authentication-key
<key>. The following output is a Wireshark packet capture of
the header of an OSPF packet displaying Type 1 authentication:
OSPF Header
Version: 2
Message Type: Hello Packet (1)
Packet Length: 48
Source OSPF Router: 2.2.2.2
Area ID: 0.0.0.0 (Backbone)
Checksum: 0xcd96 [correct]
Auth Type: Simple password (1)
Auth Data (Simple): cisco
Type 2 Authentication
Type 2 authentication uses MD5 or SHA for hashing the password. The hashed password is then
included in the OSPF header.
- Area configuration: to enable Type 2 authentication for an OSPF area,
use the OSPF process command
area <area-id> authentication
message-digest.
- Interface configuration: Type 2 authentication is enabled at the
interface using the interface mode command
ip ospf authentication
message-digest
The MD5 key is then configured at the interface using the interface mode command
ip ospf message-digest-key <key-id> md5 <password> .
The key ID and password must match.
OSPF supports the following SHA algorithms: HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384,
HMAC-SHA-512. OSPF supports the use of key chains. When configuring the key chain,
the following features are configured for the keychain: the cryptographic
algorithm, key ID, key string.
R1(config)#key chain OSPF_KEY
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string cisco
R1(config-keychain-key)#cryptographic-algorithm HMAC-SHA-384
To configure the authentication key on the interface:
R1(config)#interface g1/0
R1(config)#ip ospf authentication key-chain OSPF_KEY
The following is the header of an OSPF packet after the configuration of Type 2
authentication using MD5.
OSPF Header
Version: 2
Message Type: DB Description (2)
Packet Length: 32
Source OSPF Router: 1.1.1.1
Area ID: 0.0.0.0 (Backbone)
Checksum: 0x0000 (None)
Auth Type: Cryptographic (2)
Auth Crypt Key id: 1
Auth Crypt Data Length: 16
Auth Crypt Sequence Number: 1667856667
Auth Crypt Data: a6df33177d1e6cdfc85153e69f1c3087
Type 2 authentication adds an additional TLV, the crypto authentication TLV:
Crypto Authentication TLV
TLV Type: 2
TLV Length: 20
Sequence number: 0x636982a9
Auth Data: 56650cbfc5a38d43dc18702f553ae0fb
Virtual-link Authentication
A virtual-link is an area 0 interface. It inherits area 0 authentication configurations.
The virtual-link is the interface, the key configuration goes at the interface.
The authentication type can be configured globally or at the interface.
Like any other OSPF interface, virtual-link interface authentication overrides the
area 0 configured authentication type.
The virtual-link runs as a demand circuit. Always clear the virtual-link after
configuring authentication.
Verification
Authentication can be verified using the following commands:
show ip ospf
Command verifies if authentication has been configured for the area.
R1#show ip ospf
Routing Process "ospf 1" with ID 1.1.1.1
Start time: 00:00:29.024, Time elapsed: 03:38:17.128
Supports only single TOS(TOS0) routes
..
Cisco NSF helper support enabled
Reference bandwidth unit is 100 mbps
Area BACKBONE(0.0.0.0)
Number of interfaces in this area is 4
Area has message digest authentication
SPF algorithm last executed 00:26:30.208 ago
SPF algorithm executed 17 times
Area ranges are
10.1.32.0/22 Passive Advertise
Number of LSA 17. Checksum Sum 0x097919
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 0.0.0.7
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:13:57.260 ago
SPF algorithm executed 19 times
Area ranges are
From the above output, Type 2 authentication has been configured for the backbone
area. Area authentication has not been configured for area 0.0.0.7.
show ip ospf interface
This command verifies the authentication type configured at the interface:
R1#show ip ospf interface
OSPF_VL0 is up, line protocol is up
Internet Address 10.255.254.1/30, Area 0.0.0.0, Attached via Not Attached
Process ID 1, Router ID 1.1.1.1, Network Type VIRTUAL_LINK, Cost: 2
Topology-MTID Cost Disabled Shutdown Topology Name
0 2 no no Base
Configured as demand circuit
Run as demand circuit
DoNotAge LSA allowed
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:02
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 4/6, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 12
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Message digest authentication enabled
Youngest key id is 1
.....
show ip ospf virtual-links
This command specifically verifies the operational state of the virtual links including
any authentication that may have been configured.
R1#show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 8.8.8.8 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 0.0.0.7, via interface GigabitEthernet1/0
Topology-MTID Cost Disabled Shutdown Topology Name
0 2 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:03
Message digest authentication enabled
Youngest key id is 1
R1#
OSPF Security Recommendations
- It is recommended to implement the highest authentication level supported on
a device.
- Best to use OSPFv3 to manage IPv4 networks. Though it uses IPv6 for security, it
is more secure.
- Implement the use of passive interfaces. This prevents OSPF communications on an
interface lowering the possibility of unwanted traffic injection. All interfaces
can be configured as passive by default.
Verification and Troubleshooting of Authentication
During verification and troubleshooting of OSPF authentication configuration,
take note of the following:
- Authentication type and password is the same between the OSPF neighbors.
- The interface mode authentication type overrides the area mode authentication.
- For Type 2 authentication, the key ID must match on the OSPF neighbors.
The following commands can the used to verify OSPF authentication configuration:
show ip ospfshow ip ospf interfaceshow key chain
With SHA/MD5 authentication, the packet is not encrypted. A digest of the key ID and password is embedded
in the packet header.
OSPFv3
Differences between OSPFv2 and OSPFv3
OSFPv3 is defined in RFC 5340.
Like OSPFv2, OSPFv3 uses IP protocol 89.
OSPFv3, in many ways functions similar to OSPF with most algorithms for OSPFv2 being preserved.
The key differences between OSPFv3 and OSPFv2:
- Packet format: OSPFv3 runs over IPv6 and the number of fields in the packet header has been reduced:
- The authentication fields have been removed
- Hello packet address information has been removed. Instead it contains the interface ID which is used as the network
-LSA's Link State ID if the router becomes a DR.
- Neighbor adjacencies: OSPFv3 inter-router communication is handled by link-local addressing with the
source IP address being exclusively a link-local IPv6 address; the only exception being virtual-links where a global
prefix is used.
The destination address depends on the network type.
- Support for IPv4 and IPv6: OSPFv3 supports IPv6 and IPv4 address-families. However, to advertise IPv4 prefixes,
both IPv4 and IPv6 must be enabled on the link due to OSPFv3 use of link-local addressing for inter-router communication.
- New LSA types: LSA types 8 (link) and 9 (intra-area prefix) have been introduced while types 3 and 4 have been renamed
to inter-area prefix and inter-area router LSA respectively.
- Removal of addressing semantics: addressing information has been removed from OSPFv3 packets and
is now carried as LSA payloads in Link State Update packets. This makes
OSPFv3 easily adaptable to new network protocols. The router-LSA and network-LSAs no longer contain network
addresses. They express topology information.
- Security: OSPFv3 does not natively support authentication as does OSPFv2. This is because the authentication
related headers have been removed.
However it leverages encryption and authentication features of IPSec.
OSPFv3 LSA Flooding Scope
OSPFv3 flooding scope is now explicitly coded in the LSA's LS type field:
- Link-local scope: limited to the local-link and not beyond. It is used for the link-LSA.
- Area scope: LSA flooding to a single area only. It is used for
router LSAs, network LSAs, inter-area prefix LSAs, inter-area router LSAs, and
intra-area prefix LSAs.
- Autonomous System scope: flooding throughout the entire OSPF routing domain.
OSPFv3 type 5 LSAs have AS flood-scoping. A router that originates AS-scoped LSAs is
considered an AS Boundary Router (ASBR) and will set its E-bit in router-LSAs for regular areas.
The LS type field has been increased from 8-bits to 16-bits. The three high-order bits of the new
LS type field allow for the encoding of flooding information:
- The first bit U (unrecognised) indicates how a router should handle an
LSA if it is unrecognised.
- The second and third bits, both S (scope) bits, indicate how the LSA
should be flooded.
- The remaining bits of the link-state field indicate the function code of the LSA.
OSPFv3 uses two multicast addresses to maintain neighbor adjacencies and support route exchange:
- FF02::5 (AllSPFRouters): In broadcast and non-broadcast network types,
the DR sends updates to DROthers using this multicast address and
its interface link-local address as the source IPv6 address. In point-to-point and point-to-multipoint network types,
routers send updates to the AllSPFRouters multicast address.
Where neighbors are configured manually, unicast updates are sent.
- FF02::6 (AllDRouters): address is configured automatically on a
designated router (DR) and backup designated router(BDR) interface in a broadcast
and non-broadcast network type after their successful election.
DROther routers send updates to this address and the DR updates the rest of the routers on the segment
by sending the update to the AllSPFRouters multicast address (FF02::5).
Presence of any of the OSPFv3 multicast addresses on an interface confirms that the network that interface is
participating in is being advertised with OSPFv3. This can be verified by the
command show ipv6 interface <interface-id>:
R7#show ipv6 interface gigabitethernet0/0
GigabitEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C807:5FF:FE33:8
No Virtual link-local address(es):
No global unicast address is configured
Joined group address(es):
FF02::1
FF02::2
FF02::5
FF02::6
FF02::1:FF33:8
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 30000)
ND advertised reachable time is 0 (unspecified)
ND advertised retransmit interval is 0 (unspecified)
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
R7#
From the output above, R7 is a DR or BDR on the segment that interface Gigabitethernet0/0 is
connected to.
Explicit Support for Multiple Instances Per Link
OSPFv3 supports the ability to run multiple OSPF protocol instances on a single link. This is accomplished through the
use of the "Instance ID" contained in the OSPF packet header and OSPFv3 interface data structures.
Instance ID affects the reception of OSPFv3 packets. Through support for multiple instances per link,
OSPFv3 makes it possible to have a single link belong to two or more OSPFv3 areas. Additionally, separate OSPF
routing domains may be configured with a link participating in each domain and the domains keeping their data structures
separate.
OSPFv3 Configuration
To enable a router to participate in an OSPFv3 domain:
- Initialize IPv6 unicast routing: OSPFv3 requires IPv6 to be running on the router. It will not initialize if
IPv6 is not enabled.
R7#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#ipv6 unicast-routing
- Initialize OSPFv3 process: with the config mode command
router ospfv6 <process-id>:
R7(config)#router ospfv3 1
- Define the router ID: the router ID (RID) is used to uniquely identify a router in
the OSPFv3 domain. If more than one router is using the same RID, some prefixes may be dropped by a
router with the belief that the dropped prefixes were locally originated. This will result in suboptimal
routing at best. Note that the RID of 0.0.0.0 is reserved and should not be used.
R7(config-router)#router-id 7.7.7.7
-
Step 4: Enable OSPFv3 on the interface:
R7(config)#interface gigabitethernet 0/0
R7(config-if)#ospfv3 1 ipv6 area 7
It is good practice to verify the OSPFv3 configuration:
R7#show ospfv3 interface gigabitethernet 0/0
GigabitEthernet0/0 is up, line protocol is up
Link Local Address FE80::C807:5FF:FE33:8, Interface ID 4
Area 7, Process ID 1, Instance ID 0, Router ID 7.7.7.7
Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 7.7.7.7, local address FE80::C807:5FF:FE33:8
Backup Designated router (ID) 6.6.6.6, local address FE80::C806:5FF:FE94:8
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:05
Graceful restart helper support enabled
Index 1/5/5, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 3, maximum is 10
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 2, Adjacent neighbor count is 2
Adjacent with neighbor 6.6.6.6 (Backup Designated Router)
Adjacent with neighbor 8.8.8.8
Suppress hello for 0 neighbor(s)
R7#
R7#show ospfv3 neighbor
OSPFv3 1 address-family ipv6 (router-id 7.7.7.7)
Neighbor ID Pri State Dead Time Interface ID Interface
8.8.8.8 0 FULL/ - 00:00:36 11 POS5/0
6.6.6.6 1 FULL/BDR 00:00:30 4 GigabitEthernet0/0
8.8.8.8 1 FULL/DROTHER 00:00:31 4 GigabitEthernet0/0
R7's Gigabitethernet0/0 interface does not have a global prefix configured. If R7 does not
have a global prefix configured on any of its interfaces, it will still form an adjacency. However, it will not
have prefixes to share in its updates.
Passive Interfaces
Passive interfaces are interfaces whose configured networks are advertised into OSPFv3, but
OSPFv3 neighbor adjacencies cannot form over these interfaces. Hello packets sent
to this interface are not processed.
Additionally, this interface does not receive Hello packets.
To make all interfaces passive:
R7(config)#router ospfv3 1
R7(config-router)#passive-interface default
After making all interfaces passive as indicated above, some interfaces will need to be
configured as active to allow adjacency formation and LSDB synchronization. This can be accomplished with
the negation command: no passive-interface <interface>
R7(config)#router ospfv3 1
R7(config-router)#no passive-interface gigabitethernet0/0
To configure a specific interface as a passive interface:
R7(config)#router ospfv3 1
R7(config-router)#passive-interface loopback 14
If not configured under a specific address-family, the passive-interface state applies to
an interface running both IPv4 and IPv6 network protocols.
OSPFv3 displays all interfaces on which it is running regardless of whether the interface
is configured as a passive interface or not.
R7#show ospfv3 interface brief
Interface PID Area AF Cost State Nbrs F/C
Lo10 1 7 IPv6 1 LOOP 0/0
Lo11 1 7 IPv6 1 LOOP 0/0
Lo13 1 7 IPv6 1 LOOP 0/0
Lo14 1 7 IPv6 1 LOOP 0/0
PO5/0 1 7 IPv6 1 P2P 1/1
Gi0/0 1 7 IPv6 1 DROTH 2/2
OSPFv3 Neighbor Adjacency
Neighboring OSPFv3-enabled routers need to become adjacent
before they can share their known prefixes. The adjacency stage depends on the OSPF network type of the neighbors.
Some adjacency preconditions exist:
- The router ID (RIDs) must be unique.
The RID can be viewed using most OSPFv3
show commands:
R7#show ospfv3
OSPFv3 1 address-family ipv6
Router ID 7.7.7.7
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Graceful restart helper support enabled
Reference bandwidth unit is 100 mbps
RFC1583 compatibility enabled
Area 7
Number of interfaces in this area is 6
SPF algorithm executed 2 times
Number of LSA 15. Checksum Sum 0x08DD16
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
R7#
- Interfaces must be OSPFv3 active (in an Up state). The interface through-which the
adjacency is to be formed must have OSPFv3 enabled on it and must not be in an OSPFv3 passive state.
- Interface MTU must match. Default MTU is 1500.
- Area ID for the segment must match.
- Need for a DR for the segment must match. The broadcast and non-broadcast network types require a DR while the point-to-point and point-to-multipoint network types do not require a DR.
- Hello and Dead intervals must match
- Authentication type and credentials must match
- Area type flags must match i.e. whether normal, stubby or Not-So-Stubby Area(NSSA).
Mismatched MTUs can be ignored using the command:
R7(config)# interface g0/0
R7(config-if)#ospfv3 mtu-ignore
However, ignoring MTU checks is not recommeded in production networks.
OSPF neighbor adjacencies transition through a maximum of eight states (depending on the network type):
- Down: in this state, no hello packets have been received from a neighbor.
Additionally, the OSPF-enabled interface of the local router may be shutdown.
- Attempt: unicast hello packet has been sent to neighbor but no hello
packet has been received back. This state applies to an OSPFv3 neighborship
that is manually configured using the OSPFv3 process command
neighbor x.x.x.x
in NBMA environments.
- Init: Received a hello from the neighbor. However, the neighbor router has not yet acknowledged the local router as a neighbor by including its RID in its hello packet header's 'Active Neighbor' field.
- 2-Way: Hello received from neighbor and neighbor has acknowledged the local router as a neighbor by including the local router RID in its 'Active Neighbor' field of the hello packet header. In broadcast and non-broadcast networks, DROther routers complete their adjacency formation with each other at the 2-Way stage. Election of the DR/BDR roles
is also started. The router with the higher RID is master during DR election. More on this in the next section.
- ExStart: The master/slave relationship is formed with the master being the router with the higher RID. The master controls aspects of the adjacency formation by choosing the starting sequence number for the database descriptor packets (DDP or DBD) that are used for actual exchange. Master and DR roles have no relationship. The master/slave role applies only to the local network connection between the two neighbors and does not influence the DR/BDR/DROther roles.
- Exchange: DDP or DBD packets are sent in unicast. A summary of the LSDB is exchanged through DBD packets. DBD sequence number is used for reliable acknowledgment / re-transmission.
- Loading: LSRs are sent asking for more information about particular LSAs that the local router does not have. Unicast LSUs are sent for missing links.
- Full: LSDBs of the routers are fully synchronized.
OSPF Areas
Like OSPFv2, OSPFv3 networks are built on a two-level hierarchical topology.
An area defines a flooding domain. All devices in the area agree on the topology with features such as authentication type,
area type i.e. normal, stubby, not-so-stubby area (NSSA).
Changes inside the area require LSA flooding and full SPF.
All routers in an area execute SPF when the network changes for example when links fail, when failed links are restored,
new routes added, existing routes withdrawn.
Inter-area routing is similar to distance vector because routers in another area do not have a detailed view of the local area. So they rely on the type 3 network summary LSAs. Changes such as the addition of a
new network, link flapping/failure outside the area don't always require
LSA flooding or SPF limiting the impact on router resources.
To determine the OSPFv3 areas that a router is participating in:
R1(config-if)#do show ospfv3 interface brief
Interface PID Area AF Cost State Nbrs F/C
Lo10 1 0 IPv6 1 LOOP 0/0
Lo11 1 0 IPv6 1 LOOP 0/0
Fa3/0 1 0 IPv6 1000 DR 1/1
Gi0/0 1 0 IPv6 100 BDR 1/1
Lo12 1 10 IPv6 1 LOOP 0/0
Gi1/0 1 10 IPv6 100 P2P 1/1
R1(config-if)#
R1(config-if)#do show ospfv3
OSPFv3 1 address-family ipv6
Router ID 1.1.1.1
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
It is an area border and autonomous system boundary router
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of areas in this router is 2. 1 normal 0 stub 1 nssa
Graceful restart helper support enabled
Reference bandwidth unit is 100000 mbps
RFC1583 compatibility enabled
Area BACKBONE(0)
Number of interfaces in this area is 4
SPF algorithm executed 11 times
Number of LSA 23. Checksum Sum 0x0CE520
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 10
Number of interfaces in this area is 2
It is a NSSA area
Perform type-7/type-5 LSA translation
Generates NSSA default route with cost 1
SPF algorithm executed 8 times
Number of LSA 23. Checksum Sum 0x08FB3F
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
OSPFv3 Router Types
OSPFv3 router types are similar to the OSPFv2 router types.
The router type can be verified by using the following commands:
R1(config-if)#do show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "ND"
IPv6 Routing Protocol is "ospf 1"
Router ID 1.1.1.1
Area border and autonomous system boundary router
Number of areas: 1 normal, 0 stub, 1 nssa
Interfaces (Area 0):
Loopback10
Loopback11
FastEthernet3/0
GigabitEthernet0/0
Interfaces (Area 10):
Loopback12
GigabitEthernet1/0
Redistribution:
None
Other commands such show ospfv3 can display the router's type.
OSPF Media Dependencies and Network Types
OSPFv3 has the same network types as OSPFv2 i.e., broadcast, nonbroadcast, point-to-point,
point-to-multipoint
OSPFv3 Packet Types
OSPFv3 supports up to five different types of packets to create and maintain neighborship adjacencies,
and exchange route information including withdrawing routes.
All the OSPFv3 network types use link-local addresses as source addresses;
| Type |
Packet |
Source |
Destination |
Purpose |
| 1 |
Hello |
Link-Local Address |
FF02::5 |
Discover and maintain neighbors |
| Link-local address |
Link-local address |
Initial adjacency formation |
| 2 |
Database descriptor packet (DDP or DBD) |
Link-local address |
Link-local address |
Summary / snapshot of the link-state database (LSDB) contents |
| 3 |
Link State Request (LSR) |
Link-local address |
Link-local address |
Request for additional information if missing in local LSDB |
| 4 |
Link State Update (LSU) |
Link-local address |
Link-local address |
Update in response to LSR |
| Link-local address (from DR) |
FF02::5 |
Database update to all DROther routers in a broadcast and non-broadcast network segment. |
| Link-local address (from DROther) |
FF02::6 |
Update from DROther to DR/BDR for subsequent flooding on broadcast/non-broadcast segment |
| 5 |
Link State Acknowledgement (LSAck) |
Link-local address |
Link-local address |
Response to LSU |
| Link-local address (from DR) |
FF02::5 |
Flooding acknowledgement |
| Link-local address (from DROther) |
FF02::6 |
Flooding acknowledgement to DR/BDR |
OSPFv3 Database (Link-State Database - LSDB)
The OSPFv3 database is the data structure where prefixes from the various received LSUs are stored.
The LSDB provides the input to the SPF function which generates an SPT with the local router at the root/top of the SPT.
The output of the SPF is the OSPFv3 RIB which presents routes to the router's RIB for consideration for installation into the
routing table/RIB. The LSDB can be viewed using the privileged mode command:
show ospfv3 database
OSPFv3 Link-State Advertisements (LSAs)
SPT uses only router and network LSAs for the building of the OSPFv3 topology.
The summary information on LSAs in the link-state database (LSDB) can be viewed
by issuing the privileged mode command show ospfv3 database.
R7#
R7#show ospfv3 database
OSPFv3 1 address-family ipv6 (router-id 7.7.7.7)
Router Link States (Area 7)
ADV Router Age Seq# Fragment ID Link count Bits
6.6.6.6 118 0x80000007 0 1 B
7.7.7.7 1388 0x80000004 0 1 None
8.8.8.8 1304 0x80000004 0 1 None
Net Link States (Area 7)
ADV Router Age Seq# Link ID Rtr count
6.6.6.6 1141 0x80000005 4 3
Inter Area Prefix Link States (Area 7)
ADV Router Age Seq# Prefix
6.6.6.6 884 0x80000005 2001:DB8:0:6:10::1/128
6.6.6.6 118 0x80000006 2001:DB8:0:16::2/127
6.6.6.6 118 0x80000006 2001:DB8:0:26::2/127
6.6.6.6 118 0x80000006 2001:DB8:0:2:10::1/128
6.6.6.6 118 0x80000006 2001:DB8:0:2:11::1/128
6.6.6.6 118 0x80000007 2001:DB8::12:2/127
6.6.6.6 118 0x80000007 2001:DB8::12:0/127
6.6.6.6 118 0x80000006 2001:DB8:0:16::/127
6.6.6.6 118 0x80000006 2001:DB8:0:26::/127
6.6.6.6 1164 0x80000001 2001:DB8:10:34::/127
6.6.6.6 1164 0x80000001 2001:DB8:10:13::2/127
Inter Area Router Link States (Area 7)
ADV Router Age Seq# Link ID Dest RtrID
6.6.6.6 1219 0x80000001 16843009 1.1.1.1
Link (Type-8) Link States (Area 7)
ADV Router Age Seq# Link ID Interface
6.6.6.6 1660 0x80000004 4 Gi0/0
7.7.7.7 1388 0x80000004 4 Gi0/0
8.8.8.8 1304 0x80000004 4 Gi0/0
Intra Area Prefix Link States (Area 7)
ADV Router Age Seq# Link ID Ref-lstype Ref-LSID
6.6.6.6 884 0x80000005 0 0x2001 0
7.7.7.7 1131 0x80000003 0 0x2001 0
Type-5 AS External Link States
ADV Router Age Seq# Prefix
1.1.1.1 1106 0x80000001 2001:DB8:FF:45:1::2/127
1.1.1.1 1106 0x80000001 2001:DB8:FFFF:10::/64
1.1.1.1 1106 0x80000001 2001:DB8:FFFF:11::/64
1.1.1.1 1106 0x80000001 2001:DB8:FFFF:12::/64
R7#
Link-State Advertisements (LSAs)
All addressing semantics have been removed from the LSA header, router-LSAs and network LSAs. These two LSAs
describe the OSPFv3 domain in a network protocol independent manner.
OSPFv3 LSAs include an options bit field that describes the router's capabilities:
- V6: router participates in IPv6 routing (introduced in OSPFv3).
- E: router is capable of processing external LSAs. A router in a stubby area sets the E-bit to clear (0).
Neighboring routers do not form adjacencies if they have mismatched E-bit settings
- R: router actively participates in forwarding traffic. If set to clear (0), it indicates that
the router is not to be used as a transit router for forwarding traffic but is still capable of exchanging router
information (introduced in OSPFv3).
- N: router supports type 7 LSAs (NSSA). Mismatched N-settings result in adjacency failures.
- DC: router is capable of suppressing future Hellos over interface. Interface must be configured
as demand circuits for hello packet suppression to occur.
When compared to OSPFv2, two new LSAs have been introduced: Type 8 (link) is used for link-local addresses and
Type 9 (intra-area prefix) is used for prefixes on links. The new LSAs separate the topology graph from Network-Layer
Reachability Information (NLRI).
With OSPFv2, prefix information is propagated by LSAs 1 and 2 for intra-area. If a prefix is added or removed,
full SPF is run.
With OSPFv3, prefix information is propagated through LSAs 8 and 9 to reference LSAs.
If a stub network is added or removed, full SPF is not required.
- Type 1 Router LSA (0x2001):
Every router generates router LSAs that describe the state and cost of
the router's interfaces to the area. In OSPFv3, the router LSA is modified from the LSA type 1 of OSPFv2.
Router LSA is only responsible for announcing interface parameters such as interface type and metric.
If a router's LSA bits are set to B, it is an ABR.
Type 1 router LSAs can be viewed using the privileged mode command:
show ospfv3 database router
R7#show ospfv3 database router
OSPFv3 1 address-family ipv6 (router-id 7.7.7.7
Router Link States (Area 7)
Routing Bit Set on this LSA
LS age: 65
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Router Links
Link State ID: 0
Advertising Router: 6.6.6.6
LS Seq Number: 8000000D
Checksum: 0xADA8
Length: 40
Area Border Router
Number of Links: 1
Link connected to: a Transit Network
Link Metric: 100
Local Interface ID: 4
Neighbor (DR) Interface ID: 4
Neighbor (DR) Router ID: 6.6.6.6
LS age: 591
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Router Links
Link State ID: 0
Advertising Router: 7.7.7.7
LS Seq Number: 8000000C
Checksum: 0x5B2A
Length: 56
Number of Links: 2
Link connected to: another Router (point-to-point)
Link Metric: 645
Local Interface ID: 11
Neighbor Interface ID: 11
Neighbor Router ID: 8.8.8.8
Link connected to: a Transit Network
Link Metric: 100
Local Interface ID: 4
Neighbor (DR) Interface ID: 4
Neighbor (DR) Router ID: 6.6.6.6
LS age: 746
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Router Links
Link State ID: 0
Advertising Router: 8.8.8.8
LS Seq Number: 8000000C
Checksum: 0xEA9A
Length: 56
Number of Links: 2
Link connected to: another Router (point-to-point)
Link Metric: 645
Local Interface ID: 11
Neighbor Interface ID: 11
Neighbor Router ID: 7.7.7.7
Link connected to: a Transit Network
Link Metric: 100
Local Interface ID: 4
Neighbor (DR) Interface ID: 4
Neighbor (DR) Router ID: 6.6.6.6
- Type 2 Network LSA (0x2002):
A DR in broadcast or non-broadcast network
generates a network LSA to announce all of the routers attached to the network segment including itself.
To view type 2 LSAs in the LSDB, issue the privileged mode command:
show ospfv3 database network
R7#show ospfv3 database network
OSPFv3 1 address-family ipv6 (router-id 7.7.7.7)
Net Link States (Area 7)
LS age: 1389
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Network Links
Link State ID: 4 (Interface ID of Designated Router)
Advertising Router: 7.7.7.7
LS Seq Number: 80000008
Checksum: 0x1E6B
Length: 36
Attached Router: 7.7.7.7
Attached Router: 6.6.6.6
Attached Router: 8.8.8.8
R7#
No prefix information is contained in the OSPFv3 type 2 network LSA.
- Type 3 Inter-area prefix LSA (0x2003):
Generated by ABRs to describe routes to IPv6 address prefixes that belong to other
areas. Renames the network summary LSA into inter-area prefix LSA.
R7#show ospfv3 database inter-area prefix
OSPFv3 1 address-family ipv6 (router-id 7.7.7.7)
Inter Area Prefix Link States (Area 7)
Routing Bit Set on this LSA
LS age: 1409
LS Type: Inter Area Prefix Links
Link State ID: 0
Advertising Router: 6.6.6.6
LS Seq Number: 80000008
Checksum: 0x8110
Length: 44
Metric: 0
Prefix Address: 2001:DB8:0:6:10::1
Prefix Length: 128, Options: None
Routing Bit Set on this LSA
LS age: 1409
LS Type: Inter Area Prefix Links
Link State ID: 1
Advertising Router: 6.6.6.6
LS Seq Number: 80000008
Checksum: 0xEEB5
Length: 44
Metric: 1000
Prefix Address: 2001:DB8:0:16::2
Prefix Length: 127, Options: None
Routing Bit Set on this LSA
LS age: 1409
LS Type: Inter Area Prefix Links
Link State ID: 2
Advertising Router: 6.6.6.6
LS Seq Number: 80000008
Checksum: 0xDB3F
Length: 44
Metric: 100
Prefix Address: 2001:DB8:0:26::2
Prefix Length: 127, Options: None
Routing Bit Set on this LSA
LS age: 24
LS Type: Inter Area Prefix Links
Link State ID: 3
Advertising Router: 6.6.6.6
LS Seq Number: 80000008
Checksum: 0x75B8
Length: 44
Metric: 100
Prefix Address: 2001:DB8:0:2:10::1
Prefix Length: 128, Options: None
Routing Bit Set on this LSA
LS age: 24
LS Type: Inter Area Prefix Links
Link State ID: 4
Advertising Router: 6.6.6.6
LS Seq Number: 80000008
Checksum: 0x7FAC
Length: 44
Metric: 100
Prefix Address: 2001:DB8:0:2:11::1
Prefix Length: 128, Options: None
Routing Bit Set on this LSA
LS age: 24
LS Type: Inter Area Prefix Links
Link State ID: 5
Advertising Router: 6.6.6.6
LS Seq Number: 80000008
Checksum: 0xC664
Length: 44
Metric: 101
Prefix Address: 2001:DB8::12:2
Prefix Length: 127, Options: None
Routing Bit Set on this LSA
LS age: 24
LS Type: Inter Area Prefix Links
Link State ID: 6
Advertising Router: 6.6.6.6
LS Seq Number: 80000008
Checksum: 0x7F99
Length: 44
Metric: 100
Prefix Address: 2001:DB8:0:26::
Prefix Length: 127, Options: None
Routing Bit Set on this LSA
LS age: 2797
LS Type: Inter Area Prefix Links
Link State ID: 7
Advertising Router: 6.6.6.6
LS Seq Number: 80000006
Checksum: 0x8220
Length: 44
Metric: 1000
Prefix Address: 2001:DB8:0:16::
Prefix Length: 127, Options: None
Routing Bit Set on this LSA
LS age: 2797
LS Type: Inter Area Prefix Links
Link State ID: 8
Advertising Router: 6.6.6.6
LS Seq Number: 80000006
Checksum: 0x78B3
Length: 44
Metric: 101
Prefix Address: 2001:DB8::12:0
Prefix Length: 127, Options: None
Routing Bit Set on this LSA
LS age: 2329
LS Type: Inter Area Prefix Links
Link State ID: 9
Advertising Router: 6.6.6.6
LS Seq Number: 80000007
Checksum: 0xFA53
Length: 44
Metric: 301
Prefix Address: 2001:DB8:10:13::2
Prefix Length: 127, Options: None
Routing Bit Set on this LSA
LS age: 2329
LS Type: Inter Area Prefix Links
Link State ID: 10
Advertising Router: 6.6.6.6
LS Seq Number: 80000007
Checksum: 0x111D
Length: 44
Metric: 301
Prefix Address: 2001:DB8:10:34::
Prefix Length: 127, Options: None
R7#
R7#
R7#show ipv6 route ospf
IPv6 Routing Table - default - 30 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPFv3 Intra, OI - OSPFv3 Inter, OE1 - OSPFv3 ext 1, OE2 - OSPFv3 ext 2
ON1 - OSPFv3 NSSA ext 1, ON2 - OSPFv3 NSSA ext 2, l - LISP
OI 2001:DB8::12:0/127 [110/102]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8::12:2/127 [110/102]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:2:10::1/128 [110/101]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:2:11::1/128 [110/101]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:6:10::1/128 [110/1]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:16::/127 [110/1001]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:16::2/127 [110/1001]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:26::/127 [110/101]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:26::2/127 [110/101]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
O 2001:DB8:7:8:10::1/128 [110/1]
via FE80::C808:5FF:FEB3:6, POS5/0
via FE80::C808:5FF:FEB3:8, GigabitEthernet0/0
O 2001:DB8:7:8:11::1/128 [110/1]
via FE80::C808:5FF:FEB3:6, POS5/0
via FE80::C808:5FF:FEB3:8, GigabitEthernet0/0
O 2001:DB8:7:8:12::1/128 [110/1]
via FE80::C808:5FF:FEB3:6, POS5/0
via FE80::C808:5FF:FEB3:8, GigabitEthernet0/0
O 2001:DB8:7:11::1/128 [110/1]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
O 2001:DB8:7:12::1/128 [110/1]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:10:13::2/127 [110/302]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:10:34::/127 [110/302]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OE2 2001:DB8:FF:45:1::2/127 [110/20]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OE2 2001:DB8:FFFF:10::/64 [110/20]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OE2 2001:DB8:FFFF:11::/64 [110/20]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OE2 2001:DB8:FFFF:12::/64 [110/20]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
R7#
Inter-area prefix LSAs appear in the RIB as "OI" routes.
- Type 4 Inter-area router LSA (0x2004):
Type 4 LSAs have been renamed from ASBR-summary in OSPFv2 to inter-area router LSAs in OSPFv3.
They are generated by ABRs to announce addresses of ASBRs in other areas. If a type 5 LSA is received by an ABR, the
ABR generates a type 4 LSA in the neighboring area to provide a mechanism through which the routers in another area
can identify a path to the ASBR. The inter-area router LSA can be viewed in the LSDB by issuing the privileged mode
command: show ospfv3 database inter-area router
R7#show ospfv3 database inter-area router
OSPFv3 1 address-family ipv6 (router-id 7.7.7.7)
Inter Area Router Link States (Area 7)
Routing Bit Set on this LSA
LS age: 555
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Inter Area Router Links
Link State ID: 16843009
Advertising Router: 6.6.6.6
LS Seq Number: 80000008
Checksum: 0xC6E
Length: 32
Metric: 101
Destination Router ID: 1.1.1.1
R7#
Type 4 LSAs do not contain prefix information. Type 4 inter-area router LSA is flooded in the
originating area.
- AS-External (0x4005):
ASBRs advertise AS external LSAs to announce default routes or routes learned
through redistribution. This type of LSA is flooded throughout the entire OSPFv3 domain to any non-stubby area.
Type 5 LSAs are not specific to any one area. In the LSDB, they are listed at the bottom of the LSA list.
Type 5 external LSAs can
be viewed in the LDSDB by issuing the command: show ospfv3 database external.
R7#
R7#show ospfv3 database external
OSPFv3 1 address-family ipv6 (router-id 7.7.7.7)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 3062
LS Type: AS External Link
Link State ID: 1
Advertising Router: 1.1.1.1
LS Seq Number: 80000007
Checksum: 0x1E9C
Length: 36
Prefix Address: 2001:DB8:FFFF:10::
Prefix Length: 64, Options: None
Metric Type: 2 (Larger than any link state path)
Metric: 20
Routing Bit Set on this LSA
LS age: 3062
LS Type: AS External Link
Link State ID: 2
Advertising Router: 1.1.1.1
LS Seq Number: 80000007
Checksum: 0x2692
Length: 36
Prefix Address: 2001:DB8:FFFF:11::
Prefix Length: 64, Options: None
Metric Type: 2 (Larger than any link state path)
Metric: 20
Routing Bit Set on this LSA
LS age: 3062
LS Type: AS External Link
Link State ID: 3
Advertising Router: 1.1.1.1
LS Seq Number: 80000007
Checksum: 0x2E88
Length: 36
Prefix Address: 2001:DB8:FFFF:12::
Prefix Length: 64, Options: None
Metric Type: 2 (Larger than any link state path)
Metric: 20
Routing Bit Set on this LSA
LS age: 3062
LS Type: AS External Link
Link State ID: 4
Advertising Router: 1.1.1.1
LS Seq Number: 80000007
Checksum: 0xD067
Length: 44
Prefix Address: 2001:DB8:FF:45:1::2
Prefix Length: 127, Options: None
Metric Type: 2 (Larger than any link state path)
Metric: 20
R7#
R7#
R7#
R7#show ipv6 route ospf
IPv6 Routing Table - default - 30 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPFv3 Intra, OI - OSPFv3 Inter, OE1 - OSPFv3 ext 1, OE2 - OSPFv3 ext 2
ON1 - OSPFv3 NSSA ext 1, ON2 - OSPFv3 NSSA ext 2, l - LISP
OI 2001:DB8::12:0/127 [110/102]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8::12:2/127 [110/102]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:2:10::1/128 [110/101]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:2:11::1/128 [110/101]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:6:10::1/128 [110/1]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:16::/127 [110/1001]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:16::2/127 [110/1001]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:26::/127 [110/101]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:0:26::2/127 [110/101]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
O 2001:DB8:7:8:10::1/128 [110/1]
via FE80::C808:5FF:FEB3:6, POS5/0
via FE80::C808:5FF:FEB3:8, GigabitEthernet0/0
O 2001:DB8:7:8:11::1/128 [110/1]
via FE80::C808:5FF:FEB3:6, POS5/0
via FE80::C808:5FF:FEB3:8, GigabitEthernet0/0
O 2001:DB8:7:8:12::1/128 [110/1]
via FE80::C808:5FF:FEB3:6, POS5/0
via FE80::C808:5FF:FEB3:8, GigabitEthernet0/0
O 2001:DB8:7:11::1/128 [110/1]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
O 2001:DB8:7:12::1/128 [110/1]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:10:13::2/127 [110/302]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OI 2001:DB8:10:34::/127 [110/302]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OE2 2001:DB8:FF:45:1::2/127 [110/20]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OE2 2001:DB8:FFFF:10::/64 [110/20]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OE2 2001:DB8:FFFF:11::/64 [110/20]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
OE2 2001:DB8:FFFF:12::/64 [110/20]
via FE80::C806:5FF:FE94:8, GigabitEthernet0/0
R7#
The flooding scope of type 5 LSAs is the Autonomous System (AS).
Inclusion of a forwarding address or external route tag is now optional. AS-external LSAs can reference
another LSA for inclusion of additional route attributes outside the scope of the OSPFv3 protocol For example,
the reference may be used to attach BGP path attributes to external routes.
- Type 7 LSA NSSA(0x2007):
ASBRs in NSSA advertise locally redistributed routes using Type 7 NSSA-external
LSAs.
R3#show ospfv3 database nssa-external
OSPFv3 1 address-family ipv6 (router-id 3.3.3.3)
Type-7 AS External Link States (Area 10)
Routing Bit Set on this LSA
LS age: 1701
LS Type: AS External Link
Link State ID: 0
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x63CE
Length: 28
Prefix Address: ::
Prefix Length: 0, Options: None
Metric Type: 2 (Larger than any link state path)
Metric: 1
Routing Bit Set on this LSA
LS age: 558
LS Type: AS External Link
Link State ID: 0
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0xDFEB
Length: 36
Prefix Address: 2001:DB8:FFFF:10::
Prefix Length: 64, Options: P
Metric Type: 2 (Larger than any link state path)
Metric: 20
Routing Bit Set on this LSA
LS age: 558
LS Type: AS External Link
Link State ID: 1
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0xE7E1
Length: 36
Prefix Address: 2001:DB8:FFFF:11::
Prefix Length: 64, Options: P
Metric Type: 2 (Larger than any link state path)
Metric: 20
Routing Bit Set on this LSA
LS age: 558
LS Type: AS External Link
Link State ID: 2
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0xEFD7
Length: 36
Prefix Address: 2001:DB8:FFFF:12::
Prefix Length: 64, Options: P
Metric Type: 2 (Larger than any link state path)
Metric: 20
Routing Bit Set on this LSA
LS age: 558
LS Type: AS External Link
Link State ID: 3
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0x92B6
Length: 44
Prefix Address: 2001:DB8:FF:45:1::2
Prefix Length: 127, Options: P
Metric Type: 2 (Larger than any link state path)
Metric: 20
R3#
---------------------------------------
ON ROUTER R1 WHICH IS THE NSSA ABR
-----------------------------------
R1#show ospfv3
OSPFv3 1 address-family ipv6
Router ID 1.1.1.1
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
It is an area border and autonomous system boundary router
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of areas in this router is 2. 1 normal 0 stub 1 nssa
Graceful restart helper support enabled
Reference bandwidth unit is 100000 mbps
RFC1583 compatibility enabled
Area BACKBONE(0)
Number of interfaces in this area is 2
SPF algorithm executed 3 times
Number of LSA 22. Checksum Sum 0x0BDC02
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 10
Number of interfaces in this area is 1
It is a NSSA area
Perform type-7/type-5 LSA translation
Generates NSSA default route with cost 1
SPF algorithm executed 5 times
Number of LSA 23. Checksum Sum 0x091393
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
R1#
This LSA contains prefix information and is flooded only to an NSSA area.
The NSSA ABR will block type 7 NSSA-external LSAs and perform
type-7/type-5 LSA translation.
- Type 8 LSA Link LSA (0x0008):
Type 8 LSAs are flooded only on the originating local link. Link-LSAs serve three purposes:
- Share the router's link-local address with other routers connected to the link.
- Inform other routers the link of a list of IPv6 prefixes to associate
with the link.
- Allow the router to advertise a collection of Options bits to associate with the network LSA that will be
originated for the link.
Link-local LSAs map all global unicast address prefixes associated with an interface to the link-local
interface IP address of the router. Link LSA is shared only between neighbors on the same link.
The link LSA is responsible for providing details of IPv6 prefixes associated with an interface.
Link-local addresses cannot be leaned through the receipt of Hello packets alone.
Link-local addresses appear in OSPFv3 link-LSAs. They are not allowed in other LSA types.
R6#show ospfv3 database link
OSPFv3 1 address-family ipv6 (router-id 6.6.6.6)
Link (Type-8) Link States (Area 0)
LS age: 740
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Link-LSA (Interface: FastEthernet3/0)
Link State ID: 7 (Interface ID)
Advertising Router: 1.1.1.1
LS Seq Number: 80000006
Checksum: 0x7E8A
Length: 64
Router Priority: 1
Link Local Address: FE80::C801:3FF:FECB:54
Number of Prefixes: 1
Prefix Address: 2001:DB8:0:16::
Prefix Length: 127, Options: None
LS age: 1398
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Link-LSA (Interface: FastEthernet3/0)
Link State ID: 7 (Interface ID)
Advertising Router: 6.6.6.6
LS Seq Number: 80000005
Checksum: 0x68BB
Length: 64
Router Priority: 1
Link Local Address: FE80::C806:5FF:FE94:54
Number of Prefixes: 1
Prefix Address: 2001:DB8:0:16::2
Prefix Length: 127, Options: None
LS age: 1290
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet1/0)
Link State ID: 5 (Interface ID)
Advertising Router: 2.2.2.2
LS Seq Number: 80000003
Checksum: 0xAE61
Length: 64
Router Priority: 1
Link Local Address: FE80::C802:3FF:FEEC:1C
Number of Prefixes: 1
Prefix Address: 2001:DB8:0:26::
Prefix Length: 127, Options: None
LS age: 1398
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet1/0)
Link State ID: 5 (Interface ID)
Advertising Router: 6.6.6.6
LS Seq Number: 80000004
Checksum: 0xC43
Length: 64
Router Priority: 1
Link Local Address: FE80::C806:5FF:FE94:1C
Number of Prefixes: 1
Prefix Address: 2001:DB8:0:26::2
Prefix Length: 127, Options: None
Link (Type-8) Link States (Area 7)
LS age: 1398
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet0/0)
Link State ID: 4 (Interface ID)
Advertising Router: 6.6.6.6
LS Seq Number: 80000003
Checksum: 0x68A0
Length: 44
Router Priority: 1
Link Local Address: FE80::C806:5FF:FE94:8
Number of Prefixes: 0
LS age: 671
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet0/0)
Link State ID: 4 (Interface ID)
Advertising Router: 7.7.7.7
LS Seq Number: 80000003
Checksum: 0xBEA6
Length: 44
Router Priority: 1
Link Local Address: FE80::C807:5FF:FE33:8
Number of Prefixes: 0
LS age: 1228
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet0/0)
Link State ID: 4 (Interface ID)
Advertising Router: 8.8.8.8
LS Seq Number: 80000004
Checksum: 0xB826
Length: 44
Router Priority: 1
Link Local Address: FE80::C808:5FF:FEB3:8
Number of Prefixes: 0
R6#
R6#show ipv6 interface brief
Ethernet0/0 [administratively down/down]
unassigned
GigabitEthernet0/0 [up/up]
FE80::C806:5FF:FE94:8
GigabitEthernet1/0 [up/up]
FE80::C806:5FF:FE94:1C
2001:DB8:0:26::2
GigabitEthernet2/0 [administratively down/down]
unassigned
FastEthernet3/0 [up/up]
FE80::C806:5FF:FE94:54
2001:DB8:0:16::2
FastEthernet3/1 [administratively down/down]
unassigned
FastEthernet4/0 [administratively down/down]
unassigned
FastEthernet4/1 [administratively down/down]
unassigned
POS5/0 [administratively down/down]
unassigned
POS6/0 [administratively down/down]
unassigned
Loopback10 [up/up]
FE80::C806:5FF:FE94:6
2001:DB8:0:6:10::1
Loopback11 [up/up]
FE80::C806:5FF:FE94:6
2001:DB8:7:11::1
Loopback12 [up/up]
FE80::C806:5FF:FE94:6
2001:DB8:7:12::1
R6#
R6#
R6#show ospfv3 interface brief
Interface PID Area AF Cost State Nbrs F/C
Lo10 1 0 IPv6 1 LOOP 0/0
Fa3/0 1 0 IPv6 1000 DR 1/1
Gi1/0 1 0 IPv6 100 DR 1/1
Lo11 1 7 IPv6 1 LOOP 0/0
Lo12 1 7 IPv6 1 LOOP 0/0
Gi0/0 1 7 IPv6 100 BDR 2/2
R6#
R6#
- Type 9 Intra-area Prefix LSA (0x2009):
Type 9 LSA is used to advertise IPv6 prefixes that are associated with a router, stub or
transit segment. The router and network LSAs do not specify the IP address of the prefix for a network. LSA 9 contains all the
networks inside an area. They are not propagated out of the area.
R8#
R8#show ospfv3 database prefix
OSPFv3 1 address-family ipv6 (router-id 8.8.8.8)
Intra Area Prefix Link States (Area 7)
Routing Bit Set on this LSA
LS age: 461
LS Type: Intra-Area-Prefix-LSA
Link State ID: 0
Advertising Router: 6.6.6.6
LS Seq Number: 80000002
Checksum: 0x5E54
Length: 72
Referenced LSA Type: 2001
Referenced Link State ID: 0
Referenced Advertising Router: 6.6.6.6
Number of Prefixes: 2
Prefix Address: 2001:DB8:7:11::1
Prefix Length: 128, Options: LA, Metric: 0
Prefix Address: 2001:DB8:7:12::1
Prefix Length: 128, Options: LA, Metric: 0
Routing Bit Set on this LSA
LS age: 1142
LS Type: Intra-Area-Prefix-LSA
Link State ID: 0
Advertising Router: 7.7.7.7
LS Seq Number: 80000002
Checksum: 0xE873
Length: 112
Referenced LSA Type: 2001
Referenced Link State ID: 0
Referenced Advertising Router: 7.7.7.7
Number of Prefixes: 4
Prefix Address: 2001:DB8:7:7:10::1
Prefix Length: 128, Options: LA, Metric: 0
Prefix Address: 2001:DB8:7:7:11::1
Prefix Length: 128, Options: LA, Metric: 0
Prefix Address: 2001:DB8:7:7:13::1
Prefix Length: 128, Options: LA, Metric: 0
Prefix Address: 2001:DB8:7:7:14::1
Prefix Length: 128, Options: LA, Metric: 0
Routing Bit Set on this LSA
LS age: 511
LS Type: Intra-Area-Prefix-LSA
Link State ID: 0
Advertising Router: 8.8.8.8
LS Seq Number: 80000003
Checksum: 0x6092
Length: 92
Referenced LSA Type: 2001
Referenced Link State ID: 0
Referenced Advertising Router: 8.8.8.8
Number of Prefixes: 3
Prefix Address: 2001:DB8:7:8:10::1
Prefix Length: 128, Options: LA, Metric: 0
Prefix Address: 2001:DB8:7:8:11::1
Prefix Length: 128, Options: LA, Metric: 0
Prefix Address: 2001:DB8:7:8:12::1
Prefix Length: 128, Options: LA, Metric: 0
R8#
OSPFv3 Link-local Forwarding
The OSPFv3 LSDB creates an SPT based on links instead of networks. This means that transit links only
require IPv6 link-local addresses for forwarding traffic.
Virtual Links
All virtual-links use a global scope IPv6 address as a source IPv6 address.
OSPFv3 Optimization
Multiple Instances
OSPFv3 packets include an instance ID field that may be used to manipulate which
routers on a network segment are allowed to form adjacencies. IP address information
is advertised independently by two new LSA types: intra-area prefix LSA and link-local LSA.
Advertising IP address info using LSA types eliminates the need for OSPFv3 to perform full SPF tree calculations everytime
a new address prefix is added or changed on an interface. The OSPFv3 LSDB creates a shortest
path topology tree based on links instead of networks.
Route Summarization
Summarization of the links advertised from one area into another is accomplished
using the command area <area-ID> range <prefix>.
This is configured on ABRs and for a specific address family:
address-family ipv6 unicast
area 0 range 2001:DB8:10::/65
Network Type
The network type can be modified using the interface command ospfv3 network <broadcast|non-broadcast|point-to-point>
#show ospfv3 interface brief
#int g0/2
#ospfv3 network broadcast
Security of OSPFv3 Adjacencies and Route Exchange
OSPFv3 does not support neighbor authentication inside the protocol but uses IPSec.
Authentication Header (AH) or Encapsulating Security Protocol (ESP) extension headers
are added to OSPFv3 packets to provide authentication, integrity and confidentiality.
ISAKMP support has not yet been added so keys must be manually configured. Security Parameter Index (SPI) is like a sequence number
so it needs to match on both ends. OSPFv3 simply implements only authentication. With OSPFv3, encryption is
implemented as well with the entire packet being encrypted.
- Authentication Header (AH): provides authentication using the command
ospfv3 authentication
- Encapsulating Security Payload: provides authentication and encryption
ospfv3 encryption ipsec spi 1000 esp 3des <key> sha1 <key>
Where:
Security policy index = 1000
Encryption algorithm = 3des
Encryption key = 1234567890
Authentication algorithm = sha1
Authentication key: 132324sdsfdg
Verification is done using the command show ospfv3 interface <interface-id>
#show ospfv3 interface g0/2
OSPFv3 neighbor authentication does not perform IKE to negotiate IPSec security associations (SA) values.
Therefore IPSec security parameter index (SPI) algorithm and key must be manually defined when configuring
OSPFv3 authentication. IPSec peers cannot reuse the same SPI values.
Troubleshooting Authentication
OSPFv3 area authentication is applied to the OSPFv3 router mode command. In this mode,
the encryption or authentication parameters are configured. This is done using the following:
area 0 authentication ipsec spi 1000 sha password-key.
Verification of security configuration for OSFPv3 can be done using the command:
show crypto ipsec policy
Area authentication applies to all interfaces in the area. SAs are created for outbound and inbound connections.
To view these:
show crypto ipsec sa
show crypto ipsec policy
show ospfv3 interface
