OSPF LSA Throttling

Lessons Discussion
1

This topic is to discuss the following lesson:

3

Nice work Rene, just wondering in terms of the default values, the lsa-hold value will never double as the lsa max value is also 5 seconds. So it can never wait longer than 5 seconds before generating a new LSA?

4

Hello Chris

Yes, this is the case for the default configuration. lsa-hold will not actually double unless you tweak the lsa-max value accordingly.

I hope this has been helpful!

Laz

5

Hello: Why is there a flood sat 35 and 80. I do not see any outstanding LSAs

6

Hello Ram

I’m not sure I understand your question. Can you please clarify? Thanks!

Laz

7

image
Why is there a flood sent at time 35? There has not been any LSA between 15 and 35.
Thanks

8

Hi Ram,

I understand the confusion, I’ll see if I’ll remove it. The third “flood” arrow is when normally a flood would occur, if an LSA was generated during the 2x LSA hold timer.

Rene

1 Like
9

hello rene, good job , i am just confuse about lsa arrival timers in command (timers lsa arriver) why i need to set it & how reciever router recieve more than one lsa during 10000, & I am alreay set timers lsa throttle 5000 10000 60000 at sender neighbor router which already postpond flooding operation till 10000 lsa hold times expire.
high appreciated your feedback

10

Hello Saif

Yes you are correct, that if you configure the first router in this particular topology with lsa throttle 5000 10000 60000 you will never have a case where you will receive the same LSA within 10000 milliseconds. However, this command is still useful especially if you are connecting your network with that of another entity using OSPF. You don’t have control over what the other side does, and frankly, you have no reason to trust them. So in order to protect your network, you can and should adjust the lsa arrival timer on your end to be safe.

I hope this has been helpful!

Laz

1 Like
11

Thanks appreciate your nice explanation

12

Hello,

If I understood correctly, it’s not exactly the generation of LSAs that is delayed but their flooding, right?

Also, some diagrams illustrate the flooding of LSAs, even though there was no LSA generation, during that interval. Is this correct?

Regards,
LP

13

Hello Luis

First we must determine what the terms “LSA generation” and “flooding” mean, and what the arrows in the diagrams mean.

Under normal circumstances, LSA generation and flooding occur at the same time. In actuality, they are one and the same thing. This means that whenever there is an event that “triggers” LSA generation, the LSA is generated and flooded. It is not possible to generate an LSA and hold on to it until the time comes to flood it. So generation and flooding are one and the same event.

In the diagrams, the red arrows marked “LSA” are the points in time where an LSA should have been generated and flooded, but is not. The purple “Flood” arrows are the times when the LSA is generated and flooded, as a result of the timers. There is no concept of creating an LSA and holding on to it until the time comes to flood it.

For this reason, whenever you see a “Flood” arrow, it means actual generation and flooding. Whenever you see an “LSA” arrow, it means “would have been generated and flooded” under normal circumstances.

I hope this has been helpful.

Laz

14

Hi Laz,

Thanks.

Regarding my second question, why is there a Flood arrow at 35 secs if there were no LSAs (red arrows) between 15 and 35 secs?

image

Thanks.

15

Hello Luis

Yes indeed you are correct, the Flood arrow should not be there since there was no event during the 2x lsa-hold duration that would require a generation and flooding of an LSA. So no purple arrow should appear. I’ve spoken to @ReneMolenaar about this and he too has confirmed this, so he will make the necessary modifications.

Thanks, and I hope this has been helpful!

Laz

16

Hi Guys,

Could you explain what LSA pacing and LSA retransmission for me please? I’m finding it hard to find information on this topic. What exactly is LSA pacing or group pacing?

What would these commands achieve:

 timers pacing flood
 timers pacing retransmission

 ip ospf transmit-delay
 ip ospf retransmit-interval

Thank you

17

Hello Joseph

OSPF LSA group pacing feature instructs a router to group OSPF LSAs and pace the refreshing, checksumming, and ageing functions. What is meant by “pacing” is a more uniform distribution of these operations over time. The result is that LSA refreshing, checksumming, and ageing operations will be grouped in such a way that they will take place at more regular intervals over time. The result is a more efficient use of the router’s resources. LSA group pacing is enabled by default on modern Cisco IOS devices.

Before this feature, all OSPF LSAs were on a single timer. This meant that all OSPF LSAs refreshed at once. For routers containing several thousand LSAs, this resulted in spikes of CPU and memory usage. Even if LSAs had different ages, refreshing them on a single timer actually synchronized them, resulting in excessive resource usage at the time of synchronization.

Group pacing allows LSAs to each use their own independent timer, which allows the refreshing of the LSAs to be staggered, and spread out over time, increasing efficiency.

The commands that you shared in your post shouldn’t need to be used except in very rare circumstances. As stated, pacing is enabled by default and should be sufficient for most implementations. However, in the rare case where it is needed, you can tweak these timers to more appropriately space out packet retransmissions and inter-packet timers to achieve a more efficient usage of resources. You can find out more about these commands at the following CIsco documentation:

As for these commands:

…they are not associated with pacing. These commands are used to tweak the way in which LSA updates are sent. Unlike pacing, these commands refer only to the transmission and retransmission of each particular LSA, independent of the sending of other LSAs. Specifically:

  • The ip ospf transmit-delay command is used to set the estimated time needed to send an LSA update packet (including processing time, transmission time, and propagation delay). OSPF will increment the LSA age time by the transmit delay amount before transmitting the LSA update. This is done to ensure that the age time will take into account situations where excessively large link state updates are sent that may take several seconds or even tens of seconds to send.
  • The ip ospf retransmit-interval command is used to set the time between LSA retransmissions. When a router sends an LSA to its neighbor, it keeps the LSA until it receives an acknowledgment message from the neighbor. If the router receives no acknowledgment within the retransmit interval, the local router resends the LSA. This is used to ensure that you are allowing enough time for the acknowledgement to be sent in situations where there is an increase in delay.

I hope this has been helpful!

Laz

1 Like
18

Hi, guys! Can you check if I understood the topic?

  1. An event occurs and LSA should be generated. LSA-Start comes into play.
  2. During the LSA-Start, another event occurs and instead of flood the LSA by the end of the timer, LSA-Hold comes into play.
  3. During the LSA-Hold, another event occurs and instead of flood the LSA by the end of the timer, the LSA-Hold is duplicated and is finally flooded. We received the LSAck!
  4. Another problem occurs and we are back to LSA-Start with the same LSA, but during LSA-Start another event occurs and instead of flood the LSA by the end of the timer, the LSA-Hold is duplicated again (4x) and is finally flooded.
  5. If we need to send ANOTHER LSA, we have to wait the LSA-Max. If another problem occurs, we go back to LSA-Start with default LSA-Hold value.

Is that right?

Thank you guys!

19

Hello Marcus

It looks like your explanation shows that you understand the process. Let me make a couple of clarifications.

For statement 2), this will only occur if LSA-start is a non-zero value. Remember that by default, LSA-start = 0. In addition, the initial LSA will indeed be flooded by the end of the LSA-start period, but it is the second LSA that will have to wait an additional LSA-hold amount of time.

I hope this has been helpful!

Laz

20

Hi,
Please correct me if my understanding is wrong. Two events occur (link flaps) within the lsa-hold-time which should generate two similar lsa’s . The first lsa is generated and flooded after the hold timer expires (5000ms).
The hold time now doubles (10000ms) and generates/floods the second lsa after the holdtime expires. Now the question arises, does it make sense to generate/flood the first lsa which would have the previous information of the link state?

21

Hello Abdul

Let’s take a look at your example again. Two events take place that generate LSAs. The first event will generate an LSA immediately. The second LSA that is generated is delayed by the hold time.

Now what happens if you have two, three, or four events that generate LSAs during your holdtime? Well, the algorithm will actually group those LSAs together and send them all out together after the current holdtime expires. It won’t send each individual LSA out one at a time continually doubling the hold time.

OSPF will always send all LSAs that have been generated. It doesn’t have the intelligence to say, this LSA was generated before, and this one is newer, so I’ll only send this one. Remember that there are various types of LSAs, and the messages exchanged between OSPF routers contain multiple LSAs.

It is up to each OSPF router receiving LSAs to determine which is the newest and which to incorporate into its database.

I hope this has been helpful!

Laz