44net

44net@mailman.ampr.org

1 participants
3205 discussions

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

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

8 8

Email updates to AMPR/Portal Access
by Jerry Kutche (N9LYA) 24 Jul '15

24 Jul '15

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

3 2

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

23 Jul '15

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

3 2

Iperf server for public use
by Assi Friedman 23 Jul '15

23 Jul '15

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

4 3

Portal API
by G1FEF 23 Jul '15

23 Jul '15

Portal API now back online Chris

1 0

Re: [44net] Iperf server for public use
by Assi Friedman 23 Jul '15

23 Jul '15

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

2 1

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

23 Jul '15

> 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

1 0

Re: [44net] iperf
by Steve L 22 Jul '15

22 Jul '15

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.

1 0

Re: [44net] Packet loss through UCSD?
by Rob Janssen 21 Jul '15

21 Jul '15

> 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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net