Circuit TCP-0-51, Adjacent node = 5.10 (MICRO1)
In this case it was node 51.10 but it's not unique to that machine - I've
seen the same problem from time to time on the other links as well.
It's always a transient problem; the link comes back up on its own in a
minute or so. It seems to come in "clusters" - I'll get a whole bunch of
these errors logged one afternoon, and then everything will be stable for a
day. It's not always an "unexpected packet type" error; sometimes it'll just
be a "listener receive timeout" instead.
Given that Multinet uses UDP it almost looks like UDP packets are getting
lost or trashed sporadically.
So many people are running Multinet links now - does anybody else have
this problem? Has anybody figured out the cause or a fix?
I've seen them quite a few times, but I don't know why or how to cure them.
Chrissie
Circuit TCP-0-51, Adjacent node = 5.10 (MICRO1)
In this case it was node 51.10 but it's not unique to that machine - I've
seen the same problem from time to time on the other links as well.
It's always a transient problem; the link comes back up on its own in a
minute or so. It seems to come in "clusters" - I'll get a whole bunch of
these errors logged one afternoon, and then everything will be stable for a
day. It's not always an "unexpected packet type" error; sometimes it'll just
be a "listener receive timeout" instead.
Given that Multinet uses UDP it almost looks like UDP packets are getting
lost or trashed sporadically.
So many people are running Multinet links now - does anybody else have
this problem? Has anybody figured out the cause or a fix?
Bob
batch printing by automating turning on the printer once a day, clearing
the print queue, and then turning the printer off. I've got the facility
to programmatically turn the power on and off. The printer would be
connected to a DECserver 90M.
Any ideas?
Regards, Mark
----Originalmeddelande----
Fr n:hvlems at zonnet.nl
S nt: 2011.12.31, 17.09
Till:hecnet at Update.UU.SE
mne:[HECnet] excel files
Some mailboxes cannot handle the size of the spreadsheet files.
They are now also on OZON::
Hans
Hops
SOL (59.10) =>NI-0-0 / QNA-0 <= STUPI (59.58) 8.50 -1
-1
4.27
STUPI (59.58) =>TCP-0-1 / TCP-0-59<= GORVAX (8.400) 2.52 -1
-1
1.34
GORVAX (8.400) =>TCP-0-2 / TCP-0-8 <= LEGATO (2.1) 4.52 -1
-1
2.40
How come STUPI is talking to LEGATO via GORVAX, when STUPI has a direct
Multinet connection to LEGATO? It could have done it in one hop, and
instead it chose two.
Answer: because the circuit costs are screwed up. With redundant paths
you have to be really careful about how you set your circuit costs in order
to get the routings that you want; otherwise you'll get foolish results like
this.
In this case it's the received metric. But, we got redundancy, just
not optimal routng..-:)
Setting the metrics in Hecnet is a bit tricky, as the "ethernet
bridges" are invisible to DECnet routing.
Here is a suggestion....
Set all multinet links to metric 5 in both ends.
Set all bridged ethnert interfacec to 10
??
The NETPTH executable you have runs on 36 bit machines?
Yeppp...
It's really a shame that there's not a VAX version.
But it just does a buch of NML show;s and matches the links...
-P
Hops
SOL (59.10) =>NI-0-0 / QNA-0 <= STUPI (59.58) 8.50 -1
-1
4.27
STUPI (59.58) =>TCP-0-1 / TCP-0-59<= GORVAX (8.400) 2.52 -1
-1
1.34
GORVAX (8.400) =>TCP-0-2 / TCP-0-8 <= LEGATO (2.1) 4.52 -1
-1
2.40
How come STUPI is talking to LEGATO via GORVAX, when STUPI has a direct
Multinet connection to LEGATO? It could have done it in one hop, and
instead it chose two.
Answer: because the circuit costs are screwed up. With redundant paths
you have to be really careful about how you set your circuit costs in order
to get the routings that you want; otherwise you'll get foolish results like
this.
The NETPTH executable you have runs on 36 bit machines? It's really a
shame that there's not a VAX version.
Bob
