March 2015 - NZNOG - lists.nznog.org

openwrt capable routers for NZ?
by Dave Taht 09 Mar '15

09 Mar '15

at the end of my talk someone asked me what routers I would recomend to try this stuff on here, and I sort of dodged the question. If you can come up with a list of routers available here (meet me later?), I can tell you what I know about each chipset. (I have evaluated dozens of these over the last year...) In general ath9k based gear is currently best (entirely open wifi driver), with nearly every manufacturer shipping stuff based on that. I see there is a lot of ubnt here, and most of their older products are well supported by openwrt. There is some good work beginning on the latest round of chipsets, but by and large the firmware for 802.11ac is closed.... And so on. I should also point out that there are plenty of other OSes available, and that I'm opposed to a monoculture of any hardware/software combination. See: https://gettys.wordpress.com/2014/10/06/bufferbloat-and-other-challenges/ for more details. -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

6 10

Internet in the upper south island
by lenz 08 Mar '15

08 Mar '15

Hi, I am currently trying to figure out if I can get anything else than a weak 3G signal in terms of internet just outside of St Arnaud. The address is 62 Alpine Meadows Drive, Saint Arnaud There is a phone line as well as a few other houses but the Chorus website tells me that they don't have any services there. I tried a few of the bigger providers and many tell me I can have VDSL but either don't come back to me or turn around and say "sorry, mate, can't" Anyone on the list that knows someone who might get anything faster than a 3G link to that address? Happy to shout beers on top of being a very grateful customer :) Thanks heaps cheers

1 1

Orcon Helpdesk
by Keith Davidson 07 Mar '15

07 Mar '15

Is there anyone from Orcon technical subscribed to this list who could contact me offlist please? Cheers Keith

10 10

Call for Presentations - DNS-OARC Spring Workshop, May 2015 -- Deadline Extended
by Sebastian Castro 06 Mar '15

06 Mar '15

NOTE: Previous message contained the right information, but with the subject referring to the wrong year. Apologies for the noise. The next OARC Spring Workshop will take place in Amsterdam on May 9th and 10th, the weekend before RIPE70. OARC is requesting proposals for presentations, with a preference for DDoS attack reports and mitigation techniques. Reports and field stories can cover DNS-based DDoS attacks, attacks to DNS infrastructure or side effects suffered by cache resolver operators. This workshop intends to build from previous strong OARC workshops, where operational content and research is welcome. Presentations from DNS operators are particularly welcome, as well as from DNS researchers. All DNS-related subjects are accepted, introduction to new tools, visualizations, DNSSEC and novel uses of the DNS. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Adopting practice from other conferences, a timeslot for lighting talks will be available for short presentations (5 to 10 minutes). Workshop Milestones * 18 December 2014, Call for Presentations posted * 8 January 2015, Open for submissions * 12 March 2015, Deadline for submission. Please note deadline was extended for an extra week. * 26 March 2015, Final Program published * 7 May 2015, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net//conferenceCFA.py?confId=21 The workshop will be organized on different tracks, depending on the topics and the timing of each presentation. If you are interested in a lightning talk, let us know at the time of submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> if you have questions or concerns. Sebastian Castro, for the OARC Programme Committee OARC is also seeking sponsorship for this workshop, please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

1 0

Re: [nznog] [Cerowrt-devel] ping loss "considered harmful"
by Dave Taht 05 Mar '15

05 Mar '15

I had spoken to someone at nznog that promised to combine mrtg + smokeping or cacti + smokeping so as to be able to get long term latency and bandwidth numbers on one graph. cc added. On Thu, Mar 5, 2015 at 12:38 PM, Matt Taggart <matt(a)lackof.org> wrote: > Dave Taht writes: > >> wow. It never registered to me that users might make a value judgement >> based on the amount of ping *loss*, rather than latency, and in looking back in time, I can >> think of multiple people that have said things based on their >> perception that losing pings was bad, and that sqm-scripts was "worse >> than something else because of it." > > This thread makes me realize that my standard method of measuring latency > over time might have issues. I use smokeping > > http://oss.oetiker.ch/smokeping/ in sqm-scripts's case, possibly, all you have been collecting is largely worst case behavior, which I don't mind collecting as it tends to be pretty good. :) However, I have been unclear. In the main (modern - I don't know what version you have) sqm code, IF you enable dscp squashing on inbound (the default), you do end up with a single fq_codel queue, not 3, no classification or ping prioritization. (it is the default because of all the re-marking I have seen from comcast) So if you are, as I am, monitoring your boxes from the outside, there is no classification and prioritization present for ping. do a tc -s qdisc show ifbwhatever (varies by platform) to see how many queues you have. Example of a single queued inbound rate limiter + fq_codel (yea! packet drop AND ecn working great!) root(a)lorna-gw:~# tc -s qdisc show dev ifb4ge00 qdisc htb 1: root refcnt 2 r2q 10 default 10 direct_packets_stat 0 direct_qlen 32 Sent 168443514948 bytes 334370551 pkt (dropped 0, overlimits 143273498 requeues 0) backlog 0b 0p requeues 0 qdisc fq_codel 110: parent 1:10 limit 1001p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn Sent 168443514948 bytes 334370551 pkt (dropped 17480, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 1514 drop_overlimit 0 new_flow_count 125872421 ecn_mark 1044 new_flows_len 0 old_flows_len 1 root(a)lorna-gw:~# uptime 12:45:35 up 54 days, 22:33, load average: 0.05, 0.05, 0.04 dscp classification in general, is only useful from within your own network, going outside. > which is a really nice way of measuring and visualizing packet loss and > variations in latency. I am using the default probe type which uses fping > (ICMP http://www.fping.org/ ). I LOVE smokeping and wish very much we had a way to combine it with mrtg data to see latency AND bandwidth at the same time. > > It has been working well, I set it up for a site in advance of setting up > SQM and then afterwards I can see the changes and determine if more tuning > is needed. But if ICMP is having it's priority adjusted (up or down), then > the results might not reflect the latency of other services. > > Fortunately the nice thing is that many other probe types exist > > http://oss.oetiker.ch/smokeping/probe/index.en.html > > So which probe types would be good to use for bufferbloat measurement? I > guess the answer is "whatever is important to you", but I also suspect > there is a set of things that ISPs are known to mess with. > HTTP? But also maybe HTTPS in case they are doing some sort of transparent > proxy? > DNS? > SIP? > I suppose you could even do explicit checks for things like Netflix (but > then it's easy to go off on a tangent of building a net neutrality > observatory). > > On a somewhat related note, I was once using smokeping to measure a fiber > link to a bandwidth provider and had it configured to ping the router IP on > the other side of the link. In talking to one of their engineers, I learned > that they deprioritize ICMP when talking _with_ their routers, so my > measurement weren't valid. (I don't know if they deprioritize ICMP traffic > going _through_ their routers) I do strongly recomend deprioritizing ping slightly, and as I noted, I have seen many a borken script that actually prioritized it, which is foolish, at best. I keep hoping multiple (many!) someones here will go have lunch with their company's oft lonely, oft starving sysadmin(s), to ask them what they are doing as to firewalling, QoS and traffic shaping. Most of the ones I have talked are quite eager to show off their work, which is unfortunately often of wildly varying quality and complexity. I find that an offer of saki and sushi are most conducive to getting that conversation started. I certainly would like to see more default corporate firewall/QoS/shaping rules than I have personally, for various platforms. Someone's got to have some good ideas in them... and it would be nice to know how far the bad ones, have propagated. > -- > Matt Taggart > matt(a)lackof.org > > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

1 0

Job: NEXTDC - Product Manager of Networks (SYD.AU)
by Skeeve Stevens 04 Mar '15

04 Mar '15

Hi all, Passing this to the mailing list NEXTDC is looking for a Product Manager of Network Services - related to their recent announcement of Azure Express-Route and other related products. Ideally you would be working for an existing Telco and understand networking products well. Check out the advert below. https://dl.dropboxusercontent.com/u/11825822/NEXTDC%20-%20Product%20Manager… Thanks all. ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve(a)eintellegonetworks.nz ; Web: eintellegonetworks.nz Phone: +612 8014 7398 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering

1 1

IANA IPv4 Recovered Address Space registry updated
by Selina Harrington 02 Mar '15

02 Mar '15

Hi, ICANN has updated the IANA IPv4 Recovered Address Space registry according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA. The policy states that in each IPv4 allocation period, each RIR will receive a single IPv4 allocation unit from ICANN. An IPv4 allocation period is defined as a 6-month period following 1 March or 1 September in each year. The address space selection software can be downloaded from: https://github.com/icann/ The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovere… Regards, Selina Harrington ******************************************* Internet Assigned Numbers Authority (IANA) Internet Corporation for Assigned Names & Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Phone: +1 310 301 5800 Fax: +1-310-823-8649 *******************************************

1 0