Well seems every platform is a bit different. The ip route command
works a bit different from Debian to Redhat. Here are the errors when
I tried to run rip44d on CentOS platform:
route del failed: 'LANG=C /sbin/ip route del 44.183.0.0/255.255.0.0':
Error: an
inet prefix is expected rather than "44.183.0.0/255.255.0.0".
route add failed: 'LANG=C /sbin/ip route add 44.183.0.0/255.255.0.0 via
130.208.168.63 dev tunl0 window 840 onlink': Error: an inet prefix is
expected rather than "44.183.0.0/255.255.0.0".
route del failed: 'LANG=C /sbin/ip route del 44.208.0.0/255.255.0.0':
Error: an
inet prefix is expected rather than "44.208.0.0/255.255.0.0".
route add failed: 'LANG=C /sbin/ip route add 44.208.0.0/255.255.0.0 via
94.101.48.134 dev tunl0 window 840 onlink': Error: an inet prefix is
expected rather than "44.208.0.0/255.255.0.0".
route del failed: 'LANG=C /sbin/ip route del 44.142.0.0/255.254.0.0':
Error: an
inet prefix is expected rather than "44.142.0.0/255.254.0.0".
route add failed: 'LANG=C /sbin/ip route add 44.142.0.0/255.254.0.0 via
Single point of presence only for vast connectivity. I have read others
ideas about having multiple GP hosts.. That is a great concept.
As for vendor non-specific.. I think just about any common platform of
routing will do. What I hate to see is something that has to be run on a
certain box. Whether it be RIP44d, or any other specifically modified
routing protocol. You don't see Cisco's specific standards being used
across platforms, because they can only be used with other Cisco boxes.
While I am stating all this all to obvious information, i do realize there
have been some very long nights and likely some personal sacrifices that
folks have made to have 44Net what it is today. i just think there needs to
be a road map developed like any project, to make sure everyone that has
the common interest be allowed to play, and not be locked down to what
flavor they have to have. Be it PPP, VPN, BGP with some redundancy,
vanilla, chocolate... I don't have the answer, because it's too big to wrap
my head around this early in my game. I'd be willing to be part of
something that can define and help others though.
--
Rod Ekholm
All,
Like the subject says.
I've noticed I'm getting a RIP update from 81.174.253.193 which contains
only a few of the major subnets in our nework.
Anyone got a clue as to whom this is and why they are sending them?
Thanks
Mark
Hi all,
I have setup, after many years of absence, our AMPRnet GATEWAY in
Athens, running in a LINUX BOX.
I have a dynamic IP here which rarely changes and up to now I had
access to several AMPRnet hosts.
Yesterday I had to reset my router (TL-WR1043ND running DD-WRT) and I
lost connectivity.
Checking http://portal.ampr.org I can see that my new Internet IP has
been updated (it takes about 1 hour I think).
Problem is that now I cannot ping gb7cip.ampr.org or any other AMPRnet
host I could before?
I can see that rip44d is doing it's thing using "tcpdump -i tunl0".
How long does it take for AMPRnet to be informed after a change in
Internet IP (nor 44net IP)? It has been more than 12 hours since my
router got it's new IP and no joy yet!
Any ideas guys?
--
73 de SV1UY
Demetre Ch. Valaris
IP Coordinator for AMPRnet in Greece
e-mail: demetre.sv1uy(a)gmail.com
Radio e-mail: sv1uy(a)winlink.org
(to use my radio e-mail put //WL2K in the beginning of the subject line)
http://www.qsl.net/sv1uy
I was just curious, is the portal's DNS request page up and running,
or do I need to try to contact my coordinator directly?
I'd like to add a couple of A name records for my routing experiment.
router-3.k1qv.ampr.org A 44.4.36.3
router-5.k1qv.ampr.org A 44.4.36.5
These will be the two routers that will be connected to my gateway via OpenVPN.
Thanks for the update,
Blaine, K1QV
Sent from my iPhone
Anybody that knows about BGP & GRE, I was wondering if this would be useful
for us to look into (I am not that person).
http://www.rfc-base.org/txt/rfc-6836.txt
Jim A.
Michael,
At this point, ampr-ripd (C implementation) is the best thing out
there in my opinion.
Hessu, wrote the rip44d, and that required Perl and a multicast
package to run. So running this on a WRT54G, for instance was
probably not going to happen. I'd like to think with the C
implementation, this could be a reality.
Also, I am not sure, but do think the C implementation stands the
greatest chance to run cross platform. Hessu's perl one was kind of
locked to Debian installs.
Again, it's all so new, I personally haven't had they time yet to try
it on a bunch of different platforms.
I actaully am not sure why someone would go with amprd over ampr-ripd.
Perhaps others can comment.
Steve
Here are some random thoughts:
It would be interesting or maybe helpful if the ampr.org name server
did some statistics collection. These stats could be used to help
prune dead records? I am not sure how resource intensive that might
be however. It looks like you can use Cacti in conjunction with BIND.
It is also important that we have some idea what is on the amprnet,
what it used for. The Michigan Digital Radio group has some basic
activity polling : http://server1.nuge.com/~drg/network.html
Perhaps even something that can be installed on gateways that
promiscuously monitors well know ports/services, and can be configured
to report activity to a central page? If nothing else can the gateway
portion of the portal have some additional text boxes, so folks can
explain things a bit more like the old resource.txt?
There is a message showing on my RPI gateway 44.135.96.17 tunnel TTY0
saying
"ignored packet from 44.131.160.1: 520: 504" every 5 minutes or so. any
suggestion how to resolve this...
Luc VE3JGL in Ottawa
