44net

44net@mailman.ampr.org

3194 discussions

BGP / Tunnels / JNOS
by K7VE - John 25 Jul '13

25 Jul '13

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

4 4

Re: [44net] Distributed BGP Announce
by Bryan Fields 25 Jul '13

25 Jul '13

On 7/24/13 1:02 PM, Neil Johnson wrote: > I'm a network engineer at another University in the midwest US and I > *might* be able to convince our routing guru to let us be a BGP peer and I > could setup another tunnel end point box. > > I would need explicit details on how this would work and a the potential > risks and plans for their mitigation before I approach him. > > We don't have earthquakes, just tornados and floods :-) > > No promises however. We have really two networks here. The internal 44-net and the external internet facing net. I'd propose to have a few points around the globe where we can peer the whole 44 internet facing net. Each of these locations would announce 44/8 and more specific routes for what's close to them. Behind this in the 44-net internal the gateway routers would be meshed over GRE tunnels running an IGP (IS-IS). There of course would need to be IBGP sessions between all the BGP speakers, but this would allow end user networks to tunnel to a given 44/net router, and not need to keep a full route table of the 44-net internal space. (I hate end stations needing to do routing, that's why we have routers!) This would provide full access to the 44/net from outside, easy access from the AMPR users, and full visibility between directly routed netblocks and the rest of 44-net with out having to maintain a full mesh. I'd imagine the more specific announcements from the peering points would be statically configured, but there is a way to do a limited redistribution from the IGP into the BGP. I think it would be easier to do it manually (and more stable), but given some time in the lab at work I could get this going. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

8 19

Re: [44net] Distributed BGP Announce
by Bryan Fields 25 Jul '13

25 Jul '13

On 7/24/13 6:15 PM, Marc, LX1DUC wrote: > (BTW IS-IS probably wouldn't work that well over Layer3 tunnels AFAIK, > as it is itself a Layer3 protocol and would need to be transported > over a Layer2 link (please correct me if I'm wrong)) IS-IS will work fine over GRE. GRE forms an interface over which IP/CLNS can function. Multicast and broadcast traffic works over this as well. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Posting From My AMPR.ORG Address
by n2nov＠n2nov.ampr.org 24 Jul '13

24 Jul '13

Well, I now have my ampr.org address on the mailing list from my JNOS box.

1 0

BGP / Tunnels / JNOS
by K7VE - John 24 Jul '13

24 Jul '13

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>

1 0

BGP / Linux / Tunnels / JNOS
by John D. Hays 24 Jul '13

24 Jul '13

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>

1 0

Re: [44net] On The Air
by Bryan Fields 24 Jul '13

24 Jul '13

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

2 1

Distributed BGP Announce
by Marc, LX1DUC 24 Jul '13

24 Jul '13

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

2 3

Re: [44net] Distributed BGP Announce
by Bryan Fields 24 Jul '13

24 Jul '13

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

1 0

Re: [44net] (no subject)
by kb9mwr＠gmail.com 24 Jul '13

24 Jul '13

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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net