[44net] Iperf server for public use

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: 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. Proper campus routers are designed with ASICs optimized for routing in hardware, and fire-walling is done in software. 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. 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. 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. The current configuration was choking, hence the discussion. Brian has worked with CAIDA and resolved the congestion for now. 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: 10GbE to the building infrastructure switch/router. and 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