Cisco website

OSPF Design Guide
Why Are Some OSPF Routes in the Database but Not in the Routing Table?
OSPF Incremental SPF - ispf

www.cciecandidate.com

1. Foundation

Basic
Database Exchange
Designated Routers in LAN
Designated Routers in WAN
Design, LSA Types, and Stubby Areas
OSPF Database Filter, OSPF ISPF (Incremental SPF), Advertising Routes to HSRP Virtual IP, neighbor local-as, neighbor disable-connected-check
Few things to remember about OSPF
Random OSPF Notes
Brain Teaser 2
Bonus round! How I made close, yet still appropriate, friends with OSPF
SPF Calculation & Steady-State Operation

2. Enforcing of What You Should Know

Configuration
Equal-Cost OSPF E2s Tiebreaker Is Cost to ASBR
Connect 2 Separate OSPF Backbone Areas Via Redistribution, RIP v2 Without version 2″ Command, Multilink PPP over FR (MLPoFR)
OSPF Summarization To A Specific Neighbor Using An Alternate Process ID
OSPF Multicast Addresses, ISPF, OSPF Virtual-Link Authentication, match interface, EIGRP Stub, distance ospf, neighbor fallover, bgp fast-external-fallover, bgp dampening, Bidirectional PIM with BSR
Frame Relay Inverse ARP IP DLCI number, area nssa translate type7 suppress-fa, IPv6 Redistribution Using include-connected, Stateful NAT, QoS drop, Login Block
OSPF NSSA 7-to-5 Election and BGP Dual-AS
General OSPF Comments and Making Things Harder Than They Are
OSPF ABR Type 3 LSA Filtering
Frame Relay Inverse ARP, IRB, OSPF Virtual Links, Unicast RIP, Router Auto-Install
Frame Relay Inverse ARP, DHCP Manual Bindings, OSPF Point-to-Multipoint
IP OSPF LLS disable, max lsa, redistribute maximum-prefix, Native IPv6 Tunneling, variance, set community no-advertise, ip mobile, Use Sane Bandwidth Statements
OSPF Point-To-Multipoint, OSPF Priorities, RIP timers-basic, EIGRP stub receive-only, EIGRP Route Filtering By Source Protocol
OSPF TTL=1, OSPF Tunneling in P-to-MP FR, Load-Sharing vs. Equal Cost Load-Balancing, ip telnet quiet, service compress-config, BGP Martians, Role-Based CLI Access, MVR
IRB, OSPF Flood Reduction, BGP Maximum-Prefix, NTP Broadcast, VRRP

3. Recap

Definitions
Redistribution: RIP, EIGRP, OSPF
Route Summarization: RIP, EIGRP, OSPF
Default Routes: RIP, EIGRP, OSPF

www.netcraftsmen.net/resources/

Introducing OSPF
OSPF and Route Summarization
OSPF - Part III

Discussion

»[Config] Access / Security problem on a 5505 ASA
»[Config] OSPF double check
»[Config] OSPF - how did it get this metric?
»[HELP] OSPF and EIGRP Metrics
»[Config] OSPF Cost issue on redundant links
»RIP vs OSPF
»[Config] OSPF Limit routes in/out of an area?
»OSPF Question
»[HELP] OSPF help
»OSPF Migration
»OSPF and ABR's

Introduction

OSPF has two primary characteristics. The first is that the protocol is open, which means that its specification is in the public domain. The OSPF specification is published as Request For Comments (RFC) 1247. The second principal characteristic is that OSPF is based on the SPF algorithm, which sometimes is referred to as the Dijkstra algorithm, named for the person credited with its creation.

According to RFC 2328, OSPF has its own protocol (Protocol 89) as working mechanism to implement the two characteristics. In this protocol's perspective, OSPF is a link-state routing protocol that calls for the sending of link-state advertisements (LSAs) to all other routers within the same hierarchical area. Information on attached interfaces, metrics used, and other variables are included in OSPF LSAs. As OSPF routers accumulate link-state information, they use the SPF algorithm to calculate the shortest path to each node.

As a link-state routing protocol, OSPF contrasts with RIP and IGRP, which are distance-vector routing protocols. Routers running the distance-vector algorithm send all or a portion of their routing tables in routing-update messages to their neighbors; while routers running OSPF are sending LSA and other link-state messages.

Getting OSPF to be on Up state: Router ID (RID)

Let's start with two routers with the purpose of forming up adjacency. As part of adjacency process, there will OSPF Database Exchange which contains each router's OSPF properties. With this in mind, how do the routers go about getting to know each other and exchanging their link state databases?

Before the router start exchanging the database, the OSPF on the router has to be on up state. The requirement to be on up state is that the OSPF has to have OSPF ID number. This ID number according to RFC 2328 has to be in a form of a 32-bit number. In configuration implementation, this 32-bit number can be some non-negative integer, IP address, or anything that should be unique. Examples would be 1.2.3.4 and 4.3.2.1 respectively.

Network administrators have option to either let the router chooses its own OSPF ID or has human-defined ID. The human-defined ID has priority over router-chosen one. In a case of letting the router chooses, a loopback interface IP address has priority over non-loopback interface IP address.

Here is the priority list of having OSPF ID (Router ID or RID)

• Use the RID defined by the router-id command in the router ospf paragraph.

• Use the highest IP address on any up/up loopback interface.

• Use the highest IP on any up/up non-loopback interface.

OSPF ID Characteristics

• The RID does not have to be matched by an OSPF network command.

• The RID doesn't have to be reachable by the IP routing table.

• If the router is choosing the RID itself, that choice is based on the status of interfaces at the time the router is deciding things.

• The RID never changes, unless the OSPF process restarts, or the RID is manually changed by a human. In a case of such human intervention, the OSPF process has to restart in order to have OSPF to take the updated ID

• If a RID changes, everyone else in the same OSPF area will perform a new SPF calculation.

• Some folks like to set their RIDs with an obvious numbering scheme that helps them easily identify the routers on their network.

OSPF Packet Types

The OSPF packet types listed below are part of OSPF Message Types, and will be used to establish adjacency and neighbor discovery.

The Hello protocol uses Hello packets to discover and maintain neighbor relationships. The Database Description and Link State Request packets are used in the forming of adjacency. OSPF's reliable update mechanism is implemented by the Link State Update and Link State Acknowledgment packets.

Each Link State Update packet carries a set of new link state advertisements (LSAs) one hop further away from their point of origination. A single Link State Update packet may contain the LSAs of several routers.

Following shows OSPF adjacency process incorporating (and illustrating) the use of the Message Types.

OSPF Message Types in Adjacency Process

When OSPF Router ID (RID) is set, next step is to establish adjacency. Part of the adjacency mechanism is exchanging following messages.

• Hello - neighbor discovery and keep-alive.

• Database Description (DD or DBD), also called LSDB (Link State Database) - used to send LSA headers usually at the beginning of a topology exchange, so that one router knows what LSA's the other has.

• Link-State Request (LSR) - "Hey - I want to know about this (or these) LSA (or LSA's)!"

• Link-State Update (LSU) - "Hey - here's a everything there is to know about this LSA!" (usually sent as an LSR response).

• Link-State Acknowledgement (LSAck) - "Thanks! I got the LSU."

Note that LSA's are a part of this picture in that they are exchanged via LSU's. However LSA's are not an OSPF message type, they are rather payload.

OSPF Message Exchange Process

Various OSPF messages of the types listed above are exchanged. Each of these message exchanges result in the neighbors being in states that the neighbor tracks. These states, along with the messages exchanged, follow below.

• INIT - mutual hellos - "Hi! I'm OSPF router RID 1.2.3.4."

• TWO-WAY - "Yes, I saw your hellohello yourself, I'm 4.3.2.1!"

• EXSTART - "Hello again - we need to choose a DR" and/or "Hello, DR is x.x.x.x."

• EXCHANGE - "My database of LSA's look like so." (Mutual DD messages exchanged.)

• LOADING - "Hey, I need to see everything for these LSA's"; "Okay, heres everything I have."; "Okay, thanks, I got the update."

• FULL - All LSA's have been exchanged, and now these two OSPF routers are considered fully adjacent. They will keep in touch via hellos.

OSPF Hello Protocol

The RFC 2328 states Hello Protocol as part of OSPF mechanism, whose purpose is to to establish and maintain neighbor relationships. In LAN (Broadcast Domain) environment, the Hello Protocol can also dynamically discover neighboring routers. A Designated Router (which exists in Broadcast and Non-Broadcast Domains) is elected by the Hello Protocol.

In regards of acquiring neighbors, OSPF router sends Hello packets to its neighbors, and in turn receives their Hello packets. On broadcast and point-to-point networks, the router dynamically detects its neighboring routers by sending its Hello packets to the multicast address AllSPFRouters (224.0.0.5 IP address). On non-broadcast networks, some configuration information may be necessary in order to discover neighbors. On broadcast and NBMA (non-broadcast) networks the Hello Protocol also elects a Designated router for the network.

Following is illustration of parsing OSPF packets using tcpdump on Linux, which shows how Hello message is used in keeping adjacency between one router and others.

Capturing OSPF packets on the fly, assuming eth0 is a router interface running OSPF.

where OSPF ip protocol number is 89, and the protocol field is the 9th octet on the ip header.

Another way is:

Writing captured packets to a file

Reading ospf packet from a file, we need the "-r" switch

where the output will look like the following

In this case, the router's eth0 interface has 172.16.21.1 IP address and is sending out Hello packet onto Multicast address for all adjacent routers. The Hello packet interval is set into certain seconds.

Note that ospf-all.mcast.net is a DNS name of 224.0.0.5 Multicast IP address. Should you wish to see actual IP address instead of name, add "-n" parameter.

If we need to print all the packet info, try:

and we should be able to see OSPF packet detail

Note:

-i defines capturing interface,
-r read from a file,
-v be verbose,
-vv be very verbose.

OSPF Hello Sanity Check Process

Hellos are used for sanity checks of the following parameters.

• Authentication (if any)

• Same router interface types (i.e. Ethernet, Serial)

• Matching subnets, including subnet mask (unlike EIGRP, which will allow neighbors to form, as long as the IP they are talking to falls within the same local subnet, even if the remote subnet mask is different; which can SCREW UP YOUR DAY)

• Matching area IDs (i.e. Area 0, 1, 2, etc) - OSPF adjacencies cannot form if the router interfaces are in different areas.

• Same area type (stub, not-so-stubby, etc. which we will talk more about later)

• Matching network types (i.e. broadcast, point-to-point, point-to-multipoint)

• Unique RID's.

• Equal hello and dead timers.

The Hello packets are sent as a multicast to 224.0.0.5, sourced from the routers primary IP address on that interface. OSPF adjacencies will not form on secondary addresses.

MTU Consideration

According to RFC 2328, MTU of both router interfaces has to match. Here is the quote.

"If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected."

Note that the MTU match requirement is not part of the OSPF Hello Sanity Check Process. However the Database Description exchange process won't take place when there is MTU size mismatch somewhere in the OSPF domain since OSPF Protocol 89 assumes of the same MTU size across the domain.

This MTU match requirement applies to all interfaces within the same OSPF domain. If for some reason there must be different MTU size across multiple interfaces, then an alternate is to instead run BGP as the routing protocol. Unlike OSPF that has its own protocol (Protocol 89), BGP relies on TCP protocol which is capable to adjust MTU size across interfaces as needed.

After Hello Sanity Check Process Completes

Once the routers have completed their hellos, they exchange DD packets, essentially headers of the LSA's in their database. DD's are acknowledges one for one, not with an ACK packet, but rather with a copy of the received DD sent back to the originating router.

Now that the routers have exchanged DD's, they now know what each other has to offer in the form of LSA's. So now the router must determine what LSA's his new OSPF neighbor has that he needs a copy of.

• If the LSA is missing from his LSDB, he will form an LSR and request that LSA.

• If the LSA his neighbor has is newer than the one he has, he will request that LSA via an LSR as well. This is determined via the LSA's sequence number. New LSA's start with 0x80000001 (Hex 80000001), increment, and then wrap to 0x7FFFFFFF (Hex 7FFFFFFF). If the LSA sequence number gets to 0x8000000 (Hex 8000000), then the LSA is flooded back through the network.

• LSR's are responded to with LSU's. LSU's are acknowledged either by the same LSU getting sent back, or by and LSAck.

Once LSA's have been exchanged, the new neighbors are in a "FULL" state and should have identical LSDB's. At that point, the routers can run the SPF algorithm, and populate their routing tables appropriately.

In addition to the LSA exchange business, Hello message is also used to maintain relationship with other routers. During this maintenance, Hellos are sent periodically (the hello interval to be exact) so that neighbor stay in touch.
• The default hello interval is 10 seconds by default on LAN interfaces.

• The default hello interval is 30 seconds by default on T1 and slower WAN interfaces.

• The dead interval (when an OSPF neighbor is included amongst the dearly departed and considered unreachable) defaults to 4x the hello interval.

Various Network Types in OSPF

• Broadcast (LAN)

• Non-Broadcast (WAN)

• Point-to-Point

Broadcast is typically some LAN setup when all hosts connected into some Ethernet switches. Traffic flow is from one to many or many to many (full mesh). When some of the hosts are OSPF-speaking routers, one design consideration is to setup Broadcast network types.

Non-Broadcast is WAN technology (i.e. Frame Relay network) that carries certain Broadcast properties with limitation in terms of bandwidth and speed. Traffic flow is one to many or many to many, similar to Broadcast. In the case of Frame Relay network, there are options to setup as either regular Non-Broadcast (full-mesh traffic) or Point-to-Multipoint OSPF network type (partial-mesh traffic).

Point-to-Point is basically two hosts (in this case two OSPF-speaking routers) interconnected with one or more links. From OSPF perspective, there are nothing sit between the two hosts. Traffic flow is always from one host to another.

Designated Routers

In order to keep the same database across the network, one way is to have all routers speak to all other routers. The problem by doing so is having full-mesh traffic among the routers which may tax bandwidth, in addition to higher CPU and memory utilization on all routers.

Another approach is to set a designated router (DR) acting as middle man. A router is sufficiently talking to DR for information needed or for other routers. To establish redundancy, a backup designated router (BDR) is chosen as DR backup in case of DR's unavailability.

With Broadcast and Non-Broadcast networks, OSPF requires to have one DR and one BDR. Point-to-Point network however does not need DR due to predictable traffic flow (which is always from one host to another). Therefore OSPF Point-to-Point network contains no DR or BDR.

Designated Routers in LAN (Same Broadcast Domain)

An OSPF designated router (DR) is a router in an area that is responsible to flood LSA's to every other router in the area. This saves every OSPF router from exchanging their LSDB with every other router in an OSPF area, and keeps redundant LSA exchanges to a minimum. OSPF areas on LAN's elect designated routers (DRs) and backup designated routers (BDRs). There may or may not be a DR or BDR on a segment, depending on what type of network OSPF is running across.

Here's an walkthrough of how the DR process reduces the number of LSA exchanges that would normally occur.

• A non-DR router (DROther) sends his DD (an LSA header, remember) to a multicast address of 224.0.0.6. The 224.0.0.6 is the "all DR" multicast address - remember that there's generally a DR and a BDR, so there'll be more than one.

• The DR and BDR see the LSA header. The DR will send a unicast acknowledgement of the DD by sending back the same DD again.

• The DR will then multicast the DD to 224.0.0.5, which is all OSPF routers in the area.

• The non-DR routers will acknowledge the DD with a unicast identical DD in response.

Note OSPF neighbor relationships in a LAN which is that not all OSPF routers that find each other will need to continue the Hello process until the "FULL" state. In one OSPF segment with a DR, routers only need to form "FULL" relationships with the DR and BDR. Routers that are "DROther" (ergo, not DRs), will only advance to the "TWO-WAY" state. All the DD exchanges from there will only happen with the DRs, so there's no point in DROther routers forming FULL relationships with one another.

If you're thinking there is a risk that not all routers in the OSPF area will get the same LSDB, think again. Remember, all OSPF routers will exchange a full database with the DR. It is the DR's job to make sure that all the OSPF routers are performing link-state computations from the same sheet of music, so to speak.

In a network design perspective, an OSPF DR can be (or should be) the uplink to the rest of the network (outside the broadcast domain) which the DR is seen as the "network summary router" for both rest of the network and the non-DR routers within the same broadcast domain.

OSPF Designated Router Election Process

The considerations are as follows

• A router with an OSPF priority of anywhere from 1-255 can attempt to become the DR by popping his own RID in the DR field of his Hellos.

• Routers look at the DR field in the Hellos to determine who wants to be the DR.

• If an inbound Hello lists a better DR, the router then decides that he DOESN'T want to be the DR, but that the better router does.

• Routers with the highest priority will be DR's.

• In case of a tied priority, the router with the highest RID is better.

• The router not claiming to be the DR, with the higher priority (or RID) of the remaining routers will become the BDR.

• If a new router shows up or another router has a higher priority, they can NOT preempt the existing DR.

• If the DR falls off the network, the BDR will take over as DR. A BDR election will follow.

How OSPF Thinks of Neighbors and Adjacent

OSPF thinks of "neighbors" and "adjacent" differently. Neighbors are simply OSPF routers that have found one another. They have swapped Hellos, and the Hellos match up for the needed number of parameters. Adjacent or "fully adjacent" routers are OSPF routers in a "FULL" state.

Designated Routers in WAN

Building on the concepts in the last entry about DR's and BDR's, how then do things change in different network topologies? One consideration is that routers on either side of point-to-point links do not bother with DR's or BDR's. Why should they? They are implicitly the only possible devices on the segment.

With NBMA (Non-Broadcast Multiple Access) network such as Frame Relay network, there are a number of potential scenarios, where you may or may not desire the LSA exchange efficiencies brought about by DRs. Depending on your specific requirements, you can define router interfaces as being on of several different OSPF network types. The network type you choose will govern the following.

• Whether the router will try to elect a DR.

• Whether the router has to learn about a neighbor through static configuration as opposed to the more typical Hellos.

• Whether more than two neighbors will be allowed on a given subnet.

Network types and parameters are as follows.

• Broadcast: Uses DR, Hello interval=10, No neighbor command required, More than two allowed.

• Point-to-point: No DR, Hello interval=10, No neighbor command required, More than two NOT allowed.

• Non-Broadcast (NBMA): Uses DR, Hello interval=30, Neighbor command required, More than two allowed.

• Point to multipoint (i.e. Frame-Relay network special setup): No DR, Hello interval=30, No neighbor command required, More than two allowed.

• Point to multipoint nonbroadcast: No DR, Hello interval=30, Neighbor command required, More than two allowed.

• Loopback: No DR, Hello interval=N/A, Neighbor command=N/A, More than two NOT allowed.

Use caution when configuring various OSPF network types over the various frame-relay network types you might encounter.

• Remember that your timers must match, but the defaults are different. So if your potential neighbors are configured with different OSPF network types, you can run into a problem.

• Your OSPF neighbors might be confused if some of them believe in a DR, and others do not. Everyone in the cloud should be expecting a DR, or not, for your neighbor relationships to form as you would expect and next-hops to be reachable.

• If you choose to go with a DR, then the DR and BDR need to have a PVC to all other routers in the subnet. The DR and/or BDR are expected to exchange DD's and acks with all other OSPF routers. Without the PVC in place, this process will fall apart.

• You aren't obligated to statically configure "neighbor" statements on both routes - one will suffice. But in the interest of self-documentation, it's a best practice to do it on both.

OSPF Areas

Let's discuss some OSPF design fundamentals, some of which I mentioned in an earlier post, but which are worth reviewing again.

OSPF links are grouped into contiguous areas. Contiguous word is key here. If you create an Area 9, let's say, then all of the Area 9 links must be able to reach all of the other Area 9 links through Area 9 links alone. If you were to have to traverse the Area 0 backbone to reach the other Area 9 link, then you do not have a contiguous area. Rather, you have two area 9's (and some challenges ahead).

With an area concept, OSPF has component called Area Border Routers (ABRs) to connect the backbone area and one or more areas together. Any routes in and out of one area has to traverse ABR.

OSPF is also capable of receiving external routes from outside of the domain. This external routes can be directly connected networks, static routes, or any routing protocol (including some OSPF routes from different domain). OSPF has component called Autonomous System Boundary Routers (ASBRs) to take those routes from another routing domain and redistribute them into OSPF.

You can use a single OSPF area. However, splitting your OSPF design into multiple areas has these benefits.

• The LSDB for an area is usually smaller, asking less of router memory.

• SPF calculations within an area will be quicker, under the assumption that the LSDB is smaller. Why are area LSDBs smaller? Because ABRs do not forward type 1 or 2 LSAs into an area; instead type 3 summary LSAs are send into an area.

• When a link fails in one area, routers in other areas only have to do a partial recalculation (more on that in a bit).

• You can summarize routes at border and boundary routers. Summarized routes imply smaller LSDB, and lower SPF computation overhead.

There is no requirement to have Area 0 (Backbone Area) especially when there is only single area in the OSPF domain. You can have (let's say) just Area 5 for the entire OSPF domain. There is however a requirement of Area 0 when there are multiple areas.

OSPF LSA Types

At this point, we need to review the several different types of LSAs.

Type 1 (Router)

There is one of these per router, containing the RID and all interface IP addresses. Stub networks are included. Logically, this LSA is going to tell other routers what networks this router has direct connections to.

Type 2 (Network)

There is one of these per transit network. The DR on a subnet creates these. It contains the subnet and router interfaces connected to that particular subnet. This LSA is used in the situation of how a router will know all the possible next hops to reach a remote subnet without having to form a full adjacency to every router he sees a hello from.

Type 3 (Network Summary)

ABRs use these to tell one area about another area's Types 1 and 2 LSA's. The subnet and cost information is included, but the topology - routers connected to this subnet - is not included.

Note that this Type 3 is fundamental to OSPF design. To go from one area to another, you must traverse area 0. To get to area 0, you have to go through an ABR. So why should an ABR pass along topology information into another area? That information is irrelevant.

Moving forward; a router receiving a Type 3 LSA calculates the cost by using the cost to reach the advertising ABR, plus the cost in the LSA itself. This in mind, if a network in one area changes (goes up/down or there's a topology change), routers in other areas don't have to run a full SPF calculation - only a partial - to update their routing tables. Routers within the area where the topology change happened will be receiving a Type 1 or 2 LSA and run a full SPF calculation.

Type 4 (ASBR Summary)

An advertisement of a host route used to reach an ASBR. If redistributing an E1 (Exernal Type 1, internal and external metric considered) route, the router will send an LSA type 4 for itself, plus the LSA Type 5 for the subnet.

Type 5 (AS External)

ASBRs create these to describe external routes redistributed into OSPF. If redistributing an E2 (External Type 2, only external metric considered) route, the ASBR creates a type 5 LSA and floods it, with no accompanying type 4 LSA.

Type 6 (Group Membership)

MOSPF (Multicast OSPF), which Cisco IOS does not support.

Type 7 (NSSA External)

ASBRs inside of a not-so-stubby-area will create these instead of type 5 LSAs.

Type 8 (External Attributes)

Cisco IOS does not support this type.

Type 9-11 (opaque)

Generic for future OSPF extension.

OSPF Stubby Area

A mention of stubby areas is also warranted. The point of a stubby area is to reduce the number of LSAs that will be advertised into or out of an area. Say we have Area 54 and Area 0. Traffic leaving Area 54 will have to traverse Area 0, right? Well then, why not have the Area 0-54 ABR advertise a default route into Area 54 rather than a bunch of Type 3 and/or 5 LSA's? And depending on just how picky we want to be, why should we let Area 54 advertise any Type 5 LSA's from an ASBR that might be in there? You get the idea. There are several different stubby area types, each type with its own unique combination of what LSA types are allowed into and out of the area through the ABR.

LSA Type Restriction Across Various OSPF Area Types

Below, Type 5 (External) and Type 3 (Summary) are stopped (or allowed) at the ABR from being injected INTO the area. Type 7s (NSSA external) are stopped (or allowed) OUT OF the area.

• Stub
Type 5 IN - stopped; Type 3 IN - allowed; Type 7 OUT - stopped.

• Totally stubby
Type 5 IN - stopped; Type 3 IN - stopped; Type 7 OUT - stopped.

• Not-so-stubby area (NSSA)
Type 5 IN - stopped; Type 3 IN - allowed; Type 7 OUT - allowed.

• Totally NSSA
Type 5 IN - stopped; Type 3 IN stopped; Type 7 OUT - allowed.

In summary

• All stub areas stop type 5's.

• All totally stubby areas stop type 3's.

• All not-so-stubby areas allow type 7 external LSA's to be injected into area 0.

As a recap, here is a list of possible area types in OSPF

Various OSPF Area Types and Properties

Normal Area Specification and Conditions

An Area is considered normal area is basically a default area with no restriction. To describe further,

• Normal Area can have ABR and ASBR in addition to area-specific routers

• Normal Area can never be stub area (stub, totally stub, NSSA, or totally NSSA) since then the Area is no longer seen as Normal Area. When Normal Area is converted to a Stub Area, Stub Area respective restrictions follow.

• Normal Area allows Type-5 LSA to exist within

• Normal Area does not have Type-7 LSA since such type only exist in NSSA.

Backbone Area (Area 0) Specification and Conditions

Area 0 is considered normal area with special conditions as follows

• Area 0 can have ABR and ASBR in addition to area-specific routers

• Area 0 can never be stub area (stub, totally stub, NSSA, or totally NSSA) since Area 0 needs to forward Type-3 and Type-5 LSAs to other areas

• Since Area 0 can have ASBR, Type-5 LSA can exist within Area 0 just like other normal area

• Since Area 0 can never be NSSA, Type-7 LSA can never exist within Area 0.

ASBR (Autonomous System Boundary Router) Specification and Conditions

• External routes from one OSPF domain (OSPF Autonomous System or OSPF AS) perspective is any non-internal routes, whether originates as static routes, RIP routes, EIGRP routes, IS-IS routes, BGP routes, or OSPF routes from different OSPF domain

• ASBR injects external routes into area of one OSPF domain

• When the area is normal area (including Area 0), ASBR assigns the injected external routes Type-5 LSA to describe route cost

• When the area is NSSA or totally NSSA, ASBR assigns the injected external routes Type-7 LSA to describe route cost

E1 and E2 Route Specification and Conditions

• The E1 (external type-1) and E2 (external type-2) are external routes injected to some non stubby area.

• By default, all external routes injected into OSPF non-NSSA areas are assigned Type-5 LSA and routes are set as E2 (external type-2) to describe the external route cost from ASBR to the external network.

• The external route cost described in Type-5 LSA is whichever metric value determined by the external network

• There must be configuration to specify the external routes to be as E1 (external type-1)

• When the external routes are E2, ASBR only creates Type-5 LSA to describe the route reachability within the OSPF domain

• When the external routes are E1, ASBR creates Type-5 LSA to describe the routes. In addition, ASBR creates Type-4 LSA to describe route cost to reach the ASBR

• E1 and E2 routes only exist within Area 0 and normal area

ABR (Area Border Router) Specification and Conditions

• ABR is always member of multiple areas, which at least one router interface in one area and at least one router other interface in other area

• ABR only passes Type-3 and Type-5 LSAs between Area 0 and Normal Area

• ABR only passes Type-3 LSA from Area 0 to Stub Area.

• ABR injects default route into the Stub Area (unless the Area is NSSA) to describe remaining networks outside the Stub Area that may not yet be covered by the passing Type-3 LSA. ABR assigns this default route Type-3 LSA

• ABR only passes Type-3 LSA from Stub Area (not NSSA or totally NSSA) to Area 0

• When the stub area is either totally stub or totally NSSA, ABR advertises default route to the area to describe and summarize all routes outside the area; while filters all incoming routes from other areas

• When the stub area is NSSA or totally NSSA, ABR translates Type-7 LSA received from ASBR to be Type-5 LSA to advertise outside the NSSA to Area 0.

• Since ABR translates Type-7 LSA to be Type-5 LSA before advertise the routes outside NSSA, Type-7 LSA only exists within NSSA

• The Type-5 External route which was translated from a Type-7 NSSA External route does not use a Type-4 ASBR Summary LSA, because the forward address lookup replaces the need for the ASBR Summary lookup.

N1 and N2 Route Specification and Conditions

• The N1 (NSSA type-1) and N2 (NSSA type-2) are external routes injected to NSSA

• By default, all external routes injected into OSPF NSSA areas are assigned Type-7 LSA and routes are set as N2 (NSSA type-2) to describe the external route cost from ASBR to the external network.

• The external route cost described in Type-7 LSA is whichever metric value determined by the external network

• There must be configuration to specify the external routes to be as N1 (NSSA type-1)

• N1 and N2 routes only exist within NSSA or totally NSSA

• NSSA does not allow default route injection. Therefore N1 and N2 routes can never be a default route

• If for some reason there must be a default route to exist in NSSA, there are two options. Option 1 is to set the NSSA to be totally NSSA. As mentioned, totally NSSA sets ABR advertise default route to the area to describe and summarize all routes outside the area; while filters all incoming routes from other areas. These option however forces all traffic intended to be outside the NSSA area to traverse the said ABR.

• When there is a requirement of default route in NSSA where traffic outside the area with Type-3 LSA has to be reachable through ABR while traffic outside the area not covered in the Types 3 and 7 LSA has to be reachable through other means, one can go with Option 2.

• With Option 2, one cannot rely on OSPF; rather there must be other routing mechanism to co-exist. This other routing mechanism can be any other routing protocol (i.e. BGP, EIGRP, RIP, IS-IS) or simply static route. This other routing mechanism then solely responsible to manage the default route within NSSA

• And as mentioned, this default route handled by other routing mechanism cannot be injected to NSSA

OSPF Network Design In Regards of Area Types

NSSA (Not-So-Stubby Area)

Since NSSA does not allow default route to exist, one can implement NSSA when there are following requirement.

• No hosts within the NSSA that need to access the Internet

• All external routes come in with specific network subnet

• All internal routes in a form of LSA Type 3 are allowed and are needed

• Network security protection to disallow Internet access and routing path going over Internet (Public network)

Stubby Area

As mentioned earlier, Stubby Area only permits LSA Type-3 from other areas traverse ABR into the Area. Since there may be LSA Type-5 routes from other areas that may need to be reachable from the Stubby Area in question, ABR in addition issues default route into all OSPF-speaking routers within the Area. From all OSPF-speaking routers' perspective that sit in a Stubby Area, there are LSA Type-3 from internal network to describe specific routes and also LSA Type-3 Default Route to describe any routes (including external routes) that are not yet specified in the internal network routes.

If there is only one ABR in the Stubby Area, then there is an option to convert the Stubby Area to Totally Stubby Area where all routes from other areas (both internal and external routes) are described by single route, which is a LSA Type-3 Default Route. With this approach, there is no need to provide redundant routing statement to reach any network outside the Area.

When there are multiple ABR in the Stubby Area, there is an option to have some kind of load balance. If there are (let's say) two ABR, then one ABR can just issue Default Route while the other ABR issue the internal network LSA Type-3 routes.

Normal Area

Without restriction which Normal Area can receive external routes from other areas, can have ABR and ASBR (or neither one); an option is to place Normal Area in some Public (Untrusted) network while keeping internal network in either Stubby Area or NSSA.

Area Design Consideration

Now let's consider the following scenario. Assume there are multiple eBGP peers among various external network. All external networks specify route reachability through eBGP peers (i.e. External Network 1 announces 192.168.1.0/24, External Network 2 announces 191.23.54.0/24). The objective to redistribute these eBGP routes into OSPF domain while keeping the routes separate; meaning routes come from one external network (i.e. External Network 1) cannot be seen by other external network (i.e. External Network 2); so that reachability from OSPF domain will only be traversing respective eBGP peer.

With this scenario, an option is to implement OSPF NSSA where each external network is assigned one Area. In this case let's assume External Network 1 routes are assigned Area 1 and External Network 2 routes are assigned Area 2.

The eBGP announced network will then be converted into LSA Type-7 within each NSSA. There will be LSA Type-7 within Area 1 to describe reachability to External Network 1 routes. Similarly there will be LSA Type-7 within Area 2 to describe reachability to External Network 2 routes.

Once the Area 1 LSA Type-7 going out of the Area into Area 0 (converted into LSA Type-5 by ABR), Area 2 is unable to see the LSA Type-5. Similarly, Area 1 is unable to see LSA Type-5 conversion from Area 2 LSA Type-7 routes. With this approach, one external network cannot see the other external network.

Internal network that need to reach all of the external routes have to sit in different area, which is either Normal Area or Stubby Area. Depending on some requirements, there is option to have the internal network sit in Area 0.

OSPF Forward Address Lookup

Making Use of OSPF Forwarding Addresses

The topology below illustrates an OSPF network which is in the process of peering with a new partner network. Routers 2 and 3 connect the OSPF domain (10.0.0.0/16) to the partner network (172.16.0.0/16) via eBGP. Both physical uplinks are active, but unfortunately only one eBGP session has been configured so far (between R1 and R2) with the second due to be completed in a couple weeks.



Although functional, this topology doesn't make use of R3's connection to the partner network, since only R2 has a BGP adjacency and thus is the only OSPF router redistributing a route for 172.16.0.0/16. We can see below that if R3 (or any other OSPF router in the cloud) needs to send traffic to R1, the only path is via R2.



Fortunately, OSPF provides a workaround mechanism for just such a situation. An OSPF router can set the forwarding address of a route to something other than itself to indicate an alternate next-hop. In most cases, the forwarding address is left null (0.0.0.0), suggesting that the route is reachable only via the advertising router. This is currently the case with our 172.16.0.0/16 route, as we can see.

Several conditions must be met for a forwarding address to be set in an LSA, as outlined in this document by Cisco. Essentially, the advertising router must have an OSPF adjacency on the next-hop interface, and it must be a multiaccess adjacency (not point-to-point or point-to-multipoint). This is to ensure there is at least one other router within the OSPF domain which is directly connected to the next hop router; otherwise, there would be no reason to include the forwarding address.

Returning to our topology, we realize that we can implement an OSPF adjacency between R2 and R3 across the 192.168.0.0/24 backbone link without coordinating with our partner. This should trigger R2 to begin including the forwarding address for R1 in it's 172.16.0.0 LSA.

Double-check to ensure our R2-R3 adjacency is formed across the 192.168.0.0/24 subnet:

Now let's have another look at the LSA for 172.16.0.0/16. Note that because identical copies of an LSA are stored on all routers in the OSPF domain, it really doesn't matter which we check.

Aha! Where the forwarding address was previously null, R2 is now setting it to the next-hop address (R1). And, because R3 has a direct connection to 192.168.0.1, it can now forward traffic destined for 172.16.0.0/16 directly to R1.



More on OSPF Forward Address

Recall the meaning of OSPF FA (Forward Address). This is a special field used on OSPF type 5 and 7 LSAs to convey the information of the "external route source". The purpose of FA is to optimize forwarding in situations where the external route source is connected to a shared segment. Here is an example.



In this scenario, R2 is the ASBR redistributing RIP into OSPF. At the same time, R1 does not perform redistribution. Per normal OSPF rules, the external prefixes appear "attached" to R2 and thus both R1 and R4 should route across R2 to get to the networks behind R3. In order to avoid this suboptimal routing, OSPF may insert a non-zero FA field into type-5 LSAs, containing the IP address of R3: 155.1.123.3. This will instruct R1 and R4 to route to R3 directly, instead of going across R2.

Now an important thing here the FA address must be accessible via the normal routing tables of R1 and R4. This requires the external link to be advertised into OSPF by some means, e.g. by enabling OSPF on the external link between R1, R2 and R3. Redistribution cannot be used for this purpose, as there are some restrictions. Here is a complete list of the requirements for enabling the OSPF FA in type 5 LSAs.

• OSPF is enabled on the ASBR's next hop interface

• ASBR's next hop interface is non-passive under OSPF

• ASBR's next hop interface is not point-to-point

• ASBR's next hop interface is not point-to-multipoint

• ASBR's next hop interface address falls under the network range specified in the router ospf command.

Notice the requirement for having the network type of "broadcast" or "non-broadcast" this makes sense if you think that in real life you need to have a shared link with multiple "exit points". However, you may forcefully configure a physically point-to-point link for the mentioned OSPF network types to enforce the effect of FA assignment.

OSPF Route Selections

Route Selection in terms of preferable metrics

There are four types of metrics, with the most preferred type listed in order below. An intra-area route is always preferred to an inter-area route regardless of metric, and so on for the other types.

1. Intra-area
2. Inter-area
3. External Type 1 (either E1 or N1 for NSSA), which includes both the external path cost and the sum of internal path costs to the ASBR that advertises the route,
4. External Type 2 (either E2 or N2 for NSSA), the value of which is solely that of the external path cost

Area Design Consideration

Scenario 1: External Type Choosing

Depending on your network requirement, you may want to keep external routes as default (which is External Type 2). With this type, OSPF only considers metric of what the external routes carries. As example, External Type 2 of static routes may carry Metric 1; of BGP routes may carry Metric 20. This external metric is then part of the LSA Type 5 (AS External).

Since External Type 2 is only assigned of LSA Type 5, OSPF metric to reach the route is always constant from the perspective of any OSPF-speaking router within the domain. When there are multiple ASBR in the domain introducing this same external route, there will be multiple External Type 2 routes with the same metric. These multiple External Type 2 routes with the same metric will be seen as equal, which then routers will pick one that comes first into their routing table.

Should you decide to prioritize one external route over other, one route can be set as External Type 1 while others are default (which is External Type 2).

Scenario 2: Multiple Areas with same Area ID during outage

Let's say there is an Area 123 with two ABR as follows.

Under normal condition, any traffic within the Area (intra-area) will not leave ABR to Area 0; the traffic stays within the Area 123. This means that traffic between R1 and R2 routers traverses the direct link. During direct link outage, there will then two different Area 123 with its own ABR. Should this direct link outage occur, traffic between R1 and R2 routers traverses ABR and Area 0 (inter-area).

Note that OSPF see the two Area 123 as acceptable design even when both areas share the same area ID. This acceptance is based on dedicated ABR and connection of each area.

Route Selection in terms of preferable link costs

• When there are multiple routes within the same type, OSPF selects interface or link that has the lowest cost

• Cost metric associates with bandwidth

• Cisco uses a metric like 10^8/bandwidth (the base value, 10^8 by default, can be adjusted). So, a 100Mbit/s Fast Ethernet link will have a cost of 1, a 10Mbit/s a cost of 10 and so on.

Some key points about link cost.

• You can manually set the cost on a neighbor assuming you manually created the neighbor first of all (i.e., you had to create the neighbor because the OSPF network type you're on doesn't support hellos).

• You can set the cost per interface using the Cisco IOS ip ospf cost interface command.

• Cost calculations default to the reference bandwidth of 100,000,000 divided by interface bandwidth in bps. Implicitly, this doesn't scale beyond fast-ethernet, as 10Gbps and 1Gbps would calculate to be an equal cost as fast.

• You can change your reference bandwidth with the auto-cost reference-bandwidth x mbps. Be sure to do this on all OSPF routers in your network for consistent OSPF calculations.

Design Consideration

In a LAN (broadcast domain) setup, typically all links have same bandwidth. As illustration, let's say there are three routers with 100 Mbps Ethernet port interconnected to single 100 Mbps port switch as follows.

Assuming a 100Mbit/s Fast Ethernet link has a cost of 1, then OSPF sees all three links (R1-R2, R1-R3, R2-R3) have the same cost of 1.

Now imagine that one of the router Ethernet port used is 10 Mbps instead of 100 Mbps while the two other routers have 100 Mbps. These three routers still connect to the same 100 Mbps port switch to form a LAN. You should not let the 10 Mbps link bear the same cost as the remaining 100 Mbps links even though the three links are within the same broadcast domain since the differences may confuse OSPF.

With that regards, you need to set the cost to follow the lowest bandwidth link within the broadcast domain. In other words, you need to downgrade the two 100 Mbps link bandwidth to 10 Mbps to match the one 10 Mbps port. Using the ip ospf cost interface command, you can implement ip ospf cost 10 on all 100 Mbps ports while keep 10 Mbps port as default.

Steps OSPF Takes to form neighbor relationship

Step 1

• Router ID exists (either manually or automatically defined) in a OSPF domain

• Certain interfaces are configured as part of OSPF domain

Step 2

• On those OSPF-configured interfaces, routers try to look for neighbors

• Routers look for neighbors by issuing Hello packets to 224.0.0.5 Multicast IP address. This is the INIT of the OSPF Message Exchange Process

• When any routers are responding to the Hello (the TWO-WAY of the OSPF Message Exchange Process), routers perform the Hello Sanity Check Process

• If the responding routers pass the Hello Sanity Check Process, routers move forward to the next step of the OSPF Message Exchange Process. If the responding routers don't pass, routers rejects the TWO-WAY and keep on looking for potential neighbors.

Step 3

• Assuming the responding routers pass the Hello Sanity Check Process, routers have to decide how to proceed.

Step 3.1: Point-to-Point network

• Since there is no DR (and no BDR), routers skip the EXSTART of the OSPF Message Exchange Process and onto EXCHANGE

Step 3.2: Broadcast or Non-Broadcast network

• Since there has to be DR and BDR, routers go through EXSTART of the OSPF Message Exchange Process and onto EXCHANGE.

• Note that in Broadcast or Non-Broadcast network type, not all OSPF routers that find each other will need to continue the Hello process until the "FULL" state. In one OSPF segment with a DR, routers only need to form "FULL" relationships with the DR and BDR. Routers that are "DROther" (ergo, not DRs), will only advance to the "TWO-WAY" state. All the DD exchanges from there will only happen with the DRs, so there's no point in DROther routers forming FULL relationships with one another.

Step 4

• During EXCHANGE of the OSPF Message Exchange Process, routers verify MTU size match. If MTU size mismatched is detected, routers reject the EXCHANGE and keep on looking for potential neighbors. If MTU size matches, routers complete the EXCHANGE and LOADING.

Step 5

• Once routers pass the EXCHANGE and LOADING of the OSPF Message Exchange Process, routers are at FULL; which is all LSA's have been exchanged, and now these two OSPF routers are considered fully adjacent. They will keep in touch via hellos.

Step-by-Step Adjacency Process

Following is illustration with some Wireshark capture. Let's say there are two OSPF-speaking router within Broadcast network; a 10.0.0.1 IP address and a 10.0.0.2 IP address.

Step 1: INIT



The first OSPF packet is coming from 10.0.0.1 to 224.0.0.5 in a form of Hello packet. Under OSPF Header, it has following details.

* Version: 2
* Message Type: Hello Packet
* Source OSPF Router: 10.0.0.1
* Area ID: 0

The Auth part has some data, indicating MD5 authentication is in place. We will be discussing this authentication later on.

Under OSPF Hello Packet, it has the following details.

* Network Mask: /30
* Hello Interval: 10 secs
* Router Priority: 1
* Router Dead Interval: 40 secs
* Designated Router: 10.0.0.1
* Backup Designated Router: 0.0.0.0 (undecided)

This first OSPF packet indicates that a router with RID 10.0.0.1 send 224.0.0.5 in a form of Hello packet, trying to find adjacency with some routers. In this case the 10.0.0.1 is also an actual IP address used as source to send to 224.0.0.5 Hello packet.

The 10.0.0.1 router claims to be a DR with Priority value of 1. Since the router sits in Broadcast network, the router seeks another router as BDR.

Note that this 10.0.0.1 router will not become DR once the router finds a router with better value. Since 10.0.0.1 router already has Priority value of 1, another router can only be a DR when it has higher RID and wants to be a DR.

Step 2: INIT



In the same Broadcast network, there is a router with 10.0.0.2 RID send out Hello Packet. Note that even though this router has higher RID, the router does not wish to be a DR; indicated by 0 in Designated Router.

Step 3: TWO-WAY



This packet indicates that 10.0.0.1 router sees 10.0.0.2 as potential adjacent router, so that the Active Neighbor is now 10.0.0.2 RID.

Step 4: EXSTART



Since 10.0.0.2 RID does not wish to be DR even though it has higher RID, 10.0.0.1 decides to be DR while set 10.0.0.2 as BDR.

Step 5: EXCHANGE



Packets 5 to 8 are part of the EXCHANGE where the two routers 10.0.0.1 and 10.0.0.2 have Mutual DD messages exchanged. Note that the traffic type is Unicast instead of Multicast since the communication is strictly between the two IP addresses.

Step 6: LOADING



Packet 9 is about 10.0.0.2 sending Link-State Request to 10.0.0.1, asking about all link states 10.0.0.1 is aware of. Packets 10 and 11 are responses of Packet 9, that Mutual DD message exchanges take place.

Similarly, Packet 12 is about 10.0.0.1 sending Link-State Request to 10.0.0.2, asking about all link states 10.0.0.2 is aware of.



Packet 13 is about 10.0.0.2 sending Link-State Update to 10.0.0.1 as response of Packet 12. Similarly Packet 14 is about 10.0.0.1 sending Link-State Update to 10.0.0.2 as response of earlier LSR packet from 10.0.0.1 router.



This Packet 19 is about 10.0.0.1 sending Link-State Acknowledgement as response to LSU packet from 10.0.0.2 router. As DR, 10.0.0.1 this time sends LSU packets to 224.0.0.5 Multicast IP address ensuring all routers in Broadcast network see the same DD. Similarly, 10.0.0.2 as BDR also sends LSU packets to 224.0.0.5 Multicast IP address ensuring all routers in Broadcast network see the same DD.

Step 7: FULL



Packet 26 is the maintenance Hello packet since now routers 10.0.0.1 and 10.0.0.2 are at FULL stage.

Wireshark CAP files to Review

The full cap file of the adjacency processs can be downloaded here. You need to have Wireshark in order to read the file.

Following are additional Wireshark CAP files to illustrate different scenarios.

OSPF Adjacency on Broadcast network
Three routers form OSPF adjacencies across a broadcast segment. All interface priorities are left default, so R3 (with the highest router ID) becomes the DR, and R2 (with the next-highest router ID) becomes the BDR. Capture perspective from R1.

OSPF Adjacency on Point-to-Point network
The frame relay network between four routers is configured with point-to-point subinterfaces. No DR/BDR is required as all adjacencies are point-to-point. Capture perspective from R1.

OSPF Adjacency on NBMA network
Formation of OSPF adjacencies across a Non-broadcast Multiaccess (NBMA) frame relay topology. Neighbors have been manually specified on all routers, with R1 configured to become the DR. No BDR is present. Capture perspective from R1.

OSPF Adjacency on Multipoint network
Routers 1 through 4 are configured to view the non-broadcast frame relay network as a point-to-multipoint topology. Adjacencies are formed without the need of a DR or BDR. Note that inverse ARP was used to dynamically learn the addresses of neighbors.

OSPF LSA Types
Capture of adjacency formation between OSPF routers 4 and 5 in area 20. Packet #12 contains LSAs of types 1, 2, 3, 4, and 5.

OSPF Type-7 LSA
Area 10 is configured as a not-so-stubby area (NSSA). The capture records the adjacency formed between routers 2 and 3. The link state update in packet #11 includes several type 7 LSAs from R2. Capture perspective from R3's 10.0.10.1 interface.

OSPF Down Bit
LSA Update with down bit set. Router R5 56.0.0.5 PE is receiving an update from the MPLS VPN, which is advertised to CE 56.0.0.6 ospf routing table. In order for for the packet(LSA) not to be re-advertised back into the MPLS cloud through another PE(2) router, PE sets the Down-bit to 1. filter: ospf.v2.options.dn == 1

OSPF over GRE tunnel
Configured ospf over GRE tunnel in which packets are double tagged with ip header, useful when there is no direct connection between the 2 routers but still we need to run ospf.

Steady State Operation

When the OSPF topology has stabilized, the following standards operations occur:

• Routers sent hellos based on per-interface hello intervals

• Hellos are required within each dead interval, configurable per interface. Adj failures occur if this does not happen

• Each router refloods each LSA it originated every 30 min by default (LSRefresh)

• LSA refresh must occur within the Max Age timer (Default 60 min)

Configuration Notes

Tune OSPF to quickly update database exchange

• Cisco IOS show ip ospf interface command shows how specific interface as a member of OSPF network is set to behave

• The key of quickly update database exchange is to quickly detect dead neighbors and to quickly detect new or revived neighbors

• To quickly detect dead neighbors, tune the dead interval to minimal. The command to use is a Cisco IOS ip ospf dead-interval command

• To quickly detect new or revived neighbors, tune the hello interval to minimal. The Cisco IOS command to use is ip ospf hello-interval

• OSPF Fast Hello Packets ip ospf dead-interval minimal hello-multiplier 4 would configure a dead interval of 1 second, the resulting hello interval being one quarter of a second.

OSPF Process ID

• OSPF process IDs do not have to be the same for neighbor adjacencies to form.

Tune OSPF to prefer router as DR to others

• A router OSPF priority is configured from 0 - 255 on an interface. The higher the priority, the more likely the router will become the DR.

Reset OSPF process

• Cisco IOS clear ip ospf process command will restart OSPF on that router, causing all neighbors to fail and restart.

Configure interface as member of OSPF network

• With 12.3(11)T, you don't have to use the network statement in the OSPF paragraph to enable OSPF on a particular interface. Rather, you can use ip ospf x area x to do so on a specific interface. Which I like, since so much of how OSPF operates is interface-specific.

Set OSPF router as member of Stub Area

• In the router OSPF paragraph, you configure an area to be a stub with an area x stub statement. For that area to become totally stubby, add the no-summary keyword at the end.

Set OSPF router as Stub Router

• You can create an OSPF stub router, which is not the same as a stub area. Conceptually similar, but not the same. A stub router is expected to be a network endpoint solely - not a transit router. The stub router is only going to forward packets destined for locally attached networks.

Following is illustration


OSPF Route Filtering and Route Summarization

A statement of "filtering routes" within OSPF is a bit of a misnomer, as OSPF does not exchange routes with neighbors. Rather, it exchanges link-states. To wit, there are three different approaches to route filtering with OSPF on its ABR.

• You can do a distribute-list in to filter routes that SPF has calculated and are heading for the routing table. You are not filtering inbound LSAs, but rather limiting what you will allow OSPF to populate the routing table with from the LSDB.

• You can use an ABR to filter a prefix list of networks that will not be injected into (or out of, as you have configured) an area via type 3 LSA. An ip prefix-list list-name coupled with area x filter-list prefix list-name in|out

• You can summarize contiguous networks with an area range statement in the OSPF paragraph that tells the ABR to inject a larger, single summary type 3 LSA into the area, instead of injecting all the smaller networks that fall into the summarized area. And if you wanted, you could tack on a not-advertise keyword at the end, which caused the summarized LSA to not be advertised at all.

In regards of summarization, you can only summary at area border routers (ABR) or autonomous system boundary routers (ASBR). You cannot summarize within an OSPF area, because then there would be differences within the OSPF link state database. Such differences within OSPF link state database makes OSPF sad - more technically, it blows the SPF computation right out of the water. Ergo, OSPF will not allow you to summarize within an area - only ABRs or ASBRs.

ASBR Summary

In router ospf, an ASBR summary-address 10.0.0.0 255.0.0.0 command would inject a summarized external route of 10.0.0.0/8 at an ASBR.

ABR Summary

In router ospf, an ABR area 54 range 192.168.0.0 255.255.0.0 command would inject a summarized route of 192.168.0.0/16 into an area at an ABR, which is REALLY cool for making your routing tables smaller. Think about this for a second.

Let's say you had three Areas of 1, 2 and 3, plus backbone Area 0. Now let's say you had an awesome design where you had maybe hundreds of networks in Area 1, but they were all in the 10.1.0.0/16 range. And the same story in Area 2, but all your routes were in 10.2.0.0/16. Area 3, 10.3.0.0/16. Instead of advertising every single route out of those areas into the other areas, you could summarize at each area's ABR(s). The only route you'd see in non-Area 1 routers for Area 1 destinations would be the single summary route - 10.1.0.0/16. How cool is that? Using this technique, you could get your routing table down to something small, tidy and efficient. Easy to manage, easy to troubleshoot, scalable.

Default Routes

You can use the Cisco IOS default-information originate command in OSPF with following condition.

• The command works for RIP and OSPF, so it doesn't work for EIGRP.

• This command will redistribute any default route in the routing table, whether it's static or learned via some other protocol.

• You can add the keyword always to the end of the command, which means OSPF will advertise a 0.0.0.0/0 route from that router, whether there's one to redistribute or not.

Virtual Link

A Virtual Link in OSPF is about directly interconnect Non-Area-0 areas bypassing Transit Area (Area 0). A virtual link can be used in a situation where an area can't directly connect to area 0, or where you've got two areas with the same number (partitioned discontinuous areas) that need to be connected for proper OSPF functioning.

Authenticating OSPF neighbor for security purposes

OSPF authentication is possible with following conditions.

• You can use type 0 (none), type 1 (clear text) or type 2 (MD5).

• You enable authentication on a per-interface basis with Cisco IOS ip ospf authentication command.

• Default is none (no authentication).

• You can change the default authentication type for an area with the area authentication command in the router ospf paragraph.

• Keys are configured as interface commands.

• You can use multiple keys; if you do, OSPF will send one copy of the message per key, resulting in multiple messages.

Scenario Analysis

Following is an illustration. Suppose we have two directly connected IOS routers running OSPF, configured as follows.


Notice that the two authentication keys are different. Will they form an adjacency? The answer is yes. Let's explore why.

Recall that there are three types of OSPFv2 authentication

• Null - No authentication (yes, this counts as a type)

• Plain - A shared string is included in each OSPF packet as plain text (extremely weak)

• MD5 - A shared secret is used to generate a hash included in each OSPF packet

For illustration, this is how a plain authentication string appears in an OSPF packet header.



Contrast this to the irreversible hash-based authentication offered by MD5



The IOS command ip ospf authentication is used to configure plain authentication on an interface, whereas ip ospf authentication message-digest is used to configure MD5 authentication. Simple enough, right? However, there is a bit of dangerous ambiguity lurking here: two very different commands are used to configure the authentication keys for these two methods, which we'll cover in a moment.

The following is the output of show ip ospf interface from R1:

Note that although MD5 authentication is indeed enabled, OSPF reports that we have not configured an authentication key, so it defaults to using what is essentially a null key. Because this null key is the same on both routers, the adjacency forms successfully.

The problem here is that the wrong command has been used to specify the authentication key. A ip ospf authentication-key is used only for plain authentication. To specify an MD5 authentication key, we must use the command ip ospf message-digest-key

After correcting the configuration, we can verify that MD5 authentication is now in use.

This is the kind of mistake that can really trip you up, as it will appear to be working at first glance, but leaves your adjacencies wide open to hijacking.

NSSA with Multiple ABR

We all (hopefully) know what an NSSA is in OSPF. It's that cute little area that's sort of stubby, but not completely, which allows us to cut down on the size of the OSPF database while still doing redistribution into an area. What is a little lesser known fact however, is how calculation towards an external route originated in an NSSA differs from a normal route redistributed into OSPF. Check the above link for the detailed walkthrough of how this works, along with the diagram and initial configs for those of you that dont already have a subscription to the product, but the spirit of the situation is as follows.

As previously seen with OSPF Not-So-Stubby Areas, Type-7 NSSA External LSAs are translated to Type-5 External LSAs by the ABR connecting the NSSA to area 0. When multiple ABRs connect the NSSA to area 0, the ABR with the highest router-id is elected as the Type-7 to 5 translator, and is responsible for re-originating the Type-5 LSA into area 0. This election process is an optimization of the OSPF database, and relates to how the Type-7 NSSA External route uses the forward address field to ensure optimal routing.

Recall that with normal external routes, only one Type-5 LSA is originated by the router performing the redistribution. When the route moves between areas, each ABR originates a Type-4 ASBR Summary LSA advertising their reachability to the ASBR. This means that for all Type-5 External LSA inter-area lookups OSPF would require Ext_Routes + Num_ABRs + Num_Routers LSAs, where Ext_Routes is the number of Type-5 LSAs, Num_ABRs is the number of ABRs generating Type-4 ASBR summaries, and Num_Routers is the number of Type-1 LSAs from the routers in the local area.

Now with Type-7 LSAs the situation becomes more complicated, because this information needs to be re-originated at the ABR level as the route moves into area 0. Let's suppose for the sake of argument that each ABR connecting the NSSA to area 0 did do a translation of Type-7 to 5. This would mean for all inter-area lookups on a Type-5 External LSAs that were translated from Type-7, there would be (NSSA_Routes * Num_ABRs) + Num_ABRs + Num_Routers LSAs, where NSSA_Routes is the number of Type-7 LSAs to start.

This operation would be highly redundant and inefficient, because each ABR would re-originate the same Type-5 LSA, each with the same forwarding address. To avoid this only one ABR performs the Type-7 to 5 translation, but maintains the forward address field, essentially separating the relationship between the routing advertisement and the traffic flow. This principle can be illustrated as follows.

Let's assume the following

OSPF-speaking routers with associated RID
R1: 150.1.1.1
R3: 150.1.3.3 (ABR)
R5: 150.1.5.5
R6: 150.1.6.6 (ABR)
SW3: 150.1.9.9 (ASBR)

External route: 9.9.9.9

Before any modification in the OSPF domain, R5 performs a lookup on the Type-5 LSA for 9.9.9.9 that was translated from a Type-7 LSA. At this point R3 has an OSPF Router-ID of 150.1.3.3, and R6 has 150.1.6.6. The advertising router R5 sees is 150.1.6.6 (R6), since R6 won the translator election due to the higher RID. Note however, the forward address is set to 150.1.9.9 (SW3). This means that R5 next needs to figure out how to route towards 150.1.9.9.

Since 150.1.9.9 does not belong to a device in the same area as R5, an inter-area lookup is performed on the Type-3 LSA. R5 finds that two ABRs are advertising the route to 150.1.9.9, 150.1.3.3 (R3) and 150.1.6.6 (R6), both with a metric of 3.

R5 now needs to find what the metric is to reach these ABRs. R5 checks its locally originated Type-1 Router LSA and finds that 150.1.1.1 (R1) and 150.1.3.3 (R3) are directly attached, both with a metric of 64.

R5 asks R1 who it is adjacent with, and finds 150.1.6.6 (R6) is connected over the a Virtual-Link with a metric of 1.

This means that R5's intra-area cost to R3 is 64, and to R6 is 65. Since both R3 and R6 reported a cost of 3 to the forward address 150.1.9.9, the total forward metric through R6 is 65+3 = 68, but is only 64+3 = 67 through R3. Therefore although the route is originated into area 0 by R6, the Type-7 to 5 translator, the traffic does not actually flow through R6. Instead the path through R3 installed with the default redistribution metric of 20 for the E2 route, and a forward metric of 67 through R3.

This illustrates why a Type-5 External route that was translated from a Type-7 NSSA External route does not use a Type-4 ASBR Summary LSA, because the forward address lookup replaces the need for the ASBR Summary lookup. Since the forward address is preserved only one router needs to do the translation, while the calculation of the final forwarding path stays independent

The Type-7 to 5 translator election can be modified by increasing R3's router-id to be higher than R6's.

R5 now sees the advertising router as 150.1.30.30 (R3), because this is the highest router-id of the ABRs connecting the NSSA to area 0.

Although the advertising router has changed, the forward address is still 150.1.9.9, which means the traffic flow has not changed.

Only once the forward metric via R3 is higher than the forward metric via R6 will the path selection change. This can be accomplished by changing the OSPF cost on R3's link to SW1.

Now when R5 computes the forward metric through R3 it sees the same intra-area cost of 64 to R3, but R3 increased the advertised metric to 150.1.9.9 to 1002.

The final result is that the route is installed via R6 with a metric of 20 reported by the ASBR, plus the forward metric of 68 through R6.

If R6 loses connectivity to area 0 its route to the forward address is lost, and traffic is rerouted to R3.


NSSA and Prefix Filtering using Forwarding Address

Based on the requirement that FA (Forwarding Address) needs to be reachable for the respective external routes to be considered, we may devise a filtering scheme for external routing information. More specifically, if there is a way to filter out the prefix corresponding to the FA, this will stop all routers that lost this information from using the external prefixes. There are two cases here.

• The FA prefix is filtered at the ASBR. Since OSPF must be enabled on the external link, the only option left is configuring a different area on the external link and using the inter-area route filter (area x filter-list) to block the prefix from propagating further.

• The FA prefix is filtered at the ABR(s) of the area containing the ASBR. You may use any of the methods of OSPF Route Filtering to prevent type-3 LSA generation, e.g. use the inter-area route filtering.

Let's see how this could be done in a practical scenario. Below is a diagram of a single-area OSPF implementation. R1 redistributes RIP routes into OSPF.



We enable OSPF area 0 on R1's Frame-Relay interface (which uses the default non-broadcast OSPF network type) and apply inter-area route filtering.

R1:


Now look at the OSPF database in SW2:

Now check if this route is present in the routing table. Also make sure the FA address is not in the routing table too.

Now, remove the inter-are route filter in R1 and check SW2s routing table once again.

Finally, a few words on type-7 LSAs. Per the NSSA area RFC, the use of FA is mandatory with these LSAs. The reason is that there is only one 7-to-5 translating ABR and this might result in suboptimal routing without the use of FA. This makes the use of the special conditions mentioned previously unnecessary. You may always use FA-based prefix filtering with the external information conveyed in type-5 LSAs translated from type-7 LSAs.

Definitions

• LSDB - link state database. The topological database of all known routers, areas and links in the OSPF system.

• Dijkstra - the shortest path first algorithm, used to compute the fastest way to get to a particular network.

• Link-state routing protocol - exchanges information about links, as opposed to exchanging routes.

• LSA - link-state advertisement.

• LSU - link-state update.

• DD - database description. It's what gets sent in an LSU.

• Hello - used for several things in an OSPF network, including discovery, keep-alive, initial neighbor adjacency setup, and DR/BDR election.

• LSAck - sent as an acknowledgement of an LSU.

• RID - router ID. Each router ID in an OSPF system must be unique. Can be set manually, or will be chosen by the highest up/up loopback, or if no loopback, by the highest up/up IP interface.

• Neighbor state - an OSPF neighbor can have several states; init, two-way, exstart, exchange, loading, full.

• Neighbor - A discovered OSPF router on the same segment.

• Adjacent - an OSPF router that is full, i.e. the 2 routers are exchanges link-state information. Not all neighbors are considered adjacent in OSPF-speak.

• Fully-Adjacent - the OSPF database flooding process has completed.

• Two-Way - routers that have sent initial hellos to one another

• SPF algorithm - used by OSPF to compute routes based on the LSDB

• IP address of 224.0.0.5 - the multicast address for "all SPF routers"

• IP address of 224.0.0.6 - the multicast address for "all DR router"

• Area - a logical boundary group of OSPF routers.

• Network type - OSPF networks can be broadcast, point to point, point to multipoint, etc. with bearing on whether hellos will be used, whether DRs will be elected, and whether static neighbors must be assigned.

• External route - a route redistributed into OSPF from outside the routing protocol

• E1 route - external route where internal and external metrics are considered.

• E2 route - external route where only external metrics are considered.

• Hello timer - the interval between hellos, 10 seconds by default on broadcast, 30 seconds on T1 or slower.

• Dead interval - defaults to 4x the hello time, the amount of time hellos are missed before the neighbor is considered dead.

• Sequence number - placed on an LSA, it is used by routers to determine if their LSDB is current. Routers with old sequence numbers will request an update for that LSA.

• DR - designated router. The router responsible for flooding LSAs to other routers on the segment. On segments where there are DRs, OSPF routers will only become fully adjacent to DRs and BDRs.

• BDR - backup designated router. The router that takes over the DR role when the DR falls off the network.

• DROther - routers that are not DRs or BDRs.

• Priority - the higher the OSPF priority number, the more likely the router will be elected the DR.

• LSA flooding - sending LSAs to the multicast address of 224.0.0.5 (all SPF speakers on the segment).

• DR election - the process whereby a designated router is elected.

• SPF calculation - the process of determining the most efficient way to forward traffic for a specific network.

• Partial SPF calculation - what routers in one area do when routers in another area experience an LSA change.

• Full SPF calculation - what routers in one area do when there's a change to an LSA in their area.

• LSRefresh - 30 minutes by default, how long between LSA flooding a particular LSA.

• Hello time/interval - is this different from the hello timer above? I will check

• MaxAge - the timer tracking LSA age, default 2x LSRefresh. If no one's heard about this LSA by MaxAge, it's dead.

• ABR - area border router. The router sitting in between Area 0 and one or more other areas.

• ASBR - autonomous system boundary router. A router that redistributes routes from another routing protocol into the OSPF system. He could be sitting in any non-stubby area or NSSA.

• Internal router - not an ABR or ASBR. All interfaces connect to a single OSPF area.

• Transit network - the network two OSPF routers found each other on, implying that it can be used to forward packets for other networks.

• Stub network - a network with only one OSPF router connected.

• LSA type - the format for a particular LSA is defined by its type.

• Stub area - an area where type 5 LSAs are not injected.

• NSSA - not-so-stubby area. An area where type 5 LSAs are not injected in, but type 7 LSAs are allowed out.

• Totally stubby area - an area where type 5 LSA's are not injected in, and neither are type 3 LSAs. You get a default route, and that's about it. And you're going to like it, mister!

• Totally NSSA - totally not-so-stubby area. An area where type 5 LSA's are not injected in, and neither are type 3's. On the other hand, type 7's are allowed out.

• Virtual link - a logical connection that allows for areas with no physical connection to area 0 to be connected to it. Can also be used to connect partitioned areas.

• Stub router - a router that will only forward inbound packets for connected networks.

• Transit router - a router that will forward to another router if needed to get the packet to its destination.

Some Cisco IOS OSPF Commands and Features

Database Filtering

ip ospf database-filter all out
neighbor database-filter

Incremental SPF

OSPF Incremental SPF

Incremental SPF is more efficient than the full SPF algorithm, thereby allowing OSPF to converge faster on a new routing topology in reaction to a network event. So how does this work?

OSPF uses Dijkstra's SPF algorithm to compute the shortest path tree (SPT). During the computation of the SPT, the shortest path to each node is discovered. The topology tree is used to populate the routing table with routes to IP networks. When changes to a Type-1 or Type-2 link-state advertisement (LSA) occur in an area, the entire SPT is recomputed. In many cases, the entire SPT need not be recomputed because most of the tree remains unchanged.

Incremental SPF allows the system to recompute only the affected part of the tree. Recomputing only a portion of the tree rather than the entire tree results in faster OSPF convergence and saves CPU resources. Note that if the change to a Type-1 or Type-2 LSA occurs in the calculating router itself, then the full SPT is performed.

Incremental SPF is scheduled in the same way as the full SPF. Routers enabled with incremental SPF and routers not enabled with incremental SPF can function in the same internetwork.

How do you enable it?


How to verify its is enabled?


OSPF Shortest Path First Throttling

OSPF Shortest Path First Throttling

Timers used in OSPF

In any IGP there are a lot of timers involved in running the protocol. This post will not
describe the hello and dead timers, these are well known. This post describes the less known
timers that control how often packets are sent and how often SPF is run. Modifying timers is
not recommended unless you have a very good reason to do so.

Every interface running OSPF has a flood-list with the LSAs that need to be sent out that
interface. This command configures how long to wait for additional LSAs and pack them into
a single update packet. This saves resources like CPU usage but setting it too high will lead
to slower convergence.

Controls how long to wait to send LSAs that are unacknowledged using the same grouping
principle.

Every LSA has a maxage, the default is 1 hour and LSAs are usually refreshed at half their
maxage which is 30 minutes. Earlier versions of IOS would refresh all LSAs at once regardless
of age which led to CPU spikes. Later an individual timer was implemented which led to not all
LSAs expiring at once but every LSA was sent individually. The group pacing feature looks at
LSAs that are expiring at the near same time and group these together. LSAs that
expire within 75 seconds will be grouped together, the default value is 240 seconds.

Next we will look at throttling the SPF algorithm.

This timer throttles the SPF algorithm, if there is a flapping link or something causing a lot
of LSAs being sent and requiring SPF to run this can affect performance of CPU. When the first
LSA arrives the timer will run SPF after spf-start msecs. If there is another event within spf-
hold the timer will be doubled. If Another event occurs inside this hold-time the timer is once
again doubled, it is an exponential timer. Spf-max-wait makes sure there is a roof so that the
timer is not set to high. If there are no events for 2 times the max-wait the timer will revert
back to spf-start.

Also the sending and receiving of LSAs can be throttled.

Defines how long to wait before sending LSAs. By default the first LSA is sent immediately and
the timer is set to hold-interval. If another LSA needs to be generated it will be generated at
hold-interval and the hold-interval will doubled. When the topology is stable after 2 times the
max-interval the timer will revert back to start-interval. If there are several events during an
interval they will be grouped and sent at hold-interval or max-interval depending on how
many events that have occured.

How long to wait before accepting the same LSA. If it is received faster than this timer the LSA
will be dropped. This timer should be set to less than or equal to the hold-interval of the
timers throttle lsa all command.

Interface command. Estimate of time needed to send a link-state update over
a link. Should only matter on really low bandwidth links. LSAs that are sent will
have their age incremented by the amount this command specifies before
being sent.

How long to wait before transmitting unacknowledged LSAs.

OSPF Per-Interface Link-Local Signaling (LLS)

OSPF Per-Interface Link-Local Signaling

OSPF Compatability and LLS

Recently during an upgrade of a Cisco router I ran into a strange problem where my OSPF neighbors that were working prior to the upgrade stopped working after the upgrade. I also noticed that the broken neighbors were only to non-Cisco devices, namely Nortel Contivity VPN devices.

I could see this by checking the neighbor status from sh ip ospf neighbor

Doing a bit a research, I found on Cisco's website that by default Link-Local Signaling or LLS is enabled by default.

LLS allows for the extension of existing OSPF packets in order to provide additional bit space. The additional bit space enables greater information per packet exchange between OSPF neighbors. This functionality is used, for example, by the OSPF Nonstop Forwarding (NSF) Awareness feature that allows customer premises equipment (CPE) routers that are NSF-aware to help NSF-capable routers perform nonstop forwarding of packets.

When LLS is enabled at the router level, it is automatically enabled for all interfaces. The OSPF Per-Interface Link-Local Signaling feature allows you to selectively enable or disable LLS for a specific interface. You may want to disable LLS on a per-interface basis depending on your network design. For example, disabling LLS on an interface that is connected to a non-Cisco device that may be noncompliant with RFC 2328 can prevent problems with the forming of Open Shortest Path First (OSPF) neighbors in the network.

My OSPF topology is fairly small and the traffic is very light. So the need for non-stop forwarding isn't as great. In my situation I just disabled LLS globally.

As soon as I disable LLS capability - all my neighbors came right up!


OSPF Forwarding Address Suppression in Translated Type-5 LSAs

OSPF Forwarding Address Suppression in Translated Type-5 LSAs