rfc1246.txt

RFC 的详细文档！

6.5  Limitations of operational deployments

The following things have not been tested in an operational environment:

o  Multi-vendor deployments. So far all deployments have used a single
   implementation. However, extensive interoperability testing of OSPF
   has been done (see Section 7.0 of this report).

o  Regular OSPF areas. These have however been tested in all three
   rounds of the OSPF interoperability testing.

o  Virtual links. These have however been tested in OSPF's
   interoperability testing.

o  Non-broadcast networks. However, OSPF interoperability testing has
   been performed over X.25 networks.

o  TOS routing. However, this has been tested in OSPF's interoperability
   testing.


6.6  Conclusions

All basic features of the OSPF protocol have been exercised. Very large
OSPF link state databases (e.g., BARRNet's OSPF system) have been
deployed, providing a thorough test of OSPF's database synchronization
mechanisms. No OSPF protocol problems have been found in operational
deployments.

Most of the hassles in operation deployments has to do with the OSPF/RIP
interchange. Many of these issues have been ironed out on the ospf-tests
mailing list (see Section 2.0). However, the interaction between OSPF,
RIP, and EGP continues to be an active area of research.


7.0   Interoperability Testing

There have been three separate OSPF V2 interoperability testing
sessions. Five separate implementations have participated in at least
one session: implementations from the companies 3com, ACC, Proteon and
Wellfleet, and the publicly available implementation from the University
of Maryland.



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


Each of the testing sessions is described in a succeeding section. For
each session, the participants are identified, and the testing
topologies are described along with the particular protocol features
that were exercised. Any protocol problems that were encountered during
the testing are also described. In addition, for the second and third
rounds testing reports were sent to the ospf mailing lists.  These
reports are reproduced in this document.

There is quite a bit of commonality in the features that have been
tested from session to session.  There are several reasons for this
commonality. First, in each testing session an attempt has been made to
increase the size of the OSPF system under test. For example, the number
of external routes imported has doubled each session. Secondly, the
interoperability sessions have been debugging sessions as well as
protocol sessions. Many things tested in the third round were to ver-
ify that implementations had successfully fixed problems found in
earlier sessions. A brief overview of the testing session is presented
in the following table:

TABLE 4. OSPF interoperability testing at a glance.


Site      Week       Routers   Externals   Implementations
_____________________________________________________________________________
Proteon   9/25/90    6         20-30       3com, Proteon, Wellfleet
SURAnet   12/17/90   10        96          3com, ACC, Proteon, Wellfleet
3com      2/4/91     16        400         3com, ACC, Proteon, Wellfleet, UMD


For more information on the interoperability testing, the following
people can be contacted: Fred Baker [fbaker], Rob Coltun [rcoltun], Dino
Farinacci [dino], Jonathan Hsu [jhsu], John Moy [jmoy], and William
Streilein [bstreile].


7.1  Testing methodology

In the interoperability tests, the routers have been interconnected
using ethernet, serial lines (PPP and proprietary), X.25 and 802.5 token
ring. Monitoring of the routers has been done through connecting
terminals (either directly or via telnet) to the router consoles. Each
implementation has a different user interface, which makes monitoring
somewhat difficult. As explained earlier in this document, there is now
an OSPF MIB, which in the future will enable a common monitoring
interface to all implementations.

In general, each implementation has an error logging capability, and
this is often how problems are discovered. LAN protocol analyzers are



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


also used to capture OSPF protocol packet exchanges that are causing
problems. These packet traces are available for analysis either during
of after the testing sessions.

Verification of routing was done through visual inspection of
implementations' routing table and link state databases (via the console
interface), and through network debugging tools such as "ping" and
"traceroute".


7.2  First round (Proteon, 9/25/90 - 9/29/90)

The first round of OSPF protocol testing took place at Proteon Inc.'s
Westborough facility, the week of September 25, 1990. Three
implementations participated, from the vendors 3com, Proteon and
Wellfleet.

There were two 3com routers, two Wellfleet routers and two Proteon
routers available for testing.  These routers were interconnected with
ethernets and serial lines. External routes were imported from the
Proteon company internet. In addition, during off hours we were able to
connect the routers under test to the Proteon company internet, forming
one fairly large OSPF system.

The testing at Proteon proceeded as follows:

o  All routers were connected to a single ethernet. Then, as routers
   were taken up and down, the Designated Router election algorithm and
   the Database Description process were tested. Also OSPF's reliable
   flooding algorithm was tested in this configuration.

o  Twenty to thirty external routes were imported into the OSPF system
   by a Proteon router (which was simultaneously running RIP). It was
   then verified that these external routes were installed into the
   router's routing tables.

o  One of the 3com routers was configured to originate an OSPF default
   route. This tested OSPF default route processing, and also tested the
   behavior of the system when multiple routers were importing external
   routes.

o  The OSPF system was split into areas. Both regular OSPF areas (non-
   stub) and stub areas were tested.

o  The six routers under test were connected to the Proteon company
   internet (which was also running OSPF), forming an OSPF system of
   eighteen routers. This configuration was shortlived, due to a
   disagreement between the 3com and Proteon routers concerning how to



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


   represent an OSPF default route.

Unfortunately, incomplete records were kept of this testing, so that no
maps of the testing configurations can be reproduced for this document.



7.2.1  Problems found in the First round testing

A couple of OSPF protocol/specification problems were uncovered in the
first round of testing.  First, it was noticed that there was a window
in the Database Description process where concurrently flooded MaxAge
advertisements could prevent database synchronization from completing.
This required a change in the specification's handling of MaxAge LSAs.

Secondly, it was found that the OSPF specification did not specify how
the Network Mask field should be set in external LSAs that were
advertising the DefaultDestination. This was a minor problem, but caused
difficulties because of assumptions made in one implementation on how
the mask should be set.


7.3  Second round (SURAnet, 12/17/90 - 12/21/90)

The second round of OSPF protocol testing took place at SURAnet's
College Park facility, the week of December 12, 1990. Four
implementations participated, from the vendors 3com, ACC, Proteon and
Wellfleet.

There were two 3com routers, two ACC routers, two Wellfleet routers and
four Proteon routers available for testing. These routers were
interconnected with ethernets, serial lines and token rings. External
routes were imported from SURAnet by one of the Proteon routers.

The testing at SURAnet proceeded as follows. Initially nine routers were
configured as a single backbone area, with six of the routers connected
to a single ethernet. This is pictured in Figure 4.  In this
configuration, the Designated Router transition and database
synchronization process were tested. Ninety-six external routes were
imported from SURAnet to stress the flooding algorithm. By restarting
the router that was importing the routes, the flushing of advertisements
from the routing domain was tested. Additionally, variable-length
subnets and OSPF's optional TOS routing capability were tested in this
configuration.

Next the routers were configured into four separate OSPF areas, with
each area directly connected to the OSPF backbone (which was a single
ethernet). There were no virtual links in this configuration.  Inter-



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


area routing was tested, including having AS boundary routers internal
to a non-backbone area. Also tested was the case where a single router
was both an area border router and an AS boundary router.

For more details of the testing, see the "Official report of the Second
Round Testing" listed below.



7.3.1  Official report of the Second round testing

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

The second round of OSPF multi-vendor testing was done in College Park,
Maryland the week of 12/17/90. The facilities were provided by SURAnet.
Four major router vendors were present, Advanced Computer Communications
(ACC), Proteon, 3Com, and Wellfleet. A press conference and presentation
was provided for 3 different data communication magazine
representatives.

Each vendor provided at least 2 routers. Each vendor had a device
connected to a common Ethernet. This Ethernet was configured as the OSPF
backbone area. The rest of the routers were attached to the various
backbone routers via Ethernet, Token Ring, proprietary serial line, PPP
serial line, and X.25 type media. The following test scenarios were
performed and completed in the following order:

o  Intra-area routing. All routers were configured to reside in the
   backbone area. Designated Router election was performed various
   number of times so each vendor could be designated router for a
   period of time. Packet data was captured on a Sniffer for later
   observation.

o  Variable Length Subnet Masks. Some of the serial lines in the
   configuration were configured to be on the same IP network but with
   different subnet masks. It was observed that all routers stored
   routes for the different length subnets.

o  Import SURAnet routes. The Proteon router was listening for RIP
   routes generated by the SURAnet routers. These routes were imported
   into our OSPF test system. 96 external link state advertisements were
   generated as a result. Many scaling type implementation problems
   surfaced for each vendor during this exercise.

o  Type of Service generation. While the test setup was still configured
   as a single area, the 3Com router generated Type of Service link



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


   state advertisements. It was observed how the other vendor
   implementations reacted to it. Some problems were found.

o  Inter-area routing. Multiple areas were configured. Common non-
   backbone areas were shared by Proteon and Wellfleet and by ACC and
   3Com. It was observed that the correct Intra-area and Inter-area
   routes appeared in each router's routing table. At this point in the
   test setup, the Proteon router regenerated the 96 SURAnet routes into
   the configuration. It was observed that the routes were learned and
   propagated over area boundaries. Some problems occur at this point.
   More emphasis on this scenario will occur at the next round of
   testing.

o  OSPF over X.25. A point-to-point link was connected between the
   Proteon router and the 3Com router. The X.25 packet level was
   configured to run over the link. OSPF was enabled over the link to
   verify that multi-vendor OSPF over X.25 was performed. Both of these
   routers were in the same area.

o  MaxAge advertisements. Link state advertisements were flushed from
   the routing domain using the MaxAge procedure. We verified that all
   routers removed the advertisements from their databases, after they
   were properly acknowledged by the flooding procedure. Some problems
   were found in this test, although not nearly as many as in the first
   round of testing.

Each vendor agreed that this sort of testing was extremely valuable and