noise...
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Bob Armstrong
Sent: Thu 1/5/2012 12:22
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Multinet circuit costs
And now I'm seeing quite a bit more traffic on my router!
Is that good or bad??
Bob
Routing priority doesn't affect the selection of the active area router if more than one exists in an area. The only arbitration is node address : highest address wins.
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 06 Jan 2012 00:11:54
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Router for area 1
On 2012-01-05 17.21, Bob Armstrong wrote:
I wrote-
OpenVMS Network status for local node 2.1 LEGATO on 5-JAN-2012
08:11:19.43
Area Cost Hops Next Hop to Area
1 4 1 QNA-1 -> 1.300 CTAKAH
....
It bugs me, although I can't point at an actual problem that it causes,
that the routing node for area 1 is seen as CTAKAH, rather than MIM. Since
CTAKAH is not actually local to Uppsula (I think that's where MIM is) but is
rather at the other end of yet another bridge, this means that any traffic
for area one, no matter what its ultimate destination, has to make an extra
round trip to Russia.
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Nah. MIM have a higher routing priority set. (Unless Oleg Safiulling
have tweaked the routing priority of CTAKAH.) However, you sometimes run
into this issue because there are so many routers on the bridge.
Depending on your configuration, some routers will be ignored, and which
ones seems to be somewhat random. So unfortunately, it can be MIM that
gets tossed, and then it don't matter that MIM have a higher priority.
But yes, CTAKAH do sit in Russia, and it causes packets to travel some
extra time to get to places. But apart from that, it should not ever be
an issue. A slight side effect of the fact that we fake a local ethernet
segment. Had it been a real one, the packets would travel the same on
the local segment, no matter which router was used.
Johnny
Yes I agree that we have a problem. I cannot create the problem between any combination of nodes within my area. The only common factor is that both nodes I cannnot copy from all have a bridge and a tcp tunnel.
I haven't tried Ctakan yet. It's too late now.
Hans
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 06 Jan 2012 00:04:01
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet circuit costs
Ok. So we do have a problem. Time to figure out what it is, then. I can
most definitely say that multiple paths is not the problem. However,
there could be some other problem with some machine/setup/paths/whatever
that is more local to you Hans.
If it works talking to MIM, and you have the bridge running, then it
becomes a question of which machines you have problems talking to, and
we can check at both ends what the next hop is and reason if that is
reasonable and correct.
Johnny
On 2012-01-05 16.40, hvlems at zonnet.nl wrote:
Again, apologies for topposting: my cellphone is somewhat rude...
PST is UTC-8 (unless Bob lives in the Philippines, then it's UTC+8 :).
Yes I have problems wihile copying files from Legato and Star69 to Ozon.
Ozon is the area router for area 44 and uses the bridge software.
I can't access the Hecnet map but Legato has multiple paths and IIRC so does Star.
Ozon has no problem copying files from MIM or MUSIPC and both are connected with single paths (IIRC again).
Reading Bob's analysis I still think that multiple paths may lead to errors. Granted that circuit cost may fix this but right now it is, for me at least, not clear.
The area information in the output of show network/old on Ozon shows all areas and about 40% is more than 1 hop away and seen as reachable thru Legato.
Hans
-----Original Message-----
From: "Bob Armstrong"<bob at jfcl.com>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 5 Jan 2012 07:14:50
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] Multinet circuit costs
Why? What is the percieved problem?
I don't know about area 44, but I was talking to Hans on New Years Eve
about a problem where he could not copy files, while logged in to OZON, from
LEGATO (i.e. a "pull" transaction). According to Hans, it fails with "acp
file or directory lookup failed". If I did the same thing from my end (a
"push") it would start copying and actually create an empty file on OZON,
but then time out after a very long time with
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKABORT, network partner aborted logical link
Last I heard Hans was going to check the NETSERVER/FAL logs on his side for
any error messages, but that was New Years Eve and he was otherwise occupied
:-)
I see this morning that Hans has actually created a file "TARGET.TXT" on
LEGATO (dated 6PM PST on 12/31 even - what time is that in the
Netherlands??) so maybe he's solved the problem. If he did he didn't tell
me what he did.
Hans also mentioned to me that he was having similar problems with the
node STAR69 and CANADA. I think all this came up when Hans was trying to
write his HECnet crawler script to gather INFO.TXT files...
I don't think this is related to the Multinet/Bridge configuration, but I
can't guarantee it. One hidden "gotcha" in DECnet is that the circuit costs
are determined locally, so the routings don't have to be symmetrical (i.e.
the route from A->B might not be the same as the route from B->A).
If somebody (Johnny??) wants to try to figure it out, be my guest -
GUEST/GUEST. I'm a little busy at the moment and don't really have time to
look at it.
Bob
Right. Works fine on RSX too.
You just submit the job for another machine.
Johnny
On 2012-01-05 23.35, Paul_Koning at Dell.com wrote:
DAP support remote queuing, so this should be a standard capability in VMS (and other systems that have the necessary DAP support).
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Wickens
Sent: Thursday, January 05, 2012 5:33 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] Printing across HECnet
Hi guys,
Just wondering whether there is a 'standard' mechanism for queueing print jobs across DECnet areas (for example from an arbitrary node to SLAVE via HECnet)?
I've acquired a PSI PP404 high speed wide carriage printer as well as a large quantity of 11x14 paper, so was wondering if there would be any interest in an 'occasional' printing service for the cost of postage for those who either don't have a printer connected to their DEC machines or more likely who'd like wide continuous listings.
From a VMS perspective I'd need to be able to queue up print jobs for 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
On 2012-01-05 17.21, Bob Armstrong wrote:
I wrote-
OpenVMS Network status for local node 2.1 LEGATO on 5-JAN-2012
08:11:19.43
Area Cost Hops Next Hop to Area
1 4 1 QNA-1 -> 1.300 CTAKAH
....
It bugs me, although I can't point at an actual problem that it causes,
that the routing node for area 1 is seen as CTAKAH, rather than MIM. Since
CTAKAH is not actually local to Uppsula (I think that's where MIM is) but is
rather at the other end of yet another bridge, this means that any traffic
for area one, no matter what its ultimate destination, has to make an extra
round trip to Russia.
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Nah. MIM have a higher routing priority set. (Unless Oleg Safiulling have tweaked the routing priority of CTAKAH.) However, you sometimes run into this issue because there are so many routers on the bridge. Depending on your configuration, some routers will be ignored, and which ones seems to be somewhat random. So unfortunately, it can be MIM that gets tossed, and then it don't matter that MIM have a higher priority.
But yes, CTAKAH do sit in Russia, and it causes packets to travel some extra time to get to places. But apart from that, it should not ever be an issue. A slight side effect of the fact that we fake a local ethernet segment. Had it been a real one, the packets would travel the same on the local segment, no matter which router was used.
Johnny
No. Equal cost paths are valid. DECnet will do one of two things. Either pick one on random (well, there is some algorithm to it, but it don't matter, it will pick one anyway), or if the DECnet is slightly more modern than plain phase IV (it was called phase IV+ if I remember right), then DECnet will do equal path cost splitting. That is, it will use both paths.
Johnny
On 2012-01-05 16.58, Steve Davidson wrote:
The circuit costs here are set to 4 for LAN and 3 for tunnels. The issue may be that if a node (at the end of the chain so to speak) has 2 tunnel links of the same cost and that the final destination costs the same I could see where DECnet *might* get confused. Let's look at the following contrived example:
FRUGAL:: connects to LEGATO:: - cost of 3
FRUGAL:: connects to SG1:: - cost of 3
LEGATO:: connects to GORVAX:: - cost of 3
SG1:: connects to GORVAX:: - cost of 3
Fred, on node FRUGAL:: tries to copy a (large) file from GORVAX:: to FRUGAL:: *may* see some issues. On the other hand if Fred chooses to favor SG1:: over LEGATO:: (cost wise) he should not see any problems: Ex:
FRUGAL:: connects to LEGATO:: - cost of 3
FRUGAL:: connects to SG1:: - cost of 2
The route is guaranteed to be the same for the entire transaction. It will be (using poor man's routing to demonstrate) FRUGAL::SG1::GORVAX:: at a cost of 5, not FRUGAL::LEGATO::GORVAX:: at a cost of 6.
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of hvlems at zonnet.nl
Sent: Thu 1/5/2012 10:43
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet circuit costs
PS
I can copy to Legato alright.
PPS
I did check the netserver.log files and found nothing out of the order.
Ok. So we do have a problem. Time to figure out what it is, then. I can most definitely say that multiple paths is not the problem. However, there could be some other problem with some machine/setup/paths/whatever that is more local to you Hans.
If it works talking to MIM, and you have the bridge running, then it becomes a question of which machines you have problems talking to, and we can check at both ends what the next hop is and reason if that is reasonable and correct.
Johnny
On 2012-01-05 16.40, hvlems at zonnet.nl wrote:
Again, apologies for topposting: my cellphone is somewhat rude...
PST is UTC-8 (unless Bob lives in the Philippines, then it's UTC+8 :).
Yes I have problems wihile copying files from Legato and Star69 to Ozon.
Ozon is the area router for area 44 and uses the bridge software.
I can't access the Hecnet map but Legato has multiple paths and IIRC so does Star.
Ozon has no problem copying files from MIM or MUSIPC and both are connected with single paths (IIRC again).
Reading Bob's analysis I still think that multiple paths may lead to errors. Granted that circuit cost may fix this but right now it is, for me at least, not clear.
The area information in the output of show network/old on Ozon shows all areas and about 40% is more than 1 hop away and seen as reachable thru Legato.
Hans
-----Original Message-----
From: "Bob Armstrong"<bob at jfcl.com>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 5 Jan 2012 07:14:50
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] Multinet circuit costs
Why? What is the percieved problem?
I don't know about area 44, but I was talking to Hans on New Years Eve
about a problem where he could not copy files, while logged in to OZON, from
LEGATO (i.e. a "pull" transaction). According to Hans, it fails with "acp
file or directory lookup failed". If I did the same thing from my end (a
"push") it would start copying and actually create an empty file on OZON,
but then time out after a very long time with
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKABORT, network partner aborted logical link
Last I heard Hans was going to check the NETSERVER/FAL logs on his side for
any error messages, but that was New Years Eve and he was otherwise occupied
:-)
I see this morning that Hans has actually created a file "TARGET.TXT" on
LEGATO (dated 6PM PST on 12/31 even - what time is that in the
Netherlands??) so maybe he's solved the problem. If he did he didn't tell
me what he did.
Hans also mentioned to me that he was having similar problems with the
node STAR69 and CANADA. I think all this came up when Hans was trying to
write his HECnet crawler script to gather INFO.TXT files...
I don't think this is related to the Multinet/Bridge configuration, but I
can't guarantee it. One hidden "gotcha" in DECnet is that the circuit costs
are determined locally, so the routings don't have to be symmetrical (i.e.
the route from A->B might not be the same as the route from B->A).
If somebody (Johnny??) wants to try to figure it out, be my guest -
GUEST/GUEST. I'm a little busy at the moment and don't really have time to
look at it.
Bob
Oleg,
an endnode is fairly ignorant about the area it lives in.
The output of $ SHOW NET /OLD (or just plain $ SHOW NET on older systems)
is a lot more interesting on a level 1 router than on an endnode.
So since the actual overhead is minimal (given available bandwidth today)
why not mc ncp def exec type routing IV in stead?
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Oleg Safiullin
Verzonden: donderdag, januari 2012 17:35
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Router for area 1
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Hmm.
CTAKAH is set to lower router priority than MIM. I thought this is enough to
tell that MIM is preffered router...
There's no need for CTAKAH to be and area router, so I'll downgrade it to
endnode...
On 05/01/12 22:35, Paul_Koning at Dell.com wrote:
DAP support remote queuing, so this should be a standard capability in VMS (and other systems that have the necessary DAP support).
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Wickens
Sent: Thursday, January 05, 2012 5:33 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] Printing across HECnet
Hi guys,
Just wondering whether there is a 'standard' mechanism for queueing print jobs across DECnet areas (for example from an arbitrary node to SLAVE via HECnet)?
I've acquired a PSI PP404 high speed wide carriage printer as well as a large quantity of 11x14 paper, so was wondering if there would be any interest in an 'occasional' printing service for the cost of postage for those who either don't have a printer connected to their DEC machines or more likely who'd like wide continuous listings.
From a VMS perspective I'd need to be able to queue up print jobs for 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
DAP - Data Access Protocol
OK, so I should have googled first! Thanks for the pointers.
Thanks, Mark.
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens Bob
Armstrong
Verzonden: donderdag, januari 2012 17:21
Aan: hecnet at Update.UU.SE
Onderwerp: [HECnet] Router for area 1
I wrote-
OpenVMS Network status for local node 2.1 LEGATO on 5-JAN-2012
08:11:19.43
Area Cost Hops Next Hop to Area
1 4 1 QNA-1 -> 1.300 CTAKAH
....
It bugs me, although I can't point at an actual problem that it causes,
that the routing node for area 1 is seen as CTAKAH, rather than MIM. Since
CTAKAH is not actually local to Uppsula (I think that's where MIM is) but is
rather at the other end of yet another bridge, this means that any traffic
for area one, no matter what its ultimate destination, has to make an extra
round trip to Russia.
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Bob
-------------------------------------------------------------------------
Or make CTAKAH a circuit router since that is all it really does.
The "loops" in the Hecnet topology ought to be avoided but running area
routers where a circuit router would suffice is second on my list of
things I'd prefer to avoid.
Hans
