4 May
2020
4 May
'20
11:11 p.m.
Probably the same one I use for the tunnel manager.
It's pretty simple to use.
-brian
On May 4, 2020, 16:26 -0400, Paul Koning <paulkoning at comcast.net>, wrote:
On May 4, 2020, at 3:58 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2020-05-04 19:39, Paul Koning wrote:
I could certainly extend it with that...
True, and that certainly is a good argument to do the change. To make matters easy, it
turns out there is an SNMP library for Python.
paul
On May 4,
2020, at 1:35 AM, Tim Sneddon <tim at sneddon.id.au> wrote:
On Mon, May 4, 2020 at 1:57 AM Peter Lothberg <roll at stupi.com> wrote:
The Cisco DECnet router implementation does not speak "decnet management" as
we all knew. The way we are using them the tunnel end-points are on the Internet.
Most of the information "missing" is actually available through the SNMP MIB,
so if we could agree on a common read-only community and publish the IP addresses
of those routers it would be possible to complete Paul's map..
I would definitely be up for that. Maybe "hecnet-ro" for the community name?
Regards, Tim.
Nice idea. I can certainly do this. To make it work, the node
database would have to list IP addresses for MIB access. The fact that the Cisco routers don't speak
NICE isn't always a problem. If they have neighbors that do I still get the
information, since I will chart a circuit even if only one of the two sides tells me about
it.
If there is a chain of Cisco routers, the one in the middle of the chain wouldn't be
mapped. But, for example, an area served by a Cisco area router would be, since the mapper
will try to talk to the nodes in the area and ask them what their view of the neighborhood
looks like.
Well, that's not entirely enough. This means there are some major links that are not
visible. Yes, you can see that there are a Cisco box here, and a Cisco box there, but you
cannot see that they are connected.