- NZNOG - lists.nznog.org

Surgeries cancelled and patients told to avoid going to Rotorua and Taupo hospitals after fire | Stuff.co.nz
by Alan Maher 16 Jul '17

16 Jul '17

https://www.stuff.co.nz/national/health/94810043/rotorua-hospital-fire-cuts… And you know that this will take more than 24 hours. No form of fire protection?

1 0

Good luck!
by Jesse Archer 16 Jul '17

16 Jul '17

[image: Inline image 1]

3 2

Christchurch Hacker Con (CHCon) 2017 - Call for Presentations Training and Sponsors
by CHCon crew 16 Jul '17

16 Jul '17

Hi Everyone We are proud to announce the second Christchurch Hacker Conference (CHCon), to be held at the UCSA Events Centre, 90 Ilam Rd, Riccarton, on Friday 27 and Saturday 28th October, 2017. That’s right, we’re aiming for a two day conference - with an additional training day before the main event. The call for presenters, trainers, and sponsors is open. We will open registration for general attendees in the coming weeks, so stay tuned as registrations will be limited. CHCon is a two-day conference this year dedicated to technology security with an emphasis on both breaking and building. We will be offering training on the day before the conference (Thursday 26th October). We have a large amount of presenter slots that we need to fill, on everything from the Suggested Topics under the Call For Papers at https://2017.chcon.nz/#cfp. Presentation submissions are welcome from all interested parties, we're not interested in vendor pitches or commercial content. The close off date is approaching fast. More information is available here: https://2017.chcon.nz/#cfp We also have a number of training slots we'd like to fill. If you have a security related training you'd like to give the day before the main conference, please make a submission. More information is available here: https://2017.chcon.nz/#cft CHCon is strictly not for profit and to keep our conference fee as low as possible, we need sponsors to support us. The sponsorship money is used to help make CHCon, an instructive and quality event for the Canterbury & NZ tech community. More information about sponsorship is available here: https://2017.chcon.nz/#cfs Event Website: https://2017.chcon.nz/ Thanks from the CHCon crew

1 0

Request for contact in TVNZ On Demand for escalation of support ticket 117175
by Alexander Neilson 05 Jul '17

05 Jul '17

Hi All Sorry for the noise. Can someone inside TVNZ On Demand please make contact off list. It looks like some of our IP's (At $DAYJOB - inside 45.118.188.0/22) are on some kind of block list being used by TVNZ On Demand for Akamai delivered videos. The video player just shows a fairly useless error message, and when looked at in fiddler a 403 is being returned from the Akamai server. We are not aware of any lists any of the affected IP's are on and I believe they may be legacy listings. I have been trying to work through with TVNZ On Demand Support under Ticket 117175. So far I haven't been able to escalate this or get any feedback or way forward. We have worked with our upstream carrier and they have raised it with Akamai who have indicated it isn't a block they have in place but that their customer has hence trying to make contact with someone who could check if the blocks are recent or prior to being held by us and if recent what caused them so we can resolve it. Thank you for your time. Regards Alexander 022 456 2326

2 1

NZNOG 2018 Announcement
by Dave Mill 02 Jul '17

02 Jul '17

Hi all We'd like to announce that we will be holding NZNOG 2018 at the Rydges Hotel in Queenstown. The conference dates are 22 - 26 January, 2018. The conference proper will be the Thursday and Friday (25 - 26 January) as normal. If anyone is interested in sponsoring the event please make contact with info(a)nznog.org . We will be putting together this year's sponsorship prospectus soon. Previous sponsors have first right of return. Have a good weekend. Cheers Dave (on behalf of the NZNOG Trust)

1 1

RFC 8195 "Use of Large Communities"
by Job Snijders 01 Jul '17

01 Jul '17

Dear NZNOG, RFC 8195 "Use of BGP Large Communities" was just now published: https://tools.ietf.org/html/rfc8195 RFC 8195 presents examples and inspiration for the operational application of Large Communities. The document suggests logical categories of Large Communities and demonstrates an orderly manner of organizing community values within those categories to achieve typical goals in routing policy. Any network or route server operator can consider using the concepts presented as the basis for their own Large Communities repertoire. RFC 8195 is meant as a companion document in the same way that RFC 1998 provided a concrete real-world application for RFC1997 BGP Communities. The RFC draws on the experience of operator communities such as NANOG and NLNOG. A ton of open source implementations [1] with Large support are already available. And with more traditional vendors like IOS XR, Junos, Arista & Nokia having releases around the corner, I hope this will be useful when planning your Large Communities deployment later this year. Kind regards, Job [1]: http://largebgpcommunities.net/implementations/

1 0

Reminder to update noc contact list/details
by Joel Wirāmu Pauling 28 Jun '17

28 Jun '17

Hi all; was looking something up for a client and noticed the Noc list here; http://www.nznog.org/noc-list - could do with some updating. Voyager is missing, other things I know to be wrong are that several of the Noc's listed have been subsumed into larger orgs. -Joel

14 16

NZIX AGM
by Dave Mill 25 Jun '17

25 Jun '17

Hi all NZIX (the peering exchange formerly known as AKL-IX) are holding their AGM in Auckland on June 27. Details are here - https://ix.nz/2017/05/30/annual-general-meeting/ NZIX is a member run, not-for-profit, peering exchange. Have your say in where the IX is heading. Non-members are also welcome. Hope to see you there! Cheers Dave

1 1

Beer
by Lesley Longhurst 22 Jun '17

22 Jun '17

Sorry for the distraction, I just think you should all see this label. Homebrew made by a friend-of-a-friend. Rather tasty, too. [cid:image001.png(a)01D2EC34.7CF018D0] Lesley Longhurst Technical Lead - Network Services Opus International Consultants Ltd, Opus IT Operations 33 The Esplanade, Petone, Lower Hutt 5012, New Zealand PO Box 30 845, Lower Hutt 5040, New Zealand +64 21 244 3718 lesley.longhurst(a)opus.co.nz<mailto:lesley.longhurst(a)opus.co.nz> www.opus.co.nz<http://www.opus.co.nz>

1 0

InternetNZ presents: Dr Marc Bruyere - The TouSIX project: SDN IXPs from design to production
by Dean Pemberton 14 Jun '17

14 Jun '17

Hi all, Just wanted to let you know about a presentation that InternetNZ is hosting in Wellington. The TouSIX project: SDN IXPs from design to production Wed 28th Jun 12:00pm – 1:00pm InternetNZ offices, level 11, 80 Boulcott Street, Wellington, New Zealand Registration: https://the-tousix-project-sdn-ixps-from-design-to-production.lilregie.com/… Come along to a presentation from Dr. Marc Bruyere. Bio here: https://www.internetsociety.org/afpif-2016/speakers/dr-marc-bruyere The Internet eXchange Points (IXP) are essential for the Internet evolution as they empower high bandwidth low latency and inexpensive local traffic peering as opposed to transit traffic. OpenFlow SDN enables more dynamic network programmability to control network behaviour via open interfaces, as opposed to the legacy closed-box solutions and proprietary-defined interfaces. This presentation is about the migration of the TouIX from a traditional to a full OpenFlow IXP. It especially describes how switches have been selected, configured and installed, and presents the TouSIX-Manager tools that have been developed for the IXP fabric robustness and members benefit. It also includes future SDX work in Japan and elsewhere, and the historical NZ based CARDIGAN SDX. TouIX is a non-profit neutral Internet eXchange Point organisation founded in 2005. It provides an interconnected network infrastructure at 4 PoPs around the city of Toulouse and the Paris FranceIX and LyonIX IXPs. Please note catering will not be provided.

1 0

plea for increase participation in v6ops/IETF
by JORDI PALET MARTINEZ 10 Jun '17

10 Jun '17

Hello all, At the last LACNIC event, I mentioned on a couple of occasions the need for ISPs in the region, especially small and medium-sized ones, to participate in the decisions taken in the IETF IPv6 Operations Working Group (v6ops). I’m sending this here as well, as I believe the situation also apply to this region. When I asked among the attendees how many participate in v6ops, only one person raised his hand. What does it mean to participate in the mailing list? Follow some emails (sometimes only 1-2 a week, sometimes they can be several in a day), and therefore learn about what is being discussed and give your opinion and, given that decisions are made by Consensus, influence them. What consequences has NOT participating? That decisions against your interests/opinions could be taken, and obviously do not consider your perspective in the standards. Generally large operators are involved, which implies that your interests are not sufficiently represented, and in general are contrary to yours. Your "vote/opinion" is not worth more than yours, but the big one is present and the small/medium NO! I give you a very concrete example. The serious problem that small and medium ISPs have, is to continue offering IPv6 and IPv4 services to their customers, when they already do not have IPv4 addresses. Only the biggest ISPs have a great purchasing power and can influence the manufacturers to do for them what they need. One possibility to solve it, extending the life of IPv4, but not necessarily deploying IPv6, is using CGN, which is also very expensive, and breaks many things. The solution is simple. Deploying IPv6-only services in the last mile, which involves using transition mechanisms, such as 464XLAT that has been deployed on millions of smartphones worldwide, so that applications continue to operate transparently as they "believe" they have IPv4. What is the problem, then? That manufacturers of CPEs are based on an old specification (RFC7084) that does not contemplate these transition mechanisms, so when a small/medium ISP asks a manufacturer for a firmware upgrade or a new CPE, they do not include that solution and perhaps they offer it with an extra cost. In my view, this should change, and that is why I am working on a number of documents, including RFC7084-bis (https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/) To update this situation, but there is opposition from large ISPs and virtually no small/medium "talks" about it, and in fact these large ISPs deny the situation. In addition, the document also specifies the "automated" support of those cases in which the user installs other routers (which is very common as we all know, and will be more and more in IPv6, IoT, etc.), behind the router installed by the ISP, through homenet (HNCP). I am not asking for your support for my documents, but for understanding the problem and the solution that is being proposed and/or possible new ones, and for the opinion of not only those very few “big ones”, but also of many small and medium, who are most affected. If you want to subscribe to this list, search for "subscribing" at: https://www.ietf.org/mailman/listinfo/v6ops You can see the files of the discussion in: https://mailarchive.ietf.org/arch/search/?email_list=v6ops I remind you that participating in the IETF does not require a presence in the meetings, as consensus is agreed in the list. Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

Free parking network contact
by Simon 07 Jun '17

07 Jun '17

Hi there, is anyone from free parking on this list from their network operations team and can contact me please?

2 1

SkyTV NOC
by John Burns 30 May '17

30 May '17

Is anyone from SkyTV on this list? I have a /23 (allocated March 2017) that is being geoblocked on fanpass.co.nz and our customers would like us to solve it before the Lions tour starts!

1 0

cantva.canterbury.ac.nz Mail Admin at canterbury.ac.nz your server is not coming back from Greylist
by Don Gould 24 May '17

24 May '17

If there's a mail admin from canterbury.ac.nz on list, could you have a quick look at your server? We're not seeing mail coming from you because your server doesn't come back to have another go. We run a 10 minute greylist timer but you don't seem to come back for another go. # grep canterbury.ac.nz mail.log May 24 21:46:04 mx postfix/smtpd[22652]: connect from cantva.canterbury.ac.nz[132.181.2.27] May 24 21:46:05 mx tumgreyspf[22740]: Initial greylisting: REMOTEIP="132.181.2.27" HELO="cantva.canterbury.ac.nz" SENDER="stephen.hickson(a)canterbury.ac.nz" RECIPIENT="don(a)bowenvale.co.nz" QUEUEID="" May 24 21:46:05 mx postfix/smtpd[22652]: NOQUEUE: reject: RCPT from cantva.canterbury.ac.nz[132.181.2.27]: 450 4.7.1 <stephen.hickson(a)canterbury.ac.nz>: Sender address rejected: Service unavailable, greylisted (http://projects.puremagic.com/greylisting/) from=<stephen.hickson(a)canterbury.ac.nz> to=<don(a)bowenvale.co.nz> proto=ESMTP helo=<cantva.canterbury.ac.nz> TIA. D -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb) www.thinkdesignprint.co.nz skype: don.gould.nz

2 2

GLIF 2017
by GLIF Secretariat 22 May '17

22 May '17

All, Apologies for the advertising, but this global research and education networking event hosted by AARNet in Sydney may be of interest to some… Regards, Kevin Meynell ---- 17th Annual Global LambdaGrid Workshop - GLIF 2017 25-27 September 2017 Camperdown Campus, University of Sydney, Australia https://www.glif.is/meetings/2017/flyer.pdf <https://www.glif.is/meetings/2017/flyer.pdf> We are pleased to announce that registration is now open for the 17th Annual Global LambdaGrid Workshop which is being hosted by AARNet, the Australian National Research and Education Network. This will bring together leading network personnel from around the world to collaborate and exchange knowledge on new lambda networking technologies, middleware and applications. The workshop will have a specific focus on how global network architectures are supporting research applications in the Pacific region, in particular astronomy, high-energy physics, and microbiology and how big data is sent and processed around the world. There will also be discussions on the Pacific Islands Research and Education Network, long distance parallel file systems, new SDN and SDX initiatives, along with demonstrations of applications that can take advantage of these network facilities. The registration fee is AUD 450 per person (AUD 350 for registered students) up to 23 August 2017, and AUD 500 per person (AUD 400 for registered students) thereafter. Accommodation is available in the Rydges Camperdown at the special rate of AUD 165 per night including GST, the Mercure Sydney Central at the special rate of AUD 249 per night, and the Waldorf Sydney Central Serviced Apartments at the special rate of AUD 195 per night including GST. These can be reserved when registering for the workshop, and should be booked before 23 August 2017. Please note that a Software Defined Networking (SDN) Workshop will also held on Thursday, 28 September 2017 at the University of New South Wales. You can register, book accommodation and pay online at https://www.glif.is/meetings/2017/ <https://www.glif.is/meetings/2017/>

1 0

Issue with connections from CanIt-Domain-PRO anti-spam filter
by Jean-Francois Pirus 18 May '17

18 May '17

Hi all, I have an interesting issue. Just upgraded our mail server to handle srs-milter. Since the upgrade we found that the srs-milter would crash around 05:50 and 22:20 everyday. (Obviously it's got a bug) Turns out everyday around 05:50 we get a connection from canit-1.iserve.net.nz[202.191.33.141] And every night around 20:20 we get a connection from canit-scanner-2.slingshot.co.nz[60.234.4.40] They both seem to be running CanIt-Domain-PRO anti-spam filter. I cannot just block the scanner as the address is shared with MX's (ie: canit-scanner-2.slingshot.co.nz[60.234.4.40] and canit-slingshot-mx-2.t3.nz) Seems like the scanner is sending 'unusual' data once a day on a schedule. Any ideas what that single daily connection is about? or workarounds? Thanks. PS: Apart from fixing the bug myself... -- Jean-Francois Pirus | Technical Manager francois(a)clearfield.com | Mob +64 21 640 779 | DDI +64 9 282 3401 Clearfield Software Ltd | Ph +64 9 358 2081 | www.clearfield.com

2 5

Power issues in Skytower
by Patrick Ohearn 16 May '17

16 May '17

Hi list, Has anyone has any power issues in skytower this afternoon? We briefly lost power on level 47 around 1600.

1 0

AusNOG 2017 Call for Presentations
by Mark Prior 08 May '17

08 May '17

The next AusNOG conference is only four months away, scheduled to be held at The Langham, Melbourne, on 7 & 8 September 2017, so we are making our first call for presentations of interest to the Internet operations community. Previous feedback has suggested that attendees would like more content from the community so we'd like to encourage members of the community to submit more proposals, especially if you haven't previously presented! Internet operations is a broad topic but some areas of interest are: * Improving the redundancy/resiliency/sustainability of your network * Using automation to improve service reliability * Taking the network operations BCP to the next level * Using 'offline' communications tools to keep the network working * Evolution in network architectures and scaling issues * Analysis of relevant major operational events of the year Naturally other topics that are of interest to the network operator community are also welcome but presentations of a purely marketing nature are not welcome at this technical event. Notes to presenters =-=-=-=-=-=-=-=-=-= Preference will be given to presentations that result in actual operational outcomes. Session speakers should be prepared to present for 30 minutes. Keynote speakers will be expected to present for 45 minutes to 1 hour. Short presentations of strong operational content are also acceptable. Please note any timing constraints when submitting a presentation. By submitting a presentation for consideration in the AusNOG 2017 programme, and if selected the presenter will allow AusNOG to: * Take photographs of the presentation and presenter * Record and rebroadcast video and audio of the presentation and presenter * Redistribute the presentation slides, audio, video, and photographs electronically, on the AusNOG website, or otherwise but leaving all intellectual property in the hands of presenter or rightful property holder[1]. Deadlines =-=-=-=-= 12 June: Submission of presentation title, presentation description (300 words), and presenter biography (200-400 words) 10 July: Presenters notified of their acceptance status as an AusNOG 2017 presentation. 30 August: Submission of final presentation slides as Portable Document Format (pdf), PowerPoint, or Keynote. Provision of a recent digital photograph (<500k) of the presenter. All submissions must be sent by email to organisers AT ausnog DOT net. A separate call for lightning talks will be made closer to the AusNOG 2017 event. As in previous years you must be registered to attend AusNOG 2017 in order to be considered for a lightning talk. [1]: AusNOG accepts that some speakers are unable to allow us to archive their presentation due to company or corporate policy, and if the situation arises AusNOG will delete all copies in its possession after the presentation.

1 0

Alcatel IPv6 PPPoE
by Pieter De Wit 03 May '17

03 May '17

Good Morning List, I was wondering if anyone out here (there :)) has a working config for an Alcatel 7750 to give out IPv6 to subscribers. We would like to allocate /112's as a link net between the CPE and the BNG. We then want to route a /64 or /48 over this link net. All of this is configured in Radius. The link-nets are configure using the "wan-host" option under the subscriber interface. The /64 or /48 subnets is part of a /36 configured as the "pd" option. From what I was reading, it appears as if the link-nets needs to be /64...surely not ? Cheers, Pieter

11 17

Russian-controlled telecom hijacks financial services’ Internet traffic
by Michael Fincham 27 Apr '17

27 Apr '17

Morning all, For those who didn't spot this yet: <https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks…> "On Wednesday, large chunks of network traffic belonging to MasterCard, Visa, and more than two dozen other financial services companies were briefly routed through a Russian government-controlled telecom under unexplained circumstances that renew lingering questions about the trust and reliability of some of the most sensitive Internet communications." -- Michael

1 0

OOB - Vocus DC, 7A Parkhead Pl, Albany
by Bruce Forster 26 Apr '17

26 Apr '17

Hi Noggers, Looking for a 2/10mb OOB link in Vocus DC, 7A Parkhead Pl, Albany Can someone please email me off list with some pricing? -- Regards, Bruce

1 0

Re: [nznog] Alcatel IPv6 PPPoE
by JORDI PALET MARTINEZ 24 Apr '17

24 Apr '17

Sorry, wrong paste … https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf Regards, Jordi -----Mensaje original----- De: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> Fecha: lunes, 24 de abril de 2017, 23:49 Para: <nznog(a)list.waikato.ac.nz> Asunto: Re: [nznog] Alcatel IPv6 PPPoE This may be useful. Is work in progress, but we believe that we will reach consensus in the next RIPE meeting adding some suggestions that we got in the last weeks: º ALBARÁN.......: 02643/2557863 SERVICIO........: Ecommerce FECHA............: 20/04/2017 CLIENTE RECOGIDA.: MOREMAR SL CLIENTE ENTREGA.: ANA SUBIRATS RODRÍGUEZ CLIENTE ABONADO..: MOREMAR SL LOCALIDAD ENTREGA: IGUALADA OBS. ENTREGA TTM: HEMOS LLAMADO DURANTE TODA LA TARDE Y NADIE HA CONTESTADO, TENIAMOS 2 TELEFONOS Y NAD A -DESTINATARIO AUSENTE/CERRADO : X Regards, Jordi -----Mensaje original----- De: <nznog-bounces(a)list.waikato.ac.nz> en nombre de Brian E Carpenter <brian.e.carpenter(a)gmail.com> Organización: University of Auckland Responder a: <brian.e.carpenter(a)gmail.com> Fecha: lunes, 24 de abril de 2017, 22:35 Para: Pieter De Wit <pieter(a)insync.za.net>, <nznog(a)list.waikato.ac.nz> Asunto: Re: [nznog] Alcatel IPv6 PPPoE On 25/04/2017 07:51, Pieter De Wit wrote: > Good Morning List, > > I was wondering if anyone out here (there :)) has a working config for > an Alcatel 7750 to give out IPv6 to subscribers. We would like to > allocate /112's as a link net between the CPE and the BNG. We then want > to route a /64 or /48 over this link net. Please don't hand out /64s. That prevents people subnetting their IPv6 in their home or office. You can always hand out /56 if you really think /48 is too much. > All of this is configured in > Radius. > > The link-nets are configure using the "wan-host" option under the > subscriber interface. The /64 or /48 subnets is part of a /36 configured > as the "pd" option. > > From what I was reading, it appears as if the link-nets needs to be > /64...surely not ? Not unless your vendor has a pointless restriction. The only RFC in the area is https://tools.ietf.org/html/rfc6164 which recommends /127 but there's nothing to prevent /112 from working if that's what you want. Regards Brian _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

Xtra and SPF
by Glen Eustace 19 Apr '17

19 Apr '17

Hi, We have started receiving complaints from several of our customers for whom we are the MX for their domain. Some addresses in the domain are delivered locally, some are relayed to other mailboxes e.g. gmail and xtra. It seems that there are folks who still believe that SPF is a good thing and have ‘-all’ on their record. Xtra it would appear is now enforcing the rejection on email we relay to them. We are placed in an awkward position. Our customer wants us to fix something that we are not really able to. The SPF policy belongs to the sender and Xtra are doing the rejection. I have come across another add on technology for postfix called SRS for rewriting senders but that seems to be broken from all accounts as well. Is anyone else having these sort of issues, is there something I should be doing in the ‘relay’ process that will prevent the rejections I’d love to hear. Glen -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Glen Eustace, GodZone Internet Services, a division of AGRE Enterprises Ltd., P.O. Box 8020, Palmerston North, New Zealand 4446 Ph +64 6 357 8168, Mob +64 27 542 4015 “Specialising in providing low-cost professional Internet Services since 1997"

13 16

Interesting issue with iperf3 and UDP
by Dylan Hall 30 Mar '17

30 Mar '17

I stumbled across an issue with iperf3 and it's UDP mode recently that I thought was worth sharing. In short it's very bursty and in my opinion broken. Use iperf (2.0.x) instead. The interesting detail: I recently got UFB at home (200/100 plan) and wanted to put it through it's paces. I did the usual TCP tests and it all looked good, so I decided to try UDP to look for packet loss. Even with fairly low rates (10-50 Mbps) I was seeing loss vary from 5% to 50%. I tried a number of different hosts around NZ, and one in the US and although each reported different amounts of loss there was always loss. I ran the tests with "-l 1400" as an option to force 1400 byte packets. Without this iperf sends 8kB packets that get fragmented which confuses the loss figures somewhat. I repeated the tests with iperf rather than iperf3 and everything worked perfectly. Focusing on one testing host, a 10G connected server near my ISP to minimise transit network in the way. The following is a little piece of a packet capture from the sending host using iperf (2.0.5). The rate was set to 15 Mbps. I've added the Delta field which is the time since the last packet was seen in micro seconds. 23:27:57.979021 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 746 23:27:57.979766 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 745 23:27:57.980511 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 745 23:27:57.981254 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 743 23:27:57.982001 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 747 23:27:57.982749 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 748 23:27:57.983492 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 743 23:27:57.984238 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 746 23:27:57.984986 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 748 23:27:57.985731 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 745 23:27:57.986478 IP x.x.x.x.56460 > y.y.y.y.5001: UDP, length 1400 Delta: 747 The packets are very evenly spaced. The following is using iperf3 (3.1.3) also at 15 Mbps. 23:28:23.913489 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 8 23:28:23.913496 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 7 23:28:23.913505 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 9 23:28:23.913513 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 8 23:28:23.913520 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 7 23:28:23.913529 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 9 23:28:23.913537 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 8 23:28:24.012445 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 98908 23:28:24.012458 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 13 23:28:24.012468 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 10 23:28:24.012475 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 7 23:28:24.012483 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 8 23:28:24.012492 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 9 23:28:24.012499 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 7 23:28:24.012508 IP x.x.x.x.49233 > y.y.y.y.5201: UDP, length 1400 Delta: 9 It appears to send a burst of very closely spaced packets, then take a break, then repeat. The cycle is about 100ms. Applying some hopefully correct maths, it appears to send about 187kB of data in just over 1ms, then rest for almost 99ms. This gives is about the right average rate (15 Mbps), but for that first 1 ms it's sending at about 1.4 Gbps. I assume that the loss I'm seeing is either buffers over flowing somewhere in the path or the Chorus rate-limit on UFB discarding the packets. The old version of iperf uses a busy loop in the sender to achieve the very precise timing for UDP mode which has the side effect of causing 100% CPU while sending. I wonder if the change in iperf3 is an attempt to make it more efficient. Had I Googled the issue at the beginning I would have found this is a known problem: https://github.com/esnet/iperf/issues/296 https://github.com/esnet/iperf/issues/386 Hopefully this will save someone else from a couple hours of confusion :) Thanks, Dylan

3 2

Re: [nznog] AS-path changes on nzix.net route-servers
by Sid Jones 29 Mar '17

29 Mar '17

We’ve largely finished making the changes to the AS-path for those that have requested it on the APE and the WIX. We’ve not seen any issues so far. If you wish to schedule a change, please email us at peering(a)citylink.co.nz<mailto:peering(a)citylink.co.nz>

1 1