Mine is residential service, that seems to explain the difference. I just found a Comcast document that confirms port 161 is blocked. If I can get proxies for interesting Cisco HECnet routers I can consider adding mapper support for that. I just found a trivial UDP proxy (to a single destination): https://github.com/EtiennePerot/misc-scripts/blob/master/udp-relay.py -- something a bit more complex could allow talking to several destinations, but this one may be good enough. paul

I guess you can call Comcast "not real Internet" :-) Anyway, sure, if someone can supply a suitable host for it. It's not a particularly demanding application -- a PyDECnet endnode that occasionally wakes up to do some NICE requests. paul

A "real internet" forwards a correctly formed IPv6 or IPv4 packet from Node A to Node B regardless of it's content and properly sends the required ICMP messages back to the sender as specified in the RFC's. -P

All of that aside, I would actually be more exited if all Cisco boxes went away. It's really annoying to not be able to troubleshoot anything on a Cisco box, when a Cisco box is in the path of something I want to check. Johnny On 2021-11-30 19:39, Steve Davidson wrote: -- 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

Ditto on that! They don't speak NML and you can't talk to them with NCP. They're not very exciting things to have on a DECnet network... Bob

Time? Knowledge? Money for new hardware? I hope we are not going to start making rules about what is and is not allowed on the network. Ian

On 11/30/21 4:15 PM, Paul Koning wrote: The network infrastructure here is Cisco. There's a biggish Cisco router and a dozen Cisco switches on the network, spanning several floors across three buildings. None of that is going away. I view DECnet routing, as all other types of network routing, to be a part of the infrastructure. I could, with a bit of effort, be convinced to move the DECnet part of that infrastructure from a built-like-a-tank Cisco infrastructure appliance onto a server. It's true that some other parts of the low-level infrastructure here, such as DNS, DHCP, etc, run on servers as well, so it wouldn't be completely unprecedented. It's just not how I'm accustomed to designing and running commercial networks, which is something that I've been doing essentially the same way for a few decades. If someone can present to me cogent arguments for moving away from GRE tunnels on a Cisco onto a Python program running on a server that doesn't involve "I hate Cisco" (which, while not explicitly stated, comes through loud and clear in a number of these threads), and perhaps offer some guidance and assistance in the configuration, it's something that I would consider doing. There are eleven DECnet tunnels terminating here; I also have to consider the impact it would have on those people. The big point for us is that DECnet/HECnet connectivity here isn't just some recreational thing that exists on a Raspberry Pi on the dining room table for play every now and then. It's up 24/7 like the rest of the network, so that when any system at the museum that is DECnet-capable boots up, it's online. When visitors show up at the museum, they expect things to work, as that's what we advertise. We frequently demo HECnet to visitors. We also have plans coming together for a more extensive 24/7 presence on HECnet, other than the big Cisco router and the Itanium2 VMS machine that are always up. So anything that replaces the Cisco in this capacity must be a "set it and forget it" thing, essentially 100% maintenance-free, etc, just like the Cisco. I do have a minor issue with performance-sensitive infrastructure code being written in the lumbering pig that is Python, but that's a personal prejudice and I can ignore it. I understand why that choice was made. So, talk to me about these things. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

Just wanted to say thank you all for responding to my original request. Johnny - the part of the MIB most people posted here makes it less of a black hole; it tells you the areas, hops and cost the Cisco sees when you are calculating why some area is going through North America for example. You could ask for a confidential read-only password from Cisco owners. foobar for mine will continue to work. Regards Supratim --- Supratim Sanyal, W1XMT QCOCAL::SANYAL via HECnet

Some brilliant soul has already written an IP stack for RSX. ;) An SNMP implementation would seem to be a logical thing to do. -Dave On 12/1/21 6:56 AM, Johnny Billquist wrote: -- Dave McGuire, AK4HZ New Kensington, PA

On 2021-11-30 21:22, Ian McLaughlin wrote: I'd expect that money for hardware would not be a thing, since you can run that on a silly RPi for a few bucks. But the other reasons are certainly true sometimes. We are not. Anything that can speak DECnet is welcome. I'm just expressing a bit of frustration in that the Cisco boxes are really the most opaque. The fact that people are trying to adopt SNMP to just get some stuff out that all other nodes can provide within the DECnet domain says it all. But no, we should never exclude anything based on this. As long as it can communicate, it should be allowed. 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 11/30/21 3:17 PM, Peter Lothberg wrote: It will in a few months (years?). Just you wait and see. :) --

Paul, On 11/30/21 12:20 PM, Paul Koning wrote: I just NAT'd it; this should work for you: *snmpwalk -v2c -c foobar hecnet-us-east-gw.duckdns.org:31161 1.3.6.1.4.1.9.3.1.26* /s.

On 11/30/21 2:47 PM, Paul Koning wrote: The owners of these boxes probably have to give you a community string ... ?tunnel destination 73.223.113.75 ?tunnel destination 163.47.57.118 ?tunnel destination 81.138.115.178 ?tunnel destination 71.246.8.102 ?tunnel destination 76.25.105.11 ?tunnel destination 86.87.9.111 ?tunnel destination 81.236.171.34 ?tunnel destination 203.30.197.254 ?tunnel destination 73.60.223.101 ?tunnel destination 208.73.57.126 ?tunnel destination 24.98.27.217 ?tunnel destination 192.108.197.26 ?tunnel destination 50.73.179.1 ?tunnel destination 192.108.200.213 --

Works here too, with Sonic.net/AT&Tmp;T. bob at ziti:~$ snmpwalk -v2c -c foobar hecnet-us-east-gw.duckdns.org iso.3.6.1.2.1.1.1.0 = STRING: "Cisco IOS Software, 7200 Software (C7200-A3JK9S-M), Version 12.4(25d), RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Wed 18-Aug-10 11:54 by prod_rel_team" iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.9.1.222 iso.3.6.1.2.1.1.3.0 = Timeticks: (157403629) 18 days, 5:13:56.29 iso.3.6.1.2.1.1.4.0 = STRING: "\"supratim at riseup dot net\"" iso.3.6.1.2.1.1.5.0 = STRING: "IMPRTR.sanyalnet.lan" iso.3.6.1.2.1.1.6.0 = STRING: "\"Ashburn, Virginia, United States\"" iso.3.6.1.2.1.1.7.0 = INTEGER: 78 iso.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00 ... Bob