- NZNOG - lists.nznog.org

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

07 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 06 Mar '15

06 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 05 Mar '15

05 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 03 Mar '15

03 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

Re: [nznog] "The GCSB?s brake on innovation"
by Beau Murrah 25 Feb '15

25 Feb '15

Thanks! Ill keep plodding away and get a draft to the list and yourself to attach. --- Me: nz.linkedin.com/in/bmmurrah Ph: +6427 375 7897 Email: bmurrah(a)icloud.com PGP: https://keybase.io/airbridge > On 26/02/2015, at 1:48 pm, Stephen Quayle <stephenwq(a)gmail.com> wrote: > > Hey, > Bit of a nzlog list lurker, I'd just like to give some support for this idea you're proposing. > > Any further information about this act is greatly welcomed. > > I'm particularly curious on what might changes might typically be required to give notification of, and what might not. > We've already seem some implications for research based set ups, and possibly some hint of the difficulty of certifying open source instead of vendor supplied solutions. > > An area of interest was what this means for universities and where they might fall into it, as that's a bit different to your average business, or your average telco, yet i believe they could fall under broad ISP or carrier terms for general users. Often their networks and resources can be fairly public and they can have research arms that might struggle with the same issues as REANNZ. > > Just like to say thanks for anything you can provide in terms of knowledge and interpretation to the community, even if it just starts discussion. > > Cheers, > Stephen

1 0

"The GCSB’s brake on innovation"
by Michael Fincham 24 Feb '15

24 Feb '15

<http://techliberty.org.nz/the-gcsbs-brake-on-innovation/> Excerpt: Trying to do the same in NZ, but govt's TICSA legislation makes deploying SDN/NFV in backbone networks challenging http://t.co/91MUpxfOnw — Steve Cotter (@SteveCotter) February 22, 2015 [...] So this is a statement by the CEO of a government owned company whose purpose is to "establish and operate the Advanced Network in order to promote education, research and innovation for the benefit of New Zealand" saying that they can't do the research and development work they need to do because the bureaucrats in the NCSC at the GCSB are holding them back. -- Michael

2 1

APNIC Training Survey - We need your feedback!
by Elly Tawhai 22 Feb '15

22 Feb '15

Hi NZNOG Community, APNIC’s regional training program is designed to grow the skills of network operators to effectively deploy and manage network technology in the Asia Pacific. APNIC is currently assessing the training needs and requirements of the Asia Pacific Internet community to help plan and improve its training program so it can meet the community's future requirements. You can help us by taking part in the Training Survey below: https://www.apnic.net/trainingsurvey As an added incentive, anyone completing the survey before 7 March 2015 will be entered into a prize draw for an iPad Air 2. There will be a further draw for another iPad Air 2 after the survey closes on 20 March 2015, so early birds have two chances to win! All responses provided will remain confidential and will only be used by APNIC for the purposes of planning its training and technical assistance programs. Thank you for helping APNIC improve its training services. Kind regards, _______________________________________________________________________ APNIC Secretariat secretariat(a)apnic.net Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 3646 South Brisbane, QLD 4101 Australia Fax: +61 7 3858 3199 6 Cordelia Street, South Brisbane, QLD http://www.apnic.net _______________________________________________________________________

1 0

openwrt on mikrotiks (rb750, rb951) with openvswitch
by Sam Russell 19 Feb '15

19 Feb '15

After getting carried away coding at the SDN workshop this week I've gone and flashed an RB750 with the latest openwrt (chaos calmer), and discovered that the package/dependency management lacks the finesse of something like debian/ubuntu: root(a)OpenWrt:~# opkg install openvswitch Installing openvswitch (2.3.1-0dfed4ba9c8a16a1f316d709b7831a4e139472d4) to root... Downloading http://downloads.openwrt.org/snapshots/trunk/ar71xx/mikrotik/packages/packa…. Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for openvswitch: * kmod-udptunnel4 * kmod-udptunnel6 * * opkg_install_cmd: Cannot install package openvswitch. digging deeper, it appears that kmod-udptunnel is built for ar71xx/nand (https://downloads.openwrt.org/snapshots/trunk/ar71xx/nand/packages/base/) but not for the mikrotik fork (https://downloads.openwrt.org/snapshots/trunk/ar71xx/mikrotik/packages/base/) questions: - has anyone got this running? im going to build kmod-udptunnel from source and then opkg install openvswitch, but was hoping i wouldn't have to - does anyone have a preference for ar71xx-mikrotik over ar71xx-nand? i know Dean has deployed ovs from source on older mikrotiks running attitude adjustment, who else is playing in this space? cheers sam

2 1