Task 2.2 OSPF Neighbors

My rack is behaving differently from SG. BB2 is elected DR for the broadcast domain, thus peering between R1 and R2 is only 2 way as long BB2 is up. Once link to BB2 is shut down on R2, only then will R1 and R2 form full adj. In addition DR election seems to be preemptive.

Rack6R1(config-router)#do sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.6.2.2         1   2WAY/DROTHER    00:00:38    192.10.6.2      BVI1
150.6.6.6         1   FULL/BDR        00:00:39    192.10.6.6      BVI1
192.10.6.254      1   FULL/DR         00:00:36    192.10.6.254    BVI1

Comments

  • DR election is not supposed to be preemptive..

    It could have been that due to the order of operations BB2 is elected the DR, but, if you shutdown the link and then no shut it, BB2 will come back up but will not preempt and take over the DR responsability.

    Have you tried to unshut the interface to bring BB2 back to the game? If you do it, BB2 will not take over the DR responsability.

    Let us know..

  • My rack is behaving differently from SG. BB2 is elected DR for the broadcast domain, thus peering between R1 and R2 is only 2 way as long BB2 is up. Once link to BB2 is shut down on R2, only then will R1 and R2 form full adj. In addition DR election seems to be preemptive.

    Rack6R1(config-router)#do sh ip ospf nei

    Neighbor ID     Pri   State           Dead Time   Address         Interface
    150.6.2.2         1   2WAY/DROTHER    00:00:38    192.10.6.2      BVI1
    150.6.6.6         1   FULL/BDR        00:00:39    192.10.6.6      BVI1
    192.10.6.254      1   FULL/DR         00:00:36    192.10.6.254    BVI1

    Thats correct but does that make any difference in LSA flooding. Everything should be working fine even if BB2 is the DR.

  • I'm running into the same experience as sa1.  I can shut the link from R2 to BB2, wait until .254 neighbor is lost, and observethe new DR.  Then when I bring the link back up BB2 takes back over as DR.  I wonder if this has something to do with the bridge groups?

     

    Rack1R1(config-if)#do sho ip ospf neigh

     

    Neighbor ID     Pri   State           Dead Time   Address         Interface

    150.1.3.3         0   FULL/  -        00:00:32    154.1.13.3      Serial0/1/0

    150.1.2.2         1   FULL/BDR        00:00:39    192.10.1.2      BVI1

    150.1.6.6         1   2WAY/DROTHER    00:00:31    192.10.1.6      BVI1

    192.10.1.254      1   FULL/DR         00:00:39    192.10.1.254    BVI1

    Rack1R1(config-if)#

    *Jul 27 18:43:40.626: %OSPF-5-ADJCHG: Process 1, Nbr 192.10.1.254 on BVI1 from FULL to DOWN, Neighbor Down: Dead timer expired

    *Jul 27 18:43:41.382: %OSPF-5-ADJCHG: Process 1, Nbr 150.1.6.6 on BVI1 from LOADING to FULL, Loading Done

    Rack1R1(config-if)#do sho ip ospf neigh

     

    Neighbor ID     Pri   State           Dead Time   Address         Interface

    150.1.3.3         0   FULL/  -        00:00:36    154.1.13.3      Serial0/1/0

    150.1.2.2         1   FULL/DR         00:00:38    192.10.1.2      BVI1

    150.1.6.6         1   FULL/BDR        00:00:38    192.10.1.6      BVI1

    Rack1R1(config-if)#

    *Jul 27 18:44:36.678: %OSPF-5-ADJCHG: Process 1, Nbr 192.10.1.254 on BVI1 from LOADING to FULL, Loading Done

    Rack1R1(config-if)#do sho ip ospf neigh

     

    Neighbor ID     Pri   State           Dead Time   Address         Interface

    150.1.3.3         0   FULL/  -        00:00:38    154.1.13.3      Serial0/1/0

    150.1.2.2         1   2WAY/DROTHER    00:00:37    192.10.1.2      BVI1

    150.1.6.6         1   FULL/BDR        00:00:38    192.10.1.6      BVI1

    192.10.1.254      1   FULL/DR         00:00:38    192.10.1.254    BVI1

    Rack1R1(config-if)#

  • Same observation happened with my attempt for this Lab. How come BB2 always preempts the existion DR?!

    Best Regards,

    Saleh Hassan Batouq
    [email protected]

    Tel: +968 99365607
    Fax: +968 2469690
    P.O.Box:1083- Postal Code:112
    Muscat-Sultanate Of Oman



    On Sat, Jul 27, 2013 at 10:33 PM, TomTom <[email protected]> wrote:

    I'm running into the same experience as sa1.  I can shut the link from R2 to BB2, wait until .254 neighbor is lost, and observethe new DR.  Then when I bring the link back up BB2 takes back over as DR.  I wonder if this has something to do with the bridge groups?

     

    Rack1R1(config-if)#do sho ip ospf neigh

     

    Neighbor ID     Pri   State           Dead Time   Address         Interface

    150.1.3.3         0   FULL/  -        00:00:32    154.1.13.3      Serial0/1/0

    150.1.2.2         1   FULL/BDR        00:00:39    192.10.1.2      BVI1

    150.1.6.6         1   2WAY/DROTHER    00:00:31    192.10.1.6      BVI1

    192.10.1.254      1   FULL/DR         00:00:39    192.10.1.254    BVI1

    Rack1R1(config-if)#

    *Jul 27 18:43:40.626: %OSPF-5-ADJCHG: Process 1, Nbr 192.10.1.254 on BVI1 from FULL to DOWN, Neighbor Down: Dead timer expired

    *Jul 27 18:43:41.382: %OSPF-5-ADJCHG: Process 1, Nbr 150.1.6.6 on BVI1 from LOADING to FULL, Loading Done

    Rack1R1(config-if)#do sho ip ospf neigh

     

    Neighbor ID     Pri   State           Dead Time   Address         Interface

    150.1.3.3         0   FULL/  -        00:00:36    154.1.13.3      Serial0/1/0

    150.1.2.2         1   FULL/DR         00:00:38    192.10.1.2      BVI1

    150.1.6.6         1   FULL/BDR        00:00:38    192.10.1.6      BVI1

    Rack1R1(config-if)#

    *Jul 27 18:44:36.678: %OSPF-5-ADJCHG: Process 1, Nbr 192.10.1.254 on BVI1 from LOADING to FULL, Loading Done

    Rack1R1(config-if)#do sho ip ospf neigh

     

    Neighbor ID     Pri   State           Dead Time   Address         Interface

    150.1.3.3         0   FULL/  -        00:00:38    154.1.13.3      Serial0/1/0

    150.1.2.2         1   2WAY/DROTHER    00:00:37    192.10.1.2      BVI1

    150.1.6.6         1   FULL/BDR        00:00:38    192.10.1.6      BVI1

    192.10.1.254      1   FULL/DR         00:00:38    192.10.1.254    BVI1

    Rack1R1(config-if)#





    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • OSPF DR is non-preemptive as mentioned by RFC 2328. According to the RFC, the BDR is actually elected first, followed by the DR."The reason behind the election algorithm's complexity is the desire for an orderly transition from Backup Designated Router to Designated Router, when the current Designated Router fails. This orderly transition is ensured through the introduction of hysteresis: no new Backup Designated Router can be chosen until the old Backup accepts its new Designated Router responsibilities.

    However this is not the case for the scenario mentioned by batouq and TomTom. It seems to me that the shared segment between R1, R2, and BB2 were partitioned, with BB2 link was still up, hence it was still holding its role as DR. So, when the partitioned shared segment joined back together, BB2 is still claiming as DR because it never went down at all. Did you observe if this is the case on BB2 when you shutdown R2 link to BB2?

    Shutting down R2 link to BB2 actually does not bring down BB2's interface to the shared segment, hence it is holding to its role as the segment's DR. Instead of shutting down R2 link to BB2, you should shutdown SW2's F0/24 that is physically connected to BB2 eth port. (refer to PHY diagram). If you do this, I believe BB2 won't come back as DR. 

    Happy studying! [B]

Sign In or Register to comment.