- NZNOG - lists.nznog.org

Plea for help - Ethernet cables.
by Dean Pemberton 09 Jan '14

09 Jan '14

So it turns out that the SDN OpenFlow tutorial has turned into a bit if a thing. While it was going to use mainly VMs and simulators, Citylink has supplied 20 mikrotik routerboards for the class to actually configure into an openflow controlled data plane. On ya guys, much appreciated, great NZNOG and SDN supporters as always. What I'm after now however is the around 60 Ethernet cables to hook it all together. If anyone could help me out so that I don't need to buy them that would be awesome. Yes you get then back afterwards. Thanks heaps. It should be an awesome tut. Dean

1 0

Situations Vacant: Senior Network Engineer
by Mark Foster 09 Jan '14

09 Jan '14

Greetings, ICONZ-Webvisions currently have a vacancy for a Senior Network Engineer, to be based at the iWV offices in Auckland. We're looking for an experienced Cisco engineer with experience working on ASR, 2800/2900/3700/6500/7200 series devices, with exposure to the ISP world preferred. Other acronyms you'd be familiar with at a senior level would include MPLS, VRF, BGP, OSPF, QoS, VoIP. CCNP or equivalent experience is the listed minimum qualification. If you are interested, or know anyone who might be, please have them drop me a note ASAP - we're already interviewing likely candidates and will need to make an offer fairly soon. Off-list questions, or expressions of interest, are welcomed in the meantime. Thanks, Mark.

1 0

Want a free NZNOG 2014 conference ticket?
by Dean Pemberton 06 Jan '14

06 Jan '14

Krystal is looking for one or 2 more volunteers to help with registration and pack up. Duties will be - manning the registration desk on Thursday Morning (8am - 9.30am) and helping pack up gear to be shipped back in INZ on Friday after conference ends (4.00 - 6.00). If you put your hand up then we're happy to comp you a ticket, they may miss a couple of talks - but you should still manage to attend the bulk of the conference. If you're interested then please email krystal(a)internetnz.net.nz and let her know. If there is a huge influx of interest then some advanced algorithm will be used to determine those accepted. =)

2 1

Call for Presentations - DNS-OARC Spring Workshop, May 2014
by Sebastian Castro 05 Jan '14

05 Jan '14

Call for Presentations - DNS-OARC Spring Workshop, May 2014 Next OARC Spring Workshop will take place in Warsaw, Poland on May 10th and 11th, the weekend before RIPE68. OARC is requesting proposals for presentations, with a preference for DNS privacy and confidentiality work and ideas, and DNS over alternative (non UDP) transports. This workshop continues OARC's tradition of having meetings include a strong operational component. Presentations from DNS operators are particularly welcome. We'll also gladly accept talks from DNS researchers, as well as any other DNS-related subjects such as tools, visualizations and data analysis. 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 section of lightning talks will be added for short presentations. Workshop Milestones * 20 December 2013, Call for Presentations posted * 6 January 2014, Open for submissions * 1 March 2014, Deadline for submission * 28 March 2014, Final Program published * May 9 2014, Final deadline for slideset submission Details for abstract submission are be published here: https://indico.dns-oarc.net/event/workshop-2014-05 If you consider submitting a presentation, please let the Programme Committee know in advance to help us organize the presentations tracks. 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 (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.)

1 0

CARDIGAN implements RPKI - Cleanliness of prefixes onWIX
by Dean Pemberton 05 Jan '14

05 Jan '14

Hi All, CARDIGAN has just finished implementing RPKI Origin Validation on its WIX peering connection. What this effectively does is finds out if ASs are permitted to announce the IP addresses that they are advertising to the exchange. CARDIGAN then makes a decision on wether to allow invalid announcements to be turned into OpenFlow rules. So I thought you'd all be interested in the state of the prefixes on the exchange. The following table has removed all the routes for which no RPKI information was found. This leaves two conditions: Lines which start with a "V" have a valid RPKI ROA. That means that the AS originating the prefix has been explicitly authorised by the IP resource owner to do so. Likes which start with an "I" have an RPKI ROA which is different to the route seen. This means that the AS originating the prefix has been explicitly disallowed from doing so by the IP resource owner. These are explicit authorisations as the IP Resource owner has had to go to an RPKI trust anchor (normally the RIRs) and request certification of the ASs allowed to originate the prefix (or subnet of the prefix). For most of us (who are APNIC members) this is as simple as logging into the MyAPNIC portal and creating an ROA. APNIC handles everything else for you. Anything that turns up as an "I" on this list, I'm going to be looking at pretty carefully before I prefer into the CARDIGAN network. Anyone with more questions about RPKI, how it works, what it means, how to get it going. Feel free to post/email me. Network Next Hop Metric LocPrf Weight Path V* 58.28.0.0/16 202.7.1.22 30 0 9439 17435 i V*> 202.7.1.22 30 0 9439 17435 i V* 103.10.233.0/24 202.7.0.190 30 0 9439 132003 i V*> 202.7.0.190 30 0 9439 132003 i V* 103.23.16.0/22 202.7.0.222 30 0 9439 132040 i V*> 202.7.0.221 30 0 9439 132040 i I* 103.23.16.0/24 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i I* 103.23.17.0/24 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i I* 103.23.18.0/23 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i V* 113.197.96.0/22 202.7.0.211 30 0 9439 45831 45831 i V*> 202.7.0.211 30 0 9439 45831 45831 i I* 113.197.96.0/28 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.96.32/27 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.96.96/28 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.96.112/28 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.96.168/29 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.98.32/29 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.98.64/27 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 116.90.130.16/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.130.96/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.135.0/24 202.7.0.176 10 0 9439 38477 45641 i I*> 202.7.0.176 10 0 9439 38477 45641 i V* 116.90.139.0/24 202.7.0.176 30 0 9439 38477 i V*> 202.7.0.176 30 0 9439 38477 i I* 116.90.139.0/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.8/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.16/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.24/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.64/27 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.144/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i V* 118.90.0.0/16 202.7.1.22 30 0 9439 17435 i V*> 202.7.1.22 30 0 9439 17435 i 202.7.0.76 20 0 9439 24006 i V* 182.154.0.0 202.7.1.22 30 0 9439 17435 i V*> 202.7.1.22 30 0 9439 17435 i 202.7.0.168 20 0 9439 i I* 198.48.0.0/23 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i I* 198.48.2.0 202.7.0.222 10 0 9439 132040 132001 i I*> 202.7.0.221 10 0 9439 132040 132001 i I* 198.48.3.0 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i I* 202.7.4.0 202.7.0.222 10 0 9439 132040 23755 i I*> 202.7.0.221 10 0 9439 132040 23755 i I* 202.7.5.0 202.7.0.222 10 0 9439 132040 23755 i I*> 202.7.0.221 10 0 9439 132040 23755 i I* 202.7.6.0 202.7.0.222 10 0 9439 132040 23755 i I*> 202.7.0.221 10 0 9439 132040 23755 i I* 202.7.7.0 202.7.0.222 10 0 9439 132040 23755 i I*> 202.7.0.221 10 0 9439 132040 23755 i V* 203.119.88.0/23 202.7.1.253 30 0 9439 42 187 i V*> 202.7.1.253 30 0 9439 42 187 i 202.7.1.252 20 0 9439 i 202.7.0.147 20 0 9439 24183 45563 i 202.7.0.147 20 0 9439 24183 ? 202.7.0.128 20 0 9439 i 202.7.0.107 20 0 9439 i

2 3

2821 ipv4 table size
by Bill Walker 30 Dec '13

30 Dec '13

Hate to post this but my google foo is failing me anyone know the ipv4 max table size on a 2821? Would be running eBGP with two peers. Sent from my iPhone

2 2

Fraud Calls
by Davey Goode 27 Dec '13

27 Dec '13

Hi All, I hope everyone is having a good break ! If anyone out there has had any of their customers PBX's hacked recently (in the last 2 - 3 weeks) and have experienced a large call flow to say Somalia or some other dodgy destination id be keen to hear from you, I'm after the destination numbers they are dialling. replies off list would be great. cheers davey

3 2

How often does NZRS root reload?
by Skeeve Stevens 18 Dec '13

18 Dec '13

Hey all, Just registered a co.nz domain and it is registered and visible in whois. But ;; AUTHORITY SECTION: co.nz. 3285 IN SOA loopback.dns.net.nz. soa.nzrs.net.nz. 2013121964 900 300 604800 3600 How often does this server refresh its data? ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve(a)eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud

3 4

NZNOG 2014 Update
by Dean Pemberton 16 Dec '13

16 Dec '13

Hi Everyone. Registrations have been open for the conference for a while now and I'm pleased to say that they are at an unprecedented level for this time of year. Given that we've only just released the program, thats an outstanding achievement. With some great help from InternetNZ the conference is shaping up to be as awesome as usual. First up I'd like to thank the sponsors who have signed on thus far: Go Wireless - Gold Network Hardware Resale - Gold Vocus - Gold CityLink - Gold GKC - Silver Brocade - Silver Arbor Networks - Silver APNIC - Silver Extreme Networks - Silver Kordia - Bandwidth Sponsor We have more slots open for sponsorship as well as the much coveted Platinum sponsor position. If you would like to ensure that your organisation gets high visability at the event then contact sponsorship(a)nznog.org for a sponsorship pack. We know that the program is an important part of convincing your organisations that you need to attend. This year we've got a wide range of speakers lined up along with some great Workshops and tutorials. Program: International Keynotes: Tom Paseka (CloudFlare) - NZ Perspectives from a global CDN Roland Dobbins (Arbor Networks) - TBA Conference Presentations: Geoff Huston (APNIC) - Measuring DNSSEC Jamie Baddeley (Citylink) - NZIX2/Citylink SDN Sam Russell (REANNZ) - Building a better Skype with WebRTC, SIP, and ENUM Barry Brailey (DNC) .nz DNSSEC programme Jean-Sébastien Fontana (Extreme Networks) - Introduction to TRILL Gerard Creamer (Netspace) - Experiences with dual A records vs anycasting Beatty Lane-Davis (Cyan) - SDN & NFV Michael Fincham (Unleash) - RPKI Peter Gent (MBIE) - 5GHz Wireless Links Jan Jorz (ISOC) - BCOP Project Quintin Russ (SiteHost) - IPv6 deployment in the cloud InternetNZ Update APNIC update WAND update Lightning Talks Workshops: Network Infrastructure Security BGP Routing Tutorials: OpenDNSSEC Installation and Configuration (1/2 day) SDN/OpenFlow Installation (1/2 day) Mikrotik Routing (full day) APNIC Internet Resource Management (1/2 day) We'd suggest you register now. At least this side of Xmas. Flights, Accommodation etc will likely be easier and cheaper the sooner you do it. Better than doing it in a panic in mid January. For more information on how to register, head off to http://www.nznog.org/register See you all there. Dean

1 0

Keeping it local
by Martin Kealey 15 Dec '13

15 Dec '13

I have a question which I'm hoping the NZNOG community can help me with. Within NZ, what is the maximum number of hops from APE to any consumer's interface device? (smarty-phone, ADSL modem, whatever)? Or more pragmatically, let's say the 99th percentile, as in, fewer than 1% of customers are more than X hops away from APE. If this information is already available, I'd appreciate a pointer, otherwise... If you are an ISP could you give me an indicative number of hops from APE to your customers' CPE. If you can include a prefix length reflecting the number of affected customers that would help too. (Ideally the maximum across all your customers, but if you have a few oddball customers with longer paths, just the 99% will do.) If you're an ISP customer and would like to tell me your hop-count to APE (counting from your CPE, not from your computer) and your ISP's name, that would also be appreciated. Replies off-list and I will summarize back to the list. Here's the background: I'm investigating ways of limiting traffic so that it does not leave New Zealand, that can be configured on an application-by-application basis. Obviously if one has an upstream to "global" and a separate upstream to APE or WIX, then it's simple to filter traffic at those egresses. However for the average end-user, it's difficult to get multiple VLANs to their provider, let alone multiple physical links. In an ideal world, one would simply set some QoS bits and your upstream would understand them and do the filtering based on *their* egress, but in practice I haven't heard of any suppliers offering such a service. So I'm looking at DIY options ... In particular, I'm looking at setting the TTL on outgoing packets. We know how many hops it is from "our" hosts to APE, and I guestimate no more than 2 hops from a consumers border device (modem, whatever) to their client devices; So far it looks like setting the TTL so that it's down to 5 at APE will mean most of NZ is reachable, and most of the rest of the world isn't, assuming the international provider is as many hops from me as APE. But I'd really like to get a firmer idea of "how much of NZ will be unreachable given an egress hop limit of X?" (The idea is to find X where the list of exception prefixes is small enough to manage manually, while still blocking the majority of foreign traffic.) What I'd like to find out from the NZNOG community is the distribution of customers at various hop-counts from APE. -Martin

3 3