44net June 2013

44net@mailman.ampr.org

31 participants
31 discussions

by Maiko Langelaar

Good afternoon, It would see that 44.133.48.66 is popping, snmpding, and other amounts of traffic from time to time to various ampr.org systems and doing so *without warning* type of thing. I just got hit with a bunch of SNMP requests, others have been hit with POP requests. Can anyone find out who the owner of that particular system or network is, so that I can contact the entity or person. Or perhaps a bit more draconian, can someone deal with it. Thanks in advance. Maiko Langelaar VE4KLM

11 years, 4 months

Cisco/juniper configs?

by Bryan Fields

Greetings, I've been doing some work to get the IPIP tunnel information into a router on a daily basis, has anyone else automated this? I was wondering how the reachability of this from the global routing table of the public internet works, if at all. Everything I've been reading says this is all separate, but we do interconnect at a couple locations. I must admit I'm new to this, but is 44/8 intended to be totally separate a la the GRX network? Granted my use of this space is for high speed wireless networks on the ham bands, I have little interest in the 9.6 kilobaud TCP/IP packet radio. I've got some of the 900MHz FHSS gear hacked to run in a narrower channel, and I've been experimenting with running some of the 5ghz units in the ham band at 5cm (5mhz channel is able to do about 10mbit/s). My intention is to have it all work across hardware routers, ie cisco/ALU/juniper rather than maintain a bunch of linux boxes. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

12 years

Newbie issue

by lleachii＠aol.com

Marc, LX1DUC, Per Brian in a Jan 22 note: 44.0.0.1 responds to pings received from the Internet. It does not respond to pings coming into it over an encap connection to it, for some reason that I've not been able to figure out. I believe it to be a difficulty in getting it to recognize decapped pings. If you are receiving the rip44 announcements, you have properly configured your tunnel to receive IP-in-IP encapsulation from 44.0.0.1. Feel free to use: http://44.60.44.10/tools or http://kb3vwg-010.ampr.org/tools I see your encap as: 44.161.202.0 via 46.29.183.253 dev tunl0 onlink window 840 44.161.203.0 via 46.29.183.253 dev tunl0 onlink window 840 44.161.229.0 via 46.29.183.253 dev tunl0 onlink window 840 Also, I am unable to ping 44.161.229.126. What script/configuration did you use to enable your tunnel; did you specify a local or remote IP (un-needed)? Feel free to look at my script at http://44.60.44.13/startampr 73, Lynwood KB3VWG

12 years

portal: database damage

by Brian Kantor

Chris reports that he's repaired the portal allocations mechanism but that some recent allocation requests were lost and will have to be resubmitted. The cause was apparently an unexpected power failure in the data centre. - Brian ----- Forwarded message from Chris <chris(a)g1fef.co.uk> ----- Looks like some records were corrupted, I've repaired the db by rolling it back, but that means the most recent transactions where lost, so recent allocation requests will have to be re-submitted. Cheers, Chris ----- End forwarded message -----

12 years, 1 month

Re: [44net] hardware vs. software

by Michael E. Fox - N6MEF

Actually, Linux on x86 hardware is just as much of a "hardware-based" solution as any proprietary OS on proprietary hardware is. In fact, Linux on x86 easily outperforms most proprietary hardware solutions up to and beyond the Cisco 7x00 range, especially with the current Intel architecture systems. Vyatta (now part of Brocade) and others have proven that over and over for the last several years. I hope we can establish something that's vendor neutral, rather than any type of single vendor lock-in. Michael N6MEF ---- In the performance class we are operating in, "hardware based" is not really required. A suitable box (processor and ethernet interfaces) and software (e.g. Linux plus some usermode tools) can do the same thing.

12 years, 1 month

a common vendor neutral hardware/software stack for 44net. - was Re: hardware vs. software

by Eric Fort

It would seem Linux and Ethernet whatever architecture it's running on would seem to be the best solution available for routing Net44 at the moment and it works well. a standardized plug and play package of hardware sold by your local candy store would be nice but we're only partially there. Being that 44NET/Amprnet is supposed to be a RADIO BASED IP NETWORK (or at least interconnected islands of RADIO BASED IP NETWORK) we seem to only have half of a standardized solution to offer. It seems that we have forgotten the RADIO part. Given a live piece of cat5 with bits on it that I wish to have show up elsewhere what can we offer to the average ham that can go on the tower with Ethernet in one side and an antenna on the other, especially something standard enough that a local group can set up a network with? The only thing I can think of that even comes close is the professional grade 802.11 hardware that's out there. (much of the consumer stuff lacks the configurablity we could really use such as power control and timeouts). I might propose that we standardize the RF interface for AMPRNET on an agreed physical layer (of 802.11 unless something else is proposed and made quickly and cheaply available) and a relatively standard stack of hardware and software be put forth as a package that could be turnkey deployed by interested parties. What would others think of embarking upon such a project as a group? who might be interested? and what might we offer? (PS. I know of at least one manufacture of gear that would be quite happy to mod a standard product or products so as to have them better fit the amateur radio band plan and channels on a couple of our microwave bands as well as make provision for the ability to get significant QRO above the 25-30dbm out that seems standard. This in production batches maybe as low as lots of 100 units) Eric On Fri, Jun 28, 2013 at 1:32 PM, Michael E. Fox - N6MEF <n6mef(a)mefox.org>wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Actually, Linux on x86 hardware is just as much of a "hardware-based" > solution as any proprietary OS on proprietary hardware is. In fact, Linux > on x86 easily outperforms most proprietary hardware solutions up to and > beyond the Cisco 7x00 range, especially with the current Intel architecture > systems. Vyatta (now part of Brocade) and others have proven that over and > over for the last several years. > > I hope we can establish something that's vendor neutral, rather than any > type of single vendor lock-in. > > Michael > N6MEF > > > ---- > > In the performance class we are operating in, "hardware based" is not > really > required. > A suitable box (processor and ethernet interfaces) and software (e.g. Linux > plus some usermode > tools) can do the same thing. > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net > http://www.ampr.org/donate.html >

12 years, 1 month

Re: [44net] DMVPN routing for 44/8 subnets

by Bryan Fields

On 6/27/13 2:26 PM, K7VE - John wrote: > Great idea - wrong platform. Cisco specific solutions aren't reachable for > many. > > Look at Linux (Raspberry Pi) solutions or powerful, affordable routers like > MIkroTik and common tunneling protocols like OpenVPN, L2TP, GRE, etc. I take issue with that. MikroTik is just as much of a closed platform as Cisco/JNPR/ALU/Fond-cade/etc. Cisco is ubiquitous, to a lesser extent Juniper (though I have to favor ALU for MPLS/core!). I'd say what we need is an open standards based solution that works across linux/cisco/jnpr (maybe an o-series? :) Something custom protocol wise to tie the 44net together is not ideal either as we cannot expect the big router vendors to support amprnet protocols. I know I'm able to slap a 1ru router (ie c2[6-9]00) in lots of places with good connectivity I could never put a server. I belive there is a way to do this via NHRP with BGP. I know I have a customer doing something like this. Since we don't need crypto for 44net I suspect it would work for us. just my .02 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

12 years, 1 month

DMVPN routing for 44/8 subnets

by jesse＠hindmarsh.cc

I am working on a lab design to add some flexibility and test other connection methods to the 44.0.0.0/8 network. I currently have a Linux gateway running rip44d for my main connectivity to the other 44/8 subnets. I have setup a Cisco based DMVPN where I can route other subnets to and route back to the Linux gateway for access to other subnets. This configuration also allows access from the public Internet to the allocated subnets via a Linux gateway. I have a diagram with a working layout and is in testing now. I am looking to see if anyone might be interested in connecting up to my cloud and see what and if any problems we may encounter. I use a very similar setup with my customers and there are some distinct advantages: - The end user would only need an internet connection and a Cisco DMVPN capable router. I have used 800, 1800, 2800, 3700 series Cisco routers. - The DMVPN works when you plug the Cisco router into a direct Internet or NAT connection. You can plug it in at home behind your Netgear home router, use DHCP and a private address on the router "public" interface. - Many subnets can be routed through a single Linux gateway and distributed easily. - No issues with dynamic IP address from your provider. If you are interested or have any comments or suggestions, take a look at the network diagram I made at http://www.hindmarsh.cc/images/wc3xs-ampr44.png 73 de WC3XS - Jesse

12 years, 1 month

Re: [44net] 44Net Digest, Vol 2, Issue 78

by Rob Janssen

Jesse Hindmarsh <jesse(a)hindmarsh.cc> wrote: > > > > > > Rob, > > I like your thinking. Are you a Cisco guy too? I have been for too long :-) > > I am still partial to hardware based solutions. > > Jesse - WC3XS, CCNP Voice, CCNP RS, CCDA I learned networking with the KA9Q software and later when I got a job as a sysadmin I worked with existing Cisco routers and found many things very familiar. I learned the Cisco stuff myself from the manuals, have no CC certifications. I converted our existing network at work from leased lines to VPN some 10 years ago over Internet using DMVPN and it worked very well. (now we have dedicated lines again, but that wasn't affordable at megabit speeds 10 years ago) I suggested DMVPN before on this list, and I still think it could be a good option at least when an open implementation is available. I don't know if it is today, it has been in the works for some time. (the specs are open) In the performance class we are operating in, "hardware based" is not really required. A suitable box (processor and ethernet interfaces) and software (e.g. Linux plus some usermode tools) can do the same thing. I run IPsec tunnels between Ciscos, between Linux boxes, and between Cisco and Linux, and it is all inter-operating well. Of course we don't want to tie outselves to "only Cisco". But a solution where Cisco and open implementations (on systems like Linux and BSD) inter-operate is a very good thing. IMHO we don't need to consider compatibility with DOS (e.g. JNOS on DOS) as critical anymore. Rob

12 years, 1 month

Re: [44net] 44Net Digest, Vol 2, Issue 77

by Rob Janssen

K7VE - John <k7ve(a)k7ve.org> wrote: > Great idea - wrong platform. Cisco specific solutions aren't reachable for many. > > Look at Linux (Raspberry Pi) solutions or powerful, affordable routers like MIkroTik and common tunneling protocols like OpenVPN, L2TP, GRE, etc. The big advantage of Cisco DMVPN is that it can create a fully meshed tunnel network with endpoints on dynamic addresses, with only one (or a few) central hubs on static addresses, fully automatically. It is like what you have with a JNOS or Linux route importing encap.txt all the time, but without the hassle. Other VPN solutions are usually hub-and-spoke, where all internode traffic goes through the central hub. It is like connecting to net-44 by tunneling everything to 169.228.66.251 instead of loading a routing table. Rob

12 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net June 2013