- NZNOG - lists.nznog.org

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

Bulk .nz whois
by Simon Lyall 20 Mar '17

20 Mar '17

One if the guys at $work is working to clean up our domains (mostly .nz) . We have a few hundred that are registered all over the place at various times, by different people, etc that we are hoping to consolidate. Problem is we need to get whois data for them but we ran into the dnc's limits. Any way to get around the limits? We tried reaching out to them but all they could suggest was going via a registrar. Simon Lyall | simon(a)darkmere.gen.nz | http://simonlyall.com Sent from a phone that cost more than my car

2 2

AS-path changes on nzix.net route-servers
by Sid Jones 12 Mar '17

12 Mar '17

Reminder, the NZIX changes will start being applied from today. We’re starting the changes on the WIX. APE changes will be in the next few days. Please contact us if you see any issues - faults(a)citylink.co.nz<mailto:faults(a)citylink.co.nz> or 0800 424 895

1 0

Anyone near AKL cbd have spare 3 x 1000Base-LX/LH (cisco coded GLC-LH-SMD) SFPs?
by Gareth Fletcher 05 Mar '17

05 Mar '17

that they would want to sell or give away (or for beer!!)! Please contact me off list :) In a pinch and my china order hasn't arrived yet. it's a nice hot day in Akl, you could be drinking cool beer this afternoon :) Today is your lucky day. Cheers Gareth

1 0