HECnet

hecnet@lists.dfupdate.se

1 participants
15560 discussions

_PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by hvlems＠zonnet.nl

Area 44 is also missing. Anything I ought to have done? Hans -----Original Message----- From: Brian Hechinger <wonko at 4amlunch.net> Sender: owner-hecnet at Update.UU.SE Date: Tue, 08 Jan 2013 09:33:27 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SE Subject: Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H. On 1/7/2013 9:25 PM, Ian McLaughlin wrote: Sampsa, I appear to be missing. Are you able to add me? No, you are missing because you can't currently be found. We'll find you, be patient. :) My area router is A42RTR 42.1023. It is adjacent to SUN 52.1 and GW 61.1. Unfortunately for your scanning program, 42.1023 is a Cisco router. Yeah, Cisco routers have yet to be tackled. -brian

12 years, 5 months

MOP vs. Cisco, was Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by wonko＠4amlunch.net

On 1/8/2013 9:28 AM, Johnny Billquist wrote: On 2013-01-08 07:02, Dave McGuire wrote: On 01/08/2013 12:53 AM, Ian McLaughlin wrote: The problem with ssh is it's "out of band" as far as hecnet is concerned. It would be nice if the discovery was purely decnet. True. Well, if one can define access lists using DECnet addresses as filter terms, I'd be ok with that, for nonprivileged access. I've just verified that a MOP console request works from Linux using locally-stored authentication on the IOS side to establish a nonprivileged IOS CLI session on a 7206VXR running IOS 12.3(22), like so: $ moprc -v <MAC address> ...and like this from NCP under VMS: NCP> connect node gw physical address <MAC address> via <circuit-name> Note that the MAC address must have its octets delimited by colons under Linux, and hyphens under VMS. This is a service (protocol?) called Console Carrier Request. If you have Phase V, I think you use SET HOST/MOP under VMS. Under RSX, there is a special program called CCR that you use. And correct, this is not a routed protocol, so you need to be on the local network, and you cannot go through NCP on another machine using TELL. :-) I'm going to play with this. I think this is the solution to keeping cisco queries in-band. I'll report back on how I plan on using this. -brian

12 years, 5 months

_PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by wonko＠4amlunch.net

On 1/7/2013 9:25 PM, Ian McLaughlin wrote: Sampsa, I appear to be missing. Are you able to add me? No, you are missing because you can't currently be found. We'll find you, be patient. :) My area router is A42RTR 42.1023. It is adjacent to SUN 52.1 and GW 61.1. Unfortunately for your scanning program, 42.1023 is a Cisco router. Yeah, Cisco routers have yet to be tackled. -brian

12 years, 5 months

_PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by wonko＠4amlunch.net

On 1/7/2013 7:57 PM, Cory Smelosky wrote: On 7 Jan 2013, at 19:54,sampsa at mac.com wrote: >If we can't walk it by NCP, resutls are unpredictable. You can, it just kinda has infinite loops and whatnot. My code won't query a router more than once so loops are a non-issue. -brian

12 years, 5 months

MOP vs. Cisco, was Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by bqt＠softjar.se

On 2013-01-08 07:02, Dave McGuire wrote: On 01/08/2013 12:53 AM, Ian McLaughlin wrote: The problem with ssh is it's "out of band" as far as hecnet is concerned. It would be nice if the discovery was purely decnet. True. Well, if one can define access lists using DECnet addresses as filter terms, I'd be ok with that, for nonprivileged access. I've just verified that a MOP console request works from Linux using locally-stored authentication on the IOS side to establish a nonprivileged IOS CLI session on a 7206VXR running IOS 12.3(22), like so: $ moprc -v <MAC address> ...and like this from NCP under VMS: NCP> connect node gw physical address <MAC address> via <circuit-name> Note that the MAC address must have its octets delimited by colons under Linux, and hyphens under VMS. This is a service (protocol?) called Console Carrier Request. If you have Phase V, I think you use SET HOST/MOP under VMS. Under RSX, there is a special program called CCR that you use. And correct, this is not a routed protocol, so you need to be on the local network, and you cannot go through NCP on another machine using TELL. :-) Johnny

12 years, 5 months

Area 48.....

by wonko＠4amlunch.net

On 1/7/2013 4:25 PM, Rob Jarratt wrote: One of my plans was to extend the user mode router I wrote to interoperate with Cisco. I don't believe it is all that hard to do. The code is written to make this fairly easy. As long as your router can talk to any interface it's just a matter of setting up a tunnel (GRE, IPsec, etc) on the host to connect to the cisco. You shouldn't need to do anything other than that. -brian

12 years, 5 months

Area 48.....

by wonko＠4amlunch.net

On 1/7/2013 4:26 PM, Rob Jarratt wrote: Because the one downside of the Cisco's is they don't speak NICE. It would >be awesome if they did. > And adding NICE is also something I was thinking of adding to the user mode router, but that is a bigger job than interoperating with Cisco I think. Regards I'd prefer NICE over cisco integration. :) -brian

12 years, 5 months

subnet info, was Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by bqt＠softjar.se

I'm probably going to come back and make more comments on this later... However, a couple of points and responses right now... Eve today, areas do not correspond to adminstrative control that much. There are areas which have several different people responsible for different machines, and atleast I have "sub-delegated" parts of area 1 from time to time. Yes, we will be running out of areas eventually. Based on the current growth, I'd guess a couple of years at most, and then we're out. Areas should be used for administrative reasons, and relate less to any geographical constraints. DECnet areas work perfectly fine spanning large distances. "Sub-letting" areas should definitely be a valid approach. Each user in one area can still have their own area router, and their own connections to the rest of HECnet, as long as they also have interconnects within the area. Data mining is difficult, since there are different systems, with different possibilities of extracting it, and in different formats. A centralized repository of data is nice in many ways, but it is a headache to manage. That said, I could be convinced of setting something semi-automatic up. A reasonable way would be for people to give me machines to poll, and then I'd setup an automated process to poll those machines for files in a specific format. I can then create a database out of that, and make it available through the web, as well as over DECnet, and also as a summarized file. Anything would be pretty easy if we just have the data collected. I already have something of a start for this in the form of my database of nodes in HECnet. I'd need to extend it with more fields, but that would be pretty easy. It's all in Datatrieve today, and that should be accessible over DECnet right now (even though I seem to remember that VMS hosts had some problems with that). I'm already extracting information from that database for the hecnet web-page on MIM (accessible as Madame). So, if we can just decide on what we want, and how to make the information available, I'll sit down and write the code to fix it. Johnny On 2013-01-08 06:45, Cory Smelosky wrote: On 8 Jan 2013, at 00:25, Dave McGuire <mcguire at neurotica.com> wrote: On 01/07/2013 09:57 PM, Ian McLaughlin wrote: Yeah more and more of us are using Ciscos to do this. We really need to find a way around this issue that doesn't involve manual maintenance of routing info. Perhaps an agreed-upon entry in INFO.TXT ? That's still manually managed, but it's managed by the individual link owners. Well Brian raised the good point of "on which host?" ...I think the problem here is that INFO.TXT really looks like, to me as a relative HECnet n00b, a per-"domain" file...but there's no clear delineation of administrative domains here. We've been using areas, but we're running out of those, and there's no consistency in the node numbering within each area. We could all agree to have "an info node" with a particular node number within each area, but that won't work when we start having multiple administrative domains within a single area. Johnny talked about exactly this just today, in the context of Sampsa's relocation. Dividing lines between regions of administrative control will not correspond to area numbers for much longer, its sounds like. Yeah, I've been noticing that...I've up-to-now used a specific "info node" approach...but it DOES get a bit wonky when I divide my stuff, or skip a node number or re-use a node number. (On a semi-related note...I might implement personal node-number schemes: separating PDP-11 sims from DEC-20 sims from VMS sims from physical hardware and so on.) Perhaps a centralized database that maintains per-NODE info, not per-AREA info. Then that database could have a field that denotes the point of administrative control that is responsible for each node. Centralising the NODE info could solve a lot of problems and make data mining easier. ;) I'd also like basic (Geographic location(s) (see below for further comments), owner, that kind of stuff) per-area info to be defined in this central database. (To be honest, I'd then break it down in to sub, and sub sub areas but at times I can go a bit overboard with creating subcategories...I doubt anyone other than myself would like breaking down their areas /that/ much.) Then, some mechanism (either automated, manual, whatever) would then populate that database. Perhaps there could be several population mechanisms...a program that runs under VMS, RSX, RSTS/E, or whatever, and something over IP for everything else. A web interface to the database would also be nice. How would it be done? Flatfile and having Johnny or someone add all node info by hand? ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 5 months

MOP vs. Cisco, was Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by roll＠Stupi.SE

=46rom NCP? You can't do a "tell node connect..." Type thing can you? The p= roblem is MOP isn't routed so a connection to the router would have to happe= n from something local. "Tell" speaks NML, cisco only implements Decnet routing and forwaring, l2 and l3..... -P Ian Sent from my iPad On 2013-01-07, at 10:02 PM, Dave McGuire <mcguire at neurotica.com> wrote: On 01/08/2013 12:53 AM, Ian McLaughlin wrote: The problem with ssh is it's "out of band" as far as hecnet is concerned. It would be nice if the discovery was purely decnet. =20 True. =20 Well, if one can define access lists using DECnet addresses as filter terms, I'd be ok with that, for nonprivileged access. =20 I've just verified that a MOP console request works from Linux using locally-stored authentication on the IOS side to establish a nonprivileged IOS CLI session on a 7206VXR running IOS 12.3(22), like so: =20 $ moprc -v <MAC address> =20 ...and like this from NCP under VMS: =20 NCP> connect node gw physical address <MAC address> via <circuit-name> =20 Note that the MAC address must have its octets delimited by colons under Linux, and hyphens under VMS. =20 -Dave =20 --=20 Dave McGuire, AK4HZ New Kensington, PA =20 =20 --- Filter service subscribers can train this email as spam or not-spam here: = http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=3D0AB18D20595911= E28A4BA96E93ED0201

12 years, 5 months

MOP vs. Cisco, was Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by mcguire＠neurotica.com

On 01/08/2013 02:22 AM, Gregg Levine wrote:

12 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet