44net

44net@mailman.ampr.org

3194 discussions

Re: [44net] Strange Broadcasts...
by Rob Janssen 15 Jun '15

15 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Don Fanning <don(a)00100100.net> > Date: > 06/15/2015 12:35 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > >> >When you want to do something about a SPOF it is only required to do the >> >RIP transmission >> >from another system in parallel. E.g. from the system running the portal. >> > >> > > RIP still doesn't solve routing loops that occur. RIP doesn't converge > quickly (currently 44ripd takes 5+ minutes to send any new*static* change > - if your firewall is configured to receive said packets from said > source). I fail to see why that is a problem. Few gateway stations appear a day, and having to wait 5 minutes before they are routed is really no big deal. Before, many gateway stations loaded a routing table maybe once a day, or even less frequently. Again, we are a radio hobbyist network, not some financial trade network. > RIP has no concept of bandwidth limitations or multiple paths for > the same route (ie: load balanced connections with different ISP). Again, let's first set up something that is popular and has many users, and then we can always consider doing things like that. For now we, and many others, find ourselves fortunate to have found a SINGLE ISP that wants to sponsor us. When we setup radio connections to our neighboring countries we may achieve some redundancy. And I prefer that way over settting up a tunneling system over the internet. Or even over routing over the internet. Remember we are an amateur radio network, not some multinational company trying to setup a rendundant data network with zero failures. Rob

2 1

Re: [44net] Strange Broadcasts...
by Rob Janssen 15 Jun '15

15 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Bryan Fields <Bryan(a)bryanfields.net> > Date: > 06/14/2015 09:48 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On 6/14/15 3:35 PM, Rob Janssen wrote: >> >Your problem is that you want to try to talk us into believing that we have a problem with >> >reliability, while for most of us it is clear that we first and foremost have a problem with >> >existance. The amateur digital network is nearly dead, we are trying to revive it and make >> >it thrive like it did in the early days, a network built and operated by hobbyists, and you >> >are continuously trying to impress us with your knowledge about professional networks and >> >your concerns about failure modes. > Rob, take a chill pill. > > Take a look at the HamWAN, HAMNET, and what I'm doing here in the bay area. > It's very much alive, and we're educating people about high-speed ham packet > networks everyday. I had over 200 people at the TAPR forum at Dayton this > year for my talk. > I am not talking about the work you do locally but about the way you approach "us" after you have found some problem with your gateway implementation. Not even mainly about the discussion that just has started, but about a similar discussion that was started about the same topic some time ago. You continuously refer to Brian's system at UCSD as "broken", and I don't like that attitude. Especially not because it really is possible to fit in your system to co-exist in the network as it is now, as is demonstrated by our gateway. Rob

2 1

Re: [44net] Two questions
by Rob Janssen 15 Jun '15

15 Jun '15

> Subject: > Re: [44net] Two questions > From: > Bryan Fields <Bryan(a)bryanfields.net> > Date: > 06/14/2015 09:10 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > No, the issue is the_broken_ routing at UCSD. > > ARDC does not announce the 44/8, UCSD does it for them and has a static route > for 44/8 pointing at the gateway box. This is broken routing since the > gateway is unaware of the more specific networks. > > What needs to be done is the UCSD gateway needs to be made aware of the > subnets in the global table and only announce the subnets it knows about. > There are routing protocols that would make this easy. But that is already in place!! It is the IPIP tunnel mesh. As long as you provide an IPIP tunnel for the subnet you advertise yourself on BGP, with a tunnel endpoint on an internet address OUTSIDE 44.0.0.0/8, there is no problem at all! We do have the same situation as UCSD at our gateway. Our ISP does the BGP advertising of 44.137.0.0/16 and routes the traffic to the gateway. We have registered the same space on the portal, and we have an external address for that (213.222.29.194). All the routing is fine, also for people who send the traffic to UCSD. Because UCSD sees the more specific route 44.137.0.0/16 first and sends the traffic via IPIP to us, instead of sending it out to the default gw that would bounce it back. When you would set up the same configuration, you would be out of trouble. When you don't want a single system to be responsible for the IPIP tunnel you can setup some redundancy, as long as you don't "conveniently" take a subnet out of 44.0.0.0/8 for that, because that does not work. It is known it does not work. > > <tangent> > I'd argue the BGP networks would be better if 44/8 was split up in such a way > set aside a /12 (for example!) for BGP subnets and a /12 for the IPIP users. > This makes the routing much easier to configure on a IPIP encap gateway. The > present geographic area way of doing it leads to routing table bloat. > </tangent> I don't agree with that. It will just make a new configuration necessary for something that now works OK just by the mechanisms we already have. Rob

1 0

Two questions
by Jann Traschewski 15 Jun '15

15 Jun '15

Hi! I have two questions: 1. Around 99% of all webcams on the HAMNET are *only* reachable if you establish the connection using a *source-44* ip address. Do you think this restriction is enough if you don't want to expose the webcam to the internet but want to share with other AMPRNet users? 2. We tell our HAMNET users to put the route 44.0.0.0/8 via <wireless router to HAMNET access point> into their DSL/cable routers. Some well-known internet services for radio amateurs are nowadays hosted on the internet using network44 addresses. Who needs to be blamed if the connection from the HAMNET user to the well-known internet service is not as stable as expected by the user? 73, Jann -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

6 12

Re: [44net] AMPRNet Interoperability with BGP (fwd)
by Tim Osburn 14 Jun '15

14 Jun '15

On Sun, 14 Jun 2015, Brian Kantor wrote: > Date: Sun, 14 Jun 2015 18:20:22 -0700 > From: Brian Kantor <Brian(a)ucsd.edu> > Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] AMPRNet Interoperability with BGP > > (Please trim inclusions from previous messages) > _______________________________________________ > On Sun, Jun 14, 2015 at 05:26:26PM -0700, Tim Osburn wrote: >> This only requires at >> least 1 (or more) ISP (or companies running BGP) willing to setup a >> BGP over GRE tunnel to Brian's server to make this work. There are >> currently two ISP I know of willing to do this if Brian is willing to >> do this on the AMPRnet Server shown in the drawing. > > I'm willing but not able. The server 'amprgw' is an old FreeBSD system > that doesn't understand GRE. We have been discussing updating it to > a more modern system (both hardware and software) but at this point > it doesn't seem like that's going to happen. We've not been able to > identify ANY router product that can do what the gateway needs to do > in order to replace 'amprgw'. > > I have an alternative suggestion, which would be to find an ISP or two > that are willing to take over the IPIP tunnel routing. > > They would BGP advertise /24 summary routes for the smaller tunnels, as well > as appropriate routes for the wider tunneled subnets. That way there is > no fixed route that blinds the tunnels to the BGP subnets. UCSD could > still advertise the 44/8 overarching route (which I strongly believe is > essential to preventing prefix hijacks), but since there would be more > specific routes for the BGP and tunnel subnets, that wouldn't matter. > It would only be necessary for the tunneled gateways to change their > tunnel endpoint address -- there is no need for tunneled gateways to > suddenly have to change software or overall configuration. > > Flaws? > - Brian > If we did BGP over IPIP would that work? Are you able to run Quagga or something that can do BGP/Routemaps on your FreeBSD box? What version of FreeBSD is it? Is the CAIDA telescope a external system? Perhaps a SHIM box with quagga & GRE Tunnels between CAIDA & amprgw? Tim Osburn www.osburn.com 206.812.6214 W7RSZ

2 2

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Don Fanning <don(a)00100100.net> > Date: > 06/13/2015 10:05 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Alright, let's take this a different route. > > What would it take to make IPIP mesh more robust? > > If BGP capable nodes were to announce and route for IPIP endpoints within > it's endpoint, that would remove the SPOF at UCSD. No, it will just make the system more complicated. Especially when you introduce yet another routing protocol, even worse, a manufacturer proprietary protocol. When you want to do something about a SPOF it is only required to do the RIP transmission from another system in parallel. E.g. from the system running the portal. Rob

2 1

44.161.239.0/24
by Brian Kantor 14 Jun '15

14 Jun '15

Will the person announcing 44.161.239.0/24 via BGP please contact me off-list. - Brian

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Bryan Fields <Bryan(a)bryanfields.net> > Date: > 06/13/2015 11:59 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On 6/13/15 4:05 PM, Don Fanning wrote: >> >IPIP would also get the >> >benefit of possibly routing EIGRP between IPIP mesh sites so that if one >> >BGP route were to have catastrophic failure, another BGP announced route >> >would already be announced and EIGRP would route to that end point. > This is a joke, correct? > > You're proposing fixing broken routing using a non-standard protocol. IIRC > EIGRP uses IP multicast for announcements (same as OSPF) so you'd need to run > it over some sort of tunnel (gre) interface anyways. > > Just use BGP with a private AS up to the edge Internet connected BGP nodes if > you're building tunnels. > > Tim Osburn and myself (and others) had proposed standards based way to move > the IPIP tunnels to a redundant gateway design a few years back. It's not > hard, but there is no movement from ARDC to actually move forward with it. > I'd be happy with a study of proposed ideas, at least it's forward movement. > Your problem is that you want to try to talk us into believing that we have a problem with reliability, while for most of us it is clear that we first and foremost have a problem with existance. The amateur digital network is nearly dead, we are trying to revive it and make it thrive like it did in the early days, a network built and operated by hobbyists, and you are continuously trying to impress us with your knowledge about professional networks and your concerns about failure modes. Furthermore, you try to enforce your ideas by criticizing the efforts of volunteers and trying to do a coup d'etat. It does not work that way. When you have a real improvement to introduce you should demonstrate how to do it in a way compatible to what others are doing, and understanding. What I find a joke is that you are concerned about having a single point of failure, and then roll out a solution that does not work *at all* under some static circumstances. Better have a single point of failure in a network that works most of the time, than a network that never works OK. (some pure theorist may disagree with that and claim that something that never works is more reliable that something that works 99.9% of the time, but I am not in that camp) Rob

2 1

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Strange Broadcasts... > From: > Nigel Vander Houwen <nigel(a)k7nvh.com> > Date: > 06/13/2015 09:30 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Rob, > > Thank you for making my point. The reason you cant use a 44/8 address for a tunnel endpoint is because routing is broken. > > Nigel > I don't agree with you. There is a problem with routing inside UCSD in that case, but there are other reasons why that should not be done. When you run an IPIP gateway on a source-address-filtered system (and in my opinion, ALL user connections should be soirce-address-filtered!! ISP's that don't to that just suck!) you need to route back traffic from net-44 to internet via the gateway. The only viable way of setting up policy routing rules to do that falls apart when tunnel endpoints are inside 44.0.0.0/8. So that should just be prohibited. (As Marius also explained, it is even worse when tunnel endpoints exist within subnets that are also advertised as being gatewayed) Rob

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 13 Jun '15

13 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Bryan Fields <Bryan(a)bryanfields.net> > Date: > 06/13/2015 09:40 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I agree, however the configuration of a single gateway announcing 44/8 without > the ability to reach more specific networks is_broken_ routing. Let me say > this again: > > _The UCSD Gateway has BROKEN ROUTING affecting the REACHABILITY of IPIP users._ > > If BGP users announce a subnet that 99.99999% of the internet can see, but > IPIP users behind the UCSD gateway can't reach it, it's not BGP users that > have broken routing, it's the silly UCSD gateway. This is INCORRECT, it is actually your own system that is broken. When you put up a system that announces a BGP route on Internet, you should also make that system part of the IPIP mesh for the same subnet that you advertise on BGP. Then, those that want to reach you on IPIP do not need to go via the UCSD gateway but can directly reach you on IPIP. Remember IPIP is a mesh, there is no "central gateway" other than that it has the largest subnet and attracts all traffic that is not otherwise routed. Routing the IPIP traffic is your own responsibility, don't shift it to UCSD or Brian. Rob

7 22

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net