OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Erblichs (erblichs_at_EARTHLINK.NET)
Date: Tue Oct 01 2002 - 12:46:10 CDT

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

    Group,

            I haven't seen whether last year's RFC on Out-of-band
            LSDB Resynchronization draft had been formalized into a
            standardized RFC.

            So these comments may be way late, with this
            different approach to perform LSDB Resynchronization.

            I haven't tried this .... but in my mind this
            method could accomplish the same thing with
            legacy routers and remove the need for a
            option bit which is becoming a scarse thing
            in version 2. And be a lightweight mechanism.

            Since the neighbor field in a hello PDU is the
            normal indicator of 2-way communication, why
            not just temporarily drop the neighbor field
            of the adjacency that you wish to re-establish?

            Yes, I am assuming that based on your internal
            request to perform this operation you reset
            your neighbor state machine and set a internal
            "OOB request neighbor field flag".

            At best you can re-establish the link on average
            of 1/2 hello interval and at worst you will have
            to wait router-dead-interval timeframe before
            you re-acknowledge the arrival of hellos from
            the neighbor that you wish resync the adjacency.
            (or wait before you resend hellos?)

            The preference is to just with-hold the neighbor
            from the neighbor field. This would allow the
            OOB requester to remain as a DR or BDR if that
            was his orignal router OSPF type. This would
            remove any necessary overhead of elections,
            adjacency reformations, and substantial SPF
            calculations.

            Then the question is how to utilize the flag
            to make sure that you don't deallocate any
            neighbor data structures and whether you increment
            the sequence number of your orignated LSAs,
            keep them the same, or set MAXAGE and then resend.
            More than likely you will also have to withold
            flooding to the neighbor or acks back to the
            neighbor from his flooding of LSAs. If LSAs were
            recv'ed from the neighbor during flooding, I would
            probably incorporate them into my LSDB.

            Independent of how you deal with the above issues,
            you then must re-attempt to synchronize the LSDB.
            Assuming that their were more than two OSPF speaking
            routers in your area, your previous interaction should
            have minimal effects on your neighbor. More than
            likely, he had kept your earlier originated LSAs
            in his database. And you just resync, upon reaching
            full state again with the neighbor, you clear your
            internal "OOB request neighbor field flag".

            Is there a dual-behaviour (one who wants to redo the
            initial LSDB synchronization and one who keeps the
            established adj) achieved by establishing
            a adjacency and then removing the neighbor specified
            in the hello field that really requires the
            OOB requestor in the scenario to cycle into a
            period of router-dead-interval before sending out
            new hellos AND ... ????

            Flames now allowed....

            Mitchell Erblich
            ==========================