OSPF LSAs and LSDB flooding Tutorial

Hello Naresh

If you put these numbers into a Hex to Decimal converter, you’ll see that you end up with
0x80000001 = 2147483649
0x7FFFFFFF = 2147483647

This looks strange. Actually, it looks completely incorrect!! The reason these numbers are used is because the LSA sequence numbers are signed. That is, they include a negative or positive sign which is indicated by the very first of the 32 bits. The LSA sequence numbers will start with 0x80000001 which is compared to binary below:

Hex       0x8  0    0    0    0    0    0    1
Binary    1000 0000 0000 0000 0000 0000 0000 0001

Note the 1 in the leftmost position. This indicates a negative sign, and that digit is not used to denote the number. So 0x80000001 is equal to -1 in decimal. Now as the numbers increment, they actually decrement. What I mean is you start with -1, then -2, -3 etc until you get to -2147483648. Then it goes to 0 and then the numbers increment up to +2147483648 which is 0x7FFFFFFF. Here is this number compared to its binary representation as well:

Hex       0x7  F    F    F    F    F    F    F
Binary    0111 1111 1111 1111 1111 1111 1111 1111

Note the 0 on the left most bit. This indicates a positive ‘+’ number. Once this number is reached, then it goes back to -1 or 0x80000001 and the process continues.

Now all of this is really academic, because increments occur every 30 minutes in a stable network. Never in all the history of networking have these increments wrapped around to the initial sequence number because it will take over 600 years to do so, and OSPF has been around only several decades. :stuck_out_tongue:

I hope this has been helpful!

Laz

1 Like