Skip to main content

Appendix G. Differences from RFC 2178

        changing the mask in the body to NM1 and inserting the cost
        of the new network. Then originate a new LSA for the old
        network [NA,NM2], with Link State ID equal to NA or'ed
        together with the bits that are not set in NM2 (i.e.,
        network [NA,NM2]'s broadcast address).

The above algorithm assumes that all masks are contiguous; this
ensures that when two networks have the same address, one mask is
more specific than the other. The algorithm also assumes that no
network exists having an address equal to another network's
broadcast address. Given these two assumptions, the above algorithm
always produces unique Link State IDs. The above algorithm can also
be reworded as follows:  When originating an AS-external-LSA, try to
use the network number as the Link State ID.  If that produces a
conflict, examine the two networks in conflict. One will be a subset
of the other. For the less specific network, use the network number
as the Link State ID and for the more specific use the network's
broadcast address instead (i.e., flip all the "host" bits to 1).  If
the most specific network was originated first, this will cause you
to originate two LSAs at once.

As an example of the algorithm, consider its operation when the
following sequence of events occurs in a single router (Router A).


(1) Router A wants to originate an AS-external-LSA for
    [10.0.0.0,255.255.255.0]:

    (a) A Link State ID of 10.0.0.0 is used.

(2) Router A then wants to originate an AS-external-LSA for
    [10.0.0.0,255.255.0.0]:

    (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a
        new Link State ID of 10.0.0.255.

    (b) A Link State ID of 10.0.0.0 is used for
        [10.0.0.0,255.255.0.0].

(3) Router A then wants to originate an AS-external-LSA for
    [10.0.0.0,255.0.0.0]:







    (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a
        new Link State ID of 10.0.255.255.

    (b) A Link State ID of 10.0.0.0 is used for
        [10.0.0.0,255.0.0.0].

    (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
        of 10.0.0.255.

F. Multiple interfaces to the same network/subnet

There are at least two ways to support multiple physical interfaces
to the same IP subnet. Both methods will interoperate with
implementations of RFC 1583 (and of course this memo). The two
methods are sketched briefly below. An assumption has been made that
each interface has been assigned a separate IP address (otherwise,
support for multiple interfaces is more of a link-level or ARP issue
than an OSPF issue).

Method 1:
    Run the entire OSPF functionality over both interfaces, sending
    and receiving hellos, flooding, supporting separate interface
    and neighbor FSMs for each interface, etc. When doing this all
    other routers on the subnet will treat the two interfaces as
    separate neighbors, since neighbors are identified (on broadcast
    and NBMA networks) by their IP address.

    Method 1 has the following disadvantages:

    (1) You increase the total number of neighbors and adjacencies.

    (2) You lose the bidirectionality test on both interfaces, since
        bidirectionality is based on Router ID.

    (3) You have to consider both interfaces together during the
        Designated Router election, since if you declare both to be
        DR simultaneously you can confuse the tie-breaker (which is
        Router ID).

Method 2:
    Run OSPF over only one interface (call it the primary
    interface), but include both the primary and secondary
    interfaces in your Router-LSA.

    Method 2 has the following disadvantages:

    (1) You lose the bidirectionality test on the secondary
        interface.

    (2) When the primary interface fails, you need to promote the
        secondary interface to primary status.

G. Differences from RFC 2178

This section documents the differences between this memo and RFC
2178.  All differences are backward-compatible. Implementations of
this memo and of RFCs 2178, 1583, and 1247 will interoperate.

G.1 Flooding modifications

    Three changes have been made to the flooding procedure in
    Section 13.

    The first change is to step 4 in Section 13. Now MaxAge LSAs are
    acknowledged and then discarded only when both a) there is no
    database copy of the LSA and b) none of router's neighbors are
    in states Exchange or Loading. In all other cases, the MaxAge
    LSA is processed like any other LSA, installing the LSA in the
    database and flooding it out the appropriate interfaces when the
    LSA is more recent than the database copy (Step 5 of Section
    13). This change also affects the contents of Table 19.

    The second change is to step 5a in Section 13. The MinLSArrival
    check is meant only for LSAs received during flooding, and
    should not be performed on those LSAs that the router itself
    originates.

    The third change is to step 8 in Section 13. Confusion between
    routers as to which LSA instance is more recent can cause a
    disastrous amount of flooding in a link-state protocol (see
    [Ref26]). OSPF guards against this problem in two ways: a) the
    LS age field is used like a TTL field in flooding, to eventually
    remove looping LSAs from the network (see Section 13.3), and b)
    routers refuse to accept LSA updates more frequently than once
    every MinLSArrival seconds (see Section 13).  However, there is
    still one case in RFC 2178 where disagreements regarding which
    LSA is more recent can cause a lot of flooding traffic:
    responding to old LSAs by reflooding the database copy.  For
    this reason, Step 8 of Section 13 has been amended to only
    respond with the database copy when that copy has not been sent
    in any Link State Update within the last MinLSArrival seconds.
Last updated on