rfc1246.txt

中、英文RFC文档大全打包下载完全版 .

We attempted to duplicate Milo Medin's ping test to dramatically
illustrate the performance of RIP over OSPF. To do this, we selected a
host on the farthest point from our workstation, and ran a continuous
ping to it. We would then bring down a primary DS1 circuit, and watch
the time it took to switch to the fallback route.  Following this, we
would bring the circuit back up, and study the time it took to re-sync
to the new path.     With RIP, we were unable to fully complete the
experiment, because the farthest point was exactly equal to the new (and
preferred) primary path, and therefore, RIP would never choose it on
it's own, until the path it was currently using failed. With OSPF, it
took 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 6

o  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/1300


6.4  Features exercised during operational deployment

In operational environments, all basic mechanisms of the OSPF protocol
have 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 1991


o  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 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