Description

This article demonstrates how an ospfMaxAgeLsa trap works in OSPF routers on Juniper Networks MX/EX Series devices by using an example. 

 

Symptoms

It is observed that the ospfMaxAgeLsa trap is seen under normal operations when a link-state advertisement (LSA) in a link-state database has aged to MaxAge, but such a trap is not generated by all OSPF routers.

This behavior is explained by using the example that follows:

Conditions Used in the Topology

  • The R1 router-id is 172.16.0.1.

  • The R2 router-id is 172.16.0.2.

  • The tester's own router-id is 192.168.0.1 and its testing LSA ID is 192.168.1.2.

Topology

Tester injecting LSA 192.168.1.2 to R1 and R2

The setup also uses the ospfMaxAgeLsa MIB (1.3.6.1.2.1.14.16.2.13), which is defined as follows. For more information, refer to OSPF-TRAP-MIB DEFINITIONS .

   ospfLsa NOTIFICATION-TYPE
        OBJECTS {
                    ospfRouterId, -- The originator of the trap
                    ospfLsdbAreaId,  -- 0.0.0.0 for AS Externals
                    ospfLsdbType,
                    ospfLsdbLsid,
                    ospfLsdbRouterId
                  }
        STATUS             current
        DESCRIPTION
           "An ospfMaxAgeLsa trap signifies  that  one  of
           the LSA in the router's link-state database has
           aged to MaxAge."
   ::= { ospfTraps 13 }

When the above setup was tested, the following points were observed:

  • If an OSPF router receives an LSA with age<3600 from a neighbor router and it holds this LSA till age=3600, then the router sends an ospfMaxAgeLsa trap with LSUpdate and MaxAge flooding.

  • If the OSPF router receives an LSUpdate with age=3600 before the router's own timer reaches 3600, it will not send a trap.

 

Log to Show Sequence of Trap Generation

The following log describes the actual sequence of generating the ospfMaxAgeLsa trap.

<-------- R1 received age=3595(0xe0b) from tester(10.10.10.2)

Feb 23 12:22:10.916509 Received OSPF packet of type and wire_length 4, 52
Feb 23 12:22:10.916552 OSPF rcvd LSUpdate 10.10.10.2 -> 224.0.0.5 (ge-0/0/0.0 IFL 553 area 0.0.0.0)
Feb 23 12:22:10.916582   Version 2, length 52, ID 192.168.0.1, area 0.0.0.0
Feb 23 12:22:10.916607   checksum 0x0, authtype 0
Feb 23 12:22:10.916632   adv count 1
Feb 23 12:22:10.916662   id 192.168.1.2, type Router (0x1), age 0xe0b 
Feb 23 12:22:10.916687   options 0x2
Feb 23 12:22:10.916714   adv rtr 192.168.1.2, seq 0x80000014, cksum 0xa822, len 24
Feb 23 12:22:10.916741     bits 0x0, link count 0
Feb 23 12:22:10.917122 task_timer_set_oneshot_latest: timer OSPF_LSA age interval set to 5   <--- R1 will reach max-age at 12:22:15.


<-------- R1 sent age=3596(0xe0c) to R2 (R1 adds +1sec to next node)

Feb 23 12:22:10.956546 OSPF sent LSUpdate 10.10.11.1 -> 224.0.0.5 (ge-0/0/1.0 IFL 554 area 0.0.0.0)
Feb 23 12:22:10.956589   Version 2, length 52, ID 172.16.0.1, area 0.0.0.0
Feb 23 12:22:10.956616   adv count 1
Feb 23 12:22:10.956646   id 192.168.1.2, type Router (0x1), age 0xe0c
Feb 23 12:22:10.956670   options 0x2
Feb 23 12:22:10.956698   adv rtr 192.168.1.2, seq 0x80000014, cksum 0xa822, len 24
Feb 23 12:22:10.956725     bits 0x0, link count 0
 

<-------- R2 received age=3596 from R1

Feb 23 12:22:10.959424 Received OSPF packet of type and wire_length 4, 52
Feb 23 12:22:10.959468 OSPF rcvd LSUpdate 10.10.11.1 -> 224.0.0.5 (ge-0/0/1.0 IFL 557 area 0.0.0.0)
Feb 23 12:22:10.959498   Version 2, length 52, ID 172.16.0.1, area 0.0.0.0
Feb 23 12:22:10.959523   checksum 0x0, authtype 0
Feb 23 12:22:10.959548   adv count 1
Feb 23 12:22:10.959578   id 192.168.1.2, type Router (0x1), age 0xe0c
Feb 23 12:22:10.959603   options 0x2
Feb 23 12:22:10.959630   adv rtr 192.168.1.2, seq 0x80000014, cksum 0xa822, len 24
Feb 23 12:22:10.959657     bits 0x0, link count 0
Feb 23 12:22:10.960022 task_timer_set_oneshot_latest: timer OSPF_LSA age interval set to 4   <--- R2 will reach max-age at 12:22:14.
 

<-------- R2 sent LSAck to R1

Feb 23 12:22:11.962418 OSPF sent LSAck 10.10.11.2 -> 224.0.0.5 (ge-0/0/1.0 IFL 557 area 0.0.0.0)
 

<-------- R1 received LSAck from R2

Feb 23 12:22:11.967797 OSPF rcvd LSAck 10.10.11.2 -> 224.0.0.5 (ge-0/0/1.0 IFL 554 area 0.0.0.0)
 
  :

 
<-------- R2 reached max-age faster than R1
<-------- R2 sent age=3600(0xe10) to R1

Feb 23 12:22:14.962917 OSPF LSA Router 192.168.1.2192.168.1.2 FLOODED on ge-0/0/1.0 area 0.0.0.0
Feb 23 12:22:14.962969 OSPF sent LSUpdate 10.10.11.2 -> 224.0.0.5 (ge-0/0/1.0 IFL 557 area 0.0.0.0)
Feb 23 12:22:14.963000   Version 2, length 52, ID 172.16.0.2, area 0.0.0.0
Feb 23 12:22:14.963025   adv count 1
Feb 23 12:22:14.963054   id 192.168.1.2, type Router (0x1), age 0xe10
Feb 23 12:22:14.963079   options 0x2
Feb 23 12:22:14.963106   adv rtr 192.168.1.2, seq 0x80000014, cksum 0xa822, len 24
Feb 23 12:22:14.963133     bits 0x0, link count 0
 

<-------- R2 generated ospfMaxAgeLsa trap

Feb 23 12:22:14 snmpd[0]  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Feb 23 12:22:14 snmpd[0]  <<< V1 Trap
Feb 23 12:22:14 snmpd[0]  <<<  Source:      172.27.112.182
Feb 23 12:22:14 snmpd[0]  <<<  Destination: 10.10.11.1
Feb 23 12:22:14 snmpd[0]  <<<  Version:     SNMPv1
Feb 23 12:22:14 snmpd[0]  <<<  Community:   hoge
Feb 23 12:22:14 snmpd[0]  <<<  Agent addr:  10.10.11.2
Feb 23 12:22:14 snmpd[0]  <<<  sysUpTime:   (75336896) 209:16:08.96
Feb 23 12:22:14 snmpd[0]  <<<  Enterprise:  ospfTraps
Feb 23 12:22:14 snmpd[0]  <<<  Generic trap: 6, Specific trap: 13
 

<-------- R1 received age=3600 from R2

Feb 23 12:22:14.968800 OSPF rcvd LSUpdate 10.10.11.2 -> 224.0.0.5 (ge-0/0/1.0 IFL 554 area 0.0.0.0)
Feb 23 12:22:14.968831   Version 2, length 52, ID 172.16.0.2, area 0.0.0.0
Feb 23 12:22:14.968857   checksum 0x0, authtype 0
Feb 23 12:22:14.968882   adv count 1
Feb 23 12:22:14.968913   id 192.168.1.2, type Router (0x1), age 0xe10
Feb 23 12:22:14.968938   options 0x2
Feb 23 12:22:14.968967   adv rtr 192.168.1.2, seq 0x80000014, cksum 0xa822, len 24
Feb 23 12:22:14.968994     bits 0x0, link count 0
 

<-------- R1 got max-age by R2's LSA, then R1 just logged it without trap

Feb 23 12:22:14.969159 OSPF LSA Router 192.168.1.2  192.168.1.2  from 10.10.11.2 Advertising router id is MAX-AGEd
Feb 23 12:22:14.969203 OSPF LSA Router 192.168.1.2  192.168.1.2  from 10.10.11.2 newer than db
 

<-------- R1 sent LSAck to R2

Feb 23 12:22:15.971739 OSPF sent LSAck 10.10.11.1 -> 224.0.0.5 (ge-0/0/1.0 IFL 554 area 0.0.0.0)
 

<-------- R2 received LSAck from R1

Feb 23 12:22:15.974984 OSPF rcvd LSAck 10.10.11.1 -> 224.0.0.5 (ge-0/0/1.0 IFL 557 area 0.0.0.0)

 

Solution

MaxAge notes the number of seconds an LSA can remain in the OSPF database. It provides a mechanism to remove stale information from the link-state database. Typically, all LSAs begin with age 0 and increment to a MaxAge value of 3600 seconds.

When an LSA reaches the MaxAge, the LSA is reflooded in which the MaxAge value is reset and then the LSA is flushed from the database on every OSPF router. To ensure that its LSAs are up to date, each OSPF router periodically refreshes the self-generated link state prior to reaching the MaxAge value.

Junos OS performs this refresh every 3000 seconds.

This is expected behavior for Juniper Networks MX/EX Series routers.

As shown in the example above, the OSPF router generates a MaxAge trap only when a non-self-originated LSA reaches the MaxAge value in its link-state database. It will not generate a MaxAge trap if it receives an LSA whose age field has already reached the MaxAge value. When the OSPF router receives an LSA with MaxAge=3600 (or the MaxAge value that has been set), it just acknowledges and logs the reception of the LSA with MaxAge if traceoptions is enabled.

 

Modification History

2022-08-17: Updated art and IPs. Article is still relevant and valid.