On Sun, 25 May 2014, Cory Smelosky wrote:
Okay. Copied!
However...
NTL -- Config File -- Partition GEN Too Fragmented
PAR$DF ,GEN,15.,TOP,2.,12.
NCP -- Set failed, operation failure
Network Initializer function failed
It seems its a big too big. :(
It'd be nice if bigger memory boards on ebay weren't $250. :(
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Oh, right. Now I remember. Maybe I'll have some time later this week. I'll let you know.
-brian
On May 25, 2014, at 15:21, Cory Smelosky <b4 at gewt.net> wrote:
On Sun, 25 May 2014, Brian Hechinger wrote:
On Sun, May 25, 2014 at 11:56:20PM +0800, Tim Sneddon wrote:
Thanks for the mention Brian. Yes, I am happy to help out. I'm not sure
what is going on with Cory's tunnel to you, but I certainly have mine
working:
a12rtr#show decnet neigh
Net Node Interface MAC address Flags
0 9.1023 Tunnel52 0000.0000.0000 A
I have compared our tunnel configs and they are both the same, so I'm
guessing it is a Cory's end.
Cory, let me know if you want some help fixing this, although it seems your
up to your eyeballs in it with your 11/23+.
The issue isn't tunnels, exactly. It's the fact that I currently can't
contact Cory's router via SNMP to push the new config to. This doesn't
affect people like you who's tunnel config is still correct but does
affect someone like me who's IP has changed so Cory's router can no
longer talk to me. And I can't update it because his router refuses to
talk to me. :)
Oh, SNMP push works. TFTP doesn't.
-brian
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
From the VMS log on LEGATO -
%%%%%%%%%%% OPCOM 25-MAY-2014 14:01:52.62 %%%%%%%%%%%
Message from user DECNET on LEGATO
DECnet event 4.18, adjacency down
Okay. Copied!
However...
NTL -- Config File -- Partition GEN Too Fragmented
PAR$DF ,GEN,15.,TOP,2.,12.
NCP -- Set failed, operation failure
Network Initializer function failed
It seems its a big too big. :(
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
At 8:27 PM +0200 25/5/14, Johnny Billquist wrote:
More interesting would be to see EXEC COUNTERS, as well as counters for the two nodes, from both sides.
Full story:
-----------------------
NCP SHO EXE COUNT
Node counters as of 30-MAR-82 00:20:53
Executor node = 10.1 (SHARK)
0 Buffer unavailable
0 Peak logical links active
0 Aged packet loss
0 Node unreachable packet loss
0 Node out-of-range packet loss
0 Oversized packet loss
0 Packet format error
0 Partial routing update loss
0 Verification reject
NCP SHO LINE QNA-0 COUNT
Line counters as of 30-MAR-82 00:20:56
Line = QNA-0
1242 Seconds since last zeroed
5309886 Bytes received
270380 Bytes sent
73284 Multicast bytes received
13435 Data blocks received
6356 Data blocks sent
240 Multicast blocks received
0 Blocks sent, single collision
0 Blocks sent, multiple collision
0 Send failure
0 Collision detect check failure
0 Receive failure
1 Unrecognized frame destination
23 Data overrun
0 System buffer unavailable
-----------------------
NCP SHO EXE COUNT
Node counters as of 30-MAR-82 00:20:56
Executor node = 10.2 (SNAKE)
0 Buffer unavailable
0 Peak logical links active
0 Aged packet loss
0 Node unreachable packet loss
0 Node out-of-range packet loss
0 Oversized packet loss
0 Packet format error
0 Partial routing update loss
0 Verification reject
NCP SHO LINE QNA-0 COUNT
Line counters as of 30-MAR-82 00:20:59
Line = QNA-0
1244 Seconds since last zeroed
359441 Bytes received
5259859 Bytes sent
73238 Multicast bytes received
6352 Data blocks received
13533 Data blocks sent
239 Multicast blocks received
0 Blocks sent, single collision
0 Blocks sent, multiple collision
0 Send failure
0 Collision detect check failure
0 Receive failure
0 Unrecognized frame destination
0 Data overrun
0 System buffer unavailable
-----------------------
10.1 runs NFT.
10.2 runs FAL.
--
Jean-Yves Bernier
On Sun, 25 May 2014, Brian Hechinger wrote:
The issue isn't tunnels, exactly. It's the fact that I currently can't
contact Cory's router via SNMP to push the new config to. This doesn't
affect people like you who's tunnel config is still correct but does
affect someone like me who's IP has changed so Cory's router can no
longer talk to me. And I can't update it because his router refuses to
talk to me. :)
-brian
I should have Mark in my config now. He shows in a neighbour list.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
It's fixed, thanks Johnny
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Johnny Billquist
Verzonden: zondag 25 mei 2014 20:23
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] bridge problem area 44
On 2014-05-25 20:16, Hans Vlems wrote:
My bridge program no longer connects to the other end. Did something change?
I had some issues about a week ago where it seemed your end was going
yo-yo all the time, so I disabled it to test things. Forgot to turn it
back on. Fixed now.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Sun, 25 May 2014, Dave McGuire wrote:
On 05/25/2014 10:10 AM, Cory Smelosky wrote:
Got bored of copying stuff using (virtual) serial, eh? ;)
Get an M+ system with split I/D space, and use my TCP/IP instead... :-)
If all goes well whenever Dave heads out this way he'll be dropping off
some -11s that HOPEFULLY have split I&D.
I peeked into the side vents of one of them; it has a J11 of some
sort, so you should be good there!
Sweet!
-Dave
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Sun, 25 May 2014, Brian Hechinger wrote:
On Sun, May 25, 2014 at 11:56:20PM +0800, Tim Sneddon wrote:
Thanks for the mention Brian. Yes, I am happy to help out. I'm not sure
what is going on with Cory's tunnel to you, but I certainly have mine
working:
a12rtr#show decnet neigh
Net Node Interface MAC address Flags
0 9.1023 Tunnel52 0000.0000.0000 A
I have compared our tunnel configs and they are both the same, so I'm
guessing it is a Cory's end.
Cory, let me know if you want some help fixing this, although it seems your
up to your eyeballs in it with your 11/23+.
The issue isn't tunnels, exactly. It's the fact that I currently can't
contact Cory's router via SNMP to push the new config to. This doesn't
affect people like you who's tunnel config is still correct but does
affect someone like me who's IP has changed so Cory's router can no
longer talk to me. And I can't update it because his router refuses to
talk to me. :)
Oh, SNMP push works. TFTP doesn't.
-brian
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 05/25/2014 01:13 PM, Johnny Billquist wrote:
Essentially, the MAC address in the actual ethernet controller (or the
MAC address set before boot in simh) is irrelevant. Once DECnet starts
running, that MAC address is not used anymore. It is just a trivia piece
of information so that you can know what the hardware MAC address from
the factory is. It is not used by anything, especially not anything
related to network communication.
The only reason I might find the actual hard-coded MAC address to be
useful is in identifying machines. A lot of Ethernet cabinet kits have
stickers on them with the MAC address printed on them.
Of course nearly every one I've seen has been WRONG, but.. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 05/25/2014 10:10 AM, Cory Smelosky wrote:
Got bored of copying stuff using (virtual) serial, eh? ;)
Get an M+ system with split I/D space, and use my TCP/IP instead... :-)
If all goes well whenever Dave heads out this way he'll be dropping off
some -11s that HOPEFULLY have split I&D.
I peeked into the side vents of one of them; it has a J11 of some
sort, so you should be good there!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2014-05-25 20:22, Jean-Yves Bernier wrote:
At 4:05 PM +0200 25/5/14, Johnny Billquist wrote:
Like I said before. I would start by examining various counters on the
machines to
get more understanding of what the problem is, and then try to solve
it from there.
I know that different network interface speeds mess things up, for
example, and I
have code in my bridge to help get around the problem if the bridge is
sitting
between the systems.
and you would see
49 Data overrun
and growing.
This is on the node running NFT, not FAL.
The plot narrows.
For completeness (feeding Google) : 2 11M+ DECnet nodes running inside
simh inside a same instance of a VirtualBox Linux machine.
More interesting would be to see EXEC COUNTERS, as well as counters for the two nodes, from both sides.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2014-05-25 20:16, Hans Vlems wrote:
My bridge program no longer connects to the other end. Did something change?
I had some issues about a week ago where it seemed your end was going yo-yo all the time, so I disabled it to test things. Forgot to turn it back on. Fixed now.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
At 4:05 PM +0200 25/5/14, Johnny Billquist wrote:
Like I said before. I would start by examining various counters on the machines to
get more understanding of what the problem is, and then try to solve it from there.
I know that different network interface speeds mess things up, for example, and I
have code in my bridge to help get around the problem if the bridge is sitting
between the systems.
and you would see
49 Data overrun
and growing.
This is on the node running NFT, not FAL.
The plot narrows.
For completeness (feeding Google) : 2 11M+ DECnet nodes running inside simh inside a same instance of a VirtualBox Linux machine.
--
Jean-Yves Bernier
Sounds like a good idea. Probably takes less time to do than what I suggested.
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Jean-Yves Bernier
Verzonden: zondag 25 mei 2014 19:40
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Same MAC address on different nodes
At 7:04 PM +0200 25/5/14, Hans Vlems wrote:
Anyway, i'd stop using the same 08-00-2B address on two nodes,
shutdown the simulators the VM host and the real iron.
I have another idea waiting in the queue : virtualize a second NIC
and have each node have it's own. Bridge the virtual NIC's with real
ones, so they communicate over wire.
10.1 -> AA-00-04-00-01-28 -> 08:00:27:DA:68:3D en0 Linux <-> en0 MacPro
10.2 -> AA-00-04-00-02-28 -> 08:00:27:A9:51:87 en1 Linux <-> en1 MacPro
--
Jean-Yves Bernier
On 26 May 2014 01:38, Brian Hechinger <wonko at 4amlunch.net> wrote: > > On Sun, May 25, 2014 at 11:56:20PM +0800, Tim Sneddon wrote: > > > > Thanks for the mention Brian. Yes, I am happy to help out. I'm not sure > > what is going on with Cory's tunnel to you, but I certainly have mine > > working: > > > > a12rtr#show decnet neigh > > Net Node Interface MAC address Flags > > 0 9.1023 Tunnel52 0000.0000.0000 A > > > > I have compared our tunnel configs and they are both the same, so I'm > > guessing it is a Cory's end. > > > > Cory, let me know if you want some help fixing this, although it seems your > > up to your eyeballs in it with your 11/23+. > > The issue isn't tunnels, exactly. It's the fact that I currently can't > contact Cory's router via SNMP to push the new config to. This doesn't > affect people like you who's tunnel config is still correct but does > affect someone like me who's IP has changed so Cory's router can no > longer talk to me. And I can't update it because his router refuses to > talk to me. :)
Of course, silly me. I forgot your IP had changed recently.
Regards, Tim.
At 7:04 PM +0200 25/5/14, Hans Vlems wrote:
Anyway, i'd stop using the same 08-00-2B address on two nodes, shutdown the simulators the VM host and the real iron.
I have another idea waiting in the queue : virtualize a second NIC and have each node have it's own. Bridge the virtual NIC's with real ones, so they communicate over wire.
10.1 -> AA-00-04-00-01-28 -> 08:00:27:DA:68:3D en0 Linux <-> en0 MacPro
10.2 -> AA-00-04-00-02-28 -> 08:00:27:A9:51:87 en1 Linux <-> en1 MacPro
--
Jean-Yves Bernier
On Sun, May 25, 2014 at 11:56:20PM +0800, Tim Sneddon wrote:
Thanks for the mention Brian. Yes, I am happy to help out. I'm not sure
what is going on with Cory's tunnel to you, but I certainly have mine
working:
a12rtr#show decnet neigh
Net Node Interface MAC address Flags
0 9.1023 Tunnel52 0000.0000.0000 A
I have compared our tunnel configs and they are both the same, so I'm
guessing it is a Cory's end.
Cory, let me know if you want some help fixing this, although it seems your
up to your eyeballs in it with your 11/23+.
The issue isn't tunnels, exactly. It's the fact that I currently can't
contact Cory's router via SNMP to push the new config to. This doesn't
affect people like you who's tunnel config is still correct but does
affect someone like me who's IP has changed so Cory's router can no
longer talk to me. And I can't update it because his router refuses to
talk to me. :)
-brian
On 2014-05-25 19:04, Hans Vlems wrote:
You are absolutely correct, however what you see happening is strange.
The fact that performance sometimes sucks? It is not that strange. As I have mentioned a few times, DECnet do *not* handle lots of lost packets very well. It will degrade to horrendous performance.
This is easy to observe, if you have the right equipment around.
OK, I got the OS wrong. Because VMS and RT-11 are all I need :-)
:-)
That said, it should work. I'm not sure how RSX handled area routing but 30 years ago we were warned to configure endnodes because ALL the overhead incurred by circuit routers...
Huh? With ethernet, communication with adjacent nodes works without involving any routers anyway. And if you need to talk with anything beyond, you're going to go through the router on the way there anyway.
Really, unless you actually have several interfaces, there is no gain in running a router compared to an endnode. However, running a router definitely use up more resources, which is a disadvantage.
Anyway, i'd stop using the same 08-00-2B address on two nodes, shutdown the simulators the VM host and the real iron.
Would still not make any difference, which I have pointed out several times now, and also what Jean-Yves have been observing the last two days.
Really. There is no black magic here. I can explain every bit of it if someone needs more convincing.
Essentially, the MAC address in the actual ethernet controller (or the MAC address set before boot in simh) is irrelevant. Once DECnet starts running, that MAC address is not used anymore. It is just a trivia piece of information so that you can know what the hardware MAC address from the factory is. It is not used by anything, especially not anything related to network communication.
The VM host in turn cares even less, since whatever MAC address simh plays around with is fully local to simh, and does not affect the VM host.
Any questions?
Johnny
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Jean-Yves Bernier
Verzonden: zondag 25 mei 2014 18:47
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Same MAC address on different nodes
At 6:27 PM +0200 25/5/14, Hans Vlems wrote:
My apologies, it's been too long to remember rsx. A netgen is too
much work for an experiment.
No need to apologize :)
Background for the request: I had problems running two area routers
on the same lan, though just one was simh based. Both were VMS
though.
By running complex software under emulation, we take risks that
things don't work as expected. By adding a layer more with
virtualization, I take still more risks. What is amazing is that it
works most of the time.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
BTW is it possible to transfer one simulated system to another hardware host?
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Jean-Yves Bernier
Verzonden: zondag 25 mei 2014 18:47
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Same MAC address on different nodes
At 6:27 PM +0200 25/5/14, Hans Vlems wrote:
My apologies, it's been too long to remember rsx. A netgen is too
much work for an experiment.
No need to apologize :)
Background for the request: I had problems running two area routers
on the same lan, though just one was simh based. Both were VMS
though.
By running complex software under emulation, we take risks that
things don't work as expected. By adding a layer more with
virtualization, I take still more risks. What is amazing is that it
works most of the time.
--
Jean-Yves Bernier
You are absolutely correct, however what you see happening is strange.
OK, I got the OS wrong. Because VMS and RT-11 are all I need :-)
That said, it should work. I'm not sure how RSX handled area routing but 30 years ago we were warned to configure endnodes because ALL the overhead incurred by circuit routers...
Anyway, i'd stop using the same 08-00-2B address on two nodes, shutdown the simulators the VM host and the real iron.
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Jean-Yves Bernier
Verzonden: zondag 25 mei 2014 18:47
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Same MAC address on different nodes
At 6:27 PM +0200 25/5/14, Hans Vlems wrote:
My apologies, it's been too long to remember rsx. A netgen is too
much work for an experiment.
No need to apologize :)
Background for the request: I had problems running two area routers
on the same lan, though just one was simh based. Both were VMS
though.
By running complex software under emulation, we take risks that
things don't work as expected. By adding a layer more with
virtualization, I take still more risks. What is amazing is that it
works most of the time.
--
Jean-Yves Bernier
At 6:27 PM +0200 25/5/14, Hans Vlems wrote:
My apologies, it's been too long to remember rsx. A netgen is too much work for an experiment.
No need to apologize :)
Background for the request: I had problems running two area routers on the same lan, though just one was simh based. Both were VMS though.
By running complex software under emulation, we take risks that things don't work as expected. By adding a layer more with virtualization, I take still more risks. What is amazing is that it works most of the time.
--
Jean-Yves Bernier
Tim,
I need to check tomorrow. The IP you have for me is correct.
I have recently rebuilt my router config so there is no firewall, there are some primitive access lists and these may be hampering things.
Mark
On 25 May 2014, at 17:26, Tim Sneddon <tim at sneddon.id.au> wrote:
On Mon, May 26, 2014 at 12:00 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Brian,
Have seen the latest configs have been pushed through.
My router seems to be up
cmrtr01#show decnet neigh
Net Node Interface MAC address Flags
0 9.1023 Tunnel52 0000.0000.0000 A
Hi Mark,
I can't see your network on my router:
a12rtr#show decnet neigh
Net Node Interface MAC address Flags
0 9.1023 Tunnel52 0000.0000.0000 A
0 23.1023 Tunnel59 0000.0000.0000 A
0 42.1022 Tunnel51 0000.0000.0000 A
0 52.1023 Tunnel50 0000.0000.0000 A
0 61.1023 Tunnel53 0000.0000.0000 A
0 12.2 FastEthernet0/0 aa00.0400.0230
Are you running a firewall or access lists on incoming connections? The destination IP on my tunnel to you is 81.142.27.37. Is that correct?
Regards, Tim.
My apologies, it's been too long to remember rsx. A netgen is too much work for an experiment.
Background for the request: I had problems running two area routers on the same lan, though just one was simh based. Both were VMS though.
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Jean-Yves Bernier
Verzonden: zondag 25 mei 2014 18:14
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Same MAC address on different nodes
At 5:52 PM +0200 25/5/14, Hans Vlems wrote:
Mc ncp Def exec type endnode
NCP>SET EXEC TYPE ENDNODE
SET EXEC TYPE ENDNODE>>
NCP -- Set not accepted, invalid parameter value, Type
NCP>HELP SET EXEC
Use the SET EXECUTOR command to create or modify executor node parameters.
The format is:
SET EXECUTOR parameters
Parameter types are ALL or one or more of:
DTE HOST STATE
NODE INCOMING TIMER OUTGOING TIMER
INACTIVITY TIMER RETRANSMIT FACTOR ROUTING TIMER
SEGMENT BUFFER SIZE RECEIVE PASSWORD TRANSMIT PASSWORD
VERIFICATION [STATE] CONFIDENCE TIMER MAXIMUM PATH SPLITS
INCOMING PROXY OUTGOING PROXY
Trying CFE.
CFE
Enter filename: LB:[5,54]CETAB.MAC
CFE>HELP DEF EXEC
Use the DEFINE EXECUTOR command to establish executor node parameters.
The format is:
DEFINE EXECUTOR parameters
Parameter types are:
ADDRESS BROADCAST ROUTING TIMER HOST
IDENTIFICATION MAXIMUM ADDRESS MAXIMUM BROADCAST ENDNODES
MAXIMUM COST MAXIMUM HOPS MAXIMUM LINKS
MAXIMUM NODE COUNTERS NAME ROUTING TIMER
SEGMENT BUFFER SIZE VERIFICATION STATE CONFIDENCE TIMER
INCOMING PROXY OUTGOING PROXY MAXIMUM PATH SPLITS
No way to SET/DEF EXEC ENDNODE.
Both nodes have licenses for DECnet installed?
Did not know DECnet used DRM.
--
Jean-Yves Bernier
