On Jan 2, 2015, at 7:57 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-02 19:07, 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.
No, you're not thinking about the larger picture, Paul. :-)
Like I responded myself. One "problem" is all the routers that are broadcasting. Both hello messages and routing updates. And they need to go to all bridges connected. While if you had a tunnel between two routers, you'll end up with just the chatter between those two routers. Any routers located on each end, or elsewhere, is of no concern for the link.
But you re comparing different cases. GRE is like a two-station Ethernet; your bridge is more general. The flooding case of a bridge makes a difference only if you have more than two stations.
It seems to me that both cases produce the same number of packets if you configure a connection between just two stations, because each multicast goes to the one other station either in the GRE case or the bridge case.
paul
On 2015-01-03 02:00, Dave McGuire wrote:
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)
Actually, I don't know the details, even though I pretty much know how it *could* be done. I've pretty much never actually worked on a Cisco box. :-)
However, DECnet costs cannot possibly be related, as we're now not talking about DECnet protocols. (LAT and MOP are not using DECnet...)
You need to somehow tell the Cisco box to grab all ethernet packets with a certain protocol number, and pass those on over the tunnel, and have the other end do the reverse.
(Pretty much just the same as my bridge program does...)
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 19:59, Paul_Koning at Dell.com wrote:
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.
One additional "complication" is that you would need to be able to feed packets from the python code into the network receiver part to inject packets from python into the local DECnet stack, and also capture any outgoing packets and get them delivered from DECnet into the python code.
Not necessarily something that can be done even if you have pcap.
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 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
