On 2012-08-28 18:08, Mark Wickens wrote:
I'm not totally clear on your setup. You have two interfaces, eth0 and eth2.
I think I got that. And the bridge program is using eth0 for it's bridge.
But how does your ethernet looks like? Is both eth0 and eth2 connected to
the same physical network? Is the router on that same segment as well?
Both interfaces are on the same segment as the router.
What sessions are you seeing on the router?
On the router I see the following sessions:
-------------------------------------------------------------------------------
Private IP :Port #Pseudo Port Peer IP :Port Ifno Status
-------------------------------------------------------------------------------
192.168.1.126 4711 4711 130.238.19.25 4711 3 0
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2
And what did the routing table on the machine running the bridge look like,
if you have two interfaces?
No idea on this one.
The bridge program does not try to do anything clever with the UDP packets,
so they will be sent on any interface, based on your routing table. It might
sound as if your router/NAT was pointing at the IP address of eth0, but the
default entry of the routing table on your machine would be using eth2. But
this is all wild guessing right now...
OK, that probably explains it. I thought the bridge was tied to that
particular interface. It's worth pointing out that what I'm doing it
probably daft - the 2nd card was installed to use for a SIMH instance,
so I should probably de-configure it from an OS point of view.
The bridge uses the specified interface for it's bridging. That is, DECnet packets will only be sent and received from that interface.
UDP does not have an interface that specifies which network interface to use. You normally do not have any control over this aspect for UDP packets.
The UDP transport that the bridge use is just plain UDP. And the destinations are all the non-local destinations specified in the config file. Exactly which network interface traffic to those destinations exit on is something up to your UDP/IP implementation.
(Just clarifying that detail a little more...)
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 2012-08-28 17:58, Paul_Koning at Dell.com wrote:
Maybe the thing to do is to turn on both interfaces -- that will give you a dual-link end node, which is something DECnet handles just fine. In fact, I've always argued that DECnet handles multiple connections to the same LAN much better than IP ever did, mostly because it addresses nodes rather than networks or interfaces.
Uh... I would argue that that would be a very bad thing, as it means you'll have two interfaces with the same mac address... Sitting on the same network. I'm pretty sure I even have seen some DECnet documentation that just says "not supported", or even stronger words...
Johnny
paul
On Aug 28, 2012, at 11:54 AM, Mark Benson wrote:
I tried to run a similar setup and found that Debian/Ubuntu's
'network-manager' process makes a really horrific mess of managing 2
interfaces.
I ripped it out of Debian and used file entries in
/etc/network/interfaces and /etc/resolv.conf
I have no idea if Ubuntu will spit it's brain out if you try that on
12.04 as it's ver dependent on it in the GUI.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 28 Aug 2012, at 13:37, Mark Wickens <mark at wickensonline.co.uk> wrote:
I think I've found it.
My HP Microserver running Ubuntu 12.04 has two network cards in: eth0 and eth2.
--
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
I think compile time change is plenty. My comment was really speculation, and even if true it doesn't sound like something that needs the flexibility of a runtime config setting.
paul
On Aug 28, 2012, at 4:58 PM, Rob Jarratt wrote:
The multiplier can easily be changed. It is currently a #define BCT3MULT 3.
It could be made a configurable parameter instead.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 28 August 2012 20:35
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Node 4.249
BTW, the adjacency timeout rules in the routing spec are tuned for good
quality physical links. So Ethernet adjacencies allow two consecutive
lost
packets, but no more -- the timeout is 3x the hello interval.
I wonder if bridged connections should be more tolerant. If both sides
are
regular DECnet implementations that isn't an option, but Rob's router
could
use a different multiplier to derive the broadcast listen timer value.
That
would help if these bridged connections are prone to drop more packets but
you can still reasonably expect no more than N in a row to be lost. If
so, the
multiplier could be changed to N+1.
paul
On Aug 28, 2012, at 3:30 PM, Rob Jarratt wrote:
The problem stopped around the time of your first email, so I guess
you fixed it. My user mode router is not reporting adjacency up and
down any more.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE]
On Behalf Of Mark Wickens
Sent: 28 August 2012 17:08
To: hecnet at update.uu.se
Subject: Re: [HECnet] Node 4.249
I'm not totally clear on your setup. You have two interfaces, eth0
and
eth2.
I think I got that. And the bridge program is using eth0 for it's
bridge.
But how does your ethernet looks like? Is both eth0 and eth2
connected to the same physical network? Is the router on that same
segment as
well?
Both interfaces are on the same segment as the router.
What sessions are you seeing on the router?
On the router I see the following sessions:
----------------------------------------------------------------------
------
---
Private IP :Port #Pseudo Port Peer IP :Port Ifno Status
----------------------------------------------------------------------
------
---
192.168.1.126 4711 4711 130.238.19.25 4711 3 0
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2
And what did the routing table on the machine running the bridge
look like, if you have two interfaces?
No idea on this one.
The bridge program does not try to do anything clever with the UDP
packets, so they will be sent on any interface, based on your
routing table. It might sound as if your router/NAT was pointing at
the IP address of eth0, but the default entry of the routing table
on your machine would be using eth2. But this is all wild guessing
right
now...
OK, that probably explains it. I thought the bridge was tied to that
particular
interface. It's worth pointing out that what I'm doing it probably
daft -
the
2nd card was installed to use for a SIMH instance, so I should
probably
de-
configure it from an OS point of view.
The multiplier can easily be changed. It is currently a #define BCT3MULT 3.
It could be made a configurable parameter instead.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 28 August 2012 20:35
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Node 4.249
BTW, the adjacency timeout rules in the routing spec are tuned for good
quality physical links. So Ethernet adjacencies allow two consecutive
lost
packets, but no more -- the timeout is 3x the hello interval.
I wonder if bridged connections should be more tolerant. If both sides
are
regular DECnet implementations that isn't an option, but Rob's router
could
use a different multiplier to derive the broadcast listen timer value.
That
would help if these bridged connections are prone to drop more packets but
you can still reasonably expect no more than N in a row to be lost. If
so, the
multiplier could be changed to N+1.
paul
On Aug 28, 2012, at 3:30 PM, Rob Jarratt wrote:
The problem stopped around the time of your first email, so I guess
you fixed it. My user mode router is not reporting adjacency up and
down any more.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE]
On Behalf Of Mark Wickens
Sent: 28 August 2012 17:08
To: hecnet at update.uu.se
Subject: Re: [HECnet] Node 4.249
I'm not totally clear on your setup. You have two interfaces, eth0
and
eth2.
I think I got that. And the bridge program is using eth0 for it's
bridge.
But how does your ethernet looks like? Is both eth0 and eth2
connected to the same physical network? Is the router on that same
segment as
well?
Both interfaces are on the same segment as the router.
What sessions are you seeing on the router?
On the router I see the following sessions:
----------------------------------------------------------------------
------
---
Private IP :Port #Pseudo Port Peer IP :Port Ifno Status
----------------------------------------------------------------------
------
---
192.168.1.126 4711 4711 130.238.19.25 4711 3 0
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2
And what did the routing table on the machine running the bridge
look like, if you have two interfaces?
No idea on this one.
The bridge program does not try to do anything clever with the UDP
packets, so they will be sent on any interface, based on your
routing table. It might sound as if your router/NAT was pointing at
the IP address of eth0, but the default entry of the routing table
on your machine would be using eth2. But this is all wild guessing
right
now...
OK, that probably explains it. I thought the bridge was tied to that
particular
interface. It's worth pointing out that what I'm doing it probably
daft -
the
2nd card was installed to use for a SIMH instance, so I should
probably
de-
configure it from an OS point of view.
I am working on it right now, working on the Update Process so that other
routers know how to route back to me. I am hoping to have a basic router
that works on a LAN and against the bridge at the other end in the next week
or so. At this stage it will be Windows only (can run on your desktop or as
a Windows service) and various parts of the spec won't be fully implemented.
I had an earlier version running on a Raspberry Pi, but I suspect it will
take a day or two longer to get it working on there again.
Right now I have the Ethernet Initialization Layer done, the Decision
Process coded (and tested to some degree), and I have started on the Update
and Forwarding processes which are the least well developed.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Gregg Levine
Sent: 28 August 2012 20:35
To: hecnet at update.uu.se
Subject: Re: [HECnet] Node 4.249
On Tue, Aug 28, 2012 at 3:30 PM, Rob Jarratt <robert.jarratt at ntlworld.com>
wrote:
The problem stopped around the time of your first email, so I guess
you fixed it. My user mode router is not reporting adjacency up and
down any more.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE]
On Behalf Of Mark Wickens
Sent: 28 August 2012 17:08
To: hecnet at update.uu.se
Subject: Re: [HECnet] Node 4.249
I'm not totally clear on your setup. You have two interfaces, eth0
and
eth2.
I think I got that. And the bridge program is using eth0 for it's
bridge.
But how does your ethernet looks like? Is both eth0 and eth2
connected to the same physical network? Is the router on that same
segment as
well?
Both interfaces are on the same segment as the router.
What sessions are you seeing on the router?
On the router I see the following sessions:
----------------------------------------------------------------------
------
---
Private IP :Port #Pseudo Port Peer IP :Port Ifno Status
----------------------------------------------------------------------
------
---
192.168.1.126 4711 4711 130.238.19.25 4711 3 0
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2
And what did the routing table on the machine running the bridge
look like, if you have two interfaces?
No idea on this one.
The bridge program does not try to do anything clever with the UDP
packets, so they will be sent on any interface, based on your
routing table. It might sound as if your router/NAT was pointing at
the IP address of eth0, but the default entry of the routing table
on your machine would be using eth2. But this is all wild guessing
right
now...
OK, that probably explains it. I thought the bridge was tied to that
particular
interface. It's worth pointing out that what I'm doing it probably
daft -
the
2nd card was installed to use for a SIMH instance, so I should
probably
de-
configure it from an OS point of view.
Hello!
Funny you should mention that reason behind that card, Mark, I had plans
utilizing that idea, but I shelved them for the moment, when I realized
that
there would be a big problem. Namely the fact that my DSL device is
getting
on in years, and I'm not all sure what would happen when I tried any of
that.
Next:
Rob you've mentioned several times a user mode router. Presumably for
Decnet issues of course. When will it become an available option and on
what platforms?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Tue, Aug 28, 2012 at 3:30 PM, Rob Jarratt
<robert.jarratt at ntlworld.com> wrote:
The problem stopped around the time of your first email, so I guess you
fixed it. My user mode router is not reporting adjacency up and down any
more.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Mark Wickens
Sent: 28 August 2012 17:08
To: hecnet at update.uu.se
Subject: Re: [HECnet] Node 4.249
I'm not totally clear on your setup. You have two interfaces, eth0 and
eth2.
I think I got that. And the bridge program is using eth0 for it's
bridge.
But how does your ethernet looks like? Is both eth0 and eth2 connected
to the same physical network? Is the router on that same segment as
well?
Both interfaces are on the same segment as the router.
What sessions are you seeing on the router?
On the router I see the following sessions:
----------------------------------------------------------------------------
---
Private IP :Port #Pseudo Port Peer IP :Port Ifno Status
----------------------------------------------------------------------------
---
192.168.1.126 4711 4711 130.238.19.25 4711 3 0
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2
And what did the routing table on the machine running the bridge look
like, if you have two interfaces?
No idea on this one.
The bridge program does not try to do anything clever with the UDP
packets, so they will be sent on any interface, based on your routing
table. It might sound as if your router/NAT was pointing at the IP
address of eth0, but the default entry of the routing table on your
machine would be using eth2. But this is all wild guessing right now...
OK, that probably explains it. I thought the bridge was tied to that
particular
interface. It's worth pointing out that what I'm doing it probably daft -
the
2nd card was installed to use for a SIMH instance, so I should probably
de-
configure it from an OS point of view.
Hello!
Funny you should mention that reason behind that card, Mark, I had
plans utilizing that idea, but I shelved them for the moment, when I
realized that there would be a big problem. Namely the fact that my
DSL device is getting on in years, and I'm not all sure what would
happen when I tried any of that.
Next:
Rob you've mentioned several times a user mode router. Presumably for
Decnet issues of course. When will it become an available option and
on what platforms?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
BTW, the adjacency timeout rules in the routing spec are tuned for good quality physical links. So Ethernet adjacencies allow two consecutive lost packets, but no more -- the timeout is 3x the hello interval.
I wonder if bridged connections should be more tolerant. If both sides are regular DECnet implementations that isn't an option, but Rob's router could use a different multiplier to derive the broadcast listen timer value. That would help if these bridged connections are prone to drop more packets but you can still reasonably expect no more than N in a row to be lost. If so, the multiplier could be changed to N+1.
paul
On Aug 28, 2012, at 3:30 PM, Rob Jarratt wrote:
The problem stopped around the time of your first email, so I guess you
fixed it. My user mode router is not reporting adjacency up and down any
more.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Mark Wickens
Sent: 28 August 2012 17:08
To: hecnet at update.uu.se
Subject: Re: [HECnet] Node 4.249
I'm not totally clear on your setup. You have two interfaces, eth0 and
eth2.
I think I got that. And the bridge program is using eth0 for it's
bridge.
But how does your ethernet looks like? Is both eth0 and eth2 connected
to the same physical network? Is the router on that same segment as
well?
Both interfaces are on the same segment as the router.
What sessions are you seeing on the router?
On the router I see the following sessions:
----------------------------------------------------------------------------
---
Private IP :Port #Pseudo Port Peer IP :Port Ifno Status
----------------------------------------------------------------------------
---
192.168.1.126 4711 4711 130.238.19.25 4711 3 0
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2
And what did the routing table on the machine running the bridge look
like, if you have two interfaces?
No idea on this one.
The bridge program does not try to do anything clever with the UDP
packets, so they will be sent on any interface, based on your routing
table. It might sound as if your router/NAT was pointing at the IP
address of eth0, but the default entry of the routing table on your
machine would be using eth2. But this is all wild guessing right now...
OK, that probably explains it. I thought the bridge was tied to that
particular
interface. It's worth pointing out that what I'm doing it probably daft -
the
2nd card was installed to use for a SIMH instance, so I should probably
de-
configure it from an OS point of view.
The problem stopped around the time of your first email, so I guess you
fixed it. My user mode router is not reporting adjacency up and down any
more.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Mark Wickens
Sent: 28 August 2012 17:08
To: hecnet at update.uu.se
Subject: Re: [HECnet] Node 4.249
I'm not totally clear on your setup. You have two interfaces, eth0 and
eth2.
I think I got that. And the bridge program is using eth0 for it's
bridge.
But how does your ethernet looks like? Is both eth0 and eth2 connected
to the same physical network? Is the router on that same segment as
well?
Both interfaces are on the same segment as the router.
What sessions are you seeing on the router?
On the router I see the following sessions:
----------------------------------------------------------------------------
---
Private IP :Port #Pseudo Port Peer IP :Port Ifno Status
----------------------------------------------------------------------------
---
192.168.1.126 4711 4711 130.238.19.25 4711 3 0
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2
And what did the routing table on the machine running the bridge look
like, if you have two interfaces?
No idea on this one.
The bridge program does not try to do anything clever with the UDP
packets, so they will be sent on any interface, based on your routing
table. It might sound as if your router/NAT was pointing at the IP
address of eth0, but the default entry of the routing table on your
machine would be using eth2. But this is all wild guessing right now...
OK, that probably explains it. I thought the bridge was tied to that
particular
interface. It's worth pointing out that what I'm doing it probably daft -
the
2nd card was installed to use for a SIMH instance, so I should probably
de-
configure it from an OS point of view.
I'm not totally clear on your setup. You have two interfaces, eth0 and eth2.
I think I got that. And the bridge program is using eth0 for it's bridge.
But how does your ethernet looks like? Is both eth0 and eth2 connected to
the same physical network? Is the router on that same segment as well?
Both interfaces are on the same segment as the router.
What sessions are you seeing on the router?
On the router I see the following sessions:
-------------------------------------------------------------------------------
Private IP :Port #Pseudo Port Peer IP :Port Ifno Status
-------------------------------------------------------------------------------
192.168.1.126 4711 4711 130.238.19.25 4711 3 0
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2
And what did the routing table on the machine running the bridge look like,
if you have two interfaces?
No idea on this one.
The bridge program does not try to do anything clever with the UDP packets,
so they will be sent on any interface, based on your routing table. It might
sound as if your router/NAT was pointing at the IP address of eth0, but the
default entry of the routing table on your machine would be using eth2. But
this is all wild guessing right now...
OK, that probably explains it. I thought the bridge was tied to that
particular interface. It's worth pointing out that what I'm doing it
probably daft - the 2nd card was installed to use for a SIMH instance,
so I should probably de-configure it from an OS point of view.
Maybe the thing to do is to turn on both interfaces -- that will give you a dual-link end node, which is something DECnet handles just fine. In fact, I've always argued that DECnet handles multiple connections to the same LAN much better than IP ever did, mostly because it addresses nodes rather than networks or interfaces.
paul
On Aug 28, 2012, at 11:54 AM, Mark Benson wrote:
I tried to run a similar setup and found that Debian/Ubuntu's
'network-manager' process makes a really horrific mess of managing 2
interfaces.
I ripped it out of Debian and used file entries in
/etc/network/interfaces and /etc/resolv.conf
I have no idea if Ubuntu will spit it's brain out if you try that on
12.04 as it's ver dependent on it in the GUI.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 28 Aug 2012, at 13:37, Mark Wickens <mark at wickensonline.co.uk> wrote:
I think I've found it.
My HP Microserver running Ubuntu 12.04 has two network cards in: eth0 and eth2.
