44net July 2015

44net@mailman.ampr.org

40 participants
47 discussions

Re: [44net] RIPv2
by Assi Friedman 27 Jul '15

27 Jul '15

Addressing residential internet service with DHCP is a problem with the encap method. Does RIPv2 address this problem? Thanks, Assi

3 2

Re: [44net] Iperf server - kk7kx
by Rob Janssen 27 Jul '15

27 Jul '15

> 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

4 6

Re: [44net] Iperf server for public use
by Steve L 26 Jul '15

26 Jul '15

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

5 5

Re: [44net] portal down?
by Brian Kantor 26 Jul '15

26 Jul '15

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

8 9

Re: [44net] N1URO and traceroute. Was: Iperf server for public use
by Rob Janssen 26 Jul '15

26 Jul '15

> 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

1 0

Re: [44net] N1URO and traceroute. Was: Iperf server for public use
by Steve L 26 Jul '15

26 Jul '15

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. :-)

1 0

Re: [44net] Iperf server for public use
by Rob Janssen 26 Jul '15

26 Jul '15

> 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

3 4

Re: [44net] Iperf server - kk7kx
by Rob Janssen 25 Jul '15

25 Jul '15

> 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%)

2 1

Iperf server - kk7kx
by Assi Friedman 25 Jul '15

25 Jul '15

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

3 2

Re: [44net] Iperf server for public use
by Rob Janssen 24 Jul '15

24 Jul '15

> 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

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net July 2015