On 01/02/2015 07:58 PM, Johnny Billquist wrote:
It does scale better. However, it is possible to bridge LAT and/or MOP
over the link also.
Ah. Cool. I wasn't sure if it would also bridge other protocols, since
these are not related to DECnet as such.
One can tunnel most anything over GRE, even raw Ethernet frames,
regardless of the higher-level protocols. Hence the 'G' for "Generic".
Yes. But you need some ingress and egress that makes use of it. Or else
we could just as well argue that UDP can tunnel anything.
...which it can. ;) On a Cisco, assigning a DECnet cost to an
interface (and a GRE endpoint is a pseudo-interface on a Cisco) forms
that ingress/egress.
(I know YOU know this; I'm saying it for the benefit of those here who
are just learning about this)
-Dave
--
Dave McGuire, AK4HZ/3
New Kensington, PA
On 2015-01-02 19:42, Dave McGuire wrote:
On 01/02/2015 12:43 PM, Johnny Billquist wrote:
It does scale better. However, it is possible to bridge LAT and/or MOP
over the link also.
Ah. Cool. I wasn't sure if it would also bridge other protocols, since
these are not related to DECnet as such.
One can tunnel most anything over GRE, even raw Ethernet frames,
regardless of the higher-level protocols. Hence the 'G' for "Generic".
Yes. But you need some ingress and egress that makes use of it. Or else we could just as well argue that UDP can tunnel anything.
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 2015-01-02 18:45, Hans Vlems wrote:
What exactly do you mean by "it scales better" ?
Less bandwidth load on the Internet line, in my case 12 Mb/s ADSL.
Or less load on th local decent hosts?
The first would persuade me, easily.
The first indeed. The way the bridge works is that every machine on any network connected to a bridge appears as if they are on the same ethernet segment. This means that any broadcast packet from any machine is sent to all bridges.
And every router at regular intervals sends broadcast packets. As do any LAT enabled host.
The bridge program tries to be smart and not send packets destined for a known host to bridges not involved in the direct path, but also all unknown destinations are sent everywhere. And there are protocol effects of having many routers on the same segment as well.
The Cisco tunnel on the other hand means you actually have two routers talking to each other over the internet, so only the specific messages between these two routers actually is the traffic. The only other traffic passing the link is actual traffic that needs to pass over the link.
Johnny
Hans
Verzonden vanaf mijn BlackBerry 10-smartphone.
*Van: *Tim Sneddon
*Verzonden: *vrijdag 2 januari 2015 18:40
*Aan: *hecnet at update.uu.se
*Beantwoorden: *hecnet at Update.UU.SE
*Onderwerp: *Re: [HECnet] Hecnet Peering
On Sat, Jan 3, 2015 at 1:34 AM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
On 2015-01-02 18:28, Hans Vlems wrote:
Is there an advantage if you use a tunnel in stead of Johnny's
bridge
program which I use?
It scales better and use less network bandwidth, if that is a concern.
But it won't pass through LAT or MOP. Pick your poison. :-)
It does scale better. However, it is possible to bridge LAT and/or MOP
over the link also.
Regards, Tim.
--
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
Back to the problem in hand. Any ideas?
Can ping you 12.1023 and 12.2 from the router which is good; can ping 22.10 from the router which is also good; but for some reason i cannot connect from VAX (22.10) on FastEthernet0/1 to 12.2.
This must be a local issue.
Is there anything else I need to setup above what I have for FE0/1 and decnet on my router?
decnet routing 22.100
decnet node-type area
interface FastEthernet0/1
ip address 10.22.1.254 255.255.255.0
speed auto
full-duplex
lat enabled
decnet cost 4
and my tunnel to you which I don t think is the problem
interface Tunnel57
description HECnet tunnel for Tim Sneddon (Area 12) [Version:274]
no ip address
decnet cost 20
tunnel source FastEthernet0/1
tunnel destination 120.146.225.243
tunnel path-mtu-discovery
Mark
On 2 Jan 2015, at 19:38, Hans Vlems <hvlems at zonnet.nl> wrote:
I'll try to find v3.2 tomorrow Paul
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Paul_Koning at Dell.com
Verzonden: vrijdag 2 januari 2015 20:23
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Hecnet Peering
On Jan 2, 2015, at 2:08 PM, Hans Vlems <hvlems at zonnet.nl> wrote:
It would be nice to move the connection off a Linux box to a VMS system.
There is a libpcap version for VMS, it's used by simh.
The problem is Python. AFAIK that i s just v2.7 for VMS. I know my systems run that kit, but I don't use it much so a newer version may be available.
Hans
The Python 3.3 what s new document says that VMS is no longer supported due to lack of a maintainer . So it may be possible to build Python 3.2 on VMS. The current DECnet/Python code wants 3.3, but earlier on I used 3.2 and there isn t much that needs 3.3. (In other words, it would not be all that hard to change it back to allow 3.2.)
paul
I'll try to find v3.2 tomorrow Paul
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Paul_Koning at Dell.com
Verzonden: vrijdag 2 januari 2015 20:23
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Hecnet Peering
On Jan 2, 2015, at 2:08 PM, Hans Vlems <hvlems at zonnet.nl> wrote:
It would be nice to move the connection off a Linux box to a VMS system.
There is a libpcap version for VMS, it's used by simh.
The problem is Python. AFAIK that i s just v2.7 for VMS. I know my systems run that kit, but I don't use it much so a newer version may be available.
Hans
The Python 3.3 what s new document says that VMS is no longer supported due to lack of a maintainer . So it may be possible to build Python 3.2 on VMS. The current DECnet/Python code wants 3.3, but earlier on I used 3.2 and there isn t much that needs 3.3. (In other words, it would not be all that hard to change it back to allow 3.2.)
paul
On Jan 2, 2015, at 2:08 PM, Hans Vlems <hvlems at zonnet.nl> wrote:
It would be nice to move the connection off a Linux box to a VMS system.
There is a libpcap version for VMS, it's used by simh.
The problem is Python. AFAIK that i s just v2.7 for VMS. I know my systems run that kit, but I don't use it much so a newer version may be available.
Hans
The Python 3.3 what s new document says that VMS is no longer supported due to lack of a maintainer . So it may be possible to build Python 3.2 on VMS. The current DECnet/Python code wants 3.3, but earlier on I used 3.2 and there isn t much that needs 3.3. (In other words, it would not be all that hard to change it back to allow 3.2.)
paul
It would be nice to move the connection off a Linux box to a VMS system.
There is a libpcap version for VMS, it's used by simh.
The problem is Python. AFAIK that i s just v2.7 for VMS. I know my systems run that kit, but I don't use it much so a newer version may be available.
Hans
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Paul_Koning at Dell.com
Verzonden: vrijdag 2 januari 2015 19:59
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Hecnet Peering
On Jan 2, 2015, at 1:36 PM, Hans Vlems <hvlems at zonnet.nl> wrote:
Paul,
Does it run on a VMS supported version for Python?
If so then I' m interested in trying it out.
Hans
Probably not, at least not without some changes.
It typically runs as a daemon, and on VMS that s done differently. Also, it uses libpcap via the Python ctypes module. Is there a VMS port of libpcap? Even if yes, the details of what symbols you ask for in the ctypes wrapper for that library might be different.
Finally, it uses Python 3, so you d have to have that; Python 2 won t do.
It would be seriously neat if this can be made to work, though.
paul
On Jan 2, 2015, at 1:36 PM, Hans Vlems <hvlems at zonnet.nl> wrote:
Paul,
Does it run on a VMS supported version for Python?
If so then I' m interested in trying it out.
Hans
Probably not, at least not without some changes.
It typically runs as a daemon, and on VMS that s done differently. Also, it uses libpcap via the Python ctypes module. Is there a VMS port of libpcap? Even if yes, the details of what symbols you ask for in the ctypes wrapper for that library might be different.
Finally, it uses Python 3, so you d have to have that; Python 2 won t do.
It would be seriously neat if this can be made to work, though.
paul
On 01/02/2015 12:43 PM, Johnny Billquist wrote:
It does scale better. However, it is possible to bridge LAT and/or MOP
over the link also.
Ah. Cool. I wasn't sure if it would also bridge other protocols, since
these are not related to DECnet as such.
One can tunnel most anything over GRE, even raw Ethernet frames,
regardless of the higher-level protocols. Hence the 'G' for "Generic".
-Dave
--
Dave McGuire, AK4HZ/3
New Kensington, PA
Sorry guys - late to the party (West coast time zone and only a day after New Year - I was still sleeping). Did I see mention of a problem with the HUB:: tunnels, or did that get resolved? Let me know if the box needs a reboot.
Ian
On Jan 2, 2015, at 10:07 AM, <Paul_Koning at Dell.com> <Paul_Koning at Dell.com> wrote:
On Jan 2, 2015, at 12:34 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-02 18:28, Hans Vlems wrote:
Is there an advantage if you use a tunnel in stead of Johnny's bridge
program which I use?
It scales better and use less network bandwidth, if that is a concern.
Less network bandwidth because the GRE tunnel doesn t use Ethernet padding and regular Ethernet headers, while the JB bridge is a bridge so it does have both of those?
That seems like the only difference; from the DECnet routing layer point of view, both are LAN links and the protocol operation is the same for both.
FWIW, my Python based router includes GRE tunneling, and while I would not claim it is totally production grade code yet, it s in good enough shape that it might be interesting for one or two enterprising folks to try that approach. A useful property vs. Cisco boxes is the cost (free).
paul
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=48D0DC9692AA11E49…
