Daniels quest for CCIE

This is a follow up post to my last OSPF post about repairing area 0.
In the comments section Ray asked me what we can do if we have a
scenario where we have another area that is discontigous. In this
example we are using area 1. Area 1 is used everywhere but between
R1 and R4 is the backbone area. The routes will therefore be
interarea. What if we were told to make these routes appear as
intra area? First look at the topology. Download .net file and
initial and final configs here.

First we start by confirming that routes received on R1
are coming in as interarea routes.

Yes they are. This is expected behaviour. So what can we do to
make them appear as intraarea? Using a virtual link does not help
since it always belongs to area 0. We could use the tunnel technique
that was used in the previous post. Let’s try that. Same procedure as
last time. Source tunnel from physical interface. Use IP unnumbered
from an interface in area 1.

The tunnel is up and we have a new adjacency.

The IP address is 0.0.0.0/0 and located in area 1. Lets look at the
router LSA for area 1.

The address is 0.0.0.16 just as the last time. This should be 10 according
to the SNMP MIB but as one of my friends Patrick pointed out 16 in decimal
is 0×10 in hex. Maybe it is encoded in hex?

So now lets check the routing table.

Problem solved. Routes are now received as intraarea. So there you have it,
another OSPF problem solved.

First start by looking at the diagram above. This is a scenario I ran into while
doing my mock lab. It is pretty obvious that we will have issues with OSPF since area 0
is discontigous. You should be able to spot this by just looking at the diagram.

So what are the tools we have to repair discontigous areas? The most common and
straightforward is to use a virtual-link. However in this scenario it is not allowed.
First lets look what issues we will have in this topology. I have prepared the
topology and initial configs with OSPF for you which can be downloaded here, final configs are also included.

We start by looking at the routing table of R1.

We can only see the loopback of R2. Why is that? R1 is an ABR. It has an
interface in area 0 and in another area. It will not install interarea routes
received on a non backbone interface.

This is the database on R1. We can see that all IA routes are indeed in
the database but they are not being installed into the RIB. To test our
thesis from the last OSPF post, lets shutdown Fa0/0 on R1. This should in
theory mean that R1 is no longer an ABR and that it can install routes
received on a non backbone area.

It works. So our knowledge of OSPF seems good. So this is an option we
can use, although we would not have reachability to R2′s loopback. The techniques
I show here would generate no points for the OSPF section but having reachability
in IGP is critial so if you can’t do something the right way, cheat!
What I mean by that is that if you don’t have reachability you will loose points
later in BGP, MPLS, multicast and maybe even IPv6 and security section. So you
see a lot of points are at stake and if we can’t solve a task the right way do it
some other way. Use static routes if you must!

We were not allowed to use a virtual-link but lets try that anyway to
see that we can install all the routes.

Yes, now we have reachability. We would loose 2 or 3 points probably for doing
this but could potentially save us 10-15 points later. I ended up having to do
this on my mock since I had problems configuring the solution below.

So if we can’t use a virtual link, where does that leave us? We need a link
between R1 and R4 that is located in area 0. How about a tunnel? Yes, that is
definately an option. However we are not allowed to introduce any new
IP addresses into the network. How do we solve that? IP unnumbered, we have to
borrow an IP from another interface. Lets setup the tunnel.

We source the tunnel from a physical interface and the destination is the other
side of the FR connection. Why source from the physical interface? We don’t have
reachability to loopbacks yet since our IGP is broken, therefore we have to use
the physical address. Why unnumbered from the Ethernet interfaces? They are located
in area 0. We must have an IP that is located in area 0 to repair the discontigous network.

So now we have an adjacency both over serial0/0 and over the tunnel. The tunnel
interface is point-to-point and has a very high cost. Notice that the IP for
the tunnel is 0.0.0.0/0.

Now look at the routing table of R1.

We can see that prefixes are reached via 155.1.34.4. This is the IP of Fa0/0
on R4 which was derived from the IP unnumbered. So what is interesting here
is that the adjacency between R1 and R4 is not in the same subnet, so we
are bypassing that check. We can also see that we need to recurse routing
lookups since the routes are pointing at 155.1.34.4.

This route is reached via the tunnel. If we look at the OSPF database on R1
we see a router LSA for R4 and there is the P2P link.

Router Interface address is 0.0.0.16. This is interesting, normally this is
the IP address of the interface. We are now using unnumbered. I’m not sure
why it is choosing 16. RFC says the following:

“For unnumbered point-to-pointlinks, the Link Data field should be set to
the unnumbered interface’s MIB-II [Ref8] ifIndex value.

If we look at the SNMP MIB, must enable SNMP first.

So this value should be 10. Seems like Cisco is not really following
the RFC (RFC2328) here. We can enable that behaviour with interface-id snmp-if-index.

Now we have the expected value of 10.

You can read more at Cisco.

So this should give you a look into OSPF. I have also attached a packet capture so that you can look at the LS Update going over the tunnel interface. We can see that the source of the
packet is 155.1.14.4 which is R4 IP addess and the destination is 155.1.14.1.
In there we have the other IP packet which has a source of 155.1.34.4 and a destination
of 224.0.0.5.

OSPF is by far the most complicated IGP on the RS lab if we go in to the details of the protocol and the loop prevention mechanisms. While doing some labs this week I ran in to some interesting issues. This post will describe different scenarios and test your understanding of OSPF. I will show a diagram and ask a question, try to answer it and when you want to know the answer then the text is hidden below. You can see the text by marking it since it’s written with a white font.

Lets begin. We will start with an issue I ran into while doing an ASET lab (Cisco partner labs). Look at the following diagram.

R5 is a PE in a MPLS VPN backbone. R5 is running OSPF in a VRF towards the CE R4. However R5 will not install interarea routes received from R4, why? Look at the following output.

R5#sh ip ospf data sum 1.1.1.3

OSPF Router with ID (1.1.1.5) (Process ID 100)

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

Summary Net Link States (Area 51)

Routing Bit Set on this LSA
LS age: 1386
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.3 (summary Network Number)
Advertising Router: 1.1.1.4
LS Seq Number: 80000003
Checksum: 0xED3
Length: 28
Network Mask: /32
TOS: 0 Metric: 76

R5 is part of the MPLS super backbone (area0) so it is an ABR. ABRs will not install interarea routes that are received over a non backbone area. If the area between R4 and R5 was area 0 then there would be no issues but since we are using area 51 we have to use a workaround. We enable the capability vrf-lite under the ospf process which disables the loop checks of the PE

Now lets define some of the concepts of OSPF and test your understanding. Look at the diagram.

Is R3 an ABR?

No, the definition is that an ABR is a router with an UP interface in the backbone area and at least another area.

Will R3 generate IA routes for Area 1 and 2?

No, it is not an ABR so it will not generate any IA routes.

Now we create a loopback on R3 and put it in OSPF area 0. No OSPF adjacencies can of course be built over this interface. Will R3 generate any summary routes now?

Yes, even though R3 is not really connected to Area 0 it has an UP interface in area 0 so it will announce itself as an ABR and generate summary routes.

R2#sh ip ospf border-routers

OSPF Process 1 internal Routing Table

Codes: i – Intra-area route, I – Inter-area route

i 1.1.1.1 [1] via 155.1.12.1, FastEthernet0/1, ABR, Area 1, SPF 7
i 3.3.3.3 [1] via 155.1.23.3, FastEthernet0/0, ABR, Area 1, SPF 7

Summary Net Link States (Area 1)

Link ID ADV Router Age Seq# Checksum
33.33.33.33 3.3.3.3 13 0×80000001 0×004566
155.1.16.0 1.1.1.1 1958 0x8000000D 0x00B9C5
155.1.34.0 1.1.1.1 939 0×80000006 0x00155D
155.1.34.0 3.3.3.3 19 0×80000001 0x00CEA2
155.1.35.0 1.1.1.1 942 0×80000006 0x00145C
155.1.35.0 3.3.3.3 21 0×80000001 0x00C3AC
155.1.45.0 1.1.1.1 942 0×80000006 0x009BCB
155.1.45.0 3.3.3.3 21 0×80000001 0x005F06
155.1.46.0 1.1.1.1 942 0×80000006 0x0086E0

If we traceroute the IP of R5 this is the path.

R1#traceroute 155.1.35.5

Type escape sequence to abort.
Tracing the route to 155.1.35.5

1 155.1.16.6 140 msec 76 msec 48 msec
2 155.1.46.4 92 msec 64 msec 64 msec
3 155.1.45.5 184 msec * 108 msec

Why is this and how can we make the path go directly from R1 to R3 to R5? Look at the OSPF database.

Summary Net Link States (Area 1)

Link ID ADV Router Age Seq# Checksum
33.33.33.33 3.3.3.3 534 0×80000001 0×004566
155.1.16.0 1.1.1.1 437 0x8000000E 0x00B7C6
155.1.34.0 1.1.1.1 1459 0×80000006 0x00155D
155.1.34.0 3.3.3.3 542 0×80000001 0x00CEA2
155.1.35.0 1.1.1.1 1463 0×80000006 0x00145C
155.1.35.0 3.3.3.3 543 0×80000001 0x00C3AC
155.1.45.0 1.1.1.1 1463 0×80000006 0x009BCB
155.1.45.0 3.3.3.3 543 0×80000001 0x005F06
155.1.46.0 1.1.1.1 1463 0×80000006 0x0086E0

R3 is announcing the summary but it is not being used by R1. Why?

R1 and R4 have full adjacencies via Area 0 so they will not accept summary routes received on a non backbone interface. To fix this we need a full adjacency between R1 and R3 which is created with a virtual link.

R3(config-router)#area 1 virtual-link 1.1.1.1
R1(config-router)#area 1 virtual-link 3.3.3.3

R1#sh ip ospf data sum 155.1.35.0

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

Summary Net Link States (Area 0)

Routing Bit Set on this LSA
LS age: 10 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 155.1.35.0 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xC3AC
Length: 28
Network Mask: /24
TOS: 0 Metric: 1

R1#traceroute 155.1.35.5

Type escape sequence to abort.
Tracing the route to 155.1.35.5

1 155.1.13.3 64 msec 40 msec 44 msec
2 155.1.35.5 80 msec * 64 msec

R1 is now using the direct path since R3 is now a real ABR. However as R3 now has an adjacency to Area 0 it will no longer accept summary routes from R4. If we want to fix this another virtual link is needed.

I hope this post gave you some things to think about regarding OSPF. This post was mostly inspired by the great document from Petr Lapukhov

Finished OSPF Vol1 tonight. I should know pretty much everything about OSPF by now. Here are some advice that I think is good when handling OSPF.

show ip ospf data self-originate – Will show what LSAs the local router is generating

show ip ospf data summary 150.3.0.0 adv-router 150.8.4.4 – Will show the Type3 inter-area summary as advertised by the router 150.8.4.4 (Router-ID)

show ip ospf border-routers – Shows the cost of reaching ABR and ASBR, a nice shortcut for finding the forward metric when you are looking at external routes. You can find this out yourself by checking costs of the links to reach the advertising router but this is a nice shortcut.

show ip ospf data | be Type-7 – Will start the OSPF database output for the NSSA external prefixes, change Type to whatever you want to look at.

These are some of my favourites, what commands do you use yourselves? Post in comments.

Did some OSPF labbing yesterday. Ran into some interesting stuff. Imagine that you are running a frame-relay network which is hub and spoke. All routers are using their main interface for communication. The hub router has the static frame relay mapping with the broadcast keyword but the spokes don’t. They are all running OSPF network type point-to-multipoint.

What will happen if we only have broadcast capability in one direction? The hub router sends multicast out its main interface reaching all the spokes. The surprising part is that spokes reply with unicast packet using immediate hello. The adjacency forms and everything is fine and dandy. However after a while the hub declares the spokes as dead, why?

Since the spokes don’t have multicast capability the hub never receives their hello packets. Remember the hello packets are used as keepalive mechanism so after 120 seconds they are declared dead. Quite an interesting scenario and would be interesting to put as trouble ticket at the CCIE lab If you as I never heard of immediate hellos you can read this URL. Basically its a way of forming adjacencies and converging faster. Instead of only sending hello packets at HelloInterval the router will immediately respond to incoming hello packets. The draft was written by 3 Huawei engineers.

Just did this lab earlier today and wanted to post some stuff that might help people. I’ve posted earlier on how to quickly find out IP-addresses and masks with different commands. I played around a little more today and this is another one that works nicely.

RSRack1R3#sh ip int | i Internet_address|FastEth|Serial|Loop|Vlan
FastEthernet0/0 is up, line protocol is up
Internet address is 144.1.34.3/24
FastEthernet0/1 is up, line protocol is up
Internet address is 204.12.1.3/24
Serial1/0 is administratively down, line protocol is down
Serial1/1 is administratively down, line protocol is down
Serial1/2 is administratively down, line protocol is down
Serial1/3 is administratively down, line protocol is down
Loopback0 is up, line protocol is up
Internet address is 150.1.3.3/24

And then we have an OSPF command that I don’t use often enough.

RSRack1R1#sho ip ospf border-routers
OSPF Process 1 internal Routing Table
Codes: i – Intra-area route, I – Inter-area route
i 150.1.5.5 [64] via 144.1.15.5, Serial0/0.105, ASBR, Area 0, SPF 10
I 192.10.1.254 [3] via 144.1.17.7, FastEthernet0/0, ASBR, Area 0, SPF 10
i 150.1.10.10 [65] via 144.1.15.5, Serial0/0.105, ABR, Area 0, SPF 10
i 150.1.2.2 [1001] via 144.1.17.7, FastEthernet0/0, ASBR, Area 1, SPF 15
i 150.1.7.7 [1] via 144.1.17.7, FastEthernet0/0, ABR, Area 0, SPF 10
i 150.1.7.7 [1] via 144.1.17.7, FastEthernet0/0, ABR, Area 1, SPF 15
i 150.1.8.8 [2] via 144.1.17.7, FastEthernet0/0, ABR, Area 0, SPF 10
i 150.1.8.8 [2] via 144.1.17.7, FastEthernet0/0, ABR, Area 1, SPF 15
i 150.1.4.4 [128] via 144.1.15.5, Serial0/0.105, ABR/ASBR, Area 0, SPF 10

This commands shows the cost to reach the ABRs/ASBRs. This cost can be calculated manually but this way is faster for sure.

Found out an interesting thing while doing a Vol3 lab. We all know that EIGRP will not form an adjacency over a non common subnet unless special circumstances. What about OSPF? I had a lab task where I need to form an adjacency over an ip unnumbered link. To my surprise this works just fine. If you debug you will get a message like this:

*Mar 1 00:15:14.155: OSPF: Rcv pkt from 155.1.15.2, FastEthernet0/0, area 0.0.0.0 : src not on the same network

However the database is correct and routes are installed. If you want to try this yourself use two routers with a serial link between them and then do ip unnumbered from an Ethernet interface and enable OSPF as usual. Watch what happens. Does anyone have a good description of this behavior? I tried looking in the RFC but all I could find is this:

“All routers connected to a common network must agree on certain
parameters (Network mask, HelloInterval and RouterDeadInterval).
These parameters are included in Hello packets, so that differences
can inhibit the forming of neighbor relationships.”

“An adjacency is bound to the network that the two routers have
in common. If two routers have multiple networks in common,
they may have multiple adjacencies between them.”

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.

Router(config-router)# timers pacing flood 50

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.

Router(config-router)# timers pacing retransmission 100

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

Router(config-router)# timers pacing lsa-group 75

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.

timers throttle spf spf-start spf-hold spf-max-wait

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.

timers throttle lsa all start-interval hold-interval max-interval

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.

timers lsa arrival milliseconds

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.

ip ospf transmit-delay seconds

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.

ip ospf retransmit-interval seconds

How long to wait before transmitting unacknowledged LSAs.

This post is based on notes from my practicing OSPF vol1 labs. I want to have them saved
for later reference but I also think that this post can help others and clear some of the
confusions of OSPF.

Lets assume that we have some lab tasks that involve OSPF. The first thing we should do
is make a diagram with all the devices and the areas that the interfaces are connected
to. If this diagram is already provided for us and we find it usable, then don’t waste
time doing a new one! Otherwise if there isn’t one of if your not happy with it, make
a new one.

I like to make diagrams in Visio but when we diagram for the lab its about being
effective so don’t try to create some masterpiece. I just use circles for routers and
squares for switches and then I write the device name inside the circle or the square.
Then I write the interfaces on the devices and IP if needed and make circles for the
areas that include the interfaces.

So these are some of the things I have noted down when labbing.

• The default mode of OSPF on frame-relay interfaces is non-broadcast

What does this mean? Non-broadcast means a few things. Non-broadcast means we cannot
send multicast or broadcast. Non-broadcast also means that a DR will be used.
Remember that if you see the prefix non in the OSPF type then we need to use neighbors.
If we have a hub and spoke topology we want to make sure that the hub always becomes
the DR since we won’t have l2 mappings to the other spokes in our frame-relay cloud.

How can we accomplish this? Remember that electing the DR is not preemptive, so we can
set the hub to have the highest priority and it is elected the DR and everything is fine
and dandy. When we have an outage at the hub and it comes back up but reachability is
not restored, why? While the hub was away another device could have been elected the DR
and just because the hub is back does not mean that it will assume its previous role.
So we need to make sure that the hub is elected the DR and that the other devices are
not eligible to be elected DR or BDR. The way of doing this is by entering ip ospf priority 0
under the frame-relay interface. Devices with a priority of 0 are not eligible for being
elected as DR/BDR.

• Adjacencies and convergence can take a while in NBMA networks, dont panic!

What do I mean by this. While labbing I was noticing that forming adjacencies took quite
some time. I was typing show ip ospf nei and looking at the status and it would be EXSTART
or something else for quite some time before the adjacency was formed. So give it a few
minutes before you make the assumption that something is wrong with your config.
Remember that the timers on NBMA networks 30 seconds for hello and 120 for dead.

• Neighbor command is only needed on DR

We won’t break anything by entering the neighbor command on the spokes but isn’t it better
to know how something works than just throw config at it? The spokes will only communicate
with the DR and the DR will be responsible for forming the adjacency. When we enter the
neighbor command under OSPF config mode on the hub it will start sending unicast packets
to the IP addresses that we have specified. Remember that multicast is the default in
most routing protocols. The hub sends unicast packets to the spokes which will notice that
unicast is being used and start replying with unicast themselves.

• A router is not an ABR if no interfaces in area 0

This might sound a bit confusing. Lets say that we have a router with interfaces in area 1
and area 3. This must be an ABR right? Wrong! Unless it is connected to the backbone it
is not actually an ABR and it will not send type 3 summaries describing the other areas
networks. If you want some more background on this and a great article on OSPF I
recommend that you read Petr Laphukovs post at INE.

• Using point-to-point mode

This mode is the default for interfaces that use point-to-point type of encapsulations
like HDLC or PPP. This mode can also be used to force a loopback to be advertised with its
configured mask instead of a /32 host route. This mode uses multicast and no DR is elected.
There is no need for a DR here since there can only be two devices communicating to each other.

• Using point-to-multipoint mode

This mode is designed to work in partial mesh NBMA networks. When we use this mode
we will see that there is a /32 route for every spoke pointing to the hub. Also all routes
that are learned will have their next-hop changed to the IP of the hub. This means that
we do not need to have map statements for the other spokes. As this mode uses multicast
we need to have the keyword broadcast in our frame-relay statements.

• Using point-to-multipoint non-broadcast

This works the same way as point-to-multipoint but the traffic is sent via unicast packets
instead of multicast. This means that we must have neighbor statements in our OSPF config.

• Hints that we should use non-broadcast mode

If we have a broadcast segment like Ethernet and we are told that the OSPF
communication must be secured so noone can interfere with it then we should use
non-broadcast mode. Default on Ethernet segments multicast will be used but that
means that anyone can listen to the packets if they are connected to the segment.
If we enable non-broadcast the packets will be sent via unicast. Optionally we can
enable MD5 as well.

This post should give you an understanding of the different modes in OSPF,
remember that non-broacast always means neighbor statements.

 

• Defined in RFC 2328
• Supports VLSM and CIDR
• Is a link state protocol
• Uses a link state database (LSDB) for topology information, identical within area
• Reliable flooding of LSAs
• Uses hello protocol to build adjacencies
• Runs directly over IP, protocol 89
• Uses the Dijkstra algorithm

Packet types

OSPF uses five different packet types, do not confuse this with the different LSA types. The packet types are:

Type 1: Hello packet – The hello packet is used to discover/mantain neighbors
Type 2: Database description – Summarize database contents, sent when establishing adjacency.
Type 3: Link State Request – Database download
Type 4: Link State Update – Database update
Type 5: Link State ACK – Flooding acknowledgement

LSA types

These are the most common LSAs:

LS type 1: Router-LSA                   

Originated by all routers. Describes the collected states of the routers interfaces to an  area. Flooded throughout a single area only.

LS type 2: Network-LSA              

Originated for broadcast and NBMA networks by the designated router. Contains a list
 of routers connected to the network. Flooded throughout a single area only.

LS type 3: Summary-LSA            

Originated by area border routers. Describes a route to a destination outside the area(Inter-area route) but still inside the AS.

LS type 4: Summary-LSA              

Originated by area border routers. Describes routes to Autonomous System Border Routers.

LS type 5: AS-external-LSA        

Originated by Autonomous System Border Routers, flooded throughout the AS. Describes routes external to the AS. Defaults routes for the AS can be described by this LSA.

LS type 7: NSSA-LSA                     

Originated by Autonomous System Border Routers. Used to flood AS external routes through a stub area. The ABR connected to the backbone will then convert it to a type five LSA.

Designated Router (DR)

On broadcast and NBMA networks a Designated Router (DR) is elected. The router with the highest priority will be elected the DR. The priority can range from 0 to 255 where 255 is the most preferred and where 0 is ineligible to become the DR. A Backup DR (BDR) will also be elected and it will be the router with the second highest priority. The election is not preemptive which means if a router is setup later with a higher priority it will not become the DR unless clearing the OSPF process. The DR has two main functions. Generate a network LSA that lists the set of routers connected to the network. It is also responsible for maintaining adjacencies. The DR and BDR uses the AllDRRouters address of 224.0.0.6. They send updates to the 224.0.0.5 AllSPFRouters address.

Timers used by OSPF

HelloInterval – Length in seconds between hello packets sent on interface, defaults to ten seconds on broadcast networks and thirty on NBMA.
RouterDeadInterval – Number of seconds before neighbor is declared dead, 40 on broadcast and 120 on NBMA (4x missed hello packets)
Wait Timer – Number of seconds before router leaves Wait state and elects designated router. If a router joins later than this it will not have a chance to be elected as DR. Same value as RouterDeadInterval.
RxmtInterval – Number of seconds between LSA restransmissions, also used for DBD and LSR packets.

Interface states

Down – The initial state of an interface, lower level protocols have indicated that the interface is not ready for use. No protocol traffic can be sent or received and no adjacencies can form.

Loopback – The interface is looped back to the network either in hardware or in software. By default will be announced as host routes (/32). To announce with another mask on loopback interface use ip ospf network point-to-point.

Wait – Router is trying to determine the DR and BDR of the network. The router monitors the hello packets it receives. The router is not allowed to elect a DR or BDR until the wait timer has expired.

Point-to-point – In this state the interface is operational and connected to either a physical point-to-point network or to a virtual link. Upon entering this state the router attempts to form an adjacency and sends hello packets every HelloInterval.

DR Other – All routers except for DR and BDR will be in this state and will form adjacencies with the DR and BDR.

Backup – The backup designated router, will be promoted to DR if/when the DR fails. Forms adjacencies with all other routers.

DR – The designated router, forms adjacencies with all other routers. Responsible for building network LSA for attached network containing links to all routers.

Neighbor states

Attempt – Only seen on NBMA networks. No recent information has been received by the neighbor, send hello packets every HelloInterval.

Init -  A hello packet has recently been seen from the neighbor, 2-way communication has not yet beeen established. All neighbors in this state or higher are listed in hello packets sent from the interface.

2-way – Bidirectional communication has been assured through the hello protocol. The BDR is chosen from neighbors in state 2-way or greater.

ExStart – The first step in creating an adjacency between neighboring routers. The goal is to decide which router is the master and the initial DD sequence number.

Exchange – The router is describing its entire link state database with DBD packets. Every DBD packet has a sequence number and there can’t be more than one DBD packet outstanding unacknowledged at a time. LSR packets may also be sent requesting newer LSAs.

Loading – In this state LSR packets are sent asking the neighboring router for LSAs described in the DBD packets earlier.

Full – In this state the routers are now fully adjacent.

The hello protocol

Used to build and mantain neighbor adjacencies. Used to insure there is bidirectional communication between neighbors. Hello packets are sent out periodically on all OSPF interfaces unless passive interface is used. On broadcast and NMBA networks OSPF elects a Designated Router (DR) and a Backup Designated Router (BDR). If there is no support for multicast neighbors might need to be statically configured.

Synchronization of link state databases

When using link state protocols it is critical that the link state databases are syncrhonized. In OSPF this is done when building the adjacency by sending DataBase Description packets (DBD). The DBD packets describe the LSAs in the link state database, they are a summary only showing necessary information to request the whole LSA if needed. When exchanging LSAs there is a master/slave relationship. The router with the highest IP will become the master. This is indicated through the MS bit (Master/Slave). If the DBD packet is the first in sequence it will also have the I (Init) bit set. All DBD packets except for the last one will have the M bit set (More). After describing the database with DBD packets the routers can exchange the full LSAs through LSR (Link State Request) and LSU (Link State Update) packets.

Optional capabilities

ExternalRoutingCapability – indicates if the area supports external (type five) LSAs. Also known as the E-bit. Set to one if supporting external routes. Must be set to zero in stub areas.

Identifiers used by OSPF

Router-ID:

A 32-bit number that uniquely identifies a router in the AS. In Ciscos implementation OSPF will choose a loopback interface with the highest IP configured as Router-ID, if no loopback is available it will pick the highest IP of normal interfaces. Recommended to set this manually. If Router-ID has changed, a restart of the OSPF process is necessary.This can be done with the clear ip ospf process command.

Area ID:

A 32-bit number identifying the area. The number 0.0.0.0 is reserved for the backbone, also written as 0. All areas must connect to the backbone but note that if running a single area only this area doesn’t need to be area zero.

OSPF design and router roles

Topology divided into areas,  often not necessary with modern routers, scales to hundreds of routers in one area.
Depending on where router resides it can have different roles:

Internal router: Router with interfaces in only one area.
Backbone router: Router with an interface in the backbone (area zero).
Area border router (ABR): Router with interfaces in at least two areas.
Autonomous System Boundary Router (ASBR): Router which injects routing information external to the AS. Will often do redistribution.

Route preference in OSPF

1. Intra-area routes
2. Inter-area routes
3. Type 1 external
4. Type 2 external

External routing information

Can either be of type one or type two, E1 or E2. If using an E1 metric the metric will be the external cost and the cost internally to reach the router advertising the external route (ASBR). If the external metric is 100 and the internal metric is 150 then the E1 metric will be 250 but if using E2 metric it would be 100. If a route is advertised as both E1 and E2 then E1 is preferred.

The backbone

Area zero is called the backbone, most often written as area 0 but can also be expressed as 0.0.0.0. The backbone area must be contigious. Doesn’t have to be physically contigious, can use virtual links to connect areas which are not directly connected to area zero.

Stub area

Area where no external routing information is allowed (type five). To reach external routes a default route is used, the default route is sent by the ABR. The stub area can not contain an ASBR, since type five LSAs are not allowed. All routers in a stub area must agree that the area is in fact a stub. A stub area usually has only one exit point but note that a stub can have both several exit points and several ABRs in the area.