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].

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.