On 2015-01-03 02:54, Dave McGuire wrote:
On 01/02/2015 08:43 PM, Johnny Billquist wrote:
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.
Assigning a DECnet cost to a tunnel endpoint pseudo-interface causes
it to pay attention to DECnet packets.
Which is not LAT and MOP. Which is what I've written multiple times now.
:-)
Right. I didn't say it was.
Seemed to me you implied it. Oh well. Me and english... :-)
DECnet packets are routed by the Cisco router. MOP and LAT are not
protocols running on top of DECnet, but are their own protocols directly
on ethernet. Which is also why they in essence are "local only", as they
cannot be routed.
...but they can be bridged, which you can ALSO do with a GRE tunnel.
The very same GRE tunnel as is handling DECnet, in fact.
Yes. And this is where it comes to me not knowing Ciscos. I know how you do it in general if we talk networking. And this is just what my bridge does, except it don't use GRE, but is more simple and stupid. :-)
But I assume there must be a way to tell a Cisco to bridge an arbitrary ethernet protocol, using GRE as the tunneling protocol.
I remember looking at the GRE interface under NetBSD many years ago when I wanted to setup HECnet, but the documentation confused me in the details, and I just wanted something really simple, so I wrote my own bridge instead. It was a dirty hack on a dark night. It does (more or less) do what I needed, but it's really just a quick hack.
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-03 02:49, Paul_Koning at Dell.com wrote:
On Jan 2, 2015, at 8:41 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-03 02:13, Paul_Koning at Dell.com wrote:
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.
Right. But we should not talk about GRE here, because that just confuse the issue. The thing is, the Ciscos are routers, with a tunnel between the two routers. So you only have these two routers talking to each other over the tunnel.
With the bridge, you do not get that isolation. You will instead have every router on each side (even if you just have two points to the bridge) talking across the bridge. So the number of packets over the bridge is essentially proportional to the number of routers connected to the ethernet segments.
And in the HECnet specific case, the bridge actually have around 10 active points, and atleast one router at each point
Ok. But if someone wanted the efficiency of a GRE tunnel without having a device capable of talking that protocol, one could set up another instance of a JB bridge, with just those two systems on it. Then it would be just as efficient.
If you also placed a router between the rest of the net and the bridge then yes, then they become equivalent.
I agree that if you compare a point to point topology tunnel with a 10-point bridge, the two necessarily look rather different.
Yeah... :-)
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 08:43 PM, Johnny Billquist wrote:
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.
Assigning a DECnet cost to a tunnel endpoint pseudo-interface causes
it to pay attention to DECnet packets.
Which is not LAT and MOP. Which is what I've written multiple times now.
:-)
Right. I didn't say it was.
DECnet packets are routed by the Cisco router. MOP and LAT are not
protocols running on top of DECnet, but are their own protocols directly
on ethernet. Which is also why they in essence are "local only", as they
cannot be routed.
...but they can be bridged, which you can ALSO do with a GRE tunnel.
The very same GRE tunnel as is handling DECnet, in fact.
-Dave
--
Dave McGuire, AK4HZ/3
New Kensington, PA
On Jan 2, 2015, at 8:41 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-03 02:13, Paul_Koning at Dell.com wrote:
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.
Right. But we should not talk about GRE here, because that just confuse the issue. The thing is, the Ciscos are routers, with a tunnel between the two routers. So you only have these two routers talking to each other over the tunnel.
With the bridge, you do not get that isolation. You will instead have every router on each side (even if you just have two points to the bridge) talking across the bridge. So the number of packets over the bridge is essentially proportional to the number of routers connected to the ethernet segments.
And in the HECnet specific case, the bridge actually have around 10 active points, and atleast one router at each point
Ok. But if someone wanted the efficiency of a GRE tunnel without having a device capable of talking that protocol, one could set up another instance of a JB bridge, with just those two systems on it. Then it would be just as efficient.
I agree that if you compare a point to point topology tunnel with a 10-point bridge, the two necessarily look rather different.
paul
On 2015-01-03 02:36, Dave McGuire wrote:
On 01/02/2015 08:12 PM, Johnny Billquist wrote:
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.
Assigning a DECnet cost to a tunnel endpoint pseudo-interface causes
it to pay attention to DECnet packets.
Which is not LAT and MOP. Which is what I've written multiple times now. :-)
DECnet packets are routed by the Cisco router. MOP and LAT are not protocols running on top of DECnet, but are their own protocols directly on ethernet. Which is also why they in essence are "local only", as they cannot be routed.
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-03 02:13, Paul_Koning at Dell.com wrote:
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.
Right. But we should not talk about GRE here, because that just confuse the issue. The thing is, the Ciscos are routers, with a tunnel between the two routers. So you only have these two routers talking to each other over the tunnel.
With the bridge, you do not get that isolation. You will instead have every router on each side (even if you just have two points to the bridge) talking across the bridge. So the number of packets over the bridge is essentially proportional to the number of routers connected to the ethernet segments.
And in the HECnet specific case, the bridge actually have around 10 active points, and atleast one router at each point...
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.
But you get so many more multicast packets if you listen to an ethernet segment with multiple routers...
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 08:12 PM, Johnny Billquist wrote:
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.
Assigning a DECnet cost to a tunnel endpoint pseudo-interface causes
it to pay attention to DECnet packets.
-Dave
--
Dave McGuire, AK4HZ/3
New Kensington, PA
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
