📄 rfc1246.txt
字号:
flap occasionally. Our observations indicate that the routers bring up
links, and adjacencies, on average, in about 2 seconds. Routes fallback
to alternate backup paths instantly. Whole blocks of routes cut over the
instant the adjacencies are formed.
In contrast to this, our RIP routes would take about 3-6 minutes to
cutover, 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 1991
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -