15 Aug
2020
15 Aug
'20
8:42 p.m.
Gentlepeople,
I've added a new feature to the HECnet mapper (http://akdesign.dyndns.org:8080/map/)
to listen for topology change events and do incremental updates of the map as these
happen. You can see this in the current mapper display, which will show "Last
incremental change" in the map title block if there has been any incremental change
since the last full update.
For this to be most effective, the mapper needs to be sent these events from at least one
router in each area. A good choice would be the main backbone area router in each area;
better still all the backbone area routers if there are several.
So if you have one of these and are interested in participating, please do the equivalent
of this NCP command:
NCP>set logging monitor events 4.7-10,14-15,18-19 sink node 28nh
and of course the equivalent permanent command ("define" instead of
"set", and perhaps in a different utility at least for the case of RSX).
If you're running PyDECnet, you need to upgrade to the current version, rev 524. Then
add this line to the config file:
logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
When you set up a router for this, please drop me an email so I know which nodes are
currently participating.
Thanks much,
paul
15 Aug
15 Aug
10 p.m.
Hi Paul,
I can do area 29 from a29rt2. I?ll upgrade pydecnet tomorrow and set it going
Keith
On 15 Aug 2020, at 19:44, Paul Koning <paulkoning
at comcast.net> wrote:
?Gentlepeople,
I've added a new feature to the HECnet mapper (http://akdesign.dyndns.org:8080/map/)
to listen for topology change events and do incremental updates of the map as these
happen. You can see this in the current mapper display, which will show "Last
incremental change" in the map title block if there has been any incremental change
since the last full update.
For this to be most effective, the mapper needs to be sent these events from at least one
router in each area. A good choice would be the main backbone area router in each area;
better still all the backbone area routers if there are several.
So if you have one of these and are interested in participating, please do the equivalent
of this NCP command:
NCP>set logging monitor events 4.7-10,14-15,18-19 sink node 28nh
and of course the equivalent permanent command ("define" instead of
"set", and perhaps in a different utility at least for the case of RSX).
If you're running PyDECnet, you need to upgrade to the current version, rev 524.
Then add this line to the config file:
logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
When you set up a router for this, please drop me an email so I know which nodes are
currently participating.
Thanks much,
paul
16 Aug
16 Aug
1:25 a.m.
Hi, Paul.
On 2020-08-15 20:42, Paul Koning wrote:
Gentlepeople,
I've added a new feature to the HECnet mapper (http://akdesign.dyndns.org:8080/map/)
to listen for topology change events and do incremental updates of the map as these
happen. You can see this in the current mapper display, which will show "Last
incremental change" in the map title block if there has been any incremental change
since the last full update.
For this to be most effective, the mapper needs to be sent these events from at least one
router in each area. A good choice would be the main backbone area router in each area;
better still all the backbone area routers if there are several.
So if you have one of these and are interested in participating, please do the equivalent
of this NCP command:
NCP>set logging monitor events 4.7-10,14-15,18-19 sink node 28nh
and of course the equivalent permanent command ("define" instead of
"set", and perhaps in a different utility at least for the case of RSX).
If you're running PyDECnet, you need to upgrade to the current version, rev 524.
Then add this line to the config file:
logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
When you set up a router for this, please drop me an email so I know which nodes are
currently participating.
This is great. I'll set it up on MIM::
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
5:20 a.m.
Paul,
I look forward to seeing your HECnet mapper respond to topology changes.
I just set up CBVRP3 the primary router for area 30 to forward events to 28NH. Let me
know if there are any issues.
Your NCP syntax below worked perfectly for me in RSX once I defined the node 28NH. I
just put it also at the end of my network start-up command files to make it permanent.
Thanks and Best Regards,
Mark
On Aug 15, 2020, at 1:42 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Gentlepeople,
I've added a new feature to the HECnet mapper (http://akdesign.dyndns.org:8080/map/)
to listen for topology change events and do incremental updates of the map as these
happen. You can see this in the current mapper display, which will show "Last
incremental change" in the map title block if there has been any incremental change
since the last full update.
For this to be most effective, the mapper needs to be sent these events from at least one
router in each area. A good choice would be the main backbone area router in each area;
better still all the backbone area routers if there are several.
So if you have one of these and are interested in participating, please do the equivalent
of this NCP command:
NCP>set logging monitor events 4.7-10,14-15,18-19 sink node 28nh
and of course the equivalent permanent command ("define" instead of
"set", and perhaps in a different utility at least for the case of RSX).
If you're running PyDECnet, you need to upgrade to the current version, rev 524.
Then add this line to the config file:
logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
When you set up a router for this, please drop me an email so I know which nodes are
currently participating.
Thanks much,
paul
12:56 p.m.
On 2020-08-16 05:20, Mark Matlock wrote:
Paul,
I look forward to seeing your HECnet mapper respond to topology changes.
I just set up CBVRP3 the primary router for area 30 to forward events to 28NH. Let me
know if there are any issues.
Your NCP syntax below worked perfectly for me in RSX once I defined the node 28NH. I
just put it also at the end of my network start-up command files to make it permanent.
Paul was also thinking about/referring to how to set it up in the
permanent DECnet configuration. In RSX, the tool for that is CFE.
However, CFE cannot set that up fully (I was a bit surprised when I
realized this). So the best is to just do what you have done, Mark. Turn
it on in NCP at boot time.
CFE can turn on the monitoring sink as such, but you cannot point that
to a node in CFE.
Johnny
Thanks and Best Regards,
Mark
--
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 Aug 15, 2020, at 1:42 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Gentlepeople,
I've added a new feature to the HECnet mapper (http://akdesign.dyndns.org:8080/map/)
to listen for topology change events and do incremental updates of the map as these
happen. You can see this in the current mapper display, which will show "Last
incremental change" in the map title block if there has been any incremental change
since the last full update.
For this to be most effective, the mapper needs to be sent these events from at least one
router in each area. A good choice would be the main backbone area router in each area;
better still all the backbone area routers if there are several.
So if you have one of these and are interested in participating, please do the equivalent
of this NCP command:
NCP>set logging monitor events 4.7-10,14-15,18-19 sink node 28nh
and of course the equivalent permanent command ("define" instead of
"set", and perhaps in a different utility at least for the case of RSX).
If you're running PyDECnet, you need to upgrade to the current version, rev 524.
Then add this line to the config file:
logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
When you set up a router for this, please drop me an email so I know which nodes are
currently participating.
Thanks much,
paul
5:37 p.m.
Paul Koning <paulkoning at comcast.net> wrote:
If you're running PyDECnet, you need to upgrade to the current version, rev
524.
When I do an
svn co svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet
the version of pyDECnet I get is 523, NOT 524. Is this just a typo?
With the logging monitor enabled as described, this version of pyDECnet
runs for a few seconds and then dies with
2020-08-16 08:35:19.836: A2RTR: Exception caught in mainloop
Traceback (most recent call last):
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/node.py"
, line 198, in mainloop
work.dispatch ()
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/timers.p
y", line 120, in dispatch
super ().dispatch ()
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/common.p
y", line 249, in dispatch
self.owner.dispatch (self)
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/statemac
hine.py", line 63, in dispatch
newstate = self.state (data)
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/nsp.py",
line 1387, in s0
raise InternalError ("S0 state not used")
decnet.common.InternalError: S0 state not used
2020-08-16 08:35:19.842: A2RTR: Stopping node
Bob
6:40 p.m.
On Aug 16, 2020, at 11:37 AM, Robert Armstrong <bob
at jfcl.com> wrote:
Yes, sorry. Sometimes I get mixed up about revs. The remote sink stuff was added in 520
and corrected in 521.
Paul Koning <paulkoning at comcast.net>
wrote:
If you're running PyDECnet, you need to upgrade to the current version, rev
524.
When I do an
svn co svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet
the version of pyDECnet I get is 523, NOT 524. Is this just a typo?
With the logging monitor enabled as described, this version of pyDECnet
runs for a few seconds and then dies with
2020-08-16 08:35:19.836: A2RTR: Exception caught in mainloop
Traceback (most recent call last):
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/node.py"
, line 198, in mainloop
work.dispatch ()
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/timers.p
y", line 120, in dispatch
super ().dispatch ()
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/common.p
y", line 249, in dispatch
self.owner.dispatch (self)
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/statemac
hine.py", line 63, in dispatch
newstate = self.state (data)
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/nsp.py",
line 1387, in s0
raise InternalError ("S0 state not used")
decnet.common.InternalError: S0 state not used
2020-08-16 08:35:19.842: A2RTR: Stopping node
Bob
Strange. Can you enable TRACE logging and email me the resulting log?
paul
6:46 p.m.
When I do
svn checkout svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet pydecnet.latest
it says I've checked out 524. I had to make the modification for the native TAP device
support in ethernet.py but other than that, it's fine.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul
Koning
Sent: 16 August 2020 17:40
To: Bob Armstrong <bob at jfcl.com>
Cc: <hecnet at update.uu.se> <hecnet at Update.UU.SE>
Subject: Re: [HECnet] HECnet mapper -- request to backbone node operators
On Aug 16, 2020, at 11:37 AM, Robert Armstrong <bob
at jfcl.com> wrote:
Yes, sorry. Sometimes I get mixed up about revs. The remote sink stuff was added in 520
and corrected in 521.
Paul Koning <paulkoning at comcast.net>
wrote:
If you're running PyDECnet, you need to upgrade to the current
version, rev
524.
When I do an
svn co svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet
the version of pyDECnet I get is 523, NOT 524. Is this just a typo?
With the logging monitor enabled as described, this version of
pyDECnet runs for a few seconds and then dies with
2020-08-16 08:35:19.836: A2RTR: Exception caught in mainloop Traceback
(most recent call last):
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/node.py"
, line 198, in mainloop
work.dispatch ()
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/ti
mers.p
y", line 120, in dispatch
super ().dispatch ()
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/co
mmon.p
y", line 249, in dispatch
self.owner.dispatch (self)
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/st
atemac
hine.py", line 63, in dispatch
newstate = self.state (data)
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/ns
p.py",
line 1387, in s0
raise InternalError ("S0 state not used")
decnet.common.InternalError: S0 state not used
2020-08-16 08:35:19.842: A2RTR: Stopping node
Bob
Strange. Can you enable TRACE logging and email me the resulting log?
paul
17 Aug
17 Aug
2:13 a.m.
Hi Paul,
i've upgraded A35RTR on 35.1023 to PyDECnet 526 and put in the logging line as
requested.
as per Keith, i also had to make the changes to TapEth so i could speak to /dev/net/tun.
this is the same as i've done previously - but I actually had a recollection that this
change had actually been rolled into one of the previous builds? perhaps i'm wrong.
i have one query - i run PyDECnet as a daemon and normally my local log files show up/down
route visibility. i assume with the "logging monitor" line that this
functionality is changed? is there a way to set the logging so I can see the up/down in
the network as i did previously?
if it matters, i was on version 488 and did a fresh install of 526.
many thanks,
cheers, Wiz!!
________________________________
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> on behalf of Keith
Halewood <Keith.Halewood at pitbulluk.org>
Sent: Monday, 17 August 2020 2:46:41 AM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] HECnet mapper -- request to backbone node operators
When I do
svn checkout svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet pydecnet.latest
it says I've checked out 524. I had to make the modification for the native TAP device
support in ethernet.py but other than that, it's fine.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul
Koning
Sent: 16 August 2020 17:40
To: Bob Armstrong <bob at jfcl.com>
Cc: <hecnet at update.uu.se> <hecnet at Update.UU.SE>
Subject: Re: [HECnet] HECnet mapper -- request to backbone node operators
On Aug 16, 2020, at 11:37 AM, Robert Armstrong <bob
at jfcl.com> wrote:
Yes, sorry. Sometimes I get mixed up about revs. The remote sink stuff was added in 520
and corrected in 521.
Paul Koning <paulkoning at comcast.net>
wrote:
If you're running PyDECnet, you need to upgrade to the current
version, rev
524.
When I do an
svn co svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet
the version of pyDECnet I get is 523, NOT 524. Is this just a typo?
With the logging monitor enabled as described, this version of
pyDECnet runs for a few seconds and then dies with
2020-08-16 08:35:19.836: A2RTR: Exception caught in mainloop Traceback
(most recent call last):
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/node.py"
, line 198, in mainloop
work.dispatch ()
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/ti
mers.p
y", line 120, in dispatch
super ().dispatch ()
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/co
mmon.p
y", line 249, in dispatch
self.owner.dispatch (self)
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/st
atemac
hine.py", line 63, in dispatch
newstate = self.state (data)
File
"/usr/local/lib/python3.6/dist-packages/decnet-1.0-py3.6.egg/decnet/ns
p.py",
line 1387, in s0
raise InternalError ("S0 state not used")
decnet.common.InternalError: S0 state not used
2020-08-16 08:35:19.842: A2RTR: Stopping node
Bob
Strange. Can you enable TRACE logging and email me the resulting log?
paul
2:40 a.m.
David Moylan <djm at wiz.net.au> wrote:
as per Keith, i also had to make the changes to TapEth so i could speak to
/dev/net/tun.
FWIW, I just use pcap to talk to a tap device. Works fine, and no patches
to pyDECnet required.
i run PyDECnet as a daemon and normally my local log
files show up/down
route visibility.
i assume with the "logging monitor" line
that this functionality is
changed?
Same here, and my log files still show up/down events.
Say, Paul - now that we have the HECnet status reported to a single point,
how about a way for anybody to subscribe to network events? Perhaps by
email or SMS??
Bob
2:49 a.m.
Not sure you'd want a message for every event, or even significant change. I see
plenty just on Mim every hour.
Johnny
Robert Armstrong <bob at jfcl.com> skrev: (17 augusti 2020 02:40:17 CEST)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
David Moylan
<djm at wiz.net.au> wrote:
as per Keith, i also had to make the changes to TapEth so i could
speak to
/dev/net/tun.
FWIW, I just use pcap to talk to a tap device. Works fine, and no
patches
to pyDECnet required.
i run PyDECnet as a daemon and normally my local
log files show
up/down
route visibility.
i assume with the "logging monitor"
line that this functionality is
changed?
Same here, and my log files still show up/down events.
Say, Paul - now that we have the HECnet status reported to a single
point,
how about a way for anybody to subscribe to network events? Perhaps by
email or SMS??
Bob
3:09 a.m.
Same here, and my log files still show up/down
events.
i wonder if the issue isn't related to the line i added for Paul, but rather some
behavioral change between 488 and 526 which requires some config update?
i've never had any line in my config in relation to debug or informational logs - just
the log file definition on the daemon startup script.
previously when i started PyDECnet i used to get lines like:
2020-07-12 14:25:28.891: A35RTR: Starting DECnet/Python DECnet/Python V1.0-488
2020-07-12 14:25:28.897: A35RTR: Running as daemon
2020-07-12 14:25:28.902: A35RTR: Event type 2.0, Local node state change
From node 35.1023 (A35RTR), occurred 12-Jul-2020 14:25:28.902
Reason = Operator command
Old state = Off
New state = On
2020-07-12 14:25:29.967: A35RTR: Event type 4.15, Adjacency up
From node 35.1023 (A35RTR), occurred 12-Jul-2020 14:25:29.967
Circuit = GRE-12
Adjacent node = 12.1023 (A12RTR)
2020-07-12 14:25:30.351: A35RTR: Event type 4.15, Adjacency up
From node 35.1023 (A35RTR), occurred 12-Jul-2020 14:25:30.351
Circuit = GRE-31
Adjacent node = 31.1023 (IMPRTR)
and the various up/down notifications as areas go up and down as expected.
but now all i get is:
2020-08-17 10:06:24.616: A35RTR: Starting DECnet/Python DECnet/Python V1.0-526
2020-08-17 10:06:24.624: A35RTR: Logging configuration reloaded
2020-08-17 10:06:24.624: A35RTR: Now running as daemon
is there something i require in my pydecnet.conf or when i'm running the daemon that i
might be missing?
cheers, Wiz!!
________________________________
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> on behalf of
Robert Armstrong <bob at jfcl.com>
Sent: Monday, 17 August 2020 10:40:17 AM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] HECnet mapper -- request to backbone node operators
David Moylan <djm at wiz.net.au> wrote:
as per Keith, i also had to make the changes to TapEth so i could speak to /dev/net/tun.
FWIW, I just use pcap to talk to a tap device. Works fine, and no patches to pyDECnet
required.
i run PyDECnet as a daemon and normally my local log
files show up/down route visibility.
i assume with the "logging monitor" line that this functionality is changed?
Same here, and my log files still show up/down events.
Say, Paul ? now that we have the HECnet status reported to a single point, how about a
way for anybody to subscribe to network events? Perhaps by email or SMS??
Bob
3:18 a.m.
i've never had any line in my config in relation to
debug or informational
logs -
just the log file definition on the daemon startup
script.
I have a whole yaml file for logging, which is mostly taken verbatim from
Paul's example. I get tons of logged events - starting circuits, starting
datalinks, nodes up, areas up, routers discovered, etc. It doesn't seem
like it's changed with this release. You might try that.
For example, an hour ago I just got
2020-08-16 17:06:07.775: A2RTR: Event type 4.7, Circuit down, circuit fault
From node 2.1023 (A2RTR), occurred 16-Aug-2020 17:06:07.775
Circuit = MUL-35
Reason = Circuit synchronization lost
Adjacent node = 35.1023 (A35RTR)
2020-08-16 17:06:28.432: A2RTR: Event type 4.10, Circuit up
From node 2.1023 (A2RTR), occurred 16-Aug-2020 17:06:28.432
Circuit = MUL-35
Adjacent node = 35.1023 (A35RTR)
Bob
3:39 a.m.
I have a whole yaml file for logging, which is mostly
taken verbatim from Paul?s example. I get tons of logged events ? starting circuits,
starting datalinks, nodes up, areas up, routers >discovered, etc. It doesn?t seem like
it?s changed with this release. You might try that.
ok so you got me curious about this and i worked it out. i'm not using any of the
yaml/json config files for logging, so the default logging goes to the console.
by adding "logging console" to the config i get all the events as expected into
my log file as specified on the startup command line.
but i have one query for paul:
is it valid to have both "logging monitor" and the "logging console"
enabled together in the configuration file?
i want to make sure that i'm pushing data to your sink-node and that by enabling
"logging console" i'm not reverting/overriding that part of the config.
otherwise i need to implement this other logging config.
cheers, Wiz!!
________________________________
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> on behalf of
Robert Armstrong <bob at jfcl.com>
Sent: Monday, 17 August 2020 11:18:27 AM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] HECnet mapper -- request to backbone node operators
i've never had any line in my config in relation to
debug or informational logs ?
just the log file definition on the daemon startup
script.
I have a whole yaml file for logging, which is mostly taken verbatim from Paul?s
example. I get tons of logged events ? starting circuits, starting datalinks, nodes up,
areas up, routers discovered, etc. It doesn?t seem like it?s changed with this release.
You might try that.
For example, an hour ago I just got
2020-08-16 17:06:07.775: A2RTR: Event type 4.7, Circuit down, circuit fault
From node 2.1023 (A2RTR), occurred 16-Aug-2020 17:06:07.775
Circuit = MUL-35
Reason = Circuit synchronization lost
Adjacent node = 35.1023 (A35RTR)
2020-08-16 17:06:28.432: A2RTR: Event type 4.10, Circuit up
From node 2.1023 (A2RTR), occurred 16-Aug-2020 17:06:28.432
Circuit = MUL-35
Adjacent node = 35.1023 (A35RTR)
Bob
3:19 p.m.
On Aug 16, 2020, at 9:39 PM, David Moylan <djm at
wiz.net.au> wrote:
Absolutely.
The old code was logging events to the Python log -- which is meant to be the
"logging console" even if they were going to other sinks and not to console. I
fixed that.
PyDECnet implements the DECnet logging model, which has three sink types, console, file,
and monitor, and both local and remote sinks for each. Any sink type and sink destination
has its own event filters. All this was enabled in the current rev (or actually in 521).
For example, on my core router (PYTHON), I have this config setting:
logging console
logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
For local logging console, the default --events is all events; for all others the default
event filter is no events. So for example the following is valid. Perhaps not terribly
sensible, but valid:
logging console
logging file --sink-file events.dat --events *.*
logging console --sink-node ni1d --events 4.*
logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
This means: all events go to the local console, i.e., the Python log. All events also go
to event file events.dat (in RMS VAR format records containing the binary encoded events).
All events in class 4 go to the console of node ni1d, and the mapping events go to the
mapper.
paul
I have a whole yaml file for logging, which is
mostly taken verbatim from Paul?s example. I get tons of logged events ? starting
circuits, starting datalinks, nodes up, areas up, routers >discovered, etc. It doesn?t
seem like it?s changed with this release. You might try that.
ok so you got me curious about this and i worked it out. i'm not using any of the
yaml/json config files for logging, so the default logging goes to the console.
by adding "logging console" to the config i get all the events as expected into
my log file as specified on the startup command line.
but i have one query for paul:
is it valid to have both "logging monitor" and the "logging console"
enabled together in the configuration file?
16 Aug
16 Aug
7:37 p.m.
A clarification: I'm looking for an event source for each area. Even if your area
only has a single connection to other areas, it's useful to have an event source
there. The reason is that change of node reachability is visible only to routers in the
area, and this is one of the events I'm looking for.
paul
On Aug 15, 2020, at 2:42 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Gentlepeople,
I've added a new feature to the HECnet mapper (http://akdesign.dyndns.org:8080/map/)
to listen for topology change events and do incremental updates of the map as these
happen. You can see this in the current mapper display, which will show "Last
incremental change" in the map title block if there has been any incremental change
since the last full update.
For this to be most effective, the mapper needs to be sent these events from at least one
router in each area. A good choice would be the main backbone area router in each area;
better still all the backbone area routers if there are several.
So if you have one of these and are interested in participating, please do the equivalent
of this NCP command:
NCP>set logging monitor events 4.7-10,14-15,18-19 sink node 28nh
and of course the equivalent permanent command ("define" instead of
"set", and perhaps in a different utility at least for the case of RSX).
If you're running PyDECnet, you need to upgrade to the current version, rev 524.
Then add this line to the config file:
logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
When you set up a router for this, please drop me an email so I know which nodes are
currently participating.
Thanks much,
paul
8:10 p.m.
I have done this from a SIMH instance that is set as a routing node. My own
user mode router does not implement these events.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf
Of Paul Koning
Sent: 16 August 2020 18:37
To: hecnet at Update.UU.SE
Subject: [HECnet] Re: HECnet mapper -- request to backbone node operators
A clarification: I'm looking for an event source for each area. Even if
your
area
only has a single connection to other areas, it's
useful to have an event
source
there. The reason is that change of node reachability
is visible only to
routers
in the area, and this is one of the events I'm
looking for.
paul
events
On Aug 15, 2020, at 2:42 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Gentlepeople,
I've added a new feature to the HECnet mapper
(http://akdesign.dyndns.org:8080/map/) to listen for topology change and do incremental updates of the map as these happen.
You can see this
in
the current mapper display, which will show "Last
incremental change" in
the
map title block if there has been any incremental
change since the last
full
update.
>
> For this to be most effective, the mapper needs to be sent these events
from
at least one router in each area. A good choice would
be the main
backbone
area router in each area; better still all the
backbone area routers if
there are
several.
>
> So if you have one of these and are interested in participating, please
do
the
equivalent of this NCP command:
>
> NCP>set logging monitor events 4.7-10,14-15,18-19 sink node 28nh
>
> and of course the equivalent permanent command ("define" instead of
"set",
and perhaps in a different utility at least for the
case of RSX).
>
> If you're running PyDECnet, you need to upgrade to the current version,
rev
524. Then add this line to the config file:
>
> logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
>
> When you set up a router for this, please drop me an email so I know
which
nodes are currently participating.
>
> Thanks much,
> paul
>
17 Aug
17 Aug
12:48 a.m.
Paul,
I see this logged:
Aug 16 22:43:26 2020-08-16 22 43:25.975: PYRTR: Event sender connected
to 41.28 (28NH)
Regards
/s.
On 8/16/20 1:37 PM, Paul Koning wrote:
A clarification: I'm looking for an event source
for each area. Even if your area only has a single connection to other areas, it's
useful to have an event source there. The reason is that change of node reachability is
visible only to routers in the area, and this is one of the events I'm looking for.
paul
> On Aug 15, 2020, at 2:42 PM, Paul Koning <paulkoning at comcast.net> wrote:
>
> Gentlepeople,
>
> I've added a new feature to the HECnet mapper
(http://akdesign.dyndns.org:8080/map/) to listen for topology change events and do
incremental updates of the map as these happen. You can see this in the current mapper
display, which will show "Last incremental change" in the map title block if
there has been any incremental change since the last full update.
>
> For this to be most effective, the mapper needs to be sent these events from at least
one router in each area. A good choice would be the main backbone area router in each
area; better still all the backbone area routers if there are several.
>
> So if you have one of these and are interested in participating, please do the
equivalent of this NCP command:
>
> NCP>set logging monitor events 4.7-10,14-15,18-19 sink node 28nh
>
> and of course the equivalent permanent command ("define" instead of
"set", and perhaps in a different utility at least for the case of RSX).
>
> If you're running PyDECnet, you need to upgrade to the current version, rev 524.
Then add this line to the config file:
>
> logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
>
> When you set up a router for this, please drop me an email so I know which nodes are
currently participating.
>
> Thanks much,
> paul
>
--
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
1558
days inactive
1560
days old
18 comments
8 participants
participants (8)
-
bob＠jfcl.com -
bqt＠softjar.se -
djm＠wiz.net.au -
Keith.Halewood＠pitbulluk.org -
mark＠matlockfamily.com -
paulkoning＠comcast.net -
robert.jarratt＠ntlworld.com -
supratim＠riseup.net