Scribd
Upload
12 views

Counter Notes

The counter ospfv3IfEvents counts the number of times an OSPFv3 interface changes state or encounters an error. When the OSPFv3 network type is broadcast, interface state changes occur during router elections, causing the counter to increase multiple times with each interface shutdown and startup. For point-to-point interfaces, only two state changes occur in this scenario.

Uploaded by

Beryl Nisha
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
12 views

Counter Notes

The counter ospfv3IfEvents counts the number of times an OSPFv3 interface changes state or encounters an error. When the OSPFv3 network type is broadcast, interface state changes occur during router elections, causing the counter to increase multiple times with each interface shutdown and startup. For point-to-point interfaces, only two state changes occur in this scenario.

Uploaded by

Beryl Nisha
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Counter Notes:

The counter is ospfv3IfEvents and is specified in RFC5643. There is described what this
counter should be counting as follow: "The number of times this OSPFv3 interface has
changed its state or an error has occurred."
So, the counter must count the ospf interface state changes.

In the RFC 2328, we can see which states are defined for ospf interface states: The states are:
DOWN, LOOPBACK, WAITING, POINT-TO-POINT, DR OTHER, BACKUP, DR.
In this way, when we have an OSPFv3 scenario where "ospf network type is broadcast", the
ospf election process will be executed every time you do shut/no shut, and this will lead to
several states changes, following the state flow defined in RFC as follow:

This way, if you configure your OSPFv3 session to be POINT-TO-POINT, probably you will
observe the behaviour proposed in our test plan

Running the same test in sessions type broadcast, after interface comes UP, sessions can go
for example from Down to Waiting, from Waiting to Backup and from Backup to DR.
In this case, counter will increase 3 times.

The following test with network type broadcast:


CE4(config)#interface eth1
CE4(config-if)#shutdown
CE4(config-if)#commit
2023 Jul 18 23:21:04.278 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Backup (InterfaceDown)
22023 Jul 18 23:21:04.278 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Down (NeighborChange)
After receive event Interface Down, status has changed form Backup to Down.

This counts 1 time.


CE4(config-if)#no shutdown
CE4(config-if)#
CE4(config-if)#commit
2023 Jul 18 23:21:38.324 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Down (InterfaceUp)
2023 Jul 18 23:21:39.332 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Waiting (NeighborChange)
2023 Jul 18 23:22:18.325 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Backup (NeighborChange)

Here, the election process is running and the counter counts Down to Waiting and Waiting to
Backup. So, in total counter increases 3 times after shut / no shut.

Where, after a shut/no shut, the timer will be increase only 2 times, because this kind of
OSPFv3 session does not start the election process, and it only goes to DOWN state when
you shut down the interface, and after that, when you execute "no shutdown" command,
sessions goes directly to "POINT-TO-POINT".

After Shutdown:

2023 Jul 18 22:26:03.312 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Point-To-Point


(InterfaceDown)
2023 Jul 18 22:26:03.312 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Down (NeighborChange)

After NoShutdown:

2023 Jul 18 22:27:06.666 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Down (InterfaceUp) 2023
Jul 18 22:27:07.671 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Point-To-Point (NeighborChange)
2023 Jul 18 22:27:07.671 : CE4 : OSPFv3 : INFO : IFSM[eth1]: Point-To-Point
(NeighborChange)

The logs above where testing with an point-to-point interface

You might also like