rfc1246.txt

RFC 的详细文档！

that it should occur again.  3Com has offered for the third round of
testing to occur in Santa Clara sometime in February.  3Com will
encourage other OSPF implementations to join in the testing. Items that
will be tested are:

o  Intra-area routing with loops (as well as equal-cost multipath).

o  Inter-area testing including Stub and Transit area support, with both
   Intra-area and Inter-area loops.

o  Virtual link testing in the looped Inter-area configuration.

o  RIP/OSPF route interchange including testing forwarding address
   capability in external link state advertisements.

o  EGP/OSPF router interchange including the use of the route tag field
   in external link state advertisements.

o  More than two routers connected to an X.25 network. We would like to
   test OSPF's non-broadcast multi-access capabilities by attaching more
   than two vendor's routers to an X.25 packet switch.



[Moy]                                                          [Page 22]

RFC 1246                  Experience with OSPF                 July 1991


o  Several vendors running OSPF and RIP simultaneously. This will
   further test the OSPF/RIP interactions.

o  Test processing of links with cost LSInfinity. These links should be
   treated as unreachable.

Furthermore, we hope that in future rounds of testing an OSPF MIB would
allow us to also use a network management station to gather test data.

In summary, the stability of implementations were better this time more
so than the first round of testing. No problems with the protocol design
were encountered. The exchange of ideas and the cooperation among
implementors that occurred during this test effort, continues the spirit
that OSPF is truly an open protocol.


7.3.2  Problems found in the Second round testing

No problems were found in the OSPF protocol during the second round of
testing.



7.4  Third round (3com, 2/4/91 - 2/8/91)

The third round of OSPF protocol testing took place at 3com's Santa
Clara facility, the week of February 4, 1991. Five implementations
participated, from the vendors 3com, ACC, Proteon and Wellfleet and the
publicly available University of Maryland implementation (running on a
SUN workstation).

There were five 3com routers, four ACC routers, three Wellfleet routers,
three Proteon routers and the UMD Sun workstation available for testing
(giving a total of 16 routers available). These routers were
interconnected with ethernets, serial lines and X.25. External routes
were imported from BARRNet by one of the 3com routers.

The initial testing configuration is shown in Figure 5. Three areas were
configured, along with a non-contiguous backbone. The backbone was then
joined by configuring two virtual links. In this configuration the
following OSPF functionality was tested: inter-area routing and virtual
links.

The system was then reconfigured so that twelve of the routers were
connected to a single ethernet. This configuration is pictured in Figure
6. By bringing routers up and down, this configuration tested Designated
Router election, database synchronization and reliable flooding. To see
how this functionality, and also the implementations, scale, 400



[Moy]                                                          [Page 23]

RFC 1246                  Experience with OSPF                 July 1991


external routes were imported from BARRNet.



7.4.1  Official report of the Third round testing

The following report was sent to the ospf, ospf-tests, and router-
requirements mailing lists after the third round of interoperability
tests:

The third round of OSPF interoperability testing was held at 3com
Corporation in Santa Clara the week of February 4-8. Four router vendors
came to the testing: 3com, ACC, Proteon and Wellfleet. In addition, Rob
Coltun brought the University of Maryland implementation, which was run
on a Sun Workstation.

Testing was performed over ethernet, point-to-point networks (using PPP)
and X.25. In all we had 16 routers available: five 3com routers, four
ACC routers, three Proteon routers, three Wellfleet routers and Rob's
SUN. We also were able to import external routes from BARRNet.

Specific tests performed included the following:

o  Initially we configured the routers into three separate areas and a
   physically disconnected backbone. The backbone was then reconnected
   through configuration of several virtual links.  These tests verified
   the generation and processing of summary link advertisements, as well
   as the operation of virtual links.

o  We connected multiple routers to an X.25 packet switch, testing
   OSPF's non-broadcast network capability. OSPF was successfully run
   over the X.25 network, using routers that were both DR eligible and
   DR ineligible. Some problems were encountered, but they all involved
   running IP over X.25 (i.e., they were not X.25 specific).

o  We also connected a 3com router, Proteon router, and Rob's SUN to an
   ethernet, and then treated the ethernet as a non-broadcast network.
   This allowed us to connect Rob's SUN into the rest of the routing
   domain without installing the IP multicast modifications to the SUN
   kernel. It also further tested the OSPF's non-broadcast network
   capability.

o  We then reconfigured the OSPF system so that all but three of the
   routers were connected to a single ethernet. This tested the
   Designated Router functionality (12 routers were synchronizing with
   the DR). We then also tested the DR election algorithm, by
   selectively restarting the DR, or sometimes both the DR and the
   Backup DR. This also tested OSPF's Database Description process.



[Moy]                                                          [Page 24]

RFC 1246                  Experience with OSPF                 July 1991


o  In this configuration, we then imported 400 external routes from
   BARRNet (one of the 3com routers ran both OSPF and EGP). Some
   problems were encountered in implementations' buffer allocation
   strategies, and problems were also found in the way implementations
   avoid IP fragmentation. But overall, this system was fairly stable.

The following problems we found in the OSPF specification:

o  The specification should say that the "Network mask" field should not
   be verified in OSPF Hellos received over virtual links.

o  The specification should say that on multi-access networks neighbors
   are identified by their IP address, and on point-to-point networks
   and virtual links by their OSPF Router ID. This eliminates confusion
   when, for example, a router is restarted and comes up with the same
   IP address but a different Router ID.

Thanks to 3com for providing the testing facility, cables. terminals,
X.25 switch. etc. Also thanks to Vince Fuller of BARRNet for helping us
import the BARRNet routes.


7.4.2  Problems found in the Third round testing

A couple of specification/protocol problems were found in the third
round of interoperability testing. First, it was noticed that the
specification did not specify the setting of the Network Mask field in
Hellos sent over virtual links. This caused some initial difficulty in
bringing up virtual links between routers belonging to different
vendors. Secondly, it was noticed that the specification was not strict
enough in defining how OSPF neighbors are identified on multi-access
networks. This caused difficulties in one implementation when another
vendor's router was restarted with the same IP address but a different
OSPF Router ID. This is discussed more fully in the above "Official
Report of the Third Round Testing".



7.5  Overall: Features tested


All significant protocol features and mechanisms have been tested in the
three rounds of interoperability testing. In particular, the following
basic pieces of the protocol have been tested:

o  Designated Router election. With as many as thirteen routers attached
   to a single LAN, the election of Backup Designated Router and
   Designated router was verified by bringing routers up and down,



[Moy]                                                          [Page 25]

RFC 1246                  Experience with OSPF                 July 1991


   singly and in pairs.

o  Adjacency bringup. The Database Description process was verified,
   with databases having over 400 LSAs. Adjacency bringup was also
   verified in times when flooding was taking place simultaneously.

o  Reliable flooding. It was verified that OSPF's flooding algorithm
   maintains database synchronization, both in the presence of loops in
   the topology, and with large databases (over 400 LSAs).

o  Flushing advertisements from routing domain. OSPF's procedure for
   flushing old or unreachable LSAs from the routing domain was
   verified, both in the presence of topology loops and with many LSAs
   being flushed at once. This is also referred to as OSPF's MaxAge
   procedure.

o  OSPF routing hierarchy. The OSPF four level routing hierarchy:
   intra-area, inter-area. type 1 externals and type 2 externals was
   tested.

o  Import of external routing information. The importing of external
   routes has been tested, with as many as 400 imported at once. Also,
   the varying options in external LSAs has been tested: type 1 or type
   2 metrics and forwarding addresses.escribe all options. In addition,
   test setups were utilized having AS boundary routers both internal to
   non-backbone areas and also being simultaneously area border routers.

o  Running protocol over various network types. In the test setups, OSPF
   has been run over ethernet, point-to-point serial lines (both PPP and
   proprietary), 802.5 token ring and X.25.

o  Non-broadcast, multi-access networks. OSPF has been tested over X.25.
   Some testing was also done treating ethernet as a non-broadcast
   network. Two separate situations were tested: when all routers
   attached to the non-broadcast network were DR-eligible, and when only
   some of them were.

o  Authentication. OSPF's authentication procedure was tested for the
   two current authentication types.

o  Equal-cost multipath. Much of the testing was done in configurations
   with redundant paths, and equal-cost multipath was verified through
   examination of implementations' routing tables.

o  Variable-length subnet masks. It was verified that implementations
   paid attention to the network mask field present in OSPF LSAs.





[Moy]                                                          [Page 26]

RFC 1246                  Experience with OSPF                 July 1991


Testing was also performed on the following pieces of OSPF's Area
functionality:

o  Extent of advertisements. It was verified that all advertisements
   except external LSAs were flooded throughout a single area only.

o  Inter-area routing. The generation and processing of summary link
   LSAs was tested. Also tested were configurations having multiple area
   border routers attaching to a single area.

o  Virtual links.

The following OSPF options were also tested:

o  TOS routing. The interplay between TOS-capable and non-TOS-capable
   routers was tested, by configuring TOS-specific metrics in the only
   implementation (3com) supporting TOS routing.

o  Stub areas. OSPF's stub area functionality was verified.



7.6  Testing conclusions

The interoperability testing has proven to be very valuable. Many bugs
were found (and fixed) in the implementations. Some protocol problems
were found (and fixed), and gray areas of the specification were cleared
up. Implementations have also been "bullet-proofed" in order to deal
with the unexpected behavior of other implementations. All participants
in the testing now understand the maxim "be conservative in what you
generate, and liberal in what you accept" (if they didn't already).


7.7  Future work

The one thing that has gone mostly untested at the interoperability
sessions is the interaction between OSPF and other routing protocols
(such as RIP and EGP). Each interoperability session generally had a
router running multiple routing protocols in order to import external
routing information into the OSPF system. However, simultaneously
running multiple routing protocols between different vendors' routers
has not been tested.

Each vendor has developed a slightly different architecture for the
exchange of routing information between differing routing protocols.  As
the OSPF field testing has also shown, this exchange of routing
information is an area of ongoing