Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|PS|PDF|HTML] [Tracker] [IPR] [Info page]
INFORMATIONAL
Network Working Group J. Moy, EditorRequest for Comments: 1246 July 1991Experience with the OSPF protocolStatus of this MemoThis memo provides information for the Internet community. It does notspecify any Internet standard. Distribution of this memo is unlimited.AbstractThis is the second of two reports on the OSPF protocol. These reportsare required by the IAB/IESG in order for an Internet routing protocolto advance to Draft Standard Status. OSPF is a TCP/IP routing protocol,designed to be used internal to an Autonomous System (in other words,OSPF is an Interior Gateway Protocol).OSPF is currently designated as a Proposed Standard. Version 1 of theOSPF protocol was published inRFC 1131. Since then OSPF version 2 hasbeen developed. Version 2 has been documented inRFC 1247. The changesbetween version 1 and version 2 of the OSPF protocol are explained inAppendix F ofRFC 1247. It is OSPF Version 2 that is the subject of thisreport.This report documents experience with OSPF V2. This includes reports oninteroperability testing, field experience, simulations and the currentstate of OSPF implementations. It also presents a summary of the OSPFManagement Information Base (MIB), and a summary of OSPF authenticationmechanism.Please send comments to ospf@trantor.umd.edu.1.0 IntroductionThis document addresses, for OSPF V2, the requirements set forth by theIAB/IESG for an Internet routing protocol to advance to Draft Standardstate. This requirements are briefly summarized below. The remainingsections of this report document how OSPF V2 satisfies theserequirements:[Moy] [Page 1]
RFC 1246 Experience with OSPF July 1991o The specification for the routing protocol must be well written such that independent, interoperable implementations can be developed solely based on the specification. For example, it should be possible to develop an interoperable implementation without consulting the original developers of the routing protocol.o A Management Information Base (MIB) must be written for the protocol. The MIB must be in the standardization process, but does not need to be at the same level of standardization as the routing protocol.o The security architecture of the protocol must be set forth explicitly. The security architecture must include mechanisms for authenticating routing messages and may include other forms of protection.o Two or more interoperable implementations must exist. At least two must be written independently.o There must be evidence that all features of the protocol have been tested, running between at least two implementations. This must include that all of the security features have been demonstrated to operate, and that the mechanisms defined in the protocol actually provide the intended protection.o There must be significant operational experience. This must include running in a moderate number routers configured in a moderately complex topology, and must be part of the operational Internet. All significant features of the protocol must be exercised. In the case of an Interior Gateway Protocol (IGP), both interior and exterior routes must be carried (unless another mechanism is provided for the exterior routes). In the case of a Exterior Gateway Protocol (EGP), it must carry the full complement of exterior routes.This report is a compilation of information obtained from many people.The reader is referred to specific people when more information on asubject is available. People references are gathered intoSection 10.0,in a format similar to that used in [4].1.1 AcknowledgmentsThe OSPF protocol has been developed by the OSPF Working Group of theInternet Engineering Task Force. Many people have contributed to thisreport. They are listed inSection 10.0 of this report.[Moy] [Page 2]
RFC 1246 Experience with OSPF July 19912.0 DocumentationVersion 1 of the OSPF protocol is documented inRFC 1131 [1]. OSPFVersion 2, which supersedes Version 1, has been documented inRFC 1247[2]. The differences between OSPF Version 1 and Version 2 are relativelyminor, and are listed inAppendix F of RFC 1247 [2]. All informationpresented in this report concerns OSPF V2 unless explicitly mentionedotherwise.The OSPF protocol was developed by the OSPF Working Group of theInternet Engineering Task Force. This Working Group has a mailing list,ospf@trantor.umd.edu, where discussions of protocol features andoperation are held. The OSPF Working Group also meets during thequarterly Internet Engineering Task Force conferences. Reports of thesemeeting are published in the IETF's Proceedings. In addition, tworeports on the OSPF protocol have been presented to the IETF plenary(see "Everything You Ever Wanted to Know about OSPFIGP" in [5] and "OSPFUpdate" in [6]).The OSPF protocol began undergoing field trials in Spring of 1990. Amailing list, ospf-tests@seka.cso.uiuc.edu, was formed to discuss howthe field trials were proceeding. This mailing list is maintained byRoss Veach of the University of Illinois [rrv]. Archives of this listare also available. There has been quite a bit of discussion on the listconcerning OSPF/RIP/EGP interaction.A OSPF V2 Management Information Base has also been developed andpublished in [3]. For more information, seeSection 3.0 of this report.There is a free implementation of OSPF available from the University ofMaryland. This implementation was written by Rob Coltun [rcoltun].Contact Rob for details.3.0 MIBAn OSPF Management Information Base has been published inRFC 1248 [3].The MIB was written by Rob Coltun [rcoltun] and Fred Baker [fbaker]. TheOSPF MIB appears on the mgmt subtree as SMI standard-mib 13.The OSPF MIB was originally developed by Rob Coltun of the University ofMaryland, under contract to Advanced Computer Communications. A subsetof his proposal was implemented to facilitate their development, andrepresents operational experience of a sort.The MIB consists of a general variables group and ten tables:TABLE 1. OSPF MIB Organization[Moy] [Page 3]
RFC 1246 Experience with OSPF July 1991 Group Name Description ________________________________________________________________ ospfGeneralGroup General Global Variables ospfAreaTable Area Descriptions ospfStubAreaTable Default Metrics, by Type of Service ospfLsdbTable Link State Database ospfAreaRangeTable Address Range Specifications ospfHostTable Directly connected Hosts ospfIfTable OSPF Interface Variables ospfIfMetricTable Interface Metrics, by Type of Service ospfVirtIfTable Virtual Links ospfNbrTable (Non-virtual) OSPF Neighbors ospfVirtNbrTable Virtual OSPF NeighborsAs MIBs go, the OSPF MIB is quite large; 105 objects. The following aresome statistics describing the distribution of the MIB's variables:o 11 define the above Group and Tableso 10 define the Entry in a Tableo 7 are Counterso 6 are Gaugeso 68 objects mandated by the OSPF Version 2 SpecificationSection D.2 of the OSPF V2 specification [2] lists a set of requiredstatistics that an implementation must maintain. These statistics havebeen incorporated into the OSPF MIB. The MIB's thirteen Counters andGauges enable evaluation of the OSPF protocol's performance in anoperational environment. Most of the remainder of the MIB's variablesparameterize the many features that OSPF provides the networkadministrator.For more information on the MIB contact Fred Baker [fbaker].4.0 Security architectureIn OSPF, all protocol packet exchanges are authenticated. The OSPFpacket header (which is common to all OSPF packets) contains a 16-bitAuthentication type field, and 64-bits of Authentication data. Eachparticular OSPF area must run a single authentication scheme, asindicated by the Authentication type field. However, authentication keyscan be configured by the system administrator on a per-network basis.[Moy] [Page 4]
RFC 1246 Experience with OSPF July 1991When an OSPF packet is received from a network, the OSPF router firstverifies that it indicates the correct Authentication type. The routerthen authenticates the packet, running a verification algorithm usingthe configured authentication key, the 64-bits of Authentication dataand the rest of the OSPF packet data as input. The precise algorithmused is dictated by the Authentication type. Packets failing theauthentication algorithm are dropped, and the authentication failure isnoted in a MIB-accessible variable (see [3]).There are currently few Authentication types in use. The currentassignments are:TABLE 2. Current OSPF Authentication types. Type code Algorithm ____________________________________________________________________ 0 No authentication performed. 1 Simple (clear) password. 2-255 Reserved for assignment by the IANA (iana@isi.edu) > 255 Available for local (per-AS) definition.For more information on OSPF's authentication procedures, see Sections8.1,8.2, andAppendix E of [2].5.0 ImplementationsThe are multiple, interoperable implementations of OSPF currentlyavailable. This section gives a brief overview of the fiveimplementations that have participated in at least one round ofinteroperability testing. (For a detailed discussion of OSPFinteroperability testing, seeSection 7.0 of this report.) Otherimplementations do exist, but because of commercial realities (e.g., theproduct is not yet announced) they unfortunately cannot be listed here.The five implementations that have participated in the OSPFinteroperability testing are (listed in alphabetical order):o 3com. This implementation was wholly developed by 3com. It has participated in all three rounds of interoperability testing. It is also the only implementation of OSPF's TOS routing.. The 3com implementation consists of approximately 9000 lines of C code, including comments but excluding user interface and MIB code. Consult Dino Farinacci [dino] for more details.[Moy] [Page 5]
RFC 1246 Experience with OSPF July 1991o ACC. This implementation is based on the University of Maryland code. It participated in the last two rounds of interoperability testing. It also contains the only implementation of (a precursor to) the OSPF MIB (seeSection 3.0 for details), which it uses for monitoring and configuration. The ACC implementation consists of approximately 24,000 lines of C code, including its OSPF MIB code. Consult Fred Baker [fbaker] for more details.o Proteon. This implementation was wholly developed by Proteon. It has participated in all three rounds of interoperability testing. It is also the only implementation that has a significant amount of field experience (seeSection 6.0 for details). The Proteon implementation consists of approximately 9500 lines of C code, including comments but excluding user interface code. Consult John Moy [jmoy] for more details.o Wellfleet. This implementation has participated in all three rounds of interoperability testing. Consult Jonathan Hsu [jhsu] for more details.o University of Maryland. This implementation was developed wholly by Rob Coltun at the University of Maryland. It has formed the basis for a number of commercial OSPF implementations, and also participated in the latest round of interoperability testing. The University of Maryland implementation consists of approximately 10,000 lines of C code. Consult Rob Coltun [rcoltun] for more details.Note that, as required by the IAB/IESG for Draft Standard status, thereare multiple interoperable independent implementations, namely thosefrom 3com, Proteon and the University of Maryland.6.0 Operational experienceThis section discusses operational experience with the OSPF protocol.Version 1 of the OSPF protocol began to be deployed in the Internet inSpring of 1990. The results of this original deployment were reported tothe mailing list ospf-tests@seka.cso.uiuc.edu. (Archives of this mailinglist are available from Ross Veach [rrv].) No protocol bugs were foundin this first deployment, although several additional features werefound to be desirable. These new features were added to the protocol inOSPF Version 2.The OSPF protocol is now deployed in a number of places in the Internet.In this section we focus on three highly visible systems, namely theNASA Sciences Internet, BARRNet and OARnet. The dimensions of thesethree OSPF systems is summarized in the following table:[Moy] [Page 6]
RFC 1246 Experience with OSPF July 1991TABLE 3. Three operational OSPF deployments Name Version 1 date Version 2 date # routers _____________________________________________________ NSI 4/13/90 1/1/91 15 BARRNet 4/90 11/90 14 OARnet 10/15/90 not yet 13All the above deployments are using the Proteon OSPF implementation.There is one other deployment worth mentioning in this context. 3com hasstarted to deploy OSPF on their corporate network. They have 8 of theirrouters running OSPF (the 3com implementation), and are planning oncutting over the remaining routers (20 in all). Currently they have twooperational routers running OSPF and RIP simultaneously. One convertsOSPF data to RIP data, and the other RIP data to OSPF data. For moredetails, contact Dino Farinacci [dino].6.1 NSIThe NASA Science Internet (NSI) is a multiprotocol network, currentlysupporting both DECnet and TCP/IP protocols. NSI's mission is to providereliable high-speed communications to the NASA science community. TheNASA Science Internet connects with other national networks includingthe National Science Foundation's NSFNET, the Department of Energy'sESnet and the Department of Defense's MILNET. NSI also hasinternational connections to Japan, Australia, New Zealand, Chile andseveral European countries.For more information on NSI, contact Jeffrey Burgan [jeff] or Milo Medin[medin].6.1.1 NSI's OSPF systemNSI was one of the initial deployment sites for OSPF Version 1, havingdeployed the protocol in April 1990. NSI has been running OSPF V2 since1/1/91. They currently have 15 routers in their OSPF system. Thissystem is pictured in Figure 1. It consists of a nationwide collectionof serial lines, with ethernets at hub sites. The numbers associated tointerfaces/links in Figure1 are the associated OSPF costs. Note thatcertain links have been weighted so that they are less preferable thanothers.Many of NSI's OSPF routers are speaking either RIP and/or EGP as well asOSPF. Routes from these other routing protocols are selectively imported[Moy] [Page 7]
RFC 1246 Experience with OSPF July 1991into their OSPF system as externals. The current number of importedexternals is 496.All NSI externals are imported as OSPF type 2 metrics. In addition, NSIuses the OSPF external route tag to manage the readvertisement ofexternal routes. For example, a route learned at one edge of the NSIsystem via EGP can be tagged with the number of the AS from which it waslearned. Then, as the OSPF external LSA describing this route is floodedthrough the OSPF system, this tagging information is distributed to allthe other AS boundary routers. A router on the other edge of the NSI canthen say that it wants to readvertise (via EGP) routes learned from oneparticular AS but not routes learned from another AS. This allows NSI toimplement transit policies at the granularity of Autonomous Systems,instead of network numbers, which greatly reduces the network'sconfiguration burden.NSI has also experimented with OSPF stub areas, in order to supportrouters having a small amount of memory.6.1.2 NSI - Deployment analysisNSI ran a couple of experiments after OSPF's deployment to test OSPF'sconvergence time in the face of network failures, and to compare thelevel of routing traffic in OSPF with the level of routing traffic inRIP. These experiments were included in NSI status reports to the OSPFplenary.The first experiment consisted of running a continuous ICMP ping, andthen bringing down one of the links in the ping packet's path. They thentimed how long it took OSPF to find an alternate path, by noticing whenthe pings resumed. The result of this experiment is contained in MiloMedin's "NASA Sciences Internet Report" in [8]. It shows that theinterrupted ping resumed in three seconds.The second experiment consisted in analyzing the amount of routingprotocol traffic that flow over an NSI link. One of the NSI links wasinstalled, but did not have any active users yet. For this reason, alltraffic that flowed over the link was routing protocol traffic. The linkwas instrumented to continuously measure the amount of bandwidthconsumed, first in the case where RIP was running, and then in the caseof where OSPF was running. The result is shown graphically in JeffreyBurgan's "NASA Sciences Internet" report in [9]. It shows that OSPFconsumes many times less network bandwidth than RIP.[Moy] [Page 8]
RFC 1246 Experience with OSPF July 19916.2 BARRNetBARRNet is the NSFNet regional network in Northern California. At thepresent time, it serves approximately 80 member sites in an areastretching from Sacramento in the north-east to Monterey in the in thesouth-west. Sites are connected to the network at speeds from 9.6Kbps tofull T1 using Proteon and cisco routers as well as a Xylogics terminalserver. The membership is composed of a mix of university, government,and commercial organizations. BARRNet has interconnections to the NSFNet(peering with both T1 and T3 backbones at Stanford University), ESNet(peering at LLNL, with additional multi-homed sites at LBL, SLAC, andNASA Ames), and DDN national networks (peering at the FIX network atNASA Ames), and to the statewide networks of the University ofCalifornia (peering at U.C. Berkeley) and the California StateUniversity system (peering at San Francisco State and Sacramento State).Topologically, the network consists of fourteen OSPF-speaking Proteonrouters, which as a "core", with six of these redundantly connected intoa ring. All "core" sites are interconnected via full T1 circuits. Othermember sites attach as "stub" connections to the "core" sites. The bulkof these are connected in a "star" configuration at Stanford University,with lesser numbers at other "core" sites.Contact Vince Fuller [vaf] for more information on BARRNet.6.2.1 BARRNet's OSPF systemBARRNet was also one of the initial deployment sites for OSPF Version 1,having deployed the protocol in April 1990. BARRNet has been runningOSPF V2 since November 1990. They currently have 14 routers in theirOSPF system. The BARRNet OSPF system is pictured in Figure 2. Itconsists of a collection of T1 serial lines, with ethernets at hubsites.Most of BARRNet's OSPF routers are speaking either RIP and/or EGP aswell as OSPF. Routes from these other routing protocols are selectivelyimported into their OSPF system as externals. A large number of externalroutes are imported; the current number is1816. The bulk of these arethe T1 NSFNet routes, followed by several hundred NSN routes, around60-80 BARRNet routes from the non-OSPF system, and several dozen fromESNet.All external routes are imported into the BARRNet system as externaltype 1 metrics. In addition, BARRnet, like NSI, uses the OSPF's externalroute tagging feature to help manage the readvertisement of externalroutes via EGP.[Moy] [Page 9]
RFC 1246 Experience with OSPF July 1991BARRnet is also using four stub OSPF areas in order to collapse subnetinformation. These stub areas all consist of a single LAN. They do notcontain any OSPF routers in their interiors.6.2.2 BARRNet - Deployment analysisInitial deployment of OSPF Version 1 in BARRNet pointed to the need fortwo new protocol features that were added to OSPF V2, namely:o Addition of the forwarding address to OSPF external LSAs. This eliminated the extra hops that were being taken in BARRNet when only routers BR5 and BR6 were exchanging EGP information with the NSS (see Figure 2). Without the forwarding address feature, that meant that NSFNet traffic handled by routers BR10, BR16 and BR28 was taking an extra hop to get to the NSS.o Addition of stub areas. This was an attempt to get OSPF running on some of the BARRNet routers that had insufficient memory to deal with all of BARRNet's external routes.6.3 OARnetOARnet, the Ohio Academic Resources Network, is the regional network forthe state of Ohio. It serves the entire higher education community,providing Ohio schools access to colleagues worldwide. The OhioSupercomputer Center and the NSF Supercomputer Centers are reachedthrough OARnet. Libraries, databases, national and internationallaboratories and research centers are accessible to faculty, helpingmake Ohio schools competitive.OARnet was established in 1987 to provide state-wide access to the CRAYat the Ohio Supercomputer Center in Columbus, Ohio. Since then it hasevolved into a network supporting all aspects of higher education withinOhio. A primary goal of OARnet is to facilitate collaborative projectsand sharing of resources between institutions, including those outsidethe state. OARnet connections are available to Ohio academicinstitutions and corporations engaged in research, product development,or instruction. Colleges, universities, and industries currently useOARnet connections to communicate within the state and with colleaguesaround the country.OARnet uses the Internet (TCP/IP) and DECNET protocols. OARnetparticipants using TP/IP protocols are connected to the worldwideInternet, which includes all the major networks open to non-classifiedresearch. OARnet is also connected to NSFNet, the national research and[Moy] [Page 10]
RFC 1246 Experience with OSPF July 1991education network sponsored by the National Science Foundation. It hasgateways to BITNET, CSNET, CICNet (a network connecting the Big Tenuniversities), and the NASA Science Internet.For more information on OARnet, contact Kannan Varadhan [kannan].6.3.1 OARnet's OSPF systemOARnet has been running OSPF Version 1 since October 15, 1990. Theycurrently have 14 routers in their OSPF system. The OARnet OSPF systemis pictured in Figure 3.There are 29 sites connected directly to the OARnet backbone. All 13 ofOARnet's OSPF routers act as ASBRs. There are 40 OSPF internal routes onOARnet's network, and they import about 120 routes from RIP. OARnetruns EGP on the DMZnet at Columbus, which connects them to CICNet. Therouter connecting OARnet to DMZnet (OAR1 in Figure 3) runs EGP on theDMZnet side, and OSPF and RIP on the OARnet backbone. No EGP routes areimported into the OSPF system. The OAR1 router is configured to generatea default when EGP routes are available. The OAR1 router is the keystonefor routing on OARnet's network, in that it acts as an intermediary forall of OARnet's RIP centric routers.OARnet uses the Event Logging System on its Proteon routers to generatetraps for "interesting" events related to routing. They have these trapssent to an SNMP management station, where the logs are collected forlater perusal.6.3.2 OARnet - Deployment analysisOARnet is monitoring their OSPF system via collection of traps on theirSNMP management station. The following is a report on theirobservations. It has been edited slightly to conform better with theother text and maps presented in this report. For more information,contact Kannan Varadhan [kannan]:3 of our 10 DS1 circuits are on digital microwave, and these tend toflap occasionally. Our observations indicate that the routers bring uplinks, and adjacencies, on average, in about 2 seconds. Routes fallbackto alternate backup paths instantly. Whole blocks of routes cut over theinstant the adjacencies are formed.In contrast to this, our RIP routes would take about 3-6 minutes tocutover, and, on occasion, would not cut back to the preferred paths.This was our prime motivation in switching to OSPF.[Moy] [Page 11]
RFC 1246 Experience with OSPF July 1991We attempted to duplicate Milo Medin's ping test to dramaticallyillustrate the performance of RIP over OSPF. To do this, we selected ahost on the farthest point from our workstation, and ran a continuousping to it. We would then bring down a primary DS1 circuit, and watchthe time it took to switch to the fallback route. Following this, wewould bring the circuit back up, and study the time it took to re-syncto the new path. With RIP, we were unable to fully complete theexperiment, because the farthest point was exactly equal to the new (andpreferred) primary path, and therefore, RIP would never choose it onit's own, until the path it was currently using failed. With OSPF, ittook about 2 seconds to synchronize over a new, much slower 56kb path,and less than a second when the DS1 circuit came back up.Here are some more observations of the OARnet OSPF system's behavior:o 131.187.36.0 is the 56kb line to Kent State University. Kent also has a DS1 circuit leading into ASP, the Akron Pop. Likewise, UAkron.edu has a similar configuration. A roundabout backup path exists when traffic heads up to Cleveland over a couple of DS1 circuits, and then down a 56kb backup path used by another school in the Cleveland area. Some statistical information: 1. 09:55:17: SPF.37: new route to Net 131.187.36.5, type SPF cost 32 2. 09:55:18: SPF.37: new route to Net 131.187.36.6, type SPF cost 22 3. 09:55:20: SPF.21: State Change, nbr 131.187.27.6, new state <Full>, event 9 4. 09:55:21: SPF.37: new route to Net 131.187.36.5, type SPF cost 31 5. 09:55:22: SPF.37: new route to Net 131.187.36.6, type SPF cost 21 6. 09:55:28: SPF.21: State Change, nbr 131.187.21.5, new state <Full>, event 9 7. 09:55:29: SPF.21: State Change, nbr 131.187.51.6, new state <Full>, event 9 8. 09:55:31: SPF.37: new route to Net 131.187.36.5, type SPF cost 22 9. 09:55:33: SPF.37: new route to Net 131.187.36.5, type SPF cost 11 The Akron router restarts, and has to re-sync with all the lines. This restart is confirmed when one looks at the traps from gwCSP1. Traps from gwASP1 still do not get through to us, because traps are[Moy] [Page 12]
RFC 1246 Experience with OSPF July 1991 sent via UDP, and gwASP1's routing tables are not fully configured yet. Events 1 and 2 are route changes routing traffic via Cleveland, across 2 DS1 circuits and a 56kb line. When the DS1 circuit to UAkron came up, routes instantly cut over to use this as a better least cost path. This is shown in events 3, 4 and 5. In a few seconds, the line to Columbus is the next one up. This is event 6. Event 8 relates to this cutover, and is the best path yet. When the DS1 circuit to Kent is up, the link is used instantly. We are able to make such a definitive conclusion of these traps on the basis of the topological information that we have about the network and the means used to monitor them.o To illustrate the time required to fully synchronize a database, we piece together a few adjacency forming traces... Please bear in mind that these time stamps are the time stamps on the management station, and are not to be taken as the absolute truth. Things we haven't taken into account are transit times of messages, ordering of events (SNMP traps are sent using UDP), loss of event reports (recall that an entire synchronization sequence of gwASP1 on the ASP-CSP link is missing), etc. The trace below corresponds to the Akron router, gwASP1 bring up the link in the previous section. This is as observed on the other end of the line, gwCSP1. REPORT DATE: 02/26/91 ROUTER: gwcsp1 09:55:06: SPF.15: State Change, ifc 131.187.22.6, new state <Point-To-Point>, event 1 09:55:06: GW.xxx: Link Up Trap: 09:55:07: SPF.37: new route to Net 131.187.22.5, type SPF cost 1 09:55:07: SPF.21: State Change, nbr 131.187.22.5, new state <Init>, event 1 09:55:09: SPF.37: new route to Net 131.187.27.5, type SPF cost 22 09:55:11: SPF.21: State Change, nbr 131.187.22.5, new state <ExStart>, event 14 09:55:11: SPF.21: State Change, nbr 131.187.22.5, new state <2-Way>, event 3 09:55:12: SPF.21: State Change, nbr 131.187.22.5, new state <Exchange>, event 5[Moy] [Page 13]
RFC 1246 Experience with OSPF July 1991 09:55:12: SPF.21: State Change, nbr 131.187.22.5, new state <Full>, event 9 09:55:12: SPF.21: State Change, nbr 131.187.22.5, new state <Loading>, event 6 Below, is another trace of the same router restart sequence, where the router is proceeding to bring up other DS1 circuits. Bringing up the first adjacency took about 5 seconds. Subsequent adjacencies take the router less than a second as seen below. REPORT DATE: 02/26/91 ROUTER: gwasp1 09:55:20: SPF.15: State Change, ifc 131.187.27.5, new state <Point-To-Point>, event 1 09:55:20: GW.xxx: Link Up Trap: 09:55:20: SPF.21: State Change, nbr 131.187.27.6, new state <Init>, event 1 09:55:20: SPF.21: State Change, nbr 131.187.27.6, new state <ExStart>, event 14 09:55:20: SPF.21: State Change, nbr 131.187.27.6, new state <Exchange>, event 5 09:55:20: SPF.21: State Change, nbr 131.187.27.6, new state <Full>, event 9 09:55:21: SPF.21: State Change, nbr 131.187.27.6, new state <Loading>, event 6 09:55:24: SPF.21: State Change, nbr 131.187.51.6, new state <Init>, event 1 09:55:24: SPF.21: State Change, nbr 131.187.21.5, new state <Init>, event 1 09:55:25: SPF.37: new route to Net 131.187.21.6, type SPF cost 13 09:55:25: SPF.37: new route to Net 131.187.51.5, type SPF cost 22 09:55:28: SPF.21: State Change, nbr 131.187.21.5, new state <ExStart>, event 14 09:55:28: SPF.21: State Change, nbr 131.187.21.5, new state <2-Way>, event 3 09:55:28: SPF.21: State Change, nbr 131.187.21.5, new state <Exchange>, event 5 09:55:28: SPF.21: State Change, nbr 131.187.21.5, new state <Full>, event 9 09:55:28: SPF.21: State Change, nbr 131.187.21.5, new state <Loading>, event 6 09:55:29: SPF.37: new route to Net 131.187.51.6, type SPF cost 1 09:55:29: SPF.37: new route to Net 131.187.21.5, type SPF cost 1 09:55:29: SPF.21: State Change, nbr 131.187.51.6, new state <Exchange>, event 5 09:55:29: SPF.21: State Change, nbr 131.187.51.6, new state <ExStart>, event 14 09:55:29: SPF.21: State Change, nbr 131.187.51.6, new state <2-Way>, event 3 09:55:29: SPF.21: State Change, nbr 131.187.51.6,[Moy] [Page 14]
RFC 1246 Experience with OSPF July 1991 new state <Full>, event 9 09:55:29: SPF.21: State Change, nbr 131.187.51.6, new state <Loading>, event 6 A transient fault on a DS1 circuit, causes the line to flap. All routers quickly reroute around the flap, and the router itself takes about 2 seconds to bring up the adjacency once more. REPORT DATE: 02/26/91 ROUTER: gwasp1 14:33:43: GW.xxx: Link Up Trap: 14:34:19: SPF.15: State Change, ifc 131.187.22.5, new state <Down>, event 7 14:34:19: GW.xxx: Link Failure Trap: 14:34:19: SPF.47: Net 131.187.22.6 now unreachable 14:34:36: SPF.15: State Change, ifc 131.187.22.5, new state <Point-To-Point>, event 1 14:34:36: GW.xxx: Link Up Trap: 14:34:37: SPF.37: new route to Net 131.187.22.6, type SPF cost 1 14:34:45: SPF.21: State Change, nbr 131.187.22.6, new state <2-Way>, event 3 14:34:45: SPF.21: State Change, nbr 131.187.22.6, new state <Init>, event 1 14:34:46: SPF.21: State Change, nbr 131.187.22.6, new state <ExStart>, event 14 14:34:46: SPF.21: State Change, nbr 131.187.22.6, new state <Exchange>, event 5 14:34:47: SPF.21: State Change, nbr 131.187.22.6, new state <Full>, event 9 14:34:47: SPF.21: State Change, nbr 131.187.22.6, new state <Loading>, event 6o On the amount of time it takes for a router to restart, and become fully synchronized. Taking the logs in the previous instance, we notice that the CSP-ASP link comes up at 9:55:06. The last link is observed to be up at 9:55:29, which is less than a minute.o On the RIP equivalent of the tests, it took us 3 minutes to cutover to the slower speed fallback route, and we lost countless many packets. The routes never cutover to the higher speed paths when available, and we waited well over 30 minutes watching this, wondering why. Unfortu- nately, at this point, we seem to have lost the RIP statistics. On the OSPF version, we have... {nisca danw 51} ping 131.187.25.6 PING 131.187.25.6 (131.187.25.6):[Moy] [Page 15]
RFC 1246 Experience with OSPF July 1991 56 data bytes 64 bytes from 131.187.25.6: icmp seq=0 ttl(255-ttl)=54(201). time=20 ms [...] icmp seq=10 ttl(255-ttl)=54(201). time=20 ms || T1 down icmp seq=14 ttl(255-ttl)=54(201). time=180 ms icmp seq=15 ttl(255-ttl)=54(201). time=60 ms [...] icmp seq=38 ttl(255-ttl)=8(247). time=1300 ms icmp seq=39 ttl(255-ttl)=54(201). time=820 ms || Tl Up icmp seq=40 ttl(255-ttl)=54(201). time=20 ms icmp seq=41 ttl(255-ttl)=54(201). time=20 ms 131.187.25.6 PING Statistics 51 packets transmitted, 48 packets received, 5% packet loss round-trip (ms) min/avg/max = 20/277/13006.4 Features exercised during operational deploymentIn operational environments, all basic mechanisms of the OSPF protocolhave been exercised. These mechanisms include:o Designated Router election. There have been operational deployments have as many as 8 OSPF routers attached to a single broadcast network.o Database synchronization. This includes OSPF's adjacency bringup and reliable flooding procedures. Large operational OSPF link state databases (e.g., BARRNet) have provided a thorough test of these mechanisms.o Flushing advertisements. The procedure for flushing old or unreachable advertisements (the MaxAge procedure) has been tested operationally. It is interesting to note that flushing of advertisements does occur more during interoperability testing (because of the constant restart- ing of routers) that it does operationally. For example, in a week of BARRNet statistics, 9650 advertisements were flushed, while 688,278 new advertisements were flooded.o Import of external routes. All options of external LSAs have been tested operationally: type 1 metrics, type 2 metrics, forwarding addresses and the external route tag.o Authentication. The OSPF authentication procedure has been tested operationally.[Moy] [Page 16]
RFC 1246 Experience with OSPF July 1991o Equal-cost multipath. Operational deployments have included topologies with equal-cost, redundant paths.o Stub areas. These have been deployed both in BARRNet and NSI.6.5 Limitations of operational deploymentsThe 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 (seeSection 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 ConclusionsAll basic features of the OSPF protocol have been exercised. Very largeOSPF link state databases (e.g., BARRNet's OSPF system) have beendeployed, providing a thorough test of OSPF's database synchronizationmechanisms. No OSPF protocol problems have been found in operationaldeployments.Most of the hassles in operation deployments has to do with the OSPF/RIPinterchange. Many of these issues have been ironed out on the ospf-testsmailing list (seeSection 2.0). However, the interaction between OSPF,RIP, and EGP continues to be an active area of research.7.0 Interoperability TestingThere have been three separate OSPF V2 interoperability testingsessions. Five separate implementations have participated in at leastone session: implementations from the companies 3com, ACC, Proteon andWellfleet, and the publicly available implementation from the Universityof Maryland.[Moy] [Page 17]
RFC 1246 Experience with OSPF July 1991Each of the testing sessions is described in a succeeding section. Foreach session, the participants are identified, and the testingtopologies are described along with the particular protocol featuresthat were exercised. Any protocol problems that were encountered duringthe testing are also described. In addition, for the second and thirdrounds testing reports were sent to the ospf mailing lists. Thesereports are reproduced in this document.There is quite a bit of commonality in the features that have beentested from session to session. There are several reasons for thiscommonality. First, in each testing session an attempt has been made toincrease the size of the OSPF system under test. For example, the numberof external routes imported has doubled each session. Secondly, theinteroperability sessions have been debugging sessions as well asprotocol sessions. Many things tested in the third round were to ver-ify that implementations had successfully fixed problems found inearlier sessions. A brief overview of the testing session is presentedin 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, WellfleetSURAnet 12/17/90 10 96 3com, ACC, Proteon, Wellfleet3com 2/4/91 16 400 3com, ACC, Proteon, Wellfleet, UMDFor more information on the interoperability testing, the followingpeople can be contacted: Fred Baker [fbaker], Rob Coltun [rcoltun], DinoFarinacci [dino], Jonathan Hsu [jhsu], John Moy [jmoy], and WilliamStreilein [bstreile].7.1 Testing methodologyIn the interoperability tests, the routers have been interconnectedusing ethernet, serial lines (PPP and proprietary), X.25 and 802.5 tokenring. Monitoring of the routers has been done through connectingterminals (either directly or via telnet) to the router consoles. Eachimplementation has a different user interface, which makes monitoringsomewhat difficult. As explained earlier in this document, there is nowan OSPF MIB, which in the future will enable a common monitoringinterface to all implementations.In general, each implementation has an error logging capability, andthis is often how problems are discovered. LAN protocol analyzers are[Moy] [Page 18]
RFC 1246 Experience with OSPF July 1991also used to capture OSPF protocol packet exchanges that are causingproblems. These packet traces are available for analysis either duringof after the testing sessions.Verification of routing was done through visual inspection ofimplementations' routing table and link state databases (via the consoleinterface), 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.'sWestborough facility, the week of September 25, 1990. Threeimplementations participated, from the vendors 3com, Proteon andWellfleet.There were two 3com routers, two Wellfleet routers and two Proteonrouters available for testing. These routers were interconnected withethernets and serial lines. External routes were imported from theProteon company internet. In addition, during off hours we were able toconnect the routers under test to the Proteon company internet, formingone 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 nomaps of the testing configurations can be reproduced for this document.7.2.1 Problems found in the First round testingA couple of OSPF protocol/specification problems were uncovered in thefirst round of testing. First, it was noticed that there was a windowin the Database Description process where concurrently flooded MaxAgeadvertisements 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 howthe Network Mask field should be set in external LSAs that wereadvertising the DefaultDestination. This was a minor problem, but causeddifficulties because of assumptions made in one implementation on howthe 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'sCollege Park facility, the week of December 12, 1990. Fourimplementations participated, from the vendors 3com, ACC, Proteon andWellfleet.There were two 3com routers, two ACC routers, two Wellfleet routers andfour Proteon routers available for testing. These routers wereinterconnected with ethernets, serial lines and token rings. Externalroutes were imported from SURAnet by one of the Proteon routers.The testing at SURAnet proceeded as follows. Initially nine routers wereconfigured as a single backbone area, with six of the routers connectedto a single ethernet. This is pictured in Figure 4. In thisconfiguration, the Designated Router transition and databasesynchronization process were tested. Ninety-six external routes wereimported from SURAnet to stress the flooding algorithm. By restartingthe router that was importing the routes, the flushing of advertisementsfrom the routing domain was tested. Additionally, variable-lengthsubnets and OSPF's optional TOS routing capability were tested in thisconfiguration.Next the routers were configured into four separate OSPF areas, witheach area directly connected to the OSPF backbone (which was a singleethernet). There were no virtual links in this configuration. Inter-[Moy] [Page 20]
RFC 1246 Experience with OSPF July 1991area routing was tested, including having AS boundary routers internalto a non-backbone area. Also tested was the case where a single routerwas both an area border router and an AS boundary router.For more details of the testing, see the "Official report of the SecondRound Testing" listed below.7.3.1 Official report of the Second round testingThe following report was sent to the ospf, ospf-tests, and router-requirements mailing lists after the second round of interoperabilitytests: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 presentationwas provided for 3 different data communication magazinerepresentatives.Each vendor provided at least 2 routers. Each vendor had a deviceconnected to a common Ethernet. This Ethernet was configured as the OSPFbackbone area. The rest of the routers were attached to the variousbackbone routers via Ethernet, Token Ring, proprietary serial line, PPPserial line, and X.25 type media. The following test scenarios wereperformed 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 andthat it should occur again. 3Com has offered for the third round oftesting to occur in Santa Clara sometime in February. 3Com willencourage other OSPF implementations to join in the testing. Items thatwill 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 1991o 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 wouldallow us to also use a network management station to gather test data.In summary, the stability of implementations were better this time moreso than the first round of testing. No problems with the protocol designwere encountered. The exchange of ideas and the cooperation amongimplementors that occurred during this test effort, continues the spiritthat OSPF is truly an open protocol.7.3.2 Problems found in the Second round testingNo problems were found in the OSPF protocol during the second round oftesting.7.4 Third round (3com, 2/4/91 - 2/8/91)The third round of OSPF protocol testing took place at 3com's SantaClara facility, the week of February 4, 1991. Five implementationsparticipated, from the vendors 3com, ACC, Proteon and Wellfleet and thepublicly available University of Maryland implementation (running on aSUN 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 wereinterconnected with ethernets, serial lines and X.25. External routeswere imported from BARRNet by one of the 3com routers.The initial testing configuration is shown in Figure 5. Three areas wereconfigured, along with a non-contiguous backbone. The backbone was thenjoined by configuring two virtual links. In this configuration thefollowing OSPF functionality was tested: inter-area routing and virtuallinks.The system was then reconfigured so that twelve of the routers wereconnected to a single ethernet. This configuration is pictured in Figure6. By bringing routers up and down, this configuration tested DesignatedRouter election, database synchronization and reliable flooding. To seehow this functionality, and also the implementations, scale, 400[Moy] [Page 23]
RFC 1246 Experience with OSPF July 1991external routes were imported from BARRNet.7.4.1 Official report of the Third round testingThe following report was sent to the ospf, ospf-tests, and router-requirements mailing lists after the third round of interoperabilitytests:The third round of OSPF interoperability testing was held at 3comCorporation in Santa Clara the week of February 4-8. Four router vendorscame to the testing: 3com, ACC, Proteon and Wellfleet. In addition, RobColtun brought the University of Maryland implementation, which was runon 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, fourACC routers, three Proteon routers, three Wellfleet routers and Rob'sSUN. 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 1991o 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 usimport the BARRNet routes.7.4.2 Problems found in the Third round testingA couple of specification/protocol problems were found in the thirdround of interoperability testing. First, it was noticed that thespecification did not specify the setting of the Network Mask field inHellos sent over virtual links. This caused some initial difficulty inbringing up virtual links between routers belonging to differentvendors. Secondly, it was noticed that the specification was not strictenough in defining how OSPF neighbors are identified on multi-accessnetworks. This caused difficulties in one implementation when anothervendor's router was restarted with the same IP address but a differentOSPF Router ID. This is discussed more fully in the above "OfficialReport of the Third Round Testing".7.5 Overall: Features testedAll significant protocol features and mechanisms have been tested in thethree rounds of interoperability testing. In particular, the followingbasic 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 1991Testing was also performed on the following pieces of OSPF's Areafunctionality: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 conclusionsThe interoperability testing has proven to be very valuable. Many bugswere found (and fixed) in the implementations. Some protocol problemswere found (and fixed), and gray areas of the specification were clearedup. Implementations have also been "bullet-proofed" in order to dealwith the unexpected behavior of other implementations. All participantsin the testing now understand the maxim "be conservative in what yougenerate, and liberal in what you accept" (if they didn't already).7.7 Future workThe one thing that has gone mostly untested at the interoperabilitysessions is the interaction between OSPF and other routing protocols(such as RIP and EGP). Each interoperability session generally had arouter running multiple routing protocols in order to import externalrouting information into the OSPF system. However, simultaneouslyrunning multiple routing protocols between different vendors' routershas not been tested.Each vendor has developed a slightly different architecture for theexchange of routing information between differing routing protocols. Asthe OSPF field testing has also shown, this exchange of routinginformation is an area of ongoing work and a candidate for futurestandardization.[Moy] [Page 27]
RFC 1246 Experience with OSPF July 19918.0 SimulationThe OSPF protocol has been simulated by the Distributed Systems ResearchGroup at the University of Maryland Baltimore County (UMBC). The twoprincipal investigators for the OSPF simulation project are Dr.Deepinder P. Sidhu of UMBC and Rob Coltun. They have been aided by threegraduate students: S. Abdallah, T. Fu and R. Nair. This sectionattempts to summarize their simulation setup and results. For moreinformation, contact the Distributed Systems Research Group at thefollowing address: Dr. Deepinder P. Sidhu Department of Computer Science University of Maryland Baltimore County Baltimore, MD 21228 email: sidhu@umbc3.umbc.eduA demo was given of their OSPF simulation at the March 4-8, 1991 IETF inSt. Louis. Details of the demo should be available in the IETFproceedings.8.1 Simulator setupThe Distributed System Research Group uses a significantly enhancedversion of the MIT network simulator. The simulator is event driven, andcontains support for both point-to-point networks and ethernet links. Itcan simulate characteristics of both packet switches and hosts, and cansimulate internet behavior under various types of data traffic load(e.g., Poisson, normal, exponential and uniform distributions). Thislatter ability could be used, for example, to simulate how a routingprotocol works in a congested internet. Specific network topologies canbe input into the simulator, or pseudo-random network topologies can begenerated. Packet loss rates can also be simulated.To simulate OSPF, Rob Coltun's OSPF implementation was incorporated intothe simulator, essentially unchanged.The output of the simulator can be displayed in a graphical manner (ituses X windows). Any variable in the implementation under test can bemonitored. In addition, statistical reports can later be produced fromlogging files produced during the simulation runs.[Moy] [Page 28]
RFC 1246 Experience with OSPF July 19918.2 Simulation resultsThe OSPF simulation has been run using the following topologies:o The two sample topologies in the OSPF specification (Figure 2 and Figure 6 in [2]). The first of these topologies shows an Autonomous System without areas, the second the same AS with three areas and a virtual link configured.o The 19-node hub topology from [7].o A large network of over 50 nodes, all attached to a single ethernet.o A large network of over 50 nodes, containing both ethernets and serial lines, pseudo randomly generated.In these topologies, the correctness of the OSPF databasesynchronization was verified. This was done through examination of thenodes' OSPF link state databases and the nodes' routing tables. Theimplementation of multiple OSPF areas was also tested. Also, databaseconvergence time was analyzed as a function of the network components'link speeds.Also, some formal analysis of the OSPF protocol was undertaken. Theneighbor and interface state machines were analyzed. In addition, theDesignated Router election algorithm was verified for certain sets ofinitial conditions.9.0 Reference DocumentsThe following documents have been referenced by this report:[1] Moy, J., "The OSPF Specification",RFC 1131, October 1989.[2] Moy, J., "OSPF Version 2",RFC 1247, July 1991.[3] Coltun, R. and Baker, F., "OSPF Version 2 Management Information Base",RFC 1248, July 1991.[4] Reynolds, J. and Postel, J., "Assigned Numbers',RFC1060, March 1990.[5] Corporation for National Research Initiatives, "Proceedings of the Thirteenth Internet Engineering Task Force", Cocoa Beach, Florida, April 11-14, 1989.[Moy] [Page 29]
RFC 1246 Experience with OSPF July 1991[6] Corporation for National Research Initiatives, "Proceedings of the Sixteenth Internet Engineering Task Force", Florida State University, February 6-9, 1990.[7] Gardner, M., et al., "Type-of-service routing: modeling and simulation," Report 6364, BBN Communications Corporation, January 1987.[8] Corporation for National Research Initiatives, "Proceedings of the Seventeenth Internet Engineering Task Force", Pittsburgh Supercomputing Center, May 1-4, 1990.[9] Corporation for National Research Initiatives, "Proceedings of the Eighteenth Internet Engineering Task Force", University of British Columbia, July 30-August 3, 1990.10.0 PeopleThe following people have contributed information to this report and canbe contacted for further information:TABLE 5. People references in this reportTag Name Affiliation email__________________________________________________________________________________bstreile William Streilein Wellfleet bstreile@wellfleet.comdino Dino Farinacci 3com dino@buckeye.esd.3com.comfbaker Fred Baker ACC fbaker@acc.comjeff Jeffrey Burgan Sterling Software jeff@nsipo.nasa.govjhsu Jonathan Hsu Wellfleet jhsu@wellfleet.comjmoy John Moy Proteon jmoy@proteon.comkannan Kannan Varadhan OARnet kannan@oar.netmedin Milo Medin Sterling Software medin@nsipo.nasa.govrcoltun Rob Coltun U. of Maryland rcoltun@umd5.umd.edurrv Ross Veach U. of Illinois rrv@seka.cso.uiuc.eduvaf Vince Fuller BARRNet vaf@valinor.stanford.edu[Moy] [Page 30]
RFC 1246 Experience with OSPF July 1991Security ConsiderationsThe OSPF protocol's security architecture is described inSection 4.0.Author's AddressJohn MoyProteon Inc.2 Technology DriveWestborough, MA 01581Phone: (508) 898-2800Email: jmoy@proteon.com[Moy] [Page 31]
[8]ページ先頭