Technical discussion resource and ongoing discussions for referral purposes.
As technology progress we like to share useful bits and pieces to our learning community.
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.
- OSPF area 0 LSA flooding and metric manipulation
- OSPF 3 standard areas and LSA flooding
- OSPF backbone, standard area and stub area LSA flooding
- OSPF backbone, standard area and nssa area LSA flooding
- OSPF dual ABR’s between area and which one will rule the roost?
- 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
States of the routers interfaces and information on them.
The set of routers attached to the network, originated by the DR (designated router).
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.
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.
- Configure interfaces
- Configure router-id
- 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
lab@R1# set routing-options router-id 192.168.0.1
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
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.
“Fortitude is the marshal of thought, the armor of the will, and the fort of reason. ”