-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good morning,
I saw some odd routing during my tests. So I analyzed the routes added
by RIP44d. I modified the code to log the command string to add
routes, my suspicions where confirmed: rip44d v1.2 adds every route
with a prefix length of /32:
(examples)
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.161.0.0/32 via 141.75.245.225 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.129.0.0/32 via 118.22.1.194 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.147.0.0/32 via 121.99.232.227 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.183.0.0/32 via 130.208.168.63 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.94.0.0/32 via 141.224.128.8 dev tunl0 window 840 onlink table 44
All these routes should be /16
I'm trying to figure where the issue comes from, but I'm not a perl
addict, so any help is welcome. I have already confirmed that the RIP
message contains the correct netmask:
IP Address: 44.161.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 4
IP Address: 44.161.0.0 (44.161.0.0)
Netmask: 255.255.0.0 (255.255.0.0)
Next Hop: 141.75.245.225 (141.75.245.225)
Metric: 1
73 de Marc
- --
http://lx1duc.mcs.tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRVNjWAAoJEHFIN1T8ZA8vteEP/2oD1ic40dvnuZSOOdvS+NNw
BZEaIlI9gmIZ6P2FqJO4ZOs/kXLdKnxDa9hNgAV5+4bZAZyiGQIHFd1+rwIAaZKN
quzJ1h7SzYKOJYDRiMIQO8nYdDzNMYKb4H5GhSpCiDWGHnt+OJA+uV8ZXHClj7QV
y2AvJDKgrcRaf3Lr4kwghVnIHlmqibxPI2fFv8DuG8sBvIkxjtUJ21MOUq6nJD8z
HaCpJRS8169Syl3jq/8DogEvKfjkehaNmczyxWfWcN1t93Lxh+pPGu88iDhh1pNS
3CpVw7nY1aV88fQUURMNRJqB5IEDLyL9z/A6oU8t4u095SS6wj3wbzs7HpY37Oc4
UsLbqLlH88wkc1AnW5PrrzNLNyjEX4/3y1zywhwJFaVWUGRTAVKC3fB8Q4hhg0/M
r6q5LfjbFJzvZYppvsoqDMCAYHsAcg5lTP92+I1/86avntSW1Kj8bIJnrr/wGfZz
zbURMk+9U2WJlX6mnmm/Z0a/Lo+l3/T74CzXDDmr8dvEaMB9r7AeTx3M7h6H/jBi
yNrFZtwCg/ZMDcCR8jtAN8dqNOYht5uL/+N9dPZy50cyMhLjxVItl6BXrUYdXGqD
2p8zXKjwc8iPLuirvXs3cFK4dioDyJviMDTPSXss01zMBpLqj80UVltIV+xmMRf9
x6fcW9WXhFYoLN56hrti
=0CVp
-----END PGP SIGNATURE-----
It seems that you have found the very same issue I have already documented:
http://hamradio.ucsd.edu/mailman/private/44net/2013-March/000848.htmlhttps://github.com/hessu/rip44d/issues/7
Unfortunately I haven't heard back from the author or someone else and
I'm not a perl developer, so I cannot fix it myself.
Best regards,
Marc
Quoting lleachii(a)aol.com:
The populated route reads:
44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840
44.182.21.0 is a valid IP address on the ICANN Internet and does not
imply a subnet in any form.
It should contain a /24 notation as in the AMPRPortal:
44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840
No AMPR networks on my routing table (populated by RIP44d) contain the
proper CIDR notations.
Dear Bob VE3TOK (and thanks to VE3ZDA and N2NOV),
Your entry is on my route table, I'm using rip44d (not encap), so my
updates are live. The IP of my gateway is correct in the Portal. I use
the -a switch to remove my own route (and have updated it to the correct
IP); and I still receive rip44d updates over AMPR (showing that I have
not lost connectivity to the Main AMPRGW).
From testing connectivity to your subnet, I have determined that my
44GW is operational; and that some gateways may not have yet updated
their encap.
Thanks for your help; I waited a few days to to be sure that was not the
case; as I know all stations do not have dynamic routing updates, I'll
wait longer next time.
73,
Lynwood
KB3VWG
http://44.60.44.10/tools
@kb3vwg-015:~$ ping 44.135.85.1 -c 10
PING 44.135.85.1 (44.135.85.1) 56(84) bytes of data.
From 44.135.85.30: icmp_seq=7 Source Quench
From 44.135.85.30: icmp_seq=8 Source Quench
From 44.135.85.30: icmp_seq=9 Source Quench
From 44.135.85.30: icmp_seq=10 Source Quench
--- 44.135.85.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9003ms
@kb3vwg-015:~$ traceroute 44.135.85.30
traceroute to 44.135.85.30 (44.135.85.30), 30 hops max, 60 byte packets
1 kb3vwg-001.ampr.org (44.60.44.1) 0.724 ms 0.238 ms 0.218 ms
2 linux.ve3mch.ampr.org (44.135.85.151) 51.890 ms 55.835 ms 60.720 ms
3 port.ve3mch.ampr.org (44.135.85.30) 63.642 ms 62.613 ms 66.477 ms
@kb3vwg-015:~$ ping 44.135.85.30 -c 5
PING 44.135.85.30 (44.135.85.30) 56(84) bytes of data.
64 bytes from 44.135.85.30: icmp_req=1 ttl=39 time=53.9 ms
64 bytes from 44.135.85.30: icmp_req=2 ttl=39 time=51.8 ms
64 bytes from 44.135.85.30: icmp_req=3 ttl=39 time=87.4 ms
64 bytes from 44.135.85.30: icmp_req=4 ttl=39 time=52.7 ms
64 bytes from 44.135.85.30: icmp_req=5 ttl=39 time=51.9 ms
--- 44.135.85.30 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 51.899/59.607/87.406/13.919 ms
I know this is fine in regular IP routing, but is it o.k. with the AMPRgw?
I have a gateway that serves a /28 address space.
I'd like to do some testing using a couple of the addresses in that space on
a different gateway.
So, I'd like to add another gateway entry for just those two addresses
without modifying the existing gateway entry for the /28.
Regular IP longest match should prefer the /32 matches for the new gateway
over the longer /28 match for the existing gateway.
But before I implement, I wanted to verify whether or not this would be o.k.
with the portal database, the amprgw RIP routing mechanism, etc.
BTW, this would be a nice, generalized solution for a backup gateway. That
is, if the more specific route goes away, the more general route could be
used.
So, is this o.k. to do or not? If not, why not?
Thanks much,
Michael
N6MEF
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello and sorry to bother you with this.
I have added a gateway (46.29.183.253) via the portal and I have added
subnets to it. I can see the encap.txt has been updated and I do receive
RIPv2 Multicast Messages from 44.0.0.1.
I have setup rip44d and it is populating my routing table.
Example:
#ip route get 44.0.0.1
44.0.0.1 via 169.228.66.251 dev tunl0 src 44.161.229.126
cache window 840
However when trying to ping 44.0.0.1 from 44.161.229.126 I don't get any
replies.
I have followed the outgoing ICMP packets, they get encapsulated on my
gateway and the outer IP destination address is 169.228.66.251. The
packet travels without troubles thru AS51405 (the home network of
46.29.183.253) and I can actually see the packet going out to the
transit network (currently AS5577, in case you're interested).
So I'm really really sure that the IPIP packet containing the ICMP echo
request makes it out into the Internet.
I have also ran traces on all of the ingress connections towards AS51405
and I cannot see a single coming back from 169.228.66.251.
Is there anything I'm missing? I really appreciate your help.
BTW I'm allowing inbound packets carrying protocol 4 and ICMP on the
gateway, but as I don't see packets addresses towards my gateway in the
upstream network, I'm guessing it's not the firewall on my gateway H-i.
vy 73 de Marc, LX1DUC
- --
http://lx1duc.mcs.tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRUrArAAoJEHFIN1T8ZA8vXkUP/38puOAwTWz38Y9UEinjz+HM
kBLQKzeYUkVH/f1xjjVuqaiqzXss37XeAL9XeRIqkJ8znanWac8LznYl42Zvyrph
BVaRvp6+M3m4CRnNpy7LuRFfTW+DVNIS88TR+jiD+GYxXFiXc7sQSL98ozPPHYSu
QUl2pb4qqXXkVOmwjbcUami4HsBj18oCtcwE+qVwv73EBlW/S0ff6HiYawnuJPzK
yznMEeStR58K1+9IfX+o6S406JT8VnBJDQ7W6WHU0aHv3qLA+FM7Mk5DBEtHJRE5
5lwkqFwq71XSmQAX2oGWaC1rTk6pBJoSgjGAEssioP7D1hqJAHuc2fR15zDQkxXW
L7z39xc/J2z7sZleqlqldjeY9+7pA+w6opJTaZFjdMdf+yq/zuJPpWv36Pm616xy
zPnNorLHwe2WJL79+4ZPzDZamp355ATO7LFF38sx8rHJiXGuP+wb1Udi2fSG9J1O
5jYM4XHKWQnVRdTeit2WkUoEW0c+pgN0nsQ4iReXEragXdmhnpXmQhagKZP10/S5
0TMplR1D/3LLVTMRnjhxyUfY9ZtA6dw1S9DyZQadeJh6Y0KD5QoistEOgXqMnoZS
a+c5GN/cc/BSxdHrLnc+yk9FxjL+I2fuU6bwuf27fjcXuTSoGglqZMCMM636Rkj1
scOCTXhoQdfwIeA5aV/z
=Yi7/
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good evening dear OMs,
I'm really new to this Mailing-List. I have been reading through the
information available online but I have a few remaining questions:
- - Can there be more than 1 coordinator for one single area (e.g. 2 OMs
handling a country conjointly)?
- - Do the former tunnels still exist for delegations which haven't been
moved/migrated to the new portal? (Or are they offline from the
Internet side of things?)
- - The new system/portal seems to favor a mesh network of tunnels, are
intra-country tunnels (no directly connected to the AMPR gateway but
connected via a local gateway (which in turn is connected to the AMPR
gateway)) depreciated or unrecommended?
- - When I checked a few years ago, very very few networks within
44.0.0.0/8 were announced in the DFZ (like 1 or 2), this seems to have
increased. Is it recommended today to announce a delegation or parts
of it directly?
I'm sorry if these questions have been answered before, I really tried
finding them, but I might have searched using the wrong terms/words.
vy 73 de Marc, LX1DUC
- --
http://lx1duc.mcs.tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRTip1AAoJEHFIN1T8ZA8vRPAP/0oCcMWjMfOnlvdYxsp3+wUY
WVlwG92jKXVxrdXMKDVA+bqqyW6S5+xfMAA/nry0p+m/BbVOALLskcGeZncVspzu
MjZzmC+9ueO1hRRiQ9F6gFN0X+tTHDCHJRdJo83J0W4acw8WgFTQv/hxk9DuvySt
zzMJp7K0YKfh6bHsyvML4iePh4+Ra0B+3xyW8Dp0hnoesasRuCDBUSuENyp3NGL3
4fRH0FUYB29B+hbXH6aWZlbYe1DhwkrX7V/azeRmbDdgkTFBnfb/uj/+Sqp/H7d/
80nznr/su/ylxiGgW+fmBcoosbXcGlCzQ75/wT2Hf54k40zOeCPLI37Chc8CRVGd
/XgL/UyodGzg/SyJg0bQ/T63v969y/7xvdvUaXH182JyObNextPN+m5Ur6evMjIq
s6KhiGoJoLTfFEv/pEIDPPnITSwyx7dWw8IzAUp+UbscbaRNGbywp/T/GuhYpKhR
N3z2JJmrKXULp3rW/SYhSuYiMi72VVy83I/vnkVzK8J7CM09b06oenPLpt6Af8r8
2AEVbTKI0nmjBcg7lR9t+FxQSzMC+N3Jglt0RTjI76Uq5PpOdcBHL6/ISmXkYwk9
2H8yBkDz6suy1g5QPxu2WjCntIcgOZYYGNMAYxHRU69XbQMk/9x1BScGmhSMKIeR
U8de5N0G64S6JxdgtovR
=AKXa
-----END PGP SIGNATURE-----
Hi guys,
there are some "suspicious" entries in encap.txt:
route addprivate 44.131.192/29 encap 44.131.192.1
route addprivate 44.24.115.17/32 encap 44.24.115.17
There are even some other gateways listed with IP-addresses out of 44/8.
73,
Jann
DG8NGN
--
Jann Traschewski, Lenbachstr. 6, D-90489 Nuernberg, Germany
Tel.: +49-911-696971, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
Bill, WA7NWP,
I'm not sure this is best suggestion for many reasons:
- There was a discussion a few weeks back where it was determined that
all stations do not necessarily run telnet (while having others test
connectivity to my station, some were attempting to telnet to me). For
example, my station is not a TNOS/JNOS based router, and therefore does
not provide Converse (the telnet-based service we're referring to) by
default. Under that guideline, my allocation would be purged.
- We also determined that, while all stations should make their IP
addresses ping-able, that was not necessarily the case (either by intent
or error).
- For various reasons, AMPRNet allocations may not necessarily be online
or available through AMPR
- A Station does not necessarily have to download the encap to have a
working allocation (one could manually add static routes from the portal
list or use RIP44, for example)
- It would be impossible to use the download guideline for those using
the RIP44 routing protocol, as it is multicast; and doesn't know what
stations are receiving it or using it
We have to be mindful that all stations may not be identically
configured, use the same Operating Systems, routing protocols nor system
configurations to accomplish connectivity to AMPRNet.
73,
Lynwood
KB3VWG
On 03/12/2013 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote:
> Automate it for now and the future... If a client doesn't
> ping/poke/telnet/download or whatever within 30days/3months/whatever -
> purge the entry. You know - just like DHCP but at a higher level..
> :)
>
> Bill, WA7NWP
Just have them login once a year and reup their registration.. Like they
make you do for repeater coordination.. Allow a 90 day grace period and then
lock it for 30 days if still no contact they obviously have abandon it.. or
will return when they realize it is down.. Time frames I suggest are just
that.
That way no notice, no email reminders, no bother to the system or anyone..
They must login or get booted... Not trying to be mean.. but lets say ham A
has died.. The portal may never know this... Lets say they changed email, no
email reminder will ever reach them.. Let's say they lost interest, even an
email or post card could simply get ignored..
If it's simple and the system can send an email to the Last Known Good email
at say 11 Months... Fine.. Or make it a rolling 12 months from last login to
the portal.. But no need to make it any more than simple..
Let's keep its K.I.S.S
73
Sorry working late and bored.. lol
-----Original Message-----
From: 44net-bounces+n9lya=blueriver.net(a)hamradio.ucsd.edu
[mailto:44net-bounces+n9lya=blueriver.net@hamradio.ucsd.edu] On Behalf Of
lleachii(a)aol.com
Sent: Tuesday, March 12, 2013 4:37 PM
To: 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] Portal registrations
(Please trim inclusions from previous messages)
_______________________________________________
Bill, WA7NWP,
I'm not sure this is best suggestion for many reasons:
- There was a discussion a few weeks back where it was determined that all
stations do not necessarily run telnet (while having others test
connectivity to my station, some were attempting to telnet to me). For
example, my station is not a TNOS/JNOS based router, and therefore does not
provide Converse (the telnet-based service we're referring to) by default.
Under that guideline, my allocation would be purged.
- We also determined that, while all stations should make their IP addresses
ping-able, that was not necessarily the case (either by intent or error).
- For various reasons, AMPRNet allocations may not necessarily be online or
available through AMPR
- A Station does not necessarily have to download the encap to have a
working allocation (one could manually add static routes from the portal
list or use RIP44, for example)
- It would be impossible to use the download guideline for those using the
RIP44 routing protocol, as it is multicast; and doesn't know what stations
are receiving it or using it
We have to be mindful that all stations may not be identically configured,
use the same Operating Systems, routing protocols nor system configurations
to accomplish connectivity to AMPRNet.
73,
Lynwood
KB3VWG
On 03/12/2013 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote:
> Automate it for now and the future... If a client doesn't
> ping/poke/telnet/download or whatever within 30days/3months/whatever -
> purge the entry. You know - just like DHCP but at a higher level..
> :)
>
> Bill, WA7NWP
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44nethttp://www.ampr.org/donate.html
I've lost track of the status of the portal functionality.
We have a block of addresses allocated to our county network (44.4.50.0/28).
I also have two addresses allocated for my personal machines (44.4.2.152,
44.4.2.153)
But when I log into the portal I see no active records.
At some point will the existing records appear in the portal when I log in?
Thanks
N6MEF