Category Archives: OSPF

Open Shortest Path First

OSPF Network Type & Timers

Network Types:
Broadcast to Broadcast
Non-Broadcast to Non-Broadcast
Point-to-Point to Point-to-Point
Point-to-Multipoint to Point-to-Multipoint
Broadcast to Non-Broadcast (adjust hello/dead timers)
Point-to-Point to Point-to-Multipoint (adjust hello/dead timers)

#show ip ospf intergface #


Tag Archives: TLV Format
o Uses fixed format packets with all fields aligned at 32-bit boundaries for faster processing of the OSPF packets (doesn’t really matter anymore as the CPUs are really fast these days!). This was primarily done because OSPF was meant to be an IPv4 only protocol.
o The downside of the above is that the packet formats are not at all extensible. We had to come out with OSPFv3 when we wanted to provide support for IPv6.
o It uses Link State Advertisements (LSAs) for advertising the routing information and the original specification called for dropping any unrecognized LSA type.
o LSAs of type 9, 10 and 11 have been introduced for advertising other application specific information and enough vendors now support this so that they are likely to get from one side of the network to the other.
o Since the unrecognized LSA types are not flooded to neighbors it makes it very difficult to extend OSPF. This in turn means that all the OSPF routers must be upgraded network-wide to make the new extensions work.
o The new RFCs (Traffic Engineering, GMPLS extensions, etc) written for OSPF now support TLV encoding.

o Exhibits implicit opaque LSA behaviour i.e. unrecognized LSA types are flooded to the neighbors making it more extensible that OSPFv2
o Designed in a way which makes it easily extensible to any other layer 3 protocol suite.
The individual fields are not TLVs; the entire “old LSA” has been put into a TLV. This allows the new inter area ruote LSA to carry new kinds of reachability information in the future by simply including new TLV types in the new LSA type. If a new address family needs to be supported, it is just a matter of creating a new TLV that can be used to describe this new reachability and putting it into the existing inter-area LSA. The LSA provides the context, while the TLV provides the data.

Migration between the old and new TLVs is managed much like migration between narrow and wide metrics in IS-IS; routers capable of generating the new LSA types do so; these new LSAs are marked so routers that do not understand them simply reflood them (they don’t process them in any way). So long as there is any router flooding the older style TLVs within the netwrk (or flooding domain, there are options for both), the new TLVs will not be used to compute loop free paths. Once all the routers in the network (or, again, flooding domain) are advertising the new TLVs, then preference can be given to the new TLVs, and, finally, the old TLVs removed from the network.

Hopefully vendors implement these new TLV based LSA formats quickly, as they will make OSPF much more extensible over the long run.

Ep9 – What Your Mamma Never Told You About OSPF

Ep9 – What Your Mamma Never Told You About OSPF
From Network Collective

Vertex – Node/Router
Micro loop –
CAP Theorem – Originally develop for databases.

– Does full mesh very good, Partial mesh
– Ring (If you know what you’re doing, be careful with “Micro Loop”)
– Triangle based that is good for link state scalability.

OSPF is design to have synchronize database “CAP Theorem”

Is it good in Hub & Spoke design?
One of the ways to make ospf to work in hub&spoke network or for any network where ospf is performing well would be the use of “Stop synchronizing the database”

If we breakup the flooding domain using traditional ospf tools like “Areas/Hiding topology information thru summarization/prefix aggregation”

Russ White – Optimal Routing Design Book
“There’s no rule in Hub&Spoke design, The spokes don’t necessarily state for all spokes”

What we can do is go on hub and use “OSPF database all out” command. Why would you ever us this, There is a case that you might use because if the hub doesn’t send state any LSA to all any downstream spoke can still learn information from the spoke. So we can route downstream.

But how do spoke route upstream? Could be a simple static routes.

Spoke don’t have state Drother, A spoke and ospf flooding never occur downstream direction.

3 Components of routing protocol
Database (Distributive) allows everyone to see what the topology looks like.
Hello is about topology discovery. “I need to know who I am connected too.” That the primary thing about hello.
Algorithm to allow you to compute loop free paths over that database.

When we talked about distributive database we need to actually write in database theory and CAP Theorem.

CAP Theorem – Distributed database. Underneath problem.
Basically says you can choose two of three it’s Consistency, Accessibility and Partitioning.

The more you partition the database the more either to give up accessibility.

It’s affecting a single database, split it across two machine, lock the record during write so that nobody reads the wrong information out.

In routing protocols every router in your network has full access to entire database constantly there’s no way to lock records in routing protocols.

So what you do is essentially give up complete consistency in order to get accessibility and total partitioning.

When you’re building shortest path your using shortest path first algorithm that treats the network as graph, So you have edges and links or Vertices.

Sample of micro loops. Links between to routers break and path move to the upper mid router, But router still know’s that the nexthop still the left side router so it will forward it back, In case your in 10G environment it will have a big impact in your production.
Order FIB/RIB. LFA “Loop free alternate”

IP Address & Router ID
#show ip ospf database
– Type 1 LSA is not a reachable destination.
– Type 1 is a router ID
– Type 1 doesn’t mean the IP is reachable.
– It’s a string.

All link state protocol works the same way. You discover your neighbors, you build your graph based on your neighbors. There’s nothing to do with IP address when building your graph. IP has nothing to do with neighbor discovery or anything except you carry the packets over IP.

But within the actual process of discovery neighbor and building OSPF tree there’s nothing to do with IP and any of that. It’s just router ID and once you build that then you actually hang your IP reachability off the graph.


LSA TYPE 4 – When your performing inter areas lookup on a external route. Injected type 4 which injected by “ABR”. Injected by ABR at flooding domain boundary.

The reason why it’s done is because first of all the ABR is the one doing the summarization.

It knows that information going to be missing but beyond that it knows that it has 1 of those ABR has best path to reach that “ASBR” and its gonna be the one who built the type 4. So that way you know where the best way that inter area 1 is, in order to get to the shortest path to that external border. So it’s actually gives you the information back.

In this case in reducing my state by summarizing the topology information but I’m actually loosing my optimization.

How to know who’s the DR/BDR?
# show ip ospf interface
# show ip ospf neighbor

Totally summary to default.

Multiple ABR Design. ABR primary will have the routes to longest matches and ABR backup will have the default “Stub”.

Type 3 filter design – Much Cleaner easier to understand. You know what’s being allow or blocked. You can’t do this with external routes, if you don’t have lots of external, but if you need to control external routes across ABR you’re basically stuck in stub areas.

What is next in ospf?
– Making like IS-IS TLV type.
– Multi area ospf on a single link.

Note: In OSPF a link can be one on 1 area only. In IS-IS you have 2 neighbor adjacencies, Lever 1 and Level 2 . OSPF was design to have 1 single neighbor adjacencies.

TLV’s on OSPFv3 all lsa type being replicated in TLV format to get closer to ISIS.

History: IS-IS and OSPF. Why there no TLV before in OSPF. The process is much smaller, 8bit/16bit process which is big deal. So fixed link field has better performance.

OSPF Cost/Metric

E1 & E2 are external route types.
E2 have a default metric is 20 and it will not change or increment this value along a path.
E1 is have also default metric is 20 as well, but they will add metrics at each hop, which is making them easier to operate along with internal routing paths.

Open Shortest Path First (OSPF) uses “Cost” as the value of metric and uses a Reference Bandwidth of 100 Mbps for cost calculation.

The formula to calculate the cost is Reference Bandwidth divided by interface bandwidth. For example, in the case of 10 Mbps Ethernet , OSPF Metric Cost value is 100 Mbps / 10 Mbps = 10.

The default Reference Bandwidth of OSPF is 100 Mbps and the default OSPF cost formula doesn’t differentiate between interfaces with bandwidth faster than 100 Mbps. These days, 1 Gbps and 10 Gbps links are also common.

EIGRP VS OSPF Convergence

Different answer on EIGRP and OSPF convergence time:

1. I think you can configure both to converge extremely fast, but if I had all Cisco routers, I would prefer EIGRP because of it’s flexibility regarding the design. OSPF has it’s own rules (area 0, filtering/summarizing only on abrs, etc.)

However, with OSPF ip ospf dead-interval minimal hello-multiplier 4 you can set 4 hellos per second (gives hello interval = 250ms), adjust dead timer to 1 second and you will have a pretty fast convergence. I don’t know whether with EIGRP you can get under 1 second for a neighbor to fall.

2. If EIGRP has a feasible successor route in it’s topology table and the active route in the route table fails then it is almost instantenous in terms of failing over to the new route because EIGRP does not need to query any other routers or do any internal calculations, it simply installs the new route.

3. EIGRP convergence time increases as more routes need to be processed. However, there is a far bigger impact for networks with EIGRP feasible successors than for networks with no feasible successors.

Subsecond timers are not available for EIGRP. Experimentation suggests that setting the EIGRP timer below 2 seconds can lead to instability. The recommended EIGRP minimum timer settings are 2 seconds for hellos and 6 seconds for the dead timer. Subsecond settings are not an option, While OSPF Subsecond hellos are supported DeadInterval-minimum 1 second

Hello multiplier is used to specify how many Hellos to send within 1 second

Additional Article:

EIGRP is now an IETF draft so it’s no longer proprietary. See

If we look at EIGRP with default settings and OSPF with default settings and there are multiple loop free paths to a destination then EIGRP will converge much faster because it keeps what are called feasible successors in it’s topology database. These are basically loop free alternatives to the best path. EIGRP also has summarization at any point in the network. It also has stub feature which is useful when you don’t want to use a router for transit. Commonly deployed in DMVPNS. EIGRP is also less confusing than OSPF because it does not have different network types and EIGRP is easier to deploy in hub and spoke scenarios.

EIGRP uses a flat network without areas, this can both be an advantage and disadvantage.

OSPF is obviously an open standard so it’s the logical choice if you have multiple vendors. It can perform well but it requires that you tweak SPF timers because by default in IOS there is a 5 second wait before running the SPF algorithm. OSPF uses areas which means you can segment the network more logically. OSPF can only summarize between areas. OSPF is link state so it has a better view of the entire network than EIGRP before it runs the SPF algorithm. Network administrators will usually be more comfortable with OSPF because it’s more commonly deployed.

Both protocols have advantages and disadvantages. But the common answer that EIGRP should be discarded because being proprietary is not entirely true any longer.

From a practicle perspective I would say that in the case of EIGRP vs OSPF, OSPF always wins for the following reasons:

Convergence Speed:
Everyone always mentioned that EIGRP is faster than OSPF using default settings. If you deploy either protocol without reading about them and use their default settings, then you clearly don’t know what you are doing in my opinion. Why would you deploy default settings without knowing what they are, and when you do realise what they are you realise that OSPF supports BFD and becomes lightening quick (as does ISIS).

Traffic Engineering:
Because OSPF like ISIS is based on TLV values, it has been extended quite a lot. It has support for extensions like MPLS-TE and GMPLS.

Continual Expansion
As I mentioned above, OSPF and ISIS have been extended quite a lot and extension drafts are being written fairly regularly and will continue to be. EIGRP doesn’t have many of the advanced options these two do.

OSPF scales better than EIGRP with its use of areas however, I don’t think this really matters either (like the convergence time aregument, due to BFD). Not many people are running 10k routes in one area in OSPF. Typically I would use an IGP for fast routing within a given part of a network, but ultimately iBGP carries all the internal routes. Every single router doesn’t need every internal route in its RIB sourced via OSPF if you have hundreds or thousands or routers, some of them are so far away (topologically speaking) it’s worthless knowing about them.

Lastly there is the obviously reason that EIGRP is/was a Cisco proprietary technology. Although this has recently been submitted into a draft for other software vendors to start incorporating, it’s too late (I believe). No currently running network is going to waste huge sums of money switching from some other IGP to EIGRP, and I don’t know why a new network would consider it (if you are going to be mixing Cisco equipment with non-Cisco). Simply because non-Cisco equipment that supports OSPF has been doing so for years. The code is tried and test, many bugs fixed, oodles of information on line etc. It will take years for EIGRP to catch up (if it isn’t too late already!).


DR – designated router in multi access network topology act as collector and distributor for LSAs. A BDR – backup designated router is elected in case the designated router fails. All other router become DROthers. Instead flooding LSA to all routers in multi access network, DROthers only send their LSAs to the DR and BDR using multicast address The DR use multi access address And the result is that only DR router flood all the LSAs in multi access network.

DR Election:
1- Choose the highest OSPF priority (default is 1, note that if you configure priority of 0 that router wont enter the election process – used on FR networks.) router (config-if)#ip ospf priority {0 to 255}
2- Choose the highest router-id.
3- Choose the highest loopback interface.
4- Choose the highest configured physical interface (must be up/up).

What is the maximum and minimum number of DR and BDR in an Area:
You can only have 1 DR and 1 BDR in an area. When the DR goes down, the BDR becomes DR and then an election is taken place to see who is new BDR.

Network Multiaccess network
I think of multiaccess is that any network segment on which a DR needs to be elected.

DR and BDR is elected on per interface basis.Dr/Bdr is elected on multiaccess network type, so in an area the number of DR/BDRs depends on the number of multiacess interfaces you have in that particular area.

R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 1 FULL/DR 00:00:32 GigabitEthernet0/0 1 FULL/DR 00:00:36 GigabitEthernet0/1

Router-id can’t be the same as the other segment.

So if your router has 2 segments in different/same multiacess networks it can be a Dr/BDR on 1 segment at the same time it can be a DRother router on another multiacess network.Per segment an OSPF process can have a single DR with no BDR or a single DR and a single BDR.

Multi access networks create challenge for OSPF because:
a) create multiple adjacencies (one adjacencies for every pair of router)
b) extensive flooding of LSA – link state advertisement
for n -routers it is n(n-1)/2 adjacencies.

Command to verify DR/BDR:
1. show ip ospf interface
2. show ip ospf neighbor

Note: point-to-point, point-to-multipoint, point-to-multipoint non-broadcast networks will not.




Type 1 LSA: (Router) – Every router generates router link advertisements for each area to which it belongs. Router link advertisements describe the state of the router links to the area and are flooded only within that particular area. For all types of LSAs, there are 20-byte LSA headers. One of the fields of the LSA header is the link-state ID. The link-state ID of the type 1 LSA is the originating router ID.

Type 1 LSAs are generated by every router and flooded within the area. They describe the state of the router links in that area. Two type 1 LSAs in the database: one received and one is generated.

#show ip ospf database – The output shows details for both links, to what kind of network the links are connected, and their settings, such as the IP configuration. Link can be connected to a stub, to another router (point-to-point), or to a transit network. The transit network describes Ethernet or NMBA segment, which can include two or more routers. If the link is connected to a transit network, the LSA also includes the info about the DR address.
#show ip ospf database self-originate – Displays locally generated type 1 LSAs.

Type 2 LSA: (Network) – The DR of the network is responsible for advertising the network LSA. A type 2 network LSA lists each of the attached routers that make up the transit network, including the DR itself, and the subnet mask that is used on the link. The type 2 LSA then floods to all routers within the transit network area. Type 2 LSAs never cross an area boundary. The link-state ID for a network LSA is the IP interface address of the DR that advertises it.

For broadcast networks only; the designated router for the broadcast segment uses this to list all the routers connected to the segment directly.

#show ip ospf database network – Shows the details of a type 2 LSA on router.

Type 3 LSA: (Summary) – An ABR takes the information that it learned in one area and describes and summarizes it for another area in the summary link advertisement. This summarization is not on by default. The link-state ID of the type 3 LSA is the destination.

ABRs do not forward type 1 and 2 LSAs between areas to improve OSPF scalability. However, other routers still need to learn how to reach interarea subnets in other areas. OSPF advertises these subnets on ABRs by using type 3 summary LSAs.

The ABRs generate type 3 summary LSAs to describe any networks that are owned by an area to the rest of the areas in the OSPF autonomous system, as shown in the figure.
Summary LSAs are flooded throughout a single area only, but are regenerated by ABRs to flood into other areas.

#show ip ospf database – Displays OSPF LSDB.
#show ip ospf database summary – The output in the examples shows detailed information about three type 3 LSAs in the LSDB. Each type 3 LSA has a link-state ID field, which carries the network address, and together with the attached subnet mask describes the interarea network.

Type 4 LSA: (Summary External) – The ASBR summary link advertisement informs the rest of the OSPF domain how to get to the ASBR. The link-state ID includes the router ID of the described ASBR.

The ASBR sends a type 1 router LSA with a bit (known as the external bit) that is set to identify itself as an ASBR. When the ABR (identified with the border bit in the router LSA) receives this type 1 LSA, it builds a type 4 LSA and floods it to the backbone, area 0. Subsequent ABRs regenerate a type 4 LSA to flood it into their areas.

#show ip ospf database – Displays OSPF LSDB.
#show ip ospf database asbr-summary – A type 4 LSA contains information about the existence of the ASBR in the OSPF autonomous system. The information is advertised to R4 from R1, which recognizes the ASBR capability of R3 with a router ID of

Type 5 LSA: (AS External link advertisement) – which are generated by ASBRs, describe routes to destinations that are external to the autonomous system. They get flooded everywhere, except into special areas. The link-state ID of the type 5 LSA is the external network number.

Type 5 external LSAs used to describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.

#show ip ospf database – shows OSPF LSDB, with a focus on type 5 LSAs.
#show ip ospf database external – The zero forwarding address tells the rest of the routers in the OSPF domain that ASBR itself is the gateway to get to the external routes.

Type 6: Specialized LSAs that are used in multicast OSPF applications. Group membership (Multicast OSPF)
Type 7: Used in special area type NSSA for external routes. Prefixes from Not so stubby area
Type 8, 9: Used in OSPFv3 for link-local addresses and intra-area prefix. External attributes proposed attributes for ibgp peering relation.
Type 10, 11: Generic LSAs, also called opaque, which allow future extensions of OSPF.

Stub Area – An area that has a single exit point and blocks type 5/7 LSA types and receives type 3/4 LSA’s with a default route ( This type of stub area is an IETF standard. To configure an Area as a stub you’d execute the area # stub in OSPF router configuration mode on the ABR.
R1(config)#router ospf 1
R1(config-router)#area 12 stub

R2(config)#router ospf 1
R2(config-router)#area 12 stub
LSA: 1 – 3

Total Stubby Area – Permits type 1 and 2 LSA’s while blocking types 3*/4/5/7 LSA’s. *TSA’s receive a single type 3 LSA containing a default route to the ABR. This type of stub area is an extension to OSPF created by Cisco. To configure an area as a totally stubby area you’d execute the area # stub no-summary in OSPF router configuration mode on the ABR.
R1(config)#router ospf 1
R1(config-router)#area 12 stub no-summary

R2(config)#router ospf 1
R2(config-router)#area 12 stub no-summary
LSA: 1 & 2

Not-So-Stubby-Area (NSSA) – This area allows a stub area to have characteristics of a stub and non stub. External routes advertised into the OSPF autonomous system by am NSSA advertising an LSA type 7 which is translated at the ABR to type 5 and forwarded into the OSPF backbone. This type of stub area is an IETF standard. To configure an area as a NSSA you’d execute the area # nssa in OSPF router configuration mode on the ABR.
R1(config)#router ospf 1
R1(config-router)#area 12 nssa

R2(config)#router ospf 1
R2(config-router)#area 12 nssa
R2(config-router)#area 12 nssa default-information-originate (cannot be routed to external destinations without a default route)
LSA: 1 – 3 & 7

Totally NSSA – Is an area that permits LSA’s 1, 2 and 7 while blocking 3 4 and 5. This stub area receives a default route from the ABR using a type 3 LSA. This type of stub area is an extension to OSPF created by Cisco. To configure an area as a not so totally stubby area area you’d execute the area # nssa no-summary in OSPF router configuration mode on the ABR.
R1(config)#router ospf 1
R1(config-router)#area 12 nssa

R2(config)#router ospf 1
R2(config-router)#area 12 nssa
R2(config-router)#area 12 nssa default-information-originate (cannot be routed to external destinations without a default route)
R2(config-router)#area 12 nssa no-summary
LSA: 1&2 & 7


Reading OSPF Database Details

By using the show ip ospf database we can look at the LSDB and we can see the type 1 router LSAs, type 2 network LSAs and the type 3 summary LSAs here. What else do we find here?

R1#sh ip ospf database

OSPF Router with ID ( (Process ID 1)

Type-1 Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count 178 0x8000000C 0x00790D 3 1603 0x80000006 0x00F424 1

Type-2 Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum 1603 0x80000004 0x009B88

Type-3 Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum 1603 0x80000004 0x003AF5 1957 0x80000003 0x002C04 1116 0x80000004 0x004975 1702 0x80000003 0x003B83

Type-4 Summary ASB Link States (Area 0)

Link ID ADV Router Age Seq# Checksum 1 0x80000001 0x001E12

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag 7 0x80000001 0x00E944 0 8 0x80000001 0x00DE4E 0 8 0x80000001 0x002EEE 0 8 0x80000001 0x00BF53 0

Link ID: This is what identifies each LSA.
ADV router: the router that is advertising this LSA.
Age: The maximum age counter in seconds. The maximum is 3600 seconds or 1 hour.
Seq#: Here you see the sequence number which starts at 0x80000001 and will increase by 1 for each update.
Checksum: There is a checksum for each LSA.
Link count: This will show the total number of directly connected links and is only used for the router LSA.

Link Count:
From RFC 2328
two links per point-to-point network; one for the router adjacency and one for the subnet (IOS uses option 2 for the stub network link).

In OSPF database, a point-to-point link is modelled actually as two entries in LSA1: one entry describes solely a direct connection to another router, without advertising the network that is present on the link. The second entry advertises the network on the point-to-point link as a stub network.

Note that there are two entries there. The first entry describes a point-to-point link – on which R1’s interface router it starts and what does it connect to. The second entry contains the address of the network that is present on the point-to-point link.



OSPF Procces ID

Process IDs need to match within the router or your interfaces will be in separate OSPF instances.

Process id used by ospf is only to differentiate between the different processes if more than one ospf is running on the router. Its like to denote the different database formed by different ospf processes.

Process id can be any number the only thing required is the area and timers should match.


– All routers are running OSPF.
– R3 is running OSPF process 1 on network {R3-left} and OSPF process 10 on network {R3-right}.

+ R3 will have network {R1-Left} in its RIB via OSPF process 1.
+ R3 will have network {R2-Left} in its RIB because it’s directly connected.
+ R3’s OSPF-10 LSDB will not have any info about networks {R4-Left} or {R5-Left}.
+ R4’s OSPF LSDB is identical to R3’s OSPF-200-LSDB. Thus, neither {R1-Left} nor {R2-Left} will be in its RIB.

OSPF Router with ID ( (Process ID 10)

Router Link States (Area 20)

Link ID ADV Router Age Seq# Checksum Link count 31 0x80000009 0x0010EA 1 618 0x8000000B 0x00F2FD 1 27 0x80000015 0x00B272 1 address is in PID: 10.

– No 192.168.5.

Solution: Redistribute OSPF Process 10 to OSPF Process 1 on R4

R4(config)#router ospf 1
R4(config-router)#redistribute ospf 10 subnets

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag 556 0x80000002 0x003069 0 58 0x80000001 0x00BA37 0 181 0x80000001 0x00D95C 0

Why do we need to use different PID?
Suppose you work for company Alpha, who just acquired company Omega, and both companies run OSPF across their internal networks. Your long-term goal may be to integrate the two network infrastructures, but your short-term goal may be to simply get them talking. This would be one of several interim solutions.

When OSPF Becomes a Distance Vector Protocol?

When OSPF Becomes a Distance Vector Protocol?

Inter-area OSPF is actually a distance vector routing protocol.

OSPF areas are connected by one or more Area Border Routers (the other main link state protocol, IS-IS, connects areas somewhat differently) which maintain a separate link state database and calculate a separate shortest-path tree for each of their connected areas. So an ABR by definition is a member of two or more areas. It advertises the prefixes it learns in one area to its other areas by flooding Type 3 LSAs into the areas that basically say, “I know how to reach these destinations.”

Wait a minute – what that last concept described is not link state, it’s distance vector. The routers in an area cannot “see” past the ABR, and rely on the ABR to correctly tell them what prefixes it can reach. The SPF calculation within an area derives a shortest-path tree that depicts all prefixes beyond the ABR as leaf subnets connected to the ABR at some specified cost.

And that leads us to the answer to the question:

Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0.

This is my little gift to you. The next time you are being interviewed by an old coot that likes to use this question to weed out the cookbook operators from those who actually understand a little about OSPF, you can bring a smile to his grizzled face.

This process uses a quick and simple distance-vector computation algorithm, without the need for SPF computations. The router’s routing table is used extensively during this process.

How are Type 3 LSAs generated? First of all, keep in mind that OSPF generates those by walking the main routing table, not the LSDB. This is per RFC 2328 clause 12.4.3 and in full accordance with distance-vector protocol behavior. Every route in the table has additional OSPF information associated with it, such as area number, route-type (intra-area, inter-area, external) next hop, and so on.

2) Now, for dealing with the inter-area routes learned by the ARB, first of all, keep in mind that an ABR ONLY accepts and processes type-3 LSAs received from the backbone area. This is the well-know loop prevention mechanism built into OSPF, since OSPF behaves as a distance-vector protocol when dealing with inter-area routing information. This is a short description of how an ABR processes type-3 LSAs:

Summary: It’s says that when it comes to TYPE 3LSA / ABR distance-vector algorithm take place. OSPF behaves as a distance-vector protocol when dealing with inter-area routing information because it advertises the prefixes it learns in one area to its other areas by flooding Type 3 LSAs into the areas that basically say, “I know how to reach these destinations.”