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
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> "Marc, LX1DUC" <lx1duc(a)laru.lu>
> Date:
> 06/12/2015 05:06 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
>
> I do think that regardless of the OS it is much more important that anybody using 44net addresses shall support the IPIP mesh, regardless of any other routing procedures (e.g. direct BGP announcement, etc) in use. I have the "luxury" to be able to
> do direct BGP announcements, so I can reach BGP-only 44networks without NATing my 44net to my commercial IP address, others don't have this luxury but would eventually like to reach those 44etworks without the requirement for NAT.
Our country gateway is BOTH on BGP and on the IPIP mesh. It advertises the entire 44.137.0.0/16 network on both BGP and IPIP.
My systems at home are on net 44.137.41.96/28 and are linked to a local node for 44.137.40.0/23 via RADIO (unusual, I know...)
and that node is again linked to the gateway system via our HAMNET.
So my system is reachable both for BGP and for IPIP systems (and radio-connected systems) without me running IPIP myself.
Hence I don't need to do that at home.
When my radio link fails, I can setup an IPsec or OpenVPN VPN connection to our gateway, and routing in the network will
automatically adapt (the gateway and the nodes talk BGP on a private ASN# on the HAMNET side and the gateway will advertise
my 44.137.41.96/28 subnet when I setup an IPsec or OpenVPN link).
So there is no need to worry!
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Jeroen Massar <jeroen(a)massar.ch>
> Date:
> 06/11/2015 09:03 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?
> ntpd cares about it and also the Linux and FreeBSD kernels.
>
> ISC ntpd listens on each interface automatically, hence after ~200
> interfaces it breaks as it runs out of file descriptors (each interface
> gets a separate socket as it uses it that way to be able to properly
> select the interface to reply to packets on that interface).
I know about that problem! Silly ntpd listens on a separate socket for every address,
instead of just listening on a wildcard socket. It caused havoc on our gateway because
it has over 200 addresses assigned to a dummy0 interface, used by an EchoLink proxy
farm running on the machine.
Fortunately in recent versions of ntpd it can be solved by config like this:
interface ignore all
interface listen lo
interface listen eth1
interface listen tun0
interface listen tunl0
i.e. you can direct ntpd what interfaces to watch and to ignore the rest.
I think it would be better when it listened on 0.0.0.0 instead (of course you CAN set
the source address of outgoing packets on a wildcard socket, at least in Linux you can),
but I saw there already has been a heated debate about that on the mailinglist so I chose
not to suggest that and use the abovementioned workaround.
Rob
