44net

44net@mailman.ampr.org

3194 discussions

Re: [44net] directly connected and tunnel subnets
by Bryan Fields 18 Jul '13

18 Jul '13

On 7/16/13 11:00 AM, Brian Kantor wrote: > A solution would be to have the border router at each of the > directly-connected subnets also have a full set of tunnel routes and > interfaces installed, as it could then participate in the tunnel mesh > and should then be in the encap file. I don't see commercial internet > providers doing that. > > So this means that in order for the the directly-connected subnets to > also participate in the tunnel mesh, there has to be a tunnel-enabled > router downstream of the connection to the commercial Internet. Thus the > only advantage of being directly-connected is simply an independent (quite > possibly higher-bandwidth) connection to the commercial Internet backbone. > It doesn't improve internal connectivity in the AMPRNet at all. We still > need the tunnels for that. Admittedly, I've been a bit tardy in getting my BGP session up with my provider (summer is always busy for me), but perhaps there is a better way to do this. What I envision would be to have a few regional AMPR BGP routers/peering points. AMPR would need and ASN of course (I'd be willing to put up the money for this from ARIN), some hardware and a few friendly providers across the globe. I have one friendly provider, and I'm sure we could find a few more. Hardware is up to us, I'd prefer an actual router (ALU/Cisco/JNPR), but there is no reason openbgpd on a *nix box wouldn't work. So you would have each peering point announcing 44/8 but behind the peering routers would be a set of (GRE) tunnels between all the routers. The 44net BGP routers would run I-BGP across these tunnels (or ISIS/OSPF, but I feel IBGP would make more sense to manage redistribution of routes as it's got more "policy knobs" than OSPF and to a lessor extent ISIS.) The 44net non bgp users would then have IP-IP tunnels to their closest 44net peering router. For optimized routing (as it makes no sense to me for .AU users to tunnel through UCSD) we could have routing between the 44net routers announce more specific routes for directly connected subnets. We'd have to manage this, as I'm sure we don't want to add another 1000 routes to the global table (and then have filtering), but I don't see it being that many routes when a /16 is for a whole continent, which has 1 or 2 peering routers in this design. This also avoids black holes caused by 44net directly connected peers being filtered by sites that filter at less than a /24 block (don't laugh, I've seen large companies filter at a /19) Admittedly this is a very "back of a napkin" design, but it's a start. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

12 18

(no subject)
by kb9mwr＠gmail.com 17 Jul '13

17 Jul '13

k9eam ?

1 0

(no subject)
by kb9mwr＠gmail.com 17 Jul '13

17 Jul '13

k9eam ADD A 138.74.255.4

1 0

Re: [44net] directly connected and tunnel subnets
by kb9mwr＠gmail.com 17 Jul '13

17 Jul '13

Along those lines, Remi, F4ECW had an interesting idea to make PHP interface for remote fldigi. I took some his radio control code and put my receiver online. http://kb9mwr.no-ip.org/control/ Another logical use of the 44 netspace would be for a VOIP ham thing like IRLP. This would eliminate the need for port forwarding ---- Quote ---- Interoperability with the Internet, thanks to the BGP announcements and not using 10/8, *and* at the same time, access to the same services from ham radio networks which are not allowed to access the Internet over ham radio due to local regulations. That'd be cool. Run a nice web service having a net-44 address, but when the visitor comes from within the amprnet with a net-44 address, allow extra features like being able to key a transmitter. - Hessu

2 1

Re: [44net] directly connected and tunnel subnets
by Bryan Fields 16 Jul '13

16 Jul '13

On 7/16/13 4:17 PM, Brian Kantor wrote: > In addition to whatever its activities require, it costs around $500 > a year to just maintain a non-profit corp in California. > > Donations haven't kept up with that, much less to defray the initial > startup costs. We have no money. Why incorporate in Cali? Not to get political here, but it's the least business friendly state in the union. I have 3 LLC's in Florida, and spend less than 400 dollars to matain all 3 LLC's. Cost to incorporate a non-profit is $70, which is about half of a non-profit. I think status with the IRS which would make donations tax deducible is a no-brainier. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Re Networks in OZ
by VK4FQ/VK4TTT Sam 16 Jul '13

16 Jul '13

Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not being used. If you have or no of a range of IP's that are being used downunder, could you please let me know by emailing samantha(a)smellyblackdog.com.au Regards Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf)

16 47

portal: database damage
by Brian Kantor 13 Jul '13

13 Jul '13

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 -----

2 3

Re: [44net] Re Networks in OZ
by Bryan Fields 13 Jul '13

13 Jul '13

On 7/13/13 12:31 PM, Lin Holcomb wrote: > My understanding is that there may be some rouge direct connected > 44 address ranges out there too. This is from a friend at a national > CATV/ISP provider. > I don't remember the specifics but prior to the policy Change by AMPR > regarding this allocation we found some of these in their AS. If memory > serves some were in VK. This is some thing we really need to run down.... > With 16million addresses this is a hard task to police. I am guessing > that ISPs have whole groups that just deal with rouge networks in their IP > space. Just running a scan is not going to work as most ISPs will shut ya > down if you tried to scan a whole class A. It really needs to be looked at > in a AS. Not Brian's at UCSD as his will be correct. Well anyone running BGP with a full feed on their router can see what ASN's announce any netblock. The bigger question I see is how do you reliably link all of 44/8 so everyone can see everyone else. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Connectivity to AMPRnet and video
by Jesse Hindmarsh 10 Jul '13

10 Jul '13

In one of my last posts, I mentioned about connecting to the AMPRnet via DMVPN or PPTP which seemed to tangent into a hardware/software discussion. I sat quietly and enjoyed the many perspectives that many had to share. I have been connecting via a combination of Linux and DMVPN for the last two weeks and it has worked as expected. A few even used the PPTP service I have setup and had good results. I want to get some services deployed to see how flexible this setup is and if there are any issues before I attempt to extend my network using 2 ghz and 5 ghz links across the valley. Right now I have a videoconference station setup on 44.64.192.2 which anyone is welcome to connect to. Thanks Jesse - WC3XS Sent from my iPhone

3 4

Re: [44net] hardware vs. software
by lleachii＠aol.com 10 Jul '13

10 Jul '13

Regarding a few things mentioned setup/encryption - 802.11 encryption would not be necessary if you use a band not shared with Part 15 Users - 802.11 encryption technically does not obscure the fact that you are transmitting standard 802.11 Wireless Ethernet traffic - also, this debate can extend into HTTPS traffic over Amateur RF, except in an Emergency (transferring Health information for a hospital, for example, REQUIRES encryption in the US [HIPPA]) - even if HTTPS traffic is sent, packet inspection of the frames would reveal it is a HTTPS packet, its source and its destination - making the callsign the SSID is not the only method of complying with station identification rules; but it is the easiest - There are other methods of encrypting a WiFi signal other than a pre-shared key (many stations commented that they key must be posted or announced), user account authentication is another method regulation - regarding sending a music/video file or stream via 802.11 - the communication would be data, in the analog world, I would assume this would be similar to sending the sheet music via snail mail - regarding N6MEF's concern regarding 3rd party email communications, email is not an "automatically forwarded" technology; an amateur does not automatically receive that message through any technology governed by Part 97 (there are two exceptions I can imagine - if the amateur maintains his own email server at the receiving [client] end of the radio link or provides email as a service to non-amateurs) - I'm somewhat lost as to the concerns regarding inbound traffic, the problem only arises if the intent is to run infrastructure (i.e. services) over RF for non-amateur use, otherwise, the requests would initiate from an amateur station and would not be 3rd party - servers and devices on AMPR can be firewalled to only accept traffic from 44.0.0.0/8, in fact my DNS server (44.60.44.3) is configured to only resolve non AMPR IPs and domains for 44/8 traffic - if a non-amateur is reaching a 44/8, they MUST be using commodity Internet, if the services are on the gateway or on a device connected by wire or Part 15 device, that is not governed by Part 97 (Part 97 only governs Amateur RF) - I cannot find 97.109(e) - I'm not certain how 97.115 relates, except for 97.115(c) "(c) No station may transmit third party communications while being automatically controlled except a station transmitting a RTTY or data emission." Since it is a data emission, 3rd party communications can be transmitted - I'm not certain how 97.219 applies, given that email is not a message forwarding system for the 3rd party (email receipt must be initiated by the amateur, that communication is between the Amateur and their email server, not between the Amateur and the 3rd party) This is a good thread, and I'm still reading through, I hope I have not missed anything thus far. 73, Lynwood KB3VWG

3 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net