Well it doesn't play nice with the mapper Brian H and me are working on..
sampsa
On 7 Jan 2013, at 20:59, Ian McLaughlin <ian at platinum.net> wrote:
On 2013-01-07, at 10:54 AM, Cory Smelosky <b4 at gewt.net> wrote:
What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff...
I have a Cisco 7206VXR router that has Cisco's Decnet implementation on it. It is now acting as my area router, and connects to Dave's Cisco via an IP tunnel. From what I understand, Cisco's Decnet implementation is proprietary - not sure if it works well with non-Cisco stuff.
Ian
I also have Cisco tunnels running.
-brian
On 1/7/2013 1:52 PM, Ian McLaughlin wrote:
Wouldn't it be ironic if Hecnet ran out of addresses :)
Does anyone know what the largest DECnet deplayment was duing the good old days?
Ian
p.s. Johnny, just in case you've still got the bindings in your bridge for area 42, you can remove them. Thanks to Dave McGuire, I've now got my Cisco router connected to him. Is there anyone else on Hecnet offering Cisco tunnels that I could set up for redundancy?
On 2013-01-07, at 10:44 AM, sampsa at mac.com wrote:
Johnny,
As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too?
Was thinking of a PPTP VPN and then multinet to area 8..
sampsa
On 1/7/2013 1:59 PM, Ian McLaughlin wrote:
On 2013-01-07, at 10:54 AM, Cory Smelosky <b4 at gewt.net> wrote:
What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff...
I have a Cisco 7206VXR router that has Cisco's Decnet implementation on it. It is now acting as my area router, and connects to Dave's Cisco via an IP tunnel. From what I understand, Cisco's Decnet implementation is proprietary - not sure if it works well with non-Cisco stuff.
Ian
Cisco's DECnet is, well, DECnet. :)
There is nothing special about the tunnel. It's just a bog standard GRE tunnel (or you could use an IPSec tunnel if you wanted to).
The Cisco just talks DECnet on all the links you tell it to.
As far as replicating it, you'd need something that can route DECnet and can talk GRE, that's all it would take. Good luck finding that though. :)
-brian
On Jan 7, 2013, at 1:52 PM, Ian McLaughlin wrote:
Wouldn't it be ironic if Hecnet ran out of addresses :)
Does anyone know what the largest DECnet deplayment was duing the good old days?
The internal net at DEC was seriously out of addresses, though just like IP that's partly because the addressing scheme forced it to be somewhat sparse. Still, there were certainly tens of thousands of nodes on it.
paul
On 7 Jan 2013, at 13:59, Ian McLaughlin <ian at platinum.net> wrote:
On 2013-01-07, at 10:54 AM, Cory Smelosky <b4 at gewt.net> wrote:
What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff...
I have a Cisco 7206VXR router that has Cisco's Decnet implementation on it. It is now acting as my area router, and connects to Dave's Cisco via an IP tunnel. From what I understand, Cisco's Decnet implementation is proprietary - not sure if it works well with non-Cisco stuff.
Ah, I probably couldn't use it on my stuff then.
Ian
On 2013-01-07, at 10:54 AM, Cory Smelosky <b4 at gewt.net> wrote:
What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff...
I have a Cisco 7206VXR router that has Cisco's Decnet implementation on it. It is now acting as my area router, and connects to Dave's Cisco via an IP tunnel. From what I understand, Cisco's Decnet implementation is proprietary - not sure if it works well with non-Cisco stuff.
Ian
On 7 Jan 2013, at 13:52, Ian McLaughlin <ian at platinum.net> wrote:
Wouldn't it be ironic if Hecnet ran out of addresses :)
Does anyone know what the largest DECnet deplayment was duing the good old days?
I wonder if HECnet has overtaken it in size. ;)
Ian
p.s. Johnny, just in case you've still got the bindings in your bridge for area 42, you can remove them. Thanks to Dave McGuire, I've now got my Cisco router connected to him. Is there anyone else on Hecnet offering Cisco tunnels that I could set up for redundancy?
What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff...
On 2013-01-07, at 10:44 AM, sampsa at mac.com wrote:
Johnny,
As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too?
Was thinking of a PPTP VPN and then multinet to area 8..
sampsa
Wouldn't it be ironic if Hecnet ran out of addresses :)
Does anyone know what the largest DECnet deplayment was duing the good old days?
Ian
p.s. Johnny, just in case you've still got the bindings in your bridge for area 42, you can remove them. Thanks to Dave McGuire, I've now got my Cisco router connected to him. Is there anyone else on Hecnet offering Cisco tunnels that I could set up for redundancy?
On 2013-01-07, at 10:44 AM, sampsa at mac.com wrote:
Johnny,
As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too?
Was thinking of a PPTP VPN and then multinet to area 8..
sampsa
Johnny,
As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too?
Was thinking of a PPTP VPN and then multinet to area 8..
sampsa
On Jan 6, 2013, at 8:55 PM, Gerardo Cacciari wrote:
On Sat, 5 Jan 2013 01:31:36 +0000, you wrote:
Finally, in the DMC a buffer corresponds one to one with a DDCMP packet (its
implementation of property 3). That's required -- all DECnet protocols are
packet oriented and packet boundaries are meaningful. There are no byte
stream protocols in DECnet -- TCP is the only protocol among all the
networking protocols I know of that made that horrible design error.
Sorry to bother you, but right in these days I'm reading and learning
something more about transmission protocols (such as BSC, SDLC, and DDCMP),
and your statement about that TCP design error tickled my curiosity.
I know that BSC and DDCMP can be defined as character oriented protocols,
while things like SDLC (and all its derivatives) are bit oriented; there are
other differences but this is the most striking one. But let's not digress.
I'd relate TCP to DECnet NSP, rather than to DDCMP, and if I'm not wrong both
protocols (and DDCMP too) have variable length packets, according to how much
data they have to send at the moment. So, can't they both be defined byte
stream protocols? Or maybe are you referring to the fact that while NSP and
DDCMP have a per-packet acknowledgement, TCP acknowledges single bytes and so
can theoretically acknowledge just the first N bytes of a given packet?
Yes, TCP has variable length packets, as do the other protocols.
The essence of "stream oriented protocol" is not in the packet format. Instead, it is in the definition of the service provided to the application.
In TCP, the service provided is a stream of bytes delivered to the other end. The stream has no structure.
In every other networking protocol (including, ironically, UDP) the service provided is delivery of a sequence of packets to the other end. A packet is a number of bytes AND a specific packet boundary.
For example, if in TCP I send 10 bytes then 20 bytes, the receiver may see 30 bytes delivered all at once, or a delivery of 5 bytes followed by 25 bytes, or 6 deliveries of 5 bytes each. Some of those are not likely in practice, but all are valid.
On the other hand, in DECnet (or UDP, or ISO transport) if I send a 10 byte packet then a 20 byte packet, the receiver sees a 10 byte packet followed by a 20 byte packet. Nothing else is possible.
All applications need structured data of some sort. So what happens is that every application has to make up for the fact that TCP doesn't do a packet service by layering a packet delimiting scheme on top. Often that comes in the form of a header that contains a data length, then you count off that many bytes, and then you look for another header. If you ever get out of sync, you end up looking for a header in the wrong place and the protocol won't recover until you close the connection and restart.
Also, in the real world under the covers, you always have packets. So you would think that in reality, a high speed application (like iSCSI) could just assume that its headers are always found at the start of TCP buffers. And yes, that's a valid optimization, but you can NOT rely on that being true 100% of the time, because it's only a "likely" behavior, not a guarantee that's part of the TCP service definition.
By contrast, if you implemented iSCSI on top of DECnet, or OSI, you would simply have the iSCSI PDUs starting at the start of a transport layer SDU, and this whole mess would disappear. Your code would be much smaller and more reliable because you no longer have to allow for the "unlikely" case of application PDUs starting in the middle of a TCP data delivery, or worse yet, straddling a boundary.
Incidentally, there's a successor to TCP called SCTP that has packet service, and it would be a great solution to all this if only it were in general use -- but it isn't.
paul