> 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
David:
Let me see what I can do about that. While iperf doesn't support user end
messages, I posted the basic info on http://kk7kx.ampr.org.
Assi kk7kx/4x1kx
PS: a week ago someone from the mailing list pinged me asking for contacts
in the IARC. Please send me a note again to assi(a)kiloxray.com so I can
forward it to the people I know. I should probably figure out how to check
the archives on the mailman but I have been pretty busy to poke the system.
-----Original Message-----
From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu
[mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of
David Ranch
Sent: Thursday, July 23, 2015 11:26 AM
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Iperf server for public use
(Please trim inclusions from previous messages)
_______________________________________________
Hello Assi,
> 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.
Thanks for doing this and I think this is a great way to not only validate
connectivity but also performance. One issue here is what performance
should people expect. I looked but it seems that Iperf doesn't support any
sort of banner to tell people something like "Internet connection is 10Mb/s
VHDSL@ MTU of 1480 - you should expect X throughput with a last hop latency
of 23ms".
Since that isn't supported (yet), can you tell us a little about your
network connection and maybe we can get this captured into the AMPR portal.
Would be very helpful!
--David
> Subject:
> [44net] Iperf server for public use
> From:
> "Assi Friedman" <assi(a)kiloxray.com>
> Date:
> 07/23/2015 05:50 PM
>
> To:
> "'AMPRNet working group'" <44net(a)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 the same thing, unable to reach kk7kx.ampr.org
I am running iperf on the same ports (till my next reboot) on
44.92.21.35, which should be reachable both ways for anyone who cares
to mess around.
Note: the gateway this host is behind is a residential cable modem
15/1 Mbps, nothing impressive.
________________________________
>> Subject:
>> Re: [44net] Packet loss through UCSD?
>> From:
>> Assi Friedman <assi at kiloxray.com>
>> Date:
>> 07/21/2015 06:28 AM
>>
>> To:
>> AMPRNet working group <44net at hamradio.ucsd.edu>
>>
>>
>> Oops, left out the host name: kk7kx.ampr.org
>> TCP -> port 7000
>> UDP -> port 7001
>> Thanks,
>> Assi
>> kk7kx/4x1kx
>
>It does not reply at all, not even to ping.
>The tunnel endpoint can be pinged.
> Subject:
> Re: [44net] Packet loss through UCSD?
> From:
> Assi Friedman <assi(a)kiloxray.com>
> Date:
> 07/21/2015 06:28 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Oops, left out the host name: kk7kx.ampr.org
> TCP -> port 7000
> UDP -> port 7001
> Thanks,
> Assi
> kk7kx/4x1kx
It does not reply at all, not even to ping.
The tunnel endpoint can be pinged.
Rob
What is the AMPRGW machine based on?
Assi
-----Original Message-----
From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu
[mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of
Brian Kantor
Sent: Monday, July 20, 2015 10:32 PM
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Packet loss through UCSD?
(Please trim inclusions from previous messages)
_______________________________________________
> > On 2015-07-20 17:41, Assi Friedman wrote:
> >> and rather poor packet loss. Are there any issues or QoS policies
> >> implemented on the amprnet router at UCSD?
There's no QoS policy in effect, but 'amprgw' is getting hammered at the
moment, with inbound packet drops peaking in the 25% range so performance is
going to be horrible.
It's hard to see precisely what's happening but it looks like multiple hosts
(possibly a botnet) are sweeping through the 44/8 range looking for
something.
There's not much we can do about this in the short term. Long term includes
a higher-performance machine with faster network interfaces.
- Brian
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
