> Re: [44net] Bogus route entries
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 11/25/2014 07:26 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Hello,
>
> With the last apr-ripd version (1.13), this entry (or any other having the
> gateway inside its own subnet) gets ignored and can be direct routed (since
> it is BGP-ed).
> Unlike the entry 44.140.0.0/24 via some public IP which does not work.
> I would prefer to see it as it is via 44.140.0.1...
>
> Marius, YO2LOJ
Ok I must tell I have not yet installed the latest version, I am using 1.12 with the -x option
and I noted this one (as it appears near the top of the list) is coming and going all the time.
I captured a trace and this entry was not among the RIP entries sent at that time.
So the problem is somewhere upstream, not in ampr-ripd.
Next tuesday we will move our gateway to the datacenter of our ISP and we will start doing BGP
routing of 44.137 (permission from ARDC is already obtained), so then I will update ampr-ripd
and see what I can do to have entries like this working OK.
But this time my main question is why is this route changing all the time even when it is not
updated in the portal? (unlike the French one and now a Spanish one where users apparently
are experimenting and do not understand the system so they insert and delete their entry all the
time until it works)
Rob
Can somebody explain why the entry "44.140.0.0/16 via 44.140.0.1" keeps appearing and disappearing?
Of course it was already discussed before that this entry has limited usefulness, but ok when someone wants to
have it, let them (I won't be able to use it).
However, it appearing and not appearing in the routing table in a blinkenlight fashion, while the portal says:
Last modified 2014-04-12 17:46:33
Something is going wrong somewhere, but where?
Rob
> Subject:
> Re: [44net] Attn LX gateway
> From:
> "Marc, LX1DUC" <lx1duc(a)laru.lu>
> Date:
> 11/14/2014 12:25 AM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/11/2014 21:46, Rob Janssen wrote:
>
> As Rob seems to have had issues finding the correct contact email
> address for the IP address mentioned, I thought this might be helpful
> to share with the group:
>
> For IP addresses allocated by RIPE there is the Abuse (Contact) Finder:
> https://apps.db.ripe.net/search/abuse-finder.html
>
> Not each and every network has updated to the latest RIPE policies,
> but it's always worth a shot:-)
>
> 73 de Marc
It is also helpful when some contact or identifying information is present in the
gateway listing on portal.ampr.org.
In this case it only points to a clubstation with an info address, but via that I was
able to get the message forwarded to you.
It would have been helpful when your callsign and/or e-mail had been present
in the portal listing.
73,
Rob
> Subject:
> Re: [44net] amprgw ok?
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 11/18/2014 06:05 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Brian, Chris, thank you for your efforts.
>
> I took a look at the latest sent encap info and I want to bring in
> discussion the way how some gateways are announced.
>
>> >route addprivate 44.24.240/20 encap 44.24.221.1
> Now this one is ok. The gateway (44.24.221.1) is BGP announced, but not in
> the encap file. Everything ok and working.
Ok, with the exception that my systems cannot route to there, because the gateway is
within network-44. Discussed before. Hopefully will change after we are on BGP ourselves,
on a connection that does not do source address filtering.
But we won't be using a gateway within network-44 unless absolutely required, I still think
it is something to be avoided because quite a lot of gateways will not be able to route there,
and the reason of "reliability" that was given for this setup in fact results in permanent failure.
>
> Now to the other two IMHO are wrong:
>
>> >route addprivate 44.151.94.28/32 encap 44.151.94.28
> So this host expects to get encapsulated traffic to a gateway which is the
> host itself. This leeds to a routing loop and is not possible with a regular
> setup.
> This encap entry is in fact plain and simple useless: It states 'you can
> reach me via me' which gives not much information.
This one appears and disappears. Sometimes it is in my list, sometimes not. It
could be that he does not understand how to setup his system, and is not able to
read English very well. Maybe a French or otherwise Francophone person can try
to contact him and ask what is going on.
>
>> >route addprivate 44.140/16 encap 44.140.0.1
> The same applies to the above, just that the whole subnet is routed to a
> gateway which is part of that subnet itself.
>
This one also appears and disappears.
When I looked in the portal gateway list, the last two gateways were not appearing there.
Could it be that they are old gateways that have already been deleted by their owners
but are irregularly being re-announced due to the damaged database?
Rob
It appears some subnets have been purged from the portal. Can we restore
from a backup?
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] ampr-ripd 1.12 released
> From:
> "SP2L-wp" <sp2l(a)wp.pl>
> Date:
> 11/17/2014 08:02 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Rob, Marius et al.
>
> WOW!!!
> What a nifty script!
>
> Isn't small mistype here:
>
> while read d ip <--- "d" is it correct?
> do
Hi Tom,
Yes, it is correct. It reads the output of the diff command which has lines like:
< 1.2.3.4
> 5.6.7.9
It puts the < or > into $d and the IP address into $ip.
Then it either deletes or inserts the IP address in the list using the case/esac on $d.
You can copy/paste the script and run it and check using:
iptables -L ipipfilter -vn
to see if it works OK. You can run it again and nothing should change. When all is OK
you can change the ampr-ripd startup to add the -x option and modify the firewall to use
ipipfilter instead of ACCEPT for -p 4.
Make sure in the startup sequence of the system you run the script once before the
firewall is loaded, so that the ipipfilter target does exist before the rule for -p 4 is loaded.
I have my own script that sets up the entire firewall, so I call the script from there.
Rob
For those who have not yet implemented RIP or automatic import of encap.txt:
The external address of the gateway for 44.137 has changed from 194.109.64.198
to 213.222.29.194 in preparation of the setup of direct BGP routing of 44.137.0.0/16
Rob
