This is a serious question: Why is everyone so enamored with and focused on using rip44d?
Rip44d disadvantages:
1) Rip44d depends on getting the routes from a single source - amprgw, i.e. a single point of failure.
2) If that single source fails (as it did recently, for more than 12 hours), then the routes are gone, even though all of the other gateways may be completely reachable.
3) If you try to avoid that problem by timing out the routes slowly, then you might as well have a static list.
It seems to me that periodic downloading of the encaps file, followed by the ip.munge scripts is a far better approach.
Advantages:
1) You can define how often you want to download the file, based on how quickly you want to discover new gateways. For me, once nightly is fine. But it could be more often.
2) If the download of encaps fails, I continue using the same routes I had before until the next download attempt. This happens every once in a while - maybe once a month, for whatever reason. But no connectivity is lost.
3) If amprgw fails, the direct tunnels to all other gateways are unaffected. i.e. Single point of failure eliminated.
Disadvantages:
None that I can see.
So I fail to see why everyone is so enamored with rip44d. Please explain.
Thanks much,
Michael
N6MEF
Hello Mark et al,
ampd-1.0 daemon made by Marius YO2LOJ is fast, selfcontained and easy to start. It stores learned routes in encap format file, ready to use any time in case of need.
My Raspberry Pi set into DMZ zone sits behing my own router. This is the ONLY requirement to have it working.
Best regards. Tom - sp2lob
Are you running any kind of NOS on your Pi?
As far as I can tell, the ampr daemon simply populates a non-NOS machine - or am I wrong here?
Mark
On Tue, Aug 6, 2013 at 10:49 PM, sp2lob@tlen.pl wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hello Mark et al,
ampd-1.0 daemon made by Marius YO2LOJ is fast, selfcontained and easy to start. It stores learned routes in encap format file, ready to use any time in case of need.
My Raspberry Pi set into DMZ zone sits behing my own router. This is the ONLY requirement to have it working.
Best regards. Tom - sp2lob
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
It doesn't populate anything unless instructed to do so.
If you configure one single interface with a single IP it will accept ALL 44 traffic for encapsulation, so it creates only one single route: 44.0.0.0/8 via tunnel_if. Local routes, having bigger netmask will take precedence.
The poulating of routes was needed in rip44d and ampr-ripd because the kernel IPIP tunnel device needs those routes to find out its gateways for encapsulation (this is the way to configure it for multipoint operation).
So, in a simple config, you get a virtual ethernet interface from amprd having your ampr gateway address as ip, a netmask of 8 and one single route, as any interface would. All other route handling is done internally.
Marius
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Mark Phillips Sent: Wednesday, August 07, 2013 05:56 To: AMPRNet working group Subject: Re: [44net] Why rip44d?
(Please trim inclusions from previous messages) _______________________________________________ Are you running any kind of NOS on your Pi?
As far as I can tell, the ampr daemon simply populates a non-NOS machine - or am I wrong here?
Mark
On Tue, Aug 6, 2013 at 10:49 PM, sp2lob@tlen.pl wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hello Mark et al,
ampd-1.0 daemon made by Marius YO2LOJ is fast, selfcontained and easy to start. It stores learned routes in encap format file, ready to use any time in case of need.
My Raspberry Pi set into DMZ zone sits behing my own router. This is the ONLY requirement to have it working.
Best regards. Tom - sp2lob
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Wed, Aug 7, 2013 at 5:16 AM, Michael E. Fox - N6MEF n6mef@mefox.org wrote:
This is a serious question: Why is everyone so enamored with and focused on using rip44d?
It has a few advantages, and the disadvantages are easy to work around too:
- Rip44d depends on getting the routes from a single source - amprgw, i.e.
a single point of failure.
If it fails, rip44d does not remove routes at all - the old route expiration code does not run when it's not receiving route updates.
Also, it should be straightforward to set up a replacement route announcer somewhere else if necessary. It should probably be prepared in advance so that it's easy to just fire it up as necessary. Actually, both could run at the same time just as well, the receivers wouldn't care if they got the announcements twice from two different sources. Brian, how about that?
- If that single source fails (as it did recently, for more than 12 hours),
then the routes are gone, even though all of the other gateways may be completely reachable.
Nope, the routes are not gone, they don't time out when updates are not received.
- If you try to avoid that problem by timing out the routes slowly, then
you might as well have a static list.
Hm... I wouldn't say so. The upsides of the RIP approach are probably:
1) Quicker updates - as soon as amprgw loads new routes and starts announcing them, within a minute (or something like that, I don't remember the transmit interval) you'll have them on all gateways.
2) I think some people find it easier to set up than the download/munge script set. I do, but then again, I wrote my own RIP code, so don't count me as proof of that. Maybe some users of the RIP daemons could comment on this. On the other hand, there have been some problems getting the RIP packets to go through a NAT device, but most of these have been general problems of getting IPIP packets through the NAT at all (the RIP packets are within an amprnet IPIP packet so the NAT device should not actually see the RIP packet or care about it at all).
3) All gateways running RIP get the routing updates consistently at the same time (and very quickly), as compared to rather random hourly, daily or weekly downloads of encap.txt at different gateways.
4) The RIP daemons do incremental route table updates. Normally they don't touch the routing table at all - they only insert new routes when they appear in the announcements, and delete old routes when they time out (or are replaced by a new route for the same subnet). The munge scripts I've seen (or written :) first remove all tunnel routes and then insert all routes back from the new encap.txt, which is a bit suboptimal and causes packet loss for unchanged routes (which I admit might not be currently noticed by anyone, but that's another problem). If you went for a quicker update cycle (hourly? twice per hour? every two minutes?) the problem would become worse.
Advantages:
- You can define how often you want to download the file, based on how
quickly you want to discover new gateways. For me, once nightly is fine. But it could be more often.
Actually, I would count that as a disadvantage.
It might be fine for you, but assuming we would have attractive services on the network, which a lot of people would be happily using, and if you would be providing one of those services, and you only download the file nightly. Imagine that my gateway's IP address changes, I update the gateways database, and then my network's users are moaning "why can't I access N6MEH's great service" for a day. My response would have to be something like "It will start working later... I don't know when, maybe it'll take a few hours, maybe it'll take a day, or a week - I don't know, since N6MEH sets his own update schedule." I'd be more happy to know that it'll start working pretty quickly.
It works the other way around too - if I'd provide a great service on the amprnet, and I'd like to move its gateway to a new address, I'd like your network users to get to the new gateway quickly - maybe quicker than you'd care. The point is that others might find your chosen schedule too slow for their use case.
Also, when debugging problems on the network, with a new gateway, you have no idea if all the other gateways have already downloaded a new encap.txt since everyone has their own schedule. If you can't reach someone, it's either because his routing table is old, or there is some other problem - and it's hard to tell the difference, when everyone sets their own schedule.
- If the download of encaps fails, I continue using the same routes I had
before until the next download attempt. This happens every once in a while
- maybe once a month, for whatever reason. But no connectivity is lost.
Same with RIP, no problem. The received routes can be stored on disk so that they persist over a reboot (the C version does that already I think).
- If amprgw fails, the direct tunnels to all other gateways are
unaffected. i.e. Single point of failure eliminated.
You are still downloading routing updates from a single URL, I think. If that server fails, you won't get new routes. From availability perspective, that's not really different from the current RIP setup where there is a single RIP announcer and its failure only stops you from getting new updates - you're not going to loose the routes. Also, it's easy to set up a second RIP announcer.
To be honest, I can also see downsides on the RIP setup:
1) Lack of security - the global well-known password approach makes it easy to spoof fake RIP packets and adjust routing. It's easier to spoof the packets than to get people to download invalid encap.txt files (requires DNS spoofing, or man-in-the-middle, or hijacking the server where it's downloaded from).
2) Requires custom code, but we already have that for a few platforms (NOS + two variants for Linux). But the munge scripts are custom code too.
- Hessu
On Wed, Aug 07, 2013 at 08:22:35AM +0300, Heikki Hannikainen wrote:
Also, it should be straightforward to set up a replacement route announcer somewhere else if necessary. It should probably be prepared in advance so that it's easy to just fire it up as necessary. Actually, both could run at the same time just as well, the receivers wouldn't care if they got the announcements twice from two different sources. Brian, how about that?
Sounds reasonable to me. The obvious place for the other announcer is at the portal as it's the other place with the current database.
- as soon as amprgw loads new routes and starts
announcing them, within a minute (or something like that, I don't remember the transmit interval) you'll have them on all gateways.
amprgw loads new routes at the top of the hour. The announce interval is five minutes. - Brian
On Tue, 6 Aug 2013, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Wed, Aug 07, 2013 at 08:22:35AM +0300, Heikki Hannikainen wrote:
Also, it should be straightforward to set up a replacement route announcer somewhere else if necessary. It should probably be prepared in advance so that it's easy to just fire it up as necessary. Actually, both could run at the same time just as well, the receivers wouldn't care if they got the announcements twice from two different sources. Brian, how about that?
Sounds reasonable to me. The obvious place for the other announcer is at the portal as it's the other place with the current database.
amprgw loads new routes at the top of the hour. The announce interval is five minutes.
- Brian
So there's now 12 redundant transmissions of the same data. There would be no increase in net traffic if those 12 transmissions came from 12 different sources. Probably overkill, how about going for three transmitters, eack on 15 minute intervals?
Thanks for the replies, especially from Heikki, who provided really detailed responses.
A couple more questions: 1) Currently, I have the ip munge stuff putting the amprnet routes in a separate routing table. This makes my main routing table manageable/readable. Does rip44d put its routes in a separate table or in the main table?
2) I'm confused about the update/delete interval. Some have said they slow down the deletions to avoid problems with the main gateway (route sender) going away. But others have said that rip44d doesn't remove routes if it's not hearing from the route sender. In that case, it would be better not to delay the deletions. Which is correct?
Comment: I did have to chuckle at Heikki's comment about how important a quick update would be if people were putting up useful services. To use a service, I first have to know about it. And I'll probably learn about it more than 24 hours after it's available. So 15 minutes routing udates don't help. But what made me chuckle was the suggestion that people would be putting up new, useful services. Several on this list keep pushing for a discussion of new services. But everyone seems to focused on routing. So we'll end up with a more complicated, albeit probably better routing path between 44-net and the Internet. But still no services! It's like the infamous bridge to nowhere.
How about: 1) Split DNS (yes, this is mostly hidden infrastructure, but would help with services that shouldn't be made publically available or with services that get different treatment depending on if the user is in 44.x or not) 2) Email-APRS two-way gateway. What I can find seems to be a jumbled mess of this or that not-quite-there "solution". I don't find a universal gateway between BBS and APRS or between SMTP and APRS. The 44-net could be used to insure that SMTP to APRS messages are coming from amateurs. WL2K has something (http://www.winlink.org/aprslink). 3) Online graph of gateways and systems behind gateways to help users locate a way to contact people. WL2K: http://www.winlink.org/userPositions. IRLP: http://www.irlp.net/google.html 4) Directory. How does a user find where someone is so he/she can send them a message? From what I've seen, WP is not widely implemented due to: bugs, improper configuration, and maybe because it just doesn't work very well. Just like WL2K has <callsign>@winlink.org, it would be nice to be able to reach someone using a simplified address.
My own efforts are currently being spent on BBS to email gateways at all of our BBS sites. Due to the 3rd party traffic restrictions previously discussed, we're working on Internet access at each site, plus implementing email servers with spam/virus detection, etc. That's a service that the users can actually use.
Michael N6MEF
On Thu, Aug 8, 2013 at 8:21 PM, Michael E. Fox - N6MEF n6mef@mefox.org wrote:
A couple more questions:
- Currently, I have the ip munge stuff putting the amprnet routes in a
separate routing table. This makes my main routing table manageable/readable. Does rip44d put its routes in a separate table or in the main table?
By default they go in the main table. There's a command line option, -t <tablename> to make them go to a separate table, I guess most people use it and have a separate '44' routing table.
- I'm confused about the update/delete interval. Some have said they slow
down the deletions to avoid problems with the main gateway (route sender) going away. But others have said that rip44d doesn't remove routes if it's not hearing from the route sender. In that case, it would be better not to delay the deletions. Which is correct?
It'd be better to not delay, I suppose, just because of the (rare?) case of a specific route getting replaced by a new, wider prefix with a new destination address.
When initially writing rip44d I put in a longish delete interval just to be safe, and only later I gathered it'd be smart to move the old route expiration call to the received packet path, so that it's only run after packets have been received. I guess the delete time could be shortened now, if it becomes an issue somehow.
Comment: I did have to chuckle at Heikki's comment about how important a quick update would be if people were putting up useful services. To use a service, I first have to know about it. And I'll probably learn about it more than 24 hours after it's available. So 15 minutes routing udates don't help.
Well, at some point, maybe a year after you've learned to love that hypothetical useful service, the public IP address of the gateway providing that service will change. Or your own gateway will need to move to a new ISP. At that point you might appreciate the quick update!
But what made me chuckle was the suggestion that people would be putting up new, useful services. Several on this list keep pushing for a discussion of new services. But everyone seems to focused on routing.
Routing is probably easier for us than great services, and we have experience on it already, and it does need some improvements. It probably doesn't hurt to do that, too.
I run http://aprs.fi/ myself (wrote it), and some 15000-20000 visitors find it useful every day (well, at least some of them, I hope). I've been wondering about bringing it to the amprnet side somehow, so that it could be accessed from radio-based networks, and I could offer some extra services (transmitting) to the amprnet clients. The tricky part is the real-time map - Google Maps doesn't work from the amprnet, and I'd have to run my own map tile service, which is a largish additional effort. The rest of the site would work pretty much out of the box. Ah, advertisements wouldn't work either, but everyone would be OK with that.
- Split DNS (yes, this is mostly hidden infrastructure, but would help
with services that shouldn't be made publically available or with services that get different treatment depending on if the user is in 44.x or not)
Someone could also run a reverse proxy service of some sort, which would make non-commercial amateur radio services currently existing on the Internet visible to the Amprnet, with the consent of the authors of those sites. Or otherwise help those site owners to make them available.
An easy-to-use chat service would be cool, too. conversd is a bit dated although working, IRC is too technical for many (there are only 2 people on #44net channel of the Freenode IRC network). IRC with a nice web chat interface on top? XMPP with any XMPP chat client + web chat UI?
- Hessu, OH7LZB
On 08.08.13. 23:21, Heikki Hannikainen wrote:
An easy-to-use chat service would be cool, too. conversd is a bit dated although working, IRC is too technical for many (there are only 2 people on #44net channel of the Freenode IRC network). IRC with a nice web chat interface on top? XMPP with any XMPP chat client + web chat UI?
XMPP? What a nice idea! Never thought about that.
It's almost trivial to setup a chat server using node.js -- I have an application specific one running at http://qso.k7ve.org
Should work with any modern web browser.
------------------------------ 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
On Fri, Aug 9, 2013 at 2:42 AM, YT9TP op. Pedja yt9tp@uzice.net wrote:
(Please trim inclusions from previous messages) ______________________________**_________________ On 08.08.13. 23:21, Heikki Hannikainen wrote:
An easy-to-use chat service would be cool, too. conversd is a bit
dated although working, IRC is too technical for many (there are only 2 people on #44net channel of the Freenode IRC network). IRC with a nice web chat interface on top? XMPP with any XMPP chat client + web chat UI?
XMPP? What a nice idea! Never thought about that.
-
Brian Kantor -
Heikki Hannikainen -
K7VE - John -
Marius Petrescu -
Mark Phillips -
Michael E. Fox - N6MEF -
Rick Green -
sp2lob＠tlen.pl -
YT9TP op. Pedja