OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Acee Lindem (acee_at_REDBACK.COM)
Date: Mon Sep 09 2002 - 15:21:24 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Christian,
    It is closer to #2 than #1. Assuming a single area topology,
    it would be the neighbor inactivity event that triggers
    re-origination of router LSAs for A and B. Refer
    to section 12.4 in RFC 2328.

    Christian Glomb wrote:

    > Dear all,
    >
    > let's assume we are monitoring the flow of OSPF messages within one OSPF
    > area. All routers have successfully come up and are running stable, i.e.
    > only HELLO messages are exchanged between adjacent routers. Now the link
    > between Router A and Router B fails such that Router A does not receive
    > HELLOs from Router B and vice versa. After the timer RouterDeadInterval
    > has expired at each Router, Router A as well as Router B assumes that the
    > other router (or the link to the other router) has crashed. All OSPF
    > information concerning the other router is removed from the database of
    > Router A and Router B respectively and both Routers are recalculating their
    > routing tables.
    >
    > However Router A as well as Router B have working adjacencies to other
    > Routers C...E and F...H respectively and are still sending HELLOs to these
    > neighbors.
    >
    > What happens then?
    >
    > 1.
    > Due to the fact that the ID of Router B is missing in the neighbor list
    > of the HELLOs send from Router A to Routers C...E and the ID of Router A
    > is missing in the HELLO neighbor list sent from Router B to Router F...H,
    > Routers C...E as well as Routers F...H are sending a LINK_STATE_REQUEST to
    > Router A and Router B respectively, since they notice that the topology has
    > changed (i.e. one link is missing).
    > Routers A and B resp. are responding with a LINK_STATE_UPDATE. Then the
    > Flooding Procedure starts due to the receipt of such a message at Routers
    > C...E and F...H.
    >
    > OR
    >
    > 2.
    > Routers A and B resp. send a LINK_STATE_UPDATE directly to Routers C...E
    > and Router F...H after having updated their routing tables to trigger the
    > Flooding Process.
    >
    > OR
    >
    > 3. I'm completely wrong, it's working completely different.
    >
    > Thank you for your comments,
    >
    > Christian.
    >
    >

    --
    Acee