OSPF neighborship, database and routing table

OSPF sometimes can be a confusing protocol. For example if you turn on a light switch, you simply get the immediate result: Light is on. What if when you turn on the light switch but you see the shining light bulb after 40 seconds then it is more difficult to understand the result of your actions. This was a small introduction to this post which I will try to write about he link between OSPF neighborship, OSPF database and routing table. All tests are done on a virtual SRX firewall in packet mode. I have cropped a section of my OSPF topology to simplify this post.

ospf-neighborship-database-lsa

We simply have two routers connected via a point to point link and they both run OSPF. FF31 router is an ABR and J204 is an internal router (which is actually a routing instance on another router but we can ignore this detail)

On this setup following are the OSPF details

J204: Router ID=10.1.1.204, Interface IP: 200.1.2.2
J31: Router ID=10.1.1.31, Interface IP: 200.1.2.1

Question #1: What happens to the LSAs advertised by J204 and routes if the neighborship goes down?

At this point of time J31 has a healthy relationship with its neighbor J204 i.e neighborship is in FULL state and it has received Router LSA(1) from this single neighbor. As an example, we also display the route 173.1.1.0/24 advertised by the neighbor 10.1.1.204 in the routing table

root@J31> show ospf neighbor 200.1.2.2   
Address          Interface              State     ID               Pri  Dead
200.1.2.2        ge-0/0/0.806           Full      10.1.1.204       128    36

root@J31> show ospf database advertising-router 10.1.1.204 

    OSPF database, Area 0.0.0.5
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   10.1.1.204       10.1.1.204       0x80000007    13  0x22 0x81ce  96

root@J31> show route 173.1.1.0/24 

inet.0: 39 destinations, 39 routes (39 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

173.1.1.0/24       *[OSPF/10] 00:04:05, metric 20
                    > to 200.1.2.2 via ge-0/0/0.806      

Now we bring down neighborship by deactivating the routing instance J204. Now from this point, J204 router is dead. Let’s see how J31 sees this.

Now if we check the neighbor status, we can see that OSPF Dead timer goes to zero and neighbor disappears. When we check the route 173.1.1.0/24, we also see that it is gone.

root@J31> show ospf neighbor 200.1.2.2    
Address          Interface              State     ID               Pri  Dead
200.1.2.2        ge-0/0/0.806           Full      10.1.1.204       128    10

root@J31> show ospf neighbor 200.1.2.2    
Address          Interface              State     ID               Pri  Dead
200.1.2.2        ge-0/0/0.806           Full      10.1.1.204       128     3


root@J31> show ospf neighbor 200.1.2.2      <--- OSPF neighborship is DOWN

root@J31> show route 173.1.1.0/24 

but let’s check the LSA.

root@J31> show ospf database advertising-router 10.1.1.204    

    OSPF database, Area 0.0.0.5
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   10.1.1.204       10.1.1.204       0x80000007   652  0x22 0x81ce  96

Yes we J31 router, although it has lost the neighborship, it didn’t remove the LSA from its database. I believe if we don’t do anything, it will take ~3000 seconds more to reach its MaxAge 3600 to remove this LSA from the database.

Question #2: What happens if we bring the same J204 router back into OSPF domain?

J31 establishes adjacency with J204 again and LSA is refreshed with a new sequence number but up until we receive the new LSA we continue to keep the old one.

root@J31> show ospf neighbor 200.1.2.2    
Address          Interface              State     ID               Pri  Dead
200.1.2.2        ge-0/0/0.806           Init      10.1.1.204       128    34
       
root@J31> show ospf neighbor 200.1.2.2    
Address          Interface              State     ID               Pri  Dead
200.1.2.2        ge-0/0/0.806           Full      10.1.1.204       128    39

root@J31> show ospf database advertising-router 10.1.1.204    

    OSPF database, Area 0.0.0.5
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   10.1.1.204       10.1.1.204       0x80000008     8  0x22 0x411f  84   <--- A new sequence number with refreshed age.

root@J31> show route 173.1.1.0/24         

inet.0: 39 destinations, 39 routes (39 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

173.1.1.0/24       *[OSPF/10] 00:00:02, metric 20
                    > to 200.1.2.2 via ge-0/0/0.806      <---We also install the route again

If we check the wire when these events occur, we can see the LSA sent from the newly joined J204.

#tcpdump -vvnni vlan806 proto 89

   200.1.2.2 > 224.0.0.5: OSPFv2, Database Description, length 64 [len 52]
        Router-ID 10.1.1.204, Area 0.0.0.5, Authentication Type: none (0)
        Options [External, LLS, Opaque], DD Flags [Master], MTU: 1500, Sequence: 0x0a01e01c
          Advertising Router 10.1.1.204, seq 0x80000002, age 7s, length 64
            Router LSA (1), LSA-ID: 10.1.1.204
            Options: [External, Demand Circuit]
          LLS: checksum: 0xfff6, length: 3
            Extended Options (1), length: 4
              Options: 0x00000001 [LSDB resync]


    200.1.2.2 > 224.0.0.5: OSPFv2, LS-Update, length 112
        Router-ID 10.1.1.204, Area 0.0.0.5, Authentication Type: none (0), 1 LSA
          LSA #1
          Advertising Router 10.1.1.204, seq 0x80000008, age 3s, length 64       <----New LSA
            Router LSA (1), LSA-ID: 10.1.1.204
            Options: [External, Demand Circuit]
            Router LSA Options: [none]
              Stub Network: 200.1.2.0, Mask: 255.255.255.0
                topology default (0), metric 10
              Stub Network: 10.52.0.0, Mask: 255.255.255.0
                topology default (0), metric 10
              Stub Network: 10.52.1.0, Mask: 255.255.255.0
                topology default (0), metric 10
              Stub Network: 173.1.0.0, Mask: 255.255.255.0
                topology default (0), metric 10
              Stub Network: 173.1.1.0, Mask: 255.255.255.0
                topology default (0), metric 10

In a nutshell,

  • If neighborship is down, routes associated with that neighbor will be removed from routing table
  • LSAs will stay if neighborship goes down abruptly till their MaxAge
  • Having an LSA in the database doesn't mean we should install it on the routing table

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN, currently living in the Netherlands and works as a Network Support Engineer. // JNCIE-SEC #223 / RHCE / PCNSE


You have a feedback?

This site uses Akismet to reduce spam. Learn how your comment data is processed.