By asking questions, you learn things... No reason to ask for forgiveness for wanting to learn. On 2012-06-05 21:05, Rob Jarratt wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Brian Hechinger Sent: 05 June 2012 18:36 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Multinet Tunnel Connections to SG1:: On 6/5/2012 12:53 PM, Rob Jarratt wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: 04 June 2012 23:17 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Multinet Tunnel Connections to SG1:: FYI - Update now have a Cisco box, which will be setup within a few days to be able to route DECnet over IP, so that will become another options to hook into HECnet at the Update site. 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...) Johnny I assume you are using GRE on the Cisco box. I am not an expert in this stuff so pardon the na ve question but, what is it about Cisco that makes it better than the bridge? After all aren't they really doing the same thing? Is it just that you don t need a server running the bridge (could use a Raspberry Pi for that now) or is it the use of GRE? From a skim of RFC 2784 and 2890 GRE doesn't look too complicated, perhaps the bridge could be changed to implement GRE if that helps in some way. I don't know much about "professional" routers and Cisco stuff in particular. If there are advantages to using a Cisco router, what should I be looking for if I wanted to pick up something cheap on EBay? Could this work in a domestic environment with an ISP that gives out dynamic IP addresses? The cisco isn't bridging traffic across the GRE link it's doing actual DECnet routing. It's closer in function to a Multinet tunnel. -brian Forgive my ignorance, but when you say "actual DECnet routing", it must be transporting it over something, what is that something? I assume it is IP, in which case it would still need to encapsulate the DECnet in IP wouldn't it? Have I misunderstood something here? 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. As such, it does *not* pass on any ethernet DECnet traffic it sees to the other end. Instead it has two interfaces. One is the local ethernet interface. Works just like on any other machine on the local ethernet. The other interface is a point-to-point interface to the remote Cisco box. The local Cisco box then have the DECnet routing tables, whereby it knows where to send packets on, if it receives a DECnet packet not destined for itself. So it is a DECnet router. That means any local ethernet broadcast traffic is *never* send to the remote Cisco box. The bridge always have to pass on *all* broadcast packets to all remote ends connected. The Cisco box can have several point-to-point connections. Each is considered its own interface (well, circuit I'd guess, but possibly also line) in DECnet on the Cisco box. So instead of the exponential growth of ethernet packets sent all around when you have an ethernet bridge, you get a linear growth of packets with the Cisco box. And even better is the fact that DECnet have limits on how many endnodes and routers there can be on a single ethernet segment. And every machine on any bridge point will count here. As will the number of machines doing broadcasts... There are simply some scaling problems with the bridge. And even more funny (this have been touched on in the past), the bridge does not deal at all with loops in the topology. DECnet itself does, so with the Cisco boxes, you can form redundant paths between places without problems. Johnny