My thoughts.
The IPIP / JNOS network is an anachronism that is quant but doesn't take
advantage of how technology has evolved. I'm a pretty skilled network guy
but the current IPIP tunnel system has eluded me. I have gotten close, but
finally thrown my hands up each time. (I never get the rip44d to run and
find the proper password.)
However, I can get a VPN tunnel running in short order which can bring an
address range to whatever location is on the full Internet. I have a
personal class-C at home that has functioned over a VPN for over a year and
I have VPN'ed to another Net-44 gateway with success. (In both cases on
inexpensive MikroTik routers.)
I think we need to work on connectivity of the gateways to unify Net-44 and
treat the "on air" connectivity as a separate task. Whether the on air
connectivity is for IP over AX.25 at 1200 bps, WiFi/HSMM, D-STAR Digital
Data, or some new transport over RF. It doesn't do a lot of good to have
islands of on air activity without interconnectivity of Net-44. Otherwise
just use RFC 1918 address space and NAT it to the Internet.
My vision is that we have multiple BGP gateways on the Internet. Some may
advertise the whole of 44/8 and others may have smaller networks, clear
down to 44.x.x.x/24 Some will be multi-homed, some will not, but all would
be advertised to the Internet for routing. Any router advertising all of
44/8 would need to know about all routes for anything with a CIDR of less
than /8. I don't think we really want all traffic to go to 1 or 2 routers
advertising 44/8 or we're back to the everything must go through UCSD
scenario of the last couple of decades.
My recommendation is to find ISPs who are willing to 'donate' bandwidth and
routing for some number of BGP'ed networks, then place routers at those
ISPs which will support authenticated VPN service to local networks.
Say we had an ISP (or University, etc.) that would donate bandwidth for
44.24.0.0/16 and 44.12.0.0/16,44.26.0.0/16, and 44.40.0.0/16 and BGP
advertise those ranges. Let's another data center wanted to BGP
44.24.100.0/24. Traffic would flow to the best gateway for each. If
44.24.10.0/24 didn't have the ability to BGP its own address space, it
could VPN to the router at the major gateway (ISP) and that router would
tunnel traffic for that network to the gateway for 44.24.10.0/24. Then
there might be a small on the air network at 44.24.128.0/28 and its gateway
would VPN to the 44.24.10.0/24 router who would route traffic for the small
network.
This would mean that no special tables need to be passed around. Each
router would know the addresses it was responsible for and would route all
other 44 traffic to its "upstream" and non-44 network traffic to the
Internet through their service provider.
This means the "heavy lifting" of BGP and network routing would be handled
by those ISPs where the expertise exists and a new member of Net-44 could
simply setup a simple router that VPN'ed to an upstream router to get its
traffic and to send Net-44 traffic, all other traffic would simply pass
over local service provider's network.
This is all readily available, off the shelf, technology. For the end user
it is very inexpensive to setup a router with VPN. Then the local
distribution over RF can happen over whatever technology is available,
whether a TNC and FM radio, WiFi dongle, UDR56k-4, Bullet, etc.
------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
My thoughts.
The IPIP / JNOS network is an anachronism that is quant but doesn't take
advantage of how technology has evolved. I'm a pretty skilled network guy
but the current IPIP tunnel system has eluded me. I have gotten close, but
finally thrown my hands up each time. (I never get the rip44d to run and
find the proper password.)
However, I can get a VPN tunnel running in short order which can bring an
address range to whatever location is on the full Internet. I have a
personal class-C at home that has functioned over a VPN for over a year and
I have VPN'ed to another Net-44 gateway with success. (In both cases on
inexpensive MikroTik routers.)
I think we need to work on connectivity of the gateways to unify Net-44 and
treat the "on air" connectivity as a separate task. Whether the on air
connectivity is for IP over AX.25 at 1200 bps, WiFi/HSMM, D-STAR Digital
Data, or some new transport over RF. It doesn't do a lot of good to have
islands of on air activity without interconnectivity of Net-44. Otherwise
just use RFC 1918 address space and NAT it to the Internet.
My vision is that we have multiple BGP gateways on the Internet. Some may
advertise the whole of 44/8 and others may have smaller networks, clear
down to 44.x.x.x/24 Some will be multi-homed, some will not, but all would
be advertised to the Internet for routing. Any router advertising all of
44/8 would need to know about all routes for anything with a CIDR of less
than /8. I don't think we really want all traffic to go to 1 or 2 routers
advertising 44/8 or we're back to the everything must go through UCSD
scenario of the last couple of decades.
My recommendation is to find ISPs who are willing to 'donate' bandwidth and
routing for some number of BGP'ed networks, then place routers at those
ISPs which will support authenticated VPN service to local networks.
Say we had an ISP (or University, etc.) that would donate bandwidth for
44.24.0.0/16 and 44.12.0.0/16, 44.26.0.0/16, and 44.40.0.0/16 and BGP
advertise those ranges. Let's another data center wanted to BGP
44.24.100.0/24. Traffic would flow to the best gateway for each. If
44.24.10.0/24 didn't have the ability to BGP its own address space, it
could VPN to the router at the major gateway (ISP) and that router would
tunnel traffic for that network to the gateway for 44.24.10.0/24. Then
there might be a small on the air network at 44.24.128.0/28 and its gateway
would VPN to the 44.24.10.0/24 router who would route traffic for the small
network.
This would mean that no special tables need to be passed around. Each
router would know the addresses it was responsible for and would route all
other 44 traffic to its "upstream" and non-44 network traffic to the
Internet through their service provider.
This means the "heavy lifting" of BGP and network routing would be handled
by those ISPs where the expertise exists and a new member of Net-44 could
simply setup a simple router that VPN'ed to an upstream router to get its
traffic and to send Net-44 traffic, all other traffic would simply pass
over local service provider's network.
This is all readily available, off the shelf, technology. For the end user
it is very inexpensive to setup a router with VPN. Then the local
distribution over RF can happen over whatever technology is available,
whether a TNC and FM radio, WiFi dongle, UDR56k-4, Bullet, etc.
------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
On 7/24/13 5:19 PM, Brian Kantor wrote:
> Yes, I'd like to see more people working on networking over the air
> using amateur radio.
>
> Otherwise we're just another branch of the Internet and there's nothing
> new or exciting about that.
+1,
I'm doing some hacking on getting some gear into the 5 ghz ham band, and
removing power limits. It would be point to point or point to multipoint
directly into Ethernet. You can find the used units for 200-300 dollars, so
a complete 100mbit/s link would be 400 dollars or so.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear YLs and OMs,
I would like to restart the discussion about a decentralized BGP setup
for the 44net. I have thought about some kind of trial to test several
aspects of a non-central gateway approach.
So far I have come up with a few "challenges" for the trial.
- - AS Number (I can provide one for the trial, we may decide later on
what to do if and when this project goes to production)
- - IP Network (for the trial the test range 44.128.0.0/16 might be a
suitable candidate)
- - BGP Peers providing BGP session, bandwidth and a static IP address
for the trial (I can provide one peer in LX)
- - Inter-Gateway Tunnel setup (which protocol should we use? How do we
cope with lowered MTU and filtered ICMP Packet-to-big messages?)
- - Downstream tunnels (What kind of tunnel technology/protocols are we
offering? Can a subnet have upstream tunnels to several gateways?)
- - iBGP setup (How do we handle gateways with different available
upstream bandwidth? How do we redistribute routes for connected subnets?)
- - Packet filtering (Will we be using the current model of RDNS
activates access to/from the Internet? RDNS could be useful even for
hosts that shouldn't have access to/from the Internet, eventually
access to/from the Internet should be decoupled from RDNS.)
- - Test scenarios, how are we going to test different situations?
- - probably much more issues to handle (I haven't thought about the
details as long as the basics haven't been discussed)
What are your thoughts and who is willing (and able) to help with the
trial (as a gateway and/or a subnet tunnel server)?
73 de Marc, LX1DUC
- --
http://lx1duc.mcs.tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJR7v2YAAoJEHFIN1T8ZA8vJSQQAIFoXAKTS7IKJ6SxRavGb0oa
ySXvtPQg1TjhU5bGkN46efSQkAhsY7BcOg+3JwNTVEpTW5ZLO3ieN1kRKcgD/uVh
fI4z70HeFvQJeE6l2TeZxYkKU45fNEBKNQHqRRn2QU7wOHqvhOtr+jjR4UswbWIG
PyFoUEF/T7wd2jpZ6O0hA4buOy+DnMpBUeUQCQIeu7xs5+YpFGc1D21Fbo5b24FG
GLTUl4b+ssYdLf+CiFy1TlOu1wLOZorZ3DrYjexxGvpUzEUHjrazNr/pUKIc1WMq
zs3cQFTKNyjWf984Ty8WeuKrP/oy5gNFIbTmxlzm4JNYqDjPpQXZ/3Cduu/ij8Yl
n1qDAwe+PDFHh1DUVTdgiy+3JSsUy7q2GwItiJG5pOtFasLeoWeLs9iXR5dNBqtD
E8O9R7WRL989igv2XXVitwpDaiiDIpZG47kkktljFfhSiY6RtiozQRuuncQzm6bQ
0Ixl0u1Ne0B8aeQqfzUDfs6UqtoRPPoqJbRFimD22tAZg9dn50z180jU3b5oc/xX
tD06xi2CwscFLPlRknxxj/TFDfySjOHOJCmGPHUR/uBIs7ABqciY5NVkNpmPklUa
A3AW4J0uwVTB3iUpuZXktny/epj6ULg3R/FMU5Ym8Y9XFgp52km+vCvsbg9bPhtv
DQ22F6oMccLigj/6h0I+
=8ova
-----END PGP SIGNATURE-----
On 7/24/13 4:33 PM, Neil Johnson wrote:
> How would local gateways connect ? A Tunnel(s) to the global gateways ?
>
> I'm trying to imagine explaining to someone how to configure an IGP
> (especially IS-IS) :-)
yes, IPIP tunnels or GRE to their local gateway. If they wanted to have
redundancy into the AMPR net they could do IS-IS L1 to the two gateways over
these tunnels. The backbone routers would all be L2 routers.
We could do OSPF, but I see the whole area 0 thing being a bad architectural
limitation. Any design we come up with should be redundant and scalable for
all hams to benefit from.
Really if you can't configure a link state routing protocol, should you even
be trying to setup a redundant connection?
Granted it would be optional, but it would give some real protection if one of
the border routers goes down.
We only have a /8 of space, and even subdivided into /24's it's only 65k
routes, so pretty much any router on the core can handle it.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
Bill, I am not yet. Still using hard routes over the air. When/if
the over-the-air network grows in users and capable speed, that would
make perfect sense to implement.
As for ampr.org email, does anyone care to document setting up a
sendmail server for their gateway? Spam control is always a big
headache. I have been using a 3rd party mail exchanger, as that seems
easier.
And since my gateways are somewhat experimental here, I am not
subscribed using kb9mwr(a)kb9mwr.ampr.org to this list, as I don't like
worrying about bounced mail.
But my ampr address does work, and go over RF using pop3 pooling.
Steve
------Quote-----
So how are folks actually making use of all this nifty routing
technology on the air with Amateur Radio these days?
I don't remember the last time I've seen an "ampr.org" email address
here on the list. I kinda remember the last time I had one that
worked...
Bill
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
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
