> 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear YLs and OMs,
beware of the latest Mikrotik RouterOS version 6.21 and 6.22.
It generates strange IPIP packets adressed to the remote endpoint of
an IPIP tunnel. The IPIP packets itself contains an IP packet that is
addressed from the remote endpoint to the mikrotik router.
Pseudo packet capture
Frame: 1
Time: 0
Internet Protocol Version 4, Src: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik), Dst:
Re.Mo.Te.IP (Re.Mo.Te.IP)
Internet Protocol Version 4, Src: Re.Mo.Te.IP (Re.Mo.Te.IP), Dst:
Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik)
Frame: 2
Time: 10
Internet Protocol Version 4, Src: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik), Dst:
Re.Mo.Te.IP (Re.Mo.Te.IP)
Internet Protocol Version 4, Src: Re.Mo.Te.IP (Re.Mo.Te.IP), Dst:
Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik)
and so on, almost every 10 seconds.
Once I downgraded to version 6.20 the strange packets seem to have
stopped appearing.
If someone discovers the origin of this issue and knows of a way to
avoid the issue other than downgrading, please let me know.
Thanks to PE1CH for notifying me after seeing the strange IPIP packets
on his system.
73 de Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJUZTQXAAoJEHFIN1T8ZA8vGwAP/2qJuWXQLG4x3S2zPkQFll15
PA9H/ytSxxfdDsKe7tCf7Ky0qmxUV6WNVbq19/Ag1q6Ld+cBhKbWHa7BOVK9hjV0
8NO2ZV5D7KtYkhSLpNE9othhdtU/hRouevEQy/qoO6EvJxE4fEpbOrMiNX6aTAeQ
bnqBWeGsuds7/qHFjOrID0jrfYXdddMW4e9cXwRJRfiFafBIwwLaNHhlKXORaXQy
23mPs+woFskGPk4VXDxWXMuOe3TeWzpxpwldYHaPRhzfUmGBj0ogQ1tSJPiMYMy8
Rc8iE4NtmZMyP0b6IdnoIjveloCpILDIwCHD8ZRba4KSs3aRVcyLih3v67zuu3Jf
i+K7BCKXNFIQtGoY7IQQawRF8AP7vxL30r9J9pgKk7IjURDTBWRDbyZb201gdfbp
PKV+XBlm+Hq9kxs04BIYeYBES+iVLMOJYtLPQtF906EEc1RuzjjvoKu+BVqIB+vk
IRLSBqLsU4V7CM/aj2gvik4TyC2huBjhqpvxNUXeAP5CyMSfqJ8OZZmOYEGyWmZc
vif4F5HhwCjPCaQr0OCqUIKuH/hd+/4qXrFtSnTOYPT+mRCMNg1PW/IvkysS86+5
orQ1J+OeqUnfwHrXvR26l9Yo+SqKie3k+1v9iYyv6ZS7eKFKqseL+lPgQmdnnJl4
gY65U+kkGw27RtlLYw5+
=+9vG
-----END PGP SIGNATURE-----
> Subject:
> Re: [44net] Gateways with external address in net-44
> From:
> Brian <n1uro(a)n1uro.ampr.org>
> Date:
> 11/12/2014 02:07 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Wed, 2014-11-12 at 10:16 +0100, Rob Janssen wrote:
>
>> >Ok, but then I think those gateway entries should not be distributed via RIP.
>> >When they are directly routable, should we use a tunnel to reach them?
> That's only half the equasion. The other half is when one is SAFed
> (Source Address FilterED) and they policy route 44/8 via their tunnel
> interface, and anything else via UCSD...
Yes that is the problem. I need to policy route on source address because of SAF
and I use a separate routing table for the tunnels with a default to UCSD. This fails with
that 44.24.240/20 with gateway 44.24.221.1 network.
We are building a gateway for 44.137.0.0/16 which in fact has already been running since
the summer but the process of getting the provider to agree to route BGP has taken much
longer than anticipated. Anyway, this gateway (which of course is not affected by SAF itself)
has a separate public IP (194.109.64.198) for use by the IPIP tunnels to other gateways.
I think that is a better method, it avoids lots of confusion and complicated policy routing
rules.
Maybe the routing will work again once we have our country gateway up and running
with BGP and direct outbound routing of net-44 traffic (without having to tunnel to UCSD).
I plan to work out a routing configuration without separate net-44 routing table at that time.
Rob
Brian Kantor wrote:
> Those are valid gateway entries; those particular 44-net addresses
> are directly routed via BGP advertisement.
> - Brian
>
Ok, but then I think those gateway entries should not be distributed via RIP.
When they are directly routable, should we use a tunnel to reach them?
There is a problem because when the destination of the tunnel is within the net-44,
the routing gets in an encapsulation loop.
Rob
