> 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
> Subject:
> Re: [44net] Iperf server for public use
> From:
> Andy Brittain <g0hxt(a)greatbrittain.co.uk>
> Date:
> 07/23/2015 07:39 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Hi Assi
>
> Results for UDP:
>
> ------------------------------------------------------------
> Client connecting to kk7kx.ampr.org, UDP port 7000
> Sending 1470 byte datagrams
> UDP buffer size: 160 KByte (default)
> ------------------------------------------------------------
> [ 3] local 44.131.243.3 port 35310 connected with 44.8.0.160 port 7000
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0-10.0 sec 8.00 GBytes 6.86 Gbits/sec
> [ 3] Sent 893 datagrams
> [ 3] WARNING: did not receive ack of last datagram after 10 tries.
This means it failed!
> For some reason that I cant work out I get no response from the TCP test.
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?
Rob
Hi,
Anyone else having issues logging into the portal. I get a message I have to
activate my email, so it sends me an email then I click link add my user
name and I get .. Opps.. We have a problem, contacting webmaster..
Also if I send an email to the ampr system I get no replies, unless I
intentionally send a non-plain text message.. then it replies I can only
send plain text. No replies to plain text.
I suspect both systems have forgotten me..
73 Jerry N9LYA
Indiana IP Coordinator..
>> Subject:
>> [44net] Iperf server for public use
>> From:
>> "Assi Friedman" <assi at kiloxray.com>
>> Date:
>> 07/23/2015 05:50 PM
>>
>> To:
>> "'AMPRNet working group'" <44net at hamradio.ucsd.edu>
>>
>>
>> Folks:
>> I'll leave the iperf server running on kk7kx.ampr.org for the benefit of the
>> community. I combined both to operate on port 7000. To connect, use the
>> following basic syntax:
>> TCP: iperf -c kk7kx.ampr.org -p 7000
>> UDP: iperf -u -c kk7kx.ampr.org -p 7000
>> If you do use it, please be considerate.
>> Thank you,
>> Assi kk7kx/4x1kx
>Still no connectivity whatsoever with your system....
>No ping, no tcp, no udp.
>This is from 44.137.0.0/16. How do you route there?
>
>Rob
I noticed that I can reach Assi's host from the general internet, but
not from directly within the private tunnels.
Steve
Folks:
I'll leave the iperf server running on kk7kx.ampr.org for the benefit of the
community. I combined both to operate on port 7000. To connect, use the
following basic syntax:
TCP: iperf -c kk7kx.ampr.org -p 7000
UDP: iperf -u -c kk7kx.ampr.org -p 7000
If you do use it, please be considerate.
Thank you,
Assi kk7kx/4x1kx
-----Original Message-----
From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu
[mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of Will
Gwin
Sent: Wednesday, July 22, 2015 10:43 PM
To: 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] Packet loss through UCSD?
(Please trim inclusions from previous messages)
_______________________________________________
On 7/22/15 10:27 PM, David Ranch wrote:
> Linux's ipfwadm and ipchains were stateless "packet filters" but iptables
has been fully stateful for many many years. We are now at the cusp of
nftables on Linux which makes things even more programmable though I don't
know about the performance.
My mistake. It's been years since I was actively comparing the different
fire-walling methods in use by Linux. I went hardware for years and only
within the last few years went to software, when I went OpenBSD due to
native IPsec support as well as pf.
>> Filtering at a router is a sure fire way to bring throughput to a crawl.
Proper campus routers are designed with ASICs optimized for routing in
hardware, and fire-walling is done in software.
>
> Modern ASIC based firewalls can handle 100,000s of stateless filters on a
per interface basis.
Note I said 'router', not 'firewall'. Routers are designed from the silicon
up to forward packets, reduce broadcast domains and connect networks.
Firewalls are designed from the silicon up to restrict the flow of packets.
Yes firewalls will forward packets from one network to another, but their
primary purpose is inspection and restriction.
>> I have seen enterprise small office routers handle 450~500mbps of
straight routing but max out around 40mbps when fire-walling because it's
CPU bound. The results are similar when stepping up to large chassis
routers.
>
> It depends on the class of devices you're buying. There are many
inexpensive Enterprise grade firewalls (always stateful) that can run many
100s of Megabit and a few thousand dollars will get you into the 10G+ range.
Again, please note that I said 'router', not 'firewall'. As to the type of
router I was referring to in that specific example was a Cisco enterprise
branch router. Campus and data center grade routers do minimal traffic
filtering if any due to the CPU hit they incur, hence why large hardware
firewalls exist. Proper tool for the job.
> Yeah.. but we don't need that throughput or scale.
The current configuration was choking, hence the discussion. Brian has
worked with CAIDA and resolved the congestion for now.
>Just statelessly filtering at the border edge with a modern router would
solve much of these issues.
Please note that router and firewall are not the same thing. They can do the
same job, but not as effectively as the device purpose built for the job.
Also Brian already stated:
> The port 'em0' is connected to a 1G switch which is in turn connected at
10GbE to the building infrastructure switch/router.
and
> to do so requires administrative access to the campus border router that
we don't have.
Fire-walling is done at the AMPR edge, but traffic was overwhelming the
current configuration. Moving filtering to the provider router is
technologically improper and operationally restricted, hence my suggestion
to split filtering and tunneling onto separate machines to increase
capacity.
The suggestion Tom made of running an IGP to selectively advertise only
subnets which have valid destinations via the tunnels would also restrict
the amount of traffic that will ultimately be blocked from reaching the
firewall. This type of routing combined with a large null route is a common
practice in large enterprise networks. Reducing the amount of traffic that
is going to get blocked from reaching the AMPR edge will help system load
but won't help with the timeouts due to slow [or down] tunnel peers.
As this thread has demonstrated, there are a few different ways to increase
capacity of the AMPR gateway. While it may not be necessary at this time,
it's still useful information to have for whoever is going to be responding
next time there is an issue.
--
Will
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
