> Subject:
> Re: [44net] Iperf server - kk7kx
> From:
> Assi Friedman <assi(a)kiloxray.com>
> Date:
> 07/26/2015 12:23 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Based off the output of the munge script, those two addresses take
> different paths:
> /sbin/ip route add 44.137.41.96/28 via 89.18.172.156 dev tunl0 onlink
> /sbin/ip route add 44.137.0.0/16 via 213.222.29.194 dev tunl0 onlink
Ok... THAT explains something!
This is *old* data. That 44.137.41.96/28 entry was removed on April 25th this
year, and you still have it in your table.
The 44.137.41.96/28 network should now be routed via the 44.137.0.0/16 entry,
as I have moved this network from a tunnel route to a radio link to our Dutch HAMNET
which connects to internet via a national gateway for 44.137.0.0/16.
It looks like your method of managing routes only adds and modifies entries, but
never deletes them. I'm interested in what method you are using, and if you maybe
have copied it from someone else who also still uses this. It would explain some of
the broken routing we are facing.
Of course when some route no longer appears in the encap table, you should make
sure you also delete it from your local routing table. Else you will have more and
more incorrect routes as a result.
Maybe it is better to switch to using ampr-ripd, which would not have this problem.
Rob
Corey,
I get ping replies from 44.88.0.9
To traceroute over a tunnel, you may have to change the TTL to 64 like so:
This is from my gateway, 44.92.21.1
root@ampr-gw:~# ip tunnel change ttl 64 mode ipip tunl0
root@ampr-gw:~# traceroute 44.88.0.9
traceroute to 44.88.0.9 (44.88.0.9), 30 hops max, 60 byte packets
1 gw.ct.ampr.org (44.88.0.1) 62.346 ms 68.416 ms 68.897 ms
2 n1uro.ampr.org (44.88.0.9) 71.669 ms 72.287 ms 72.554 ms
root@ampr-gw:~# ip route show table 44 | grep 44.88.0
44.88.0.0/27 via 76.28.121.159 dev tunl0 proto 44 onlink window 840
44.88.0.2 via 76.28.121.159 dev tunl0 proto 44 onlink window 840
44.88.0.192/29 via 76.28.121.159 dev tunl0 proto 44 onlink window 840
44.88.0.200 via 66.162.28.8 dev tunl0 proto 44 onlink window 840
44.88.0.201 via 66.162.28.8 dev tunl0 proto 44 onlink window 840
If I remember correctly N1URO uses the munge method, and exactly how
he has that configured is best to leave to him explain.
Steve, KB9MWR
Chris tells me they had a minor fire in the datacenter where the portal
lives and they have to install some new servers and restore from backups
so the portal (and www and wiki) will be out of service for some days
until after the paying customers are back on line. This seems entirely
reasonable to me; we can get along without it for a little while.
And again I want to say thanks to Chris for writing and hosting the portal
and our other web sites.
- Brian
> Subject:
> Re: [44net] N1URO and traceroute. Was: Iperf server for public use
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 07/26/2015 05:06 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Sat, Jul 25, 2015 at 09:55:32PM -0500, Steve L wrote:
>> >To traceroute over a tunnel, you may have to change the TTL to 64 like so:
> Strange advice, considering how traceroute works, which is to send packets
> with very low TTLs (starting with a TTL of 1 and working up to 30 in most
> implementations). If it really makes a difference to set the tunnel TTL
> to 64 in order to get traceroute to work, something very strange is going on.
The problem is that the default setting of the ipip tunnel in Linux is to copy the TTL of the
packet being encapsulated into the outer IP header. When you traceroute, the packet sent to the
public IP of the tunnel endpoint will have the low TTL that traceroute is using, and so that
packet will not make it to the destination over the internet until that TTL is sufficiently
high, can be something like 10-15 these days. So you will see many lines of * * * before
finally something comes back, and often you will have interrupted the traceroute by then.
When the fixed TTL of 64 is set as shown with ip tunnel change ttl 64 ..., the encapulation
will put a fixed TTL of 64 in the outer IP header, so it makes it through the other end of
the IP tunnel in one traceroute hop, and you can traceroute without problem. Of course you
cannot see the hops the encapsulated packet takes over the internet, but with a standard
traceroute you cannot see those anyway.
For normal traffic there is no difference, as long as sufficient TTL remains in the inner IP
packet at the moment it is copied to the outer header for that packet to make it over the
internet. So when the source sets a TTL of 64 or 255, it will be fine.
Rob
Brian,
The TTL thing is really just a bad setup on our part. From what I
understand when you create a ipip tunnel in Linux in inherits the TTL
of 0 if you haven't set it when you bring up the interface.
So without making adjustments to the TTL, you won't get responses from
your amprnet-hops.
As for why Corey can't ping Brian N1URO I assume it's because Brian
uses a munge script and maybe doesn't have a private tunnel route to
Corey.
I know both n1uro.ampr.org and n3fe.ampr.org are both reachable one of
two ways. By private tunnel and/or thru UCSD. So there is plenty of
room for a routing headache. :-)
> Subject:
> Re: [44net] Iperf server for public use
> From:
> "Marc, LX1DUC" <lx1duc(a)laru.lu>
> Date:
> 07/24/2015 09:44 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> I have a BGP feed and the IPIP mesh (loaded from API).
>
> These are the relevant routing entries for 44.137.40.2.
>
> # DST-ADDRESS PREF-SRC GATEWAY DISTANCE
> 0 ADb 0.0.0.0/0 46.29.abc.xyz 250
> 1 A S 44.137.0.0/16 ampr-213.222.de... 210
> 2 Db 44.137.0.0/16 46.29.abc.xyz 250
> 3 A S 44.137.40.2/32 ampr-89.18.def.ghi 210
>
> Rule #0 and #2 are BGP routes, rule #1 and #3 are static rules added via script parsing API output.
>
> As you can see I prefer IPIP routes over BGP.
>
> Traceroute looks fine:
>
> marconi:~# traceroute -I 44.137.40.2
> traceroute to 44.137.40.2 (44.137.40.2), 30 hops max, 60 byte packets
> 1 lx0bgp-18.ampr.org (44.161.204.1) 0.390 ms 0.493 ms 0.652 ms
> 2 tunnels.lx0bgp.ampr.org (44.161.230.255) 7.681 ms 7.743 ms 7.878 ms
> 3 sys2.pe1chl.ampr.org (44.137.40.2) 24.655 ms 24.666 ms 25.041 ms
>
> 73 de Marc, LX1DUC
>
Hi Marc,
I can ping you OK from both systems. What you tried above is via tunnel, and e.g. to 44.137.0.1 can
be via BGP or Tunnel. Both will work.
But when I ping Brian N1URO from 44.137.0.1 I see the outgoing traffic via tunnel and I never see a
reply coming back. No idea what is wrong. It cannot be a firewall at my end because I would see the
reply when tracing (tshark operates before the filter).
Interesting is that he can ping me. And I can communicate with many systems, both those that use
tunnels and those that have direct BGP routing. No idea where the issue is.
Rob
> Subject:
> [44net] Iperf server - kk7kx
> From:
> "Assi Friedman" <assi(a)kiloxray.com>
> Date:
> 07/25/2015 05:56 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Folks:
> I think the direct routes to the various AMPRNet nodes are up and running.
> Iperf is running:
> TCP: iperf -c kk7kx.ampr.org -p 7000
> UDP: iperf -c kk7kx.ampr.org -p 7000 -u
> Ping and MTR should also respond.
> I do however seem to have an issue with the web page. Does
> http://kk7kx.ampr.org respond from the AMPRNet?
> Thanks,
> Assi
>
I think there still are issues. How do you route 44.137.0.0/16 ?
I can now run the iperf from 44.137.0.1 but not from 44.137.41.97
Same for the webpage.
Rob
------------------------------------------------------------
Client connecting to kk7kx.ampr.org, TCP port 7000
TCP window size: 256 KByte (default)
------------------------------------------------------------
[ 3] local 44.137.0.1 port 57548 connected with 44.8.0.160 port 7000
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.2 sec 6.50 MBytes 5.36 Mbits/sec
------------------------------------------------------------
Client connecting to kk7kx.ampr.org, UDP port 7000
Sending 1470 byte datagrams
UDP buffer size: 256 KByte (default)
------------------------------------------------------------
[ 3] local 44.137.0.1 port 54929 connected with 44.8.0.160 port 7000
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 893 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.242 ms 0/ 893 (0%)
Folks:
I think the direct routes to the various AMPRNet nodes are up and running.
Iperf is running:
TCP: iperf -c kk7kx.ampr.org -p 7000
UDP: iperf -c kk7kx.ampr.org -p 7000 -u
Ping and MTR should also respond.
I do however seem to have an issue with the web page. Does
http://kk7kx.ampr.org respond from the AMPRNet?
Thanks,
Assi
> Subject:
> Re: [44net] Iperf server for public use
> From:
> Brian <n1uro(a)n1uro.ampr.org>
> Date:
> 07/24/2015 02:46 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Rob;
>
> On Thu, 2015-07-23 at 22:46 +0200, Rob Janssen wrote:
>
>> >This means it failed!
>> >And not from UDP either. I have the same result. It does not work.
>> >Others who can reach kk7kx?
>> >
>> >Assi, what kind of return routes do you have? Do you route everything back via UCSD
>> >or do you have a proper tunnel mesh?
> I concur:
> n1uro@n1uro:~$ iperf -c kk7kx.ampr.org -p 7000
> connect failed: Connection timed out
Hi Brian,
With your system I have a different issue... when I ping n1uro.ampr.org from 44.137.40.2 which
has an IPIP tunnel on 89.18.172.156 I can ping you without problem, but when I ping from other
addresses like 44.137.0.1 or 44.137.41.97 I get no reply.
Those addresses are supposed to be handled via the tunnel for 44.137.0.0/16 which has external
address 213.222.29.194 and is also registered in the portal.
They are also reachable on the internet directly (BGP announced)
What can be the problem? Did you add some handling of BGP routed subnets that now fails because
of the dual connectivity we have? Or is it the issue that I hunted some time ago (and never really
tracked down) where there appears to be systematic packet loss in RIP announcements that makes
certain subnets disappear completely or make them flapping?
(I tried to suppress that by increasing EXPTIME to 7200 in ampr-ripd.c)
Rob
