On 6 Jun 2012, at 22:37, <Paul_Koning at Dell.com> wrote:
On Jun 6, 2012, at 5:34 PM, Johnny Billquist wrote:
On 2012-06-06 22:40, Rob Jarratt wrote:
...
It would be a fun exercise to turn the bridge into an actual DECnet router.
One day, when I have a lot of time I might even think about trying that.
Feel free. The specifications are out there, so it's definitely not an impossible task. But I guess it will take some work. It would be very nice if the bridge did turn into a WAN router...
Johnny
DECnet Phase IV is pretty straightforward. The specs are all out there. And much of it is implemented in Linux, so you can find C sources ready to go... Even if sample code only does L1 routing, you're nearly there because area routing is essentially the same thing done a second time on a second set of tables.
There may be mileage in building dedicated DECnet bridges/routers using RaspberryPi boards in a suitable case running a very cut-down Linux with an advanced version of the bridge? I am no programming wizard but I am good at compiling and testing stuff.
Would it require 2 Ethernet interfaces to work or would (like the bridge) just one work okay?
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On Jun 6, 2012, at 5:34 PM, Johnny Billquist wrote:
On 2012-06-06 22:40, Rob Jarratt wrote:
...
It would be a fun exercise to turn the bridge into an actual DECnet router.
One day, when I have a lot of time I might even think about trying that.
Feel free. The specifications are out there, so it's definitely not an impossible task. But I guess it will take some work. It would be very nice if the bridge did turn into a WAN router...
Johnny
DECnet Phase IV is pretty straightforward. The specs are all out there. And much of it is implemented in Linux, so you can find C sources ready to go... Even if sample code only does L1 routing, you're nearly there because area routing is essentially the same thing done a second time on a second set of tables.
paul
On 2012-06-06 22:40, Rob Jarratt wrote:
No, you have not misunderstood. You are just not getting the full picture.
Yes, the Cisco box will transport the DECnet frames inside something. At
the
bottom there will be IP, but most likely the DECnet frames are actually
sitting
inside UDP...
So what is the difference from the bridge program, you ask.
Well, simple, the bridge program tries to be clever about which frames to
send where, but it cannot be clever enough at times, and also there are
times when it is forced to send traffic that we might want to limit.
The reason is that the bridge is not really a part of the DECnet traffic,
but is
just relaying packets back and forth, making the two ends of the bridge
appear as if they were on the same ethernet segment.
The Cisco box, on the other hand, is a DECnet routing node. It sits on the
ethernet, and participate fully in the DECnet traffic.
Thanks. Now I get it. I didn't know that anyone other than DEC ever made
something that could route actual DECnet and therefore did not realise that
"actual DECnet router" meant "actual DECnet router" :-) Until now I thought
this was something only available in a VMS router node.
VMS not required... MIM is an area router running RSX. :-)
But yeah, "DECnet router" really meant just that.
It would be a fun exercise to turn the bridge into an actual DECnet router.
One day, when I have a lot of time I might even think about trying that.
Feel free. The specifications are out there, so it's definitely not an impossible task. But I guess it will take some work. It would be very nice if the bridge did turn into a WAN router...
Johnny
On 6/6/2012 5:26 AM, Peter Coghlan wrote:
No, you have not misunderstood. You are just not getting the full
picture. Yes, the Cisco box will transport the DECnet frames inside
something. At the bottom there will be IP, but most likely the DECnet
frames are actually sitting inside UDP...
My understanding of it is that GRE is another IP protocol on the same level
as TCP and UDP rather than using UDP.
You are correct. GRE is Layer 4 just like TCP and UDP.
-brian
On 6/4/2012 8:51 PM, Dave McGuire wrote:
On 06/04/2012 12:13 PM, Brian Hechinger wrote:
SIMH 3.9 somehow kernel paniced my solaris server!
Wow.
-brian
ps: it's older solaris, but stil!
Holy cow! I have NEVER seen that happen. (which is why I run it!)
How the heck did you do that?
Built and ran SIMH 3.9
3.8-1 works just fine (it's what i'm running now) and 3.9 runs fine in my sol11 VM.
-brian
On 6/6/2012 9:04 AM, Peter Lothberg wrote:
Could this work in a domestic environment with an ISP that
gives out dynamic IP addresses?
My head hurts.. Ask for a /56 of IPv6 space. -:)
If there are many users that need this, I will look in to it, I thnk
there was magic that could be applied.
On the side with the dhcp address it's simple. You just make the source the actual interface and not an IP.
interface Tunnel0
description Tunnel for DECnet to Dave M.
no ip address
decnet cost 10
tunnel source FastEthernet0/1
tunnel destination 50.73.179.1
tunnel path-mtu-discovery
end
interface FastEthernet0/1
description Internet Connection (Cable Modem)
ip address dhcp
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
end
Now, in my case it's actually a static IP but RCN require me to actually fetch my IP via DHCP or it won't work.
As to how to handle this on the other end, I have no clue. :)
-brian
On 6/6/2012 8:48 AM, Peter Lothberg wrote:
On 2012-06-05 03:50, Peter Lothberg wrote:
For people who don't need LAT and have a Cisco box, this is way better
than the bridge program.
(If you really want LAT with other parts of HECnet, then there is no
alternative to the bridge...)
You can bridge LAT with the cisco box... -:) ((It might even HELP you
with LAT over WAN....)) (And it can act as a LAT termianl server)
Nice. I did not know that. That's even better. Will it just bridge the
protocols you ask for, or will it do them all? Hmm, I assume it's using
GRE for this?
Johnny
I -think- there where special stuff to help with LAT in WAN scenarios,
at some point there might even have been a telnet/lat gw.. I have to
go and refresh my memory..
SuperLAT! It no longer says that in the version banner though.
bart#lat ?
WORD Name of a remote system
bart(config-subif)#lat ?
enabled Enable LAT protocol translation
host Statically define LAT services
-brian
No, you have not misunderstood. You are just not getting the full picture.
Yes, the Cisco box will transport the DECnet frames inside something. At
the
bottom there will be IP, but most likely the DECnet frames are actually
sitting
inside UDP...
So what is the difference from the bridge program, you ask.
Well, simple, the bridge program tries to be clever about which frames to
send where, but it cannot be clever enough at times, and also there are
times when it is forced to send traffic that we might want to limit.
The reason is that the bridge is not really a part of the DECnet traffic,
but is
just relaying packets back and forth, making the two ends of the bridge
appear as if they were on the same ethernet segment.
The Cisco box, on the other hand, is a DECnet routing node. It sits on the
ethernet, and participate fully in the DECnet traffic.
Thanks. Now I get it. I didn't know that anyone other than DEC ever made
something that could route actual DECnet and therefore did not realise that
"actual DECnet router" meant "actual DECnet router" :-) Until now I thought
this was something only available in a VMS router node.
It would be a fun exercise to turn the bridge into an actual DECnet router.
One day, when I have a lot of time I might even think about trying that.
Regards
Rob
As a good friend has commented to me, unless you plan on throwing a lot of money at Larry's yacht, you can forget any supposed "care" that Oracle may have. What you see is what you get... fortunately with Solaris, there may be a few souls left from the old organization that will go beyond google and a best endeavor.
Apologies... been fed up with Oracle now for quite some time...
On Mon, Jun 4, 2012 at 6:27 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2012-06-04 18:13, Brian Hechinger wrote:
SIMH 3.9 somehow kernel paniced my solaris server!
Wow.
-brian
ps: it's older solaris, but stil!
Wow. Now I am impressed. You have managed to trigger a bug in Solaris... :-)
Send an SPR to Oracle... If they care...
Johnny
On 2012-06-06 11:26, Peter Coghlan wrote:
No, you have not misunderstood. You are just not getting the full
picture. Yes, the Cisco box will transport the DECnet frames inside
something. At the bottom there will be IP, but most likely the DECnet
frames are actually sitting inside UDP...
My understanding of it is that GRE is another IP protocol on the same level
as TCP and UDP rather than using UDP.
You could definitely be right on GRE. It was way too long since I actually tried working with GRE to really remember much anymore...
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
