OSPF LSA Flooding and Metrics

OSPF and LSA Flooding

We investigate OSPF LSA flooding and metrics within the backbone area as well as other areas that are of different types evaluation and understanding.

LSA is the acronym for Link-State-Advertisements. LSA overview

Within the lab we will configure OSPF according to the design steadily in the general understanding of how OSPF works. In this lab we will ask ourselves the question:

• “What are we expecting to see?” as well as
• “What do we see? “

If there are any discrepancies then we need to look at the applicable rfc and understand the why’s and how’s of our expectation vs what we find in the topology.

I will also break this lab down in sections in case you are familiar with the ‘easy’ stuff and want to get into the ‘meaty’ stuff… feel free to scroll down although I would suggest if you use this as an OSPF case study, then use an hour or two and work through it slowly.

Do note that we are working in Junos and after your configuration statements you have to ‘commit’. I did not add all the commits after the config changes in the statements

It is my opinion that if we understand the in’s and out’s once and for all, we will never have to ‘study’ this topic again.

Sections

1. OSPF area 0 LSA flooding and metric manipulation
2. OSPF 3 standard areas and LSA flooding
3. OSPF backbone, standard area and stub area LSA flooding
4. OSPF backbone, standard area and nssa area LSA flooding
5. OSPF dual ABR’s between area and which one will rule the roost?
6. OSPF external LSA’s and metrics.

Section 1 – OSPF area 0 LSA flooding and metric manipulation

Let’s go back to basics and create the most important area namely area 0 which is also known as the backbone area. According to the rfc all other areas communicates to each other via area 0.

The first question is “Can we start OSPF with any other area except area 0”

The answer is yes, and it will work as well… the unexpected results will start when you add other areas to this non-0 area. You are on your own if you have made such a design.. case closed, do not try to rewrite the rfc.

Let’s look at the ‘first stage’ lab layout.

OSPF Network 1

We will get this running by configuring the interfaces and add the interfaces to OSPF.

LSA refresher – Single Area

OSPF LSA Flooding and metrics is a function of the protocol and will happen by default. It is our role to understand these defaults and what we can do to change or influence the protocol behavior.

Router Id’s

Important. We have to configure a router-id for each router. This ‘router-id’ used to be the loopback interface, yet due to mis-configurations etc. , it is now mandatory to configure the router-id with its own 32 bit address. Do note that although the router-id looks like an IP-address, it is just a 32 bit value.

Can this be the same as the loopback address? Absolutely yes! And it would make troubleshooting easier. Can we use a different address for the loopback and the router-id? Again the answer is yes.. if there is a sound reason why you would want to do that, you have free reign… experienced networkers will remind you though that networks are complex enough and you do not have to add more complexity, thus I will also keep the loopbacks and router-id’s the same 32 bit value.

As an example for those that have not configured OSPF on a Juniper Router before, here is R1’s configuration in the following order.

1. Configure interfaces
2. Configure router-id
3. Configure OSPF

R1 – Interfaces

lab@R1# set interfaces ge-0/0/1 unit 0 family inet address 172.16.0.1/30

lab@R1# set interfaces lo0 unit 0 family inet address 192.168.0.1/32

Configure Router-Id

lab@R1# set routing-options router-id 192.168.0.1

Configure OSPF

lab@R1# set protocols ospf area 0.0.0.0 interface lo0.0 passive

lab@R1# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0

After a similar configuration on R2, R3 and R4 according to the design layout we want to verify if we have neighbour relationships between the routers

R1

R2

R3

R4

All good at the moment, OSPF neighbours relationships are according to our design, let’s look at the OSPF database on router R1

We see a similar result on R2, R3 and R4 as well, except that the ID ‘*’ are on different ID’s as expected due to the ‘*’ indicating that this is the network advertised by the local router.

What we want to investigate is the OSPF LSA flooding and metrics and for this we can look at the current output and the field called “Type”. We have two types namely “Router” and “Network”. If we peek back into theory we realize these are LSA-1’s (the routerLSA) and LSA-2’s (the networkLSA )

If we look at another ‘show’ command it might provide us with more information, I will use R2 this time

All good again, we can still see the types as “Router” and “Network”, and we have a bit more information being indicated by “Intra” . What does “Intra” tell us ? Aha.. it means this LSA is internal to the area, else there will be an “Inter”.. we will see that later when we start adding additional areas.

The default Metric

A thing that is a bit confusing at the moment is the “Metric” value that is set at “1”. Where did the router get this metric from? We have not configured anything for the metric yet.

Digging back into theory we get the answer and understand that the default metric is calculated based on a 100Mb/s interface. (Just quickly, by default, a 100Mb/s interface metric is 1, a 10Mb/s metric is 10). It is a bit old though and will always calculate a gigabit interface as ‘1’ unless we manually change the metric per interface under the OSPF interface configuration or we can change the reference bandwidth in OSPF used for the calculation.

Changing the reference bandwidth sounds like a plan and will keep a consistency in our network. If we change the reference to 1 Gb/s it will change the metric to 1 for 1Gb/s interfaces, and if we change the reference to 10Gb/s it will change our 1Gb/s interface metric to 10. Let’s do that and change it to a 10Gb/s reference. Below the example for R2, I have done the same on all four routers.

[edit protocols ospf]

lab@R2# set reference-bandwidth 10g

What does it look like now?

Great, the metric is now 10 per link for each 1Gb/s interface. Remember that lower metric interfaces will be preferred when OSPF calculates the spf.

Let’s have a look at another output

Well, that sums up what we expected to see from OSPF LSA flooding and metrics. In an OSPF area 0 with no other external areas or external routes area there are only “Router” and “Network” LSA’s.

Damp the network LSA

With the 4 router network we still have seven LSA’s being advertised, can we not make it less?

If we have a look at the following output, we do have an insight into Designated and Backup designated routers indicated by the “DR and BDR” states. There are enough discussions on DR’s and BDR’s due to multi-access networks and because we are using Ethernet interfaces the below is expected.

Can we get rid of the DR election on Ethernet interfaces? Yes we can.

We will go back and configure the interfaces in the OSPF protocol hierarchy to be point-2point interfaces which will solve the DR elections. Below an example from R2, and we have to do the same for the neighbours else OSPF will recognise a type mismatch and our neighbour relationship will not establish.

lab@R2# set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p

lab@R2# set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 interface-type p2p

lab@R2# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p

The output of the previous show command have now changed to the following:

No more DR’s and BDR’s. Is there any change to the OSPF database?

Yes there is. We have just got rid of the network LSA’s and almost halved the database. Have these network LSA’s completely disappear? Yes and no. You will still see the attached networks using the following command, although LSA-2 are not being advertised ( screenshot output shortened)

Conclusion of Section 1

• The OSPF LSA flooding in a single area OSPF produce only 2 LSA’s namely the Router and Network LSA ( LSA-1 and LSA-2)
• The default interface metric for OSPF will be 1 for any interface faster than 100MB/s and we can change this behaviour using the reference bandwidth statement in OSPF and we can also do a ‘custom’ metric per interface within the OSPF hierarchy.
• Using p2p interface types under the OSPF configuration statements, we get rid of the Network LSA’s ( LSA-2) and half the OSPF link state database when our physical interfaces are Ethernet. No need for DR/BDR election on point-point Ethernet interfaces.

Section 2 – OSPF with 3 standard areas and LSA flooding

OSPF Flooding Part-1

In this section we will be adding two standard areas to the existing backbone or area 0. Furthermore we will change area 9 to be a Stubby-Area in the next part.
The first area, area 9 will be connected to R3 and area 27 will be connected to R4.
Below the updated design layout.

The Area Boundary Router

The first area we will configure is area 27. This will be configured on R4 and R6.
Router R4 will be an ABR ( Area Boundary Router ) with 2 ospf databases. One database for area 0 and 1 database for area 27.

The links are kept as point-2-point types within OSPF. This is done to dampen the LSA-2 like we did in part 1 keeping this a standard area. This implies that no custom configuration is done to dampen the new Summary-LSA flooding as we will notice after the configuration.

The configuration statements for R4 is as follows:

lab@R4# set protocols ospf reference-bandwidth 10g ( OSPF Interface reference metric )
lab@R4# set protocols ospf area 0.0.0.0 interface lo0.0 passive ( The interface establish neighbour relationship with ‘Hello’)
lab@R4# set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 interface-type p2p ( This was done in part 1 )
lab@R4#set protocols ospf area 0.0.0.27 interface ge-0/0/1.0 interface-type p2p ( NEW )

The configuration statements for R6 is as follows:

lab@R6# set protocols ospf area 0.0.0.27 interface lo0.0 passive ( add R6 loop-back interface)
lab@R6# set protocols ospf area 0.0.0.27 interface ge-0/0/1.0 interface-type p2p ( Make ethernet p2p )

After we commit the configuration on both routers, let’s have a look at the link state database.

As a result, we have the 2 databases on R4, and we also notice that there are new LSA’s in area 0. Furthermore area 27 has quite a number of LSA’s although there are only 2 routers in area 27 namely R4 and R6.

We will verify the link-state-database on R6 and expect to see similar entries as on R4 area 27.

Yes, both R4 and R6 have the same entries in the link state database for area 27

Area 27 ABR LSA Flooding

The new LSA’s are “Summary” LSA’s, and in theory we understand these LSA’s as LSA-3’s. Inspecting area 0 we notice these “Summary LSA’s”, which tells us about reach-ability of networks in area 27, and vice-versa. The “Summary LSA’s” in area 27 tells us about networks in area 0.
Therefore if we trace from R6 to R1 now we should have success and counting the hops in our network diagram it should be 3 hops.

(Note: I changed the reference bandwidth on R6 as well to be 10G in order to make the expected metric calculations easier)

The traceroute is expected to have 3 hops. The route from R6 to R1 should be 30 with our metrics on the gigabit interfaces set to 10 by the reference bandwidth. We are expecting to see a metric value from R6 to R1 of 30, lets verify.

Great, spot on. No anomalies here or unexpected behavior.

Area 9 ABR LSA Flooding

Onto area 9 with configuration as a standard area. We will have similar results to area 27 and later on we will change area 9 to be a Stubby-Area.

Expectation from the previous outputs of area 27 is that OSPF area 0 will have 2 additional ”Summary LSA’s” for area 9 . The OSPF area 0 should have 2 additional “Summary LSA’s being advertised via the ABR R3. OSPF area 9 should also have 2 Route LSA’s and a number of “Summary LSA’s”. Noticed that there are no “Network LSA’s in area 9 due to setting the interfaces there point-2-point as well.

The configuration of R3 and R5 are similar to the configuration of R4 and R6, only this time for area 9 instead of area 27.

The output of R3 after the OSPF configuration is as follows:

All good here, neighbour relationship are in full state in both area 0 and area 9.

Now for the OSPF database on router R3. The expectation is that there will be 2 more “Summary-LSA’s” in area 0 and area 9 with 2 “Router-LSA’s and a lot of “Summary LSA’s”

The output is as expected therefore we can conclude that reach-ability to other area’s are advertised in the “Summary-LSA”. Hence, according to OSPF  theory, the LSA-1 and LSA-2 are converted into LSA-3 by the ABR when it crosses into a different area.

No funnies here, let’s look at the metric from R5 to R1? We are expecting to see a metric of 30 as it is three hops away in area 0, remember that the link metrics are all 10.

Spot-on.