> 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
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 06/06/2015 09:48 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Hi Rob,
>
> I was quite active in the Mikrotik community and tried to push a little our
> ampr tunnel stuff.
> But the results are actually null. People are friendly but not interested.
Ok... at the moment I am reading the forum to see how change requests actually are
to be posted and how they are handled, as I have some other requests.
> The missing element is a way to create an IPIP interface without a specific
> peer IP, and add routes to specific peers on a given IPIP interface to get
> it in multipoint mode.
That is clear, yes. I already found that the do not support static routes being bound to
interfaces, let alone "onlink" routes. So even when you would want to load routes using
a script, it still cannot be done. They must have a reason for this (probably they want
to keep the routing entirely clean according to common practices), as the Linux kernel
can do a lot more than what they expose via the config interface.
>
> The easiest way to get ampr up fully is actually to set up a metarouter on a
> mipsbe routerboard (they have a xen virtualization on those), and run a
> OpenWRT in it, to do IPIP encap and run ampr-ripd. I have tried that, it
> works, but at the moment I use a PPC based routerboard which doesn't offer
> virtualization.
> But your RB2011 is a good candidate for this kind of setup, being mipsbe
> based. Others would be the RB45x, the RB75x, the RB95x and the OmniTik
> series.
As I wrote, I have no need for this because my RB2011 has a radio link to HAMNET and
as a backup I can setup an IPsec VPN to our gateway. So I don't need to be on the IPIP
mesh. And I still have a Linux system in colocation (a Raspberry Pi) that is on IPIP.
But for others, this approach can be interesting.
Some systems e.g. www.pe1chl.ampr.org and hampi.pe1chl.ampr.org are routed over
this radio link and the MikroTik (but there is no useful content on them).
>
> Regarding to linux: They run a proprietary distribution on a 3 kernel, but
> shell access is unfortunately not available, and there is no way to add 3-rd
> party extensions.
>
The device can be "rooted", though. You get a busybox shell. I have not done that yet,
it will probably make it difficult to get support in case I encounter some bug I want to be fixed.
Rob
