HECnet June 2012

hecnet@lists.dfupdate.se

38 participants
612 discussions

by jeep＠scshome.net

I see these message about every 20 minutes from random nodes. The error message is almost always: "Unexpected packet type" So where do we go from here? -Steve -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Saturday, June 09, 2012 01:15 To: hecnet at Update.UU.SE Subject: Re: [HECnet] netowrk flapping.... On 2012-06-09 07:06, Peter Lothberg wrote: We (all of us with Multinet, I think) see this problem occasionally. AFAIK no one has come up with an adequate explanation, let alone a solution. Let's figure it out. It hapens more or less exaclty every 10 minutes. You can always turn off logging if it bothers you :-) Bob, If someone trying to use the link, they will be unhappy.. (In internet backboone between core routers at 10G or 40G or 100G we started to troubleshoot if the error rate got over 1x10-e13 for a single hop...) I agree. If something is telling you that there is a problem, you should fix the problem, not silence the information. Johnny

12 years, 12 months

netowrk flapping....

by bqt＠softjar.se

On 2012-06-09 07:06, Peter Lothberg wrote: We (all of us with Multinet, I think) see this problem occasionally. AFAIK no one has come up with an adequate explanation, let alone a solution. Let's figure it out. It hapens more or less exaclty every 10 minutes. You can always turn off logging if it bothers you :-) Bob, If someone trying to use the link, they will be unhappy.. (In internet backboone between core routers at 10G or 40G or 100G we started to troubleshoot if the error rate got over 1x10-e13 for a single hop...) I agree. If something is telling you that there is a problem, you should fix the problem, not silence the information. Johnny

12 years, 12 months

netowrk flapping....

by roll＠Stupi.SE

We (all of us with Multinet, I think) see this problem occasionally. AFAIK no one has come up with an adequate explanation, let alone a solution. Let's figure it out. It hapens more or less exaclty every 10 minutes. You can always turn off logging if it bothers you :-) Bob, If someone trying to use the link, they will be unhappy.. (In internet backboone between core routers at 10G or 40G or 100G we started to troubleshoot if the error rate got over 1x10-e13 for a single hop...) --Peter

12 years, 12 months

Introducing myself... and my little network

by roll＠Stupi.SE

1) Defining the permanent node database for both TOPS10 and TOPS20. NCP rejects the DEFINE NODE commands. I guess there is some sort of utility like the one in RSX (CFE) to define the "permanent" node list, but I've not been able to find that one. There is a NIPGEN in TOPS-10 to build a CMD file with the SET NODE commands, but no NIPGEN in TOPS-20 that I've been able to find... T10/T20 has no permanent database, nor does it understand copy, look for a program named nodnam.exe it reads ini:NODNAM.INI and populated the node-name-table.. And nodnam.ini looks like this... define node 1.42 name BIGBOA define node 1.100 name FLETCH define node 1.150 name GLGMSH define node 1.200 name PLINTH define node 1.201 name CRISPS define node 1.202 name NIPPER define node 1.301 name CTEPBA define node 1.302 name XPEH 2) LAT. LAT works fine in TOPS-20. In TOPS-10 LCP tells me LAT is active, but it does not work (does not even announce itself). How do I enable LAT in TOPS-10? Don't knew. 3) And, spealking of LAT... How do I change the service identification in TOPS-20? What do you mean with service identification? The stuff in "sh exec char?" I mean, how do I change it PERMANENTLY? I guess I have to put it in some sort of auto-executing file. SYSTEM.CMD? Something in 7-1-CONFIG.CMD? Again, any pointer to docs would be very appreciated. I don't want to bug you with the thousands of questions I've got :) Right There is nothing permanent, unless you poke it in to the monitr.exe file.... Here's what's on SOL.. type 7-PTYCON.ATO SILENCE NO LOG DEFINE 0 OPR CONN OPR LOGIN OPERATOR FOO OPERATOR OPR TAKE SYSTEM:SYSTEM TAKE SYSTEM:NCP EXIT ;DEFINE SYSTEM: PS:<NEW-SYSTEM>,PS:<SYSTEM> ;SYSTEM:EXEC ^ESET LOGIN ANY ;POP OPR TAKE SYSTEM:UPMSG EXIT LOGOUT ^X EXIT $ type SYSTEM:NCP.CMD ENTER NCP SET KNOWN LOGGING STATE OFF SET EXECUTOR ID "SC40M, Stupi Stockholm, Tops20" SET KNOWN CIRCUIT ROUTER PRIORITY 10 SET CIRCUIT NI-0-0 STATE ON SET CIRCUIT NI-0-0 SERVICE ENABLED SET CIRCUIT CI-0-0.14 STATE ON SET CIRCUIT CI-0-0.15 STATE ON ;SET MODULE X25-ACCESS NODE SCMV1 NETWORK TELENET RETURN $

12 years, 12 months

Introducing myself... and my little network

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Bob Armstrong Sent: 08 June 2012 23:58 To: hecnet at Update.UU.SE Subject: RE: [HECnet] Introducing myself... and my little network On 06/08/2012 03:53 PM, Rob Jarratt wrote: I was once told that a TF series drive might be able to read past the error, but that TKs won't. FWIW, The TFxx drives have DSSI interfaces. The TZ drives are SCSI (e.g. TZ85 or TZ87). The TK drives (TK50, TK70) have DEC proprietary interfaces. A TF8x drive isn't going to do you any good unless you have a MicroVAX with a DSSI controller - Yes, I have two machines with DSSI. a TZ8x drive can at least be connected to any VAX or PDP with SCSI. AFAIK there isn't any difference, other than the interface, between a TF85 and a TZ85, or a TF87 vs TZ87. I don't think there's such a thing as a TK85 or TK87 - DEC dropped the proprietary interface after the TK70s. And I don't think there were any DSSI drives after the TF87. I know I have a TZ85 or TZ87 (maybe even both) somewhere but whether it's any better at reading bad TK50s I won't even speculate. BTW, If anybody has a TF drive that they'd like to swap for a TZ, let me know. I've got a rack of DSSI drives (RF7x and RF3x) that'd love to have a little tape drive for a cousin :-) I too would like to find any TF or RF drives, also would like to find a KFQSA so I can try out my KA655 CPUs. Regards Rob

13 years

Introducing myself... and my little network

by bob＠jfcl.com

On 06/08/2012 03:53 PM, Rob Jarratt wrote: I was once told that a TF series drive might be able to read past the error, but that TKs won't. FWIW, The TFxx drives have DSSI interfaces. The TZ drives are SCSI (e.g. TZ85 or TZ87). The TK drives (TK50, TK70) have DEC proprietary interfaces. A TF8x drive isn't going to do you any good unless you have a MicroVAX with a DSSI controller - a TZ8x drive can at least be connected to any VAX or PDP with SCSI. AFAIK there isn't any difference, other than the interface, between a TF85 and a TZ85, or a TF87 vs TZ87. I don't think there's such a thing as a TK85 or TK87 - DEC dropped the proprietary interface after the TK70s. And I don't think there were any DSSI drives after the TF87. I know I have a TZ85 or TZ87 (maybe even both) somewhere but whether it's any better at reading bad TK50s I won't even speculate. BTW, If anybody has a TF drive that they'd like to swap for a TZ, let me know. I've got a rack of DSSI drives (RF7x and RF3x) that'd love to have a little tape drive for a cousin :-) Bob

13 years

Introducing myself... and my little network

by mcguire＠neurotica.com

On 06/08/2012 03:53 PM, Rob Jarratt wrote: I have a TK50 cartridge that I have been trying to read for some time, it keeps failing at a single point. I was once told that a TF series drive might be able to read past the error, but that TKs won't. I don't know how much truth there might be to it, but I have been trying to find a TF drive for a long time, they just don't seem to come up. Are they as rare as they seem? I didn't think they were all that rare, but now that you mention it, I have seen many more TK50s and TK70s than Tx85 drives. Not sure why. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 22:07, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 3:36 PM, Johnny Billquist wrote: On 2012-06-08 21:28, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 3:18 PM, Johnny Billquist wrote: ... If you don't need 16 distinct values, you simply pad the table with extra copies of any of the meaningful values; that way the result is what you want. The easiest way to do that is to make extra copies of the entry that specifies the MAC address, but that isn't necessary, it is mentioned only because it's easy to remember. Right. But there are some interesting passages in the manual. " More than one physical address may be specified, but in Normal mode, only the first is used for receiving datagrams, and as the source address for system ID messages generated by the DELQA. In DEQNA-lock mode the specifications of multiple physical Ethernet addesses will cause the DELQA to filter all such physical Ethernet addesses for packet reception. NOTE Enabling more than one physical address is not recommended under normal circumstances. This may have a substantial impact on performance. " What do you make of that? Johnny Hm. I wonder if the LQA uses a chip that doesn't natively support multiple MAC addresses (LANCE is one such, I think). If so, it would mean that it would have to emulate this QNA feature by setting promiscuous mode on that chip and doing the 16-entry exact filtering in firmware. Well, we *know* that the LQA uses the LANCE, so I guess that answers that question. Sounds reasonable that the LQA emulates the QNA by always placing the ethernet in promiscuous mode, if the QNA works the way you describe. Bummer. That would imply that QNA actually has some benefits over LQA, which I didn't expect. :-) I wonder if "substantial" is actually true. As I mentioned, the multiple individual address feature was introduced to allow LAT not to be broken by DECnet startup, so any OS that starts LAT before DECnet (VMS is one such, I think) would end up with multiple MAC addresses. And since the main reason for LQA was to make Local Area VAXclusters work right, one would assume the performance impact from this mode is not that high, since clusters are rather picky about performance issues. Thinking about it, in combination with what you wrote, I'd say yes, if you really put several physical addresses in the table. However, a) I don't expect VMS to run a LQA in QNA mode when it can perform much better in LQA mode, and b) I don't expect (even on VMS) that LAT is started before DECnet, or that LAT would not survive a change of MAC address after the start. I know that normally I always start LAT after DECnet on my VMS boxen, but on the other hand, there is no place in the provided templates where LAT is started, so it could go anywhere. Johnny

13 years

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by Paul_Koning＠Dell.com

On Jun 8, 2012, at 3:36 PM, Johnny Billquist wrote: On 2012-06-08 21:28, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 3:18 PM, Johnny Billquist wrote: ... If you don't need 16 distinct values, you simply pad the table with extra copies of any of the meaningful values; that way the result is what you want. The easiest way to do that is to make extra copies of the entry that specifies the MAC address, but that isn't necessary, it is mentioned only because it's easy to remember. Right. But there are some interesting passages in the manual. " More than one physical address may be specified, but in Normal mode, only the first is used for receiving datagrams, and as the source address for system ID messages generated by the DELQA. In DEQNA-lock mode the specifications of multiple physical Ethernet addesses will cause the DELQA to filter all such physical Ethernet addesses for packet reception. NOTE Enabling more than one physical address is not recommended under normal circumstances. This may have a substantial impact on performance. " What do you make of that? Johnny Hm. I wonder if the LQA uses a chip that doesn't natively support multiple MAC addresses (LANCE is one such, I think). If so, it would mean that it would have to emulate this QNA feature by setting promiscuous mode on that chip and doing the 16-entry exact filtering in firmware. Bummer. That would imply that QNA actually has some benefits over LQA, which I didn't expect. I wonder if "substantial" is actually true. As I mentioned, the multiple individual address feature was introduced to allow LAT not to be broken by DECnet startup, so any OS that starts LAT before DECnet (VMS is one such, I think) would end up with multiple MAC addresses. And since the main reason for LQA was to make Local Area VAXclusters work right, one would assume the performance impact from this mode is not that high, since clusters are rather picky about performance issues. paul

13 years

Introducing myself... and my little network

by robert.jarratt＠ntlworld.com

I have a TK50 cartridge that I have been trying to read for some time, it keeps failing at a single point. I was once told that a TF series drive might be able to read past the error, but that TKs won't. I don't know how much truth there might be to it, but I have been trying to find a TF drive for a long time, they just don't seem to come up. Are they as rare as they seem? Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Dave McGuire Sent: 08 June 2012 08:57 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Introducing myself... and my little network On 06/08/2012 03:55 AM, Johnny Billquist wrote: I haven't tried cleaning TK50 heads in years, but I will (now that I have a more respectable workspace) start trying that. I will let you know how things go. I'll probably start digging into those within the next month or two. Thank you for the suggestion! I take it TK50 tapes won't read in a later drive? They will. TK70 and TK85 (if I remember right) can both read TK50. You also have the TZ30 (I think the name is), which is a TK50 compatible, but smaller drive, with SCSI. The TK85 can read TK50s? I didn't know that! If that's the case, it's likely that the TF85 (DSSI version) may as well, and I have one of those. That may be one more option to get my huge pile of TK50s read. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years

← Newer
1
...
27
28
29
30
31
32
33
...
62
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet June 2012