Possible OSPF Priority Bug - 6.4.2

[bturnbough]

It appears that the DR isnt being chosen properly, provided they follow the cisco methodology of selecting a DR/BDR.

Routers with a HIGHER priority are selected as the DR / BDR.  If there is a tie amongst the priority, then the router id is chosen.

Output from multiple firewalls:

FG100F-01 # get router info ospf neighbor OSPF process 0, VRF 0: Neighbor ID Pri State Dead Time Address Interface 192.168.0.250 1 Full/DR 00:00:35 10.100.2.2 VLAN2 1.1.1.72 1 Full/ - 00:00:31 10.240.0.2 INT_1 1.1.1.200 110 Full/ - 00:00:34 10.240.0.6 INT_3    ---------------------- should be DR (prio of 110)

FG60F-01 # get router info ospf neighbor OSPF process 0, VRF 0: Neighbor ID Pri State Dead Time Address Interface 192.168.72.250 1 Full/DR 00:00:33 10.72.2.2 VLAN2 1.1.1.100 210 Full/ - 00:00:38 10.240.0.1 INT_2   ---------------------- should be DR (prio of 200) 1.1.1.200 110 Full/ - 00:00:40 10.240.0.3 INT_3

I did a 'execute router clear ospf process' on the two routers above as well as the devices currently holding the DR roles, but it hasn't changed.  

It appears that the priority is being ignored and the IP is instead being used for the DR/BDR ospf election.  Thoughts?

[Benoit_Rech_FTNT]

Hello Brad, I checked the bug database, and I've found any issue reported on 6.4.2. I just perform a test on a FortiGate in 6.2.5, and I don't have any issue. Unfortunately, I don't have any device in 6.4.2 to make the same test. Try to debug the neighbor negotiation on the fortigate: diagnose ip router ospf nfsm enable diagnose ip router ospf level info diagnose debug enable ... change on one peer, but do not restart the OSPF process locally, otherwise the debug will be lost. Normally, you don't have to restart the OSPF process when performing this kind of changes, as they are carry over the Hello Packet. To restore the "normal" behavior diagnose debug disable diagnose ip router ospf level critical diagnose ip router ospf nfsm disable Hope this help Benoit