That would explain why I can't push a config to you. :)
-brian
On 2/27/2013 4:15 PM, Cory Smelosky wrote:
On 27 Feb 2013, at 16:13, Brian Hechinger <wonko at 4amlunch.net> wrote:
Or you can go the dynamips/GNS3 route like Cory did.
Which will be back up once my network migration is complete. I'm in the middle of moving things to a big Sun and moving to a /16 internally instead of a /24 for administrative reasons.
-brian
On 2/27/2013 4:12 PM, Ian McLaughlin wrote:
Excellent work! I think this tool is a great asset to HECnet. We just need a bit of promotion now. People are scared of Cisco equipment, but you can pick up a low-end router for $50 on ebay and it gives you everything you need to connect to HECnet.
Ian
On 2013-02-27, at 12:29 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
On 2/27/2013 3:25 PM, Dave McGuire wrote:
On 02/27/2013 03:10 PM, Brian Hechinger wrote:
The tunnel now does everything in the TODO exact that last one about
only sending configs out to only those who need them.
It now supports:
SNMP is now handled directly in python so no calling external scripts.
This allows for much better control over what happens when a router
doesn't respond.
IPSec tunnels as well as GRE tunnels (well, kinda, I still need to get a
working cisco config snippet to use, haven't done that yet)
mesh/hub/spoke topology. Each endpoint (router) can be designated one of
either hub, mesh or spoke. A spoke will only connect to a hub. hubs and
mesh will all connect to each other.
That's a damn fine piece of work!
Thank you! It's been a blast to write.
Much love to Paul for his python assistance. :)
-brian
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=6C0106D8811C11E28…
On 27 Feb 2013, at 16:13, Brian Hechinger <wonko at 4amlunch.net> wrote:
Or you can go the dynamips/GNS3 route like Cory did.
Which will be back up once my network migration is complete. I'm in the middle of moving things to a big Sun and moving to a /16 internally instead of a /24 for administrative reasons.
-brian
On 2/27/2013 4:12 PM, Ian McLaughlin wrote:
Excellent work! I think this tool is a great asset to HECnet. We just need a bit of promotion now. People are scared of Cisco equipment, but you can pick up a low-end router for $50 on ebay and it gives you everything you need to connect to HECnet.
Ian
On 2013-02-27, at 12:29 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
On 2/27/2013 3:25 PM, Dave McGuire wrote:
On 02/27/2013 03:10 PM, Brian Hechinger wrote:
The tunnel now does everything in the TODO exact that last one about
only sending configs out to only those who need them.
It now supports:
SNMP is now handled directly in python so no calling external scripts.
This allows for much better control over what happens when a router
doesn't respond.
IPSec tunnels as well as GRE tunnels (well, kinda, I still need to get a
working cisco config snippet to use, haven't done that yet)
mesh/hub/spoke topology. Each endpoint (router) can be designated one of
either hub, mesh or spoke. A spoke will only connect to a hub. hubs and
mesh will all connect to each other.
That's a damn fine piece of work!
Thank you! It's been a blast to write.
Much love to Paul for his python assistance. :)
-brian
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=6C0106D8811C11E28…
On 27 Feb 2013, at 16:12, Ian McLaughlin <ian at platinum.net> wrote:
Excellent work! I think this tool is a great asset to HECnet. We just need a bit of promotion now. People are scared of Cisco equipment, but you can pick up a low-end router for $50 on ebay and it gives you everything you need to connect to HECnet.
Yes, Excellent work!
Well, I need a Cisco 7200 chassis. Those are a bit more than $50. ;)
Ian
On 2013-02-27, at 12:29 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
On 2/27/2013 3:25 PM, Dave McGuire wrote:
On 02/27/2013 03:10 PM, Brian Hechinger wrote:
The tunnel now does everything in the TODO exact that last one about
only sending configs out to only those who need them.
It now supports:
SNMP is now handled directly in python so no calling external scripts.
This allows for much better control over what happens when a router
doesn't respond.
IPSec tunnels as well as GRE tunnels (well, kinda, I still need to get a
working cisco config snippet to use, haven't done that yet)
mesh/hub/spoke topology. Each endpoint (router) can be designated one of
either hub, mesh or spoke. A spoke will only connect to a hub. hubs and
mesh will all connect to each other.
That's a damn fine piece of work!
Thank you! It's been a blast to write.
Much love to Paul for his python assistance. :)
-brian
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=6C0106D8811C11E28…
Or you can go the dynamips/GNS3 route like Cory did.
-brian
On 2/27/2013 4:12 PM, Ian McLaughlin wrote:
Excellent work! I think this tool is a great asset to HECnet. We just need a bit of promotion now. People are scared of Cisco equipment, but you can pick up a low-end router for $50 on ebay and it gives you everything you need to connect to HECnet.
Ian
On 2013-02-27, at 12:29 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
On 2/27/2013 3:25 PM, Dave McGuire wrote:
On 02/27/2013 03:10 PM, Brian Hechinger wrote:
The tunnel now does everything in the TODO exact that last one about
only sending configs out to only those who need them.
It now supports:
SNMP is now handled directly in python so no calling external scripts.
This allows for much better control over what happens when a router
doesn't respond.
IPSec tunnels as well as GRE tunnels (well, kinda, I still need to get a
working cisco config snippet to use, haven't done that yet)
mesh/hub/spoke topology. Each endpoint (router) can be designated one of
either hub, mesh or spoke. A spoke will only connect to a hub. hubs and
mesh will all connect to each other.
That's a damn fine piece of work!
Thank you! It's been a blast to write.
Much love to Paul for his python assistance. :)
-brian
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=6C0106D8811C11E28…
Excellent work! I think this tool is a great asset to HECnet. We just need a bit of promotion now. People are scared of Cisco equipment, but you can pick up a low-end router for $50 on ebay and it gives you everything you need to connect to HECnet.
Ian
On 2013-02-27, at 12:29 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
On 2/27/2013 3:25 PM, Dave McGuire wrote:
On 02/27/2013 03:10 PM, Brian Hechinger wrote:
The tunnel now does everything in the TODO exact that last one about
only sending configs out to only those who need them.
It now supports:
SNMP is now handled directly in python so no calling external scripts.
This allows for much better control over what happens when a router
doesn't respond.
IPSec tunnels as well as GRE tunnels (well, kinda, I still need to get a
working cisco config snippet to use, haven't done that yet)
mesh/hub/spoke topology. Each endpoint (router) can be designated one of
either hub, mesh or spoke. A spoke will only connect to a hub. hubs and
mesh will all connect to each other.
That's a damn fine piece of work!
Thank you! It's been a blast to write.
Much love to Paul for his python assistance. :)
-brian
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=6C0106D8811C11E28…
On 2/27/2013 3:25 PM, Dave McGuire wrote:
On 02/27/2013 03:10 PM, Brian Hechinger wrote:
The tunnel now does everything in the TODO exact that last one about
only sending configs out to only those who need them.
It now supports:
SNMP is now handled directly in python so no calling external scripts.
This allows for much better control over what happens when a router
doesn't respond.
IPSec tunnels as well as GRE tunnels (well, kinda, I still need to get a
working cisco config snippet to use, haven't done that yet)
mesh/hub/spoke topology. Each endpoint (router) can be designated one of
either hub, mesh or spoke. A spoke will only connect to a hub. hubs and
mesh will all connect to each other.
That's a damn fine piece of work!
Thank you! It's been a blast to write.
Much love to Paul for his python assistance. :)
-brian
On 02/27/2013 03:10 PM, Brian Hechinger wrote:
The tunnel now does everything in the TODO exact that last one about
only sending configs out to only those who need them.
It now supports:
SNMP is now handled directly in python so no calling external scripts.
This allows for much better control over what happens when a router
doesn't respond.
IPSec tunnels as well as GRE tunnels (well, kinda, I still need to get a
working cisco config snippet to use, haven't done that yet)
mesh/hub/spoke topology. Each endpoint (router) can be designated one of
either hub, mesh or spoke. A spoke will only connect to a hub. hubs and
mesh will all connect to each other.
That's a damn fine piece of work!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
The tunnel now does everything in the TODO exact that last one about only sending configs out to only those who need them.
It now supports:
SNMP is now handled directly in python so no calling external scripts. This allows for much better control over what happens when a router doesn't respond.
IPSec tunnels as well as GRE tunnels (well, kinda, I still need to get a working cisco config snippet to use, haven't done that yet)
mesh/hub/spoke topology. Each endpoint (router) can be designated one of either hub, mesh or spoke. A spoke will only connect to a hub. hubs and mesh will all connect to each other.
Any questions?
-brian
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 27/02/2013, a les 16:52, Johnny Billquist <bqt at softjar.se> va escriure:
Was that an honest bug? There are some details and tricks around SAV which are not very well documented, and which can cause an unbootable system all on its own...
Yes, it was. This is the ultimate reason, found by Mark after an entertaining bug hunting dialog:
"The Massbus byte count register was incorrectly presumed to be constant during a complete I/O transfer request (it can change due to DMA activity). Prior to the conversion to use the sim_disk library, the Massbus byte count was only read once. After the code restructuring it was read early in the processing and again later in transfer processing. The subsequent read returned a different value which ultimately caused the problems."
The whole thread, including some clumsiness from me is here:
https://github.com/simh/simh/issues/30
On 2013-02-27 15:58, Jordi Guillaumes i Pons wrote:
Al 27/02/13 09:42, En/na Dave McGuire ha escrit:
I assume all of this is in the repository...Is there going to be a new
release soon?
Mark tagged the current HEAD as beta some weeks ago, but there is no
word about the release date yet. For what I'm seeing, there are no
serious bugs in the current master branch, at least in the VAX and
PDP-11 simulators. I have been using the testing versions for a time,
and they seem to be stable.
Looking forward to seeing how my NetBSD code works on that emulation.
Of course beware there could be obscure bugs... for instance we catched
one in the PDP-11 simulator which manifested itself JUST at the SAV /WB
command... The simulator worked fine thru the SYSGEN time... just to
render your disk unbootable after SAVing the new system image. :)
Was that an honest bug? There are some details and tricks around SAV which are not very well documented, and which can cause an unbootable system all on its own...
Johnny
