> 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
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
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
> 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
> 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
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
> 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
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> "Sam VK4AA" <vk4aa(a)vk4aa.com.au>
> Date:
> 06/13/2015 01:27 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Morning Gang
>
> Has anyone done authentication for paket stations connecting to our network
> by using radius?
>
>
> Sam
> VK4AA
I have tried, although not very persistently, but until now I have not succeeded.
I thought it would be easy (having some experience with radius in combination with VPN routers),
but until now I have not succeeded in getting a configuration with WiFi APs operating in EAP mode
and freeradius server on Linux to actually work. It should be possible, though.
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Tom Hayward <esarfl(a)gmail.com>
> Date:
> 06/11/2015 08:45 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Forget about this; it's just syntax. Who cares if we have to have
> hundreds of P2P interfaces instead of a single P2MP? The script
> creates them, so the burden of both methods is equivalent.
>
Well, I think it is much better (at least, cleaner) to have a single IPIP interface (P2MP) and
have a route table (separate or merged with the main table) updated by a routing protocol.
What you have made will work, but requires frequent downloading of a file and patching of
the configuration to process changes. I did that before on Linux, but after having installed
ampr-ripd I would not want to go back to that method...
About routes: in Linux it is possible to have routes bound to an interface that has a broadcast
nature (e.g. ethernet) and with a gateway that is outside the subnet served by the system itself.
So you can partition a subnet and still have only a single gateway. This can be useful on ham
networks where everyone in a local area has a Point-to-Point link to a node, and everyone
routes to others via the node, but the node does not have an address in each subnet.
RouterOS cannot handle this, but Linux can. E.g.:
node has subnet 44.137.40.0/23 and has address 44.137.41.254
user has subnet 44.137.41.96/28 and has address 44.137.41.110 on eth0
then:
ip route add 44.0.0.0/8 dev eth0 gw 44.137.41.254 onlink
To do this in RouterOS (and in many other routers) you need to set the subnet mask
to /23 on the eth0, but that means it will try to contact the others directly, not routing via the node.
This will work when the local area is switching/bridging.
Otherwise you will need to have a node address in everyone's subnet.
The same situation occurs when setting up the P2MP IPIP tunnel interface: you assign it the
subnet of your local system, so all the routes are outside the interface's subnet and need
the "dev" and "onlink" parameters. RouterOS does not support them. But Linux does.
Rob
