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.
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
