- NZNOG - lists.nznog.org

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: service(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080619 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: service(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080619 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

Rule 6... part 2.
by Steve Holdoway 21 Jul '08

21 Jul '08

Apologies to those who didn't get the Monty Python reference ( there is no rule 6, after all! ), I'll take the general census as an ok, and hope this isn't too off-list. I'm working for a company down here in Christchurch who are developing a new tool aimed at catching email spam. Much simplified, it uses linear regression techniques to create a signature of the email involved, and then performs a fuzzy match on that sig against databases held on our servers ( via a local cache to improve performance ). We reckon we've got it to be pretty indestructible ( and with a pretty small footprint ), but we need to test it further. Are there any ISP's out there who could help us out by a) trialling it ( our testing up to now has been as a milter under sendmail/postfix on linux ), and/or b) sending us loads of spam to stress our backend processes?? If so, could they contact me offlist? Cheers and thanks, Steve

1 0

Re: [nznog] DNS Vulnerability
by Ewen McNeill 21 Jul '08

21 Jul '08

In message <20080708234533.B080B112872(a)wat.la.naos.co.nz>, Ewen McNeill writes: >See also, eg, http://isc.sans.org/diary.html?storyid=4687 which has some >sane discussion of the issue [...] It appears that someone guessed close enough to how the attack worked to cause one of the people "in the know" to post a confirmation, and then attempt to withdraw it -- but of course people have found traces of the confirmation description and mirrored it. So the cat seems to be out of the bag, and presumably the Bad Guys (tm) will now try to do this for real. See, eg, http://it.slashdot.org/it/08/07/21/2212227.shtml which has various cut'n'paste copies of what seems to be the confirmation description, plus a link to the guess that prompted it. >Amongst other things they suggest patching any recursive/caching DNS >servers with vendor patches at the soonest suitable patch window. If you haven't already patched your recursive/caching DNS servers used by customers, today would be a good day to do it. So says Dan Kaminsky who found the issue in the first place: http://www.doxpara.com/?p=1176 Also beware that the NAT in at least some firewalls has been reported to undo the port randomisation that the patch introduces, resulting in predictable port numbers again (and thus no increase in randomness or protection against this attack). Linux-based firewalls are reported to be okay (apparently by default they pass through the port number used by the client on outgoing UDP packets if they can), and presumably OpenBSD based ones are okay given their choice to randomise everything. But beware of running recursive DNS servers behind NAT on firewalls without checking what the outgoing packets look like -- if in doubt perhaps put your recursive DNS servers into the DMZ outside the NAT. Ewen

1 0

Rule 6.
by Steve Holdoway 20 Jul '08

20 Jul '08

... which in this case isn't 'No pommy poofters' (: Is is appropriate to post a request for partners to trial software, or is this a breach of the aforesaid rule??? Cheers, Steve

3 2

Compromised websites
by Glen Eustace 14 Jul '08

14 Jul '08

Hi, We have had only a single site compromised so far but googling around indicates that this particular hack is all over the place. On the site in question all files .htm, .html and .shtml have had code added before the </body> tag, the code is a <jscript></jscript> that loads fgg.js from http://www.usaadw.com, the script that is loaded then tries to open an iframe but the content gives a 500 server error. I can not identify the vector used to edit all the files. This is on a linux server running apache 2 but google finds plenty of .asp pages that have been attached as well. The script is also called ngg.js but has almost identical content. Has anyone else been hit and if so, has the vector been identified ? Any assistance appreciated. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen and Rosanne Eustace GodZone Internet Services, a division of AGRE Enterprises Ltd. P.O. Box 8020, Palmerston North, New Zealand 4446. Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 21 424 015 http://www.godzone.net.nz "A Ministry specialising in providing low-cost Internet Services to NZ Christian Churches, Ministries and Organisations."

7 12

Re: [nznog] Compromised websites
by Gary T. Benner 14 Jul '08

14 Jul '08

[Reply] HI all, We use "denyhosts" as well to monitor attempts to break into SSH ports, and are getting on average 50 per day over 20 servers. Interesting that it is "real" regular! Weekends even. cheers Gary 123 Internet Ltd At 10:09 on 15/07/2008 you wrote >To : NZNOG(a)list.waikato.ac.nz >CC : >From: Steve Holdoway, steve(a)greengecko.co.nz >Content Type: text/plain >Attached: att-080715100913828-2.txt > > > > >On Tue, 15 Jul 2008 08:34:17 +1200 >Steve Holdoway <steve(a)greengecko.co.nz> wrote: > >> I don't, but I run logcheck to *tell* me ( and fcheck to tell me of any file changes, and... )! tbh my production servers have a backdoor single account ssh access to the internet, which is protected by denyhosts, and all other access is from a staging server via vpn, still using secure ( but separate ) protocols. I don't care too much about the shortcomings of denyhosts, as a) it's protecting the emergency backup service, and b) I've got enough static ip addresses whitelisted to get in from - imo it's perfect for this job. >> >> OK, you *could* break in through a distributed attack on the ssh port, but the real risk to my servers is now human, from those with the relevant knowledge of the network configuration. But to me the chances of someone looking for a starting point 9000 miles from the server, breaking in, then going through a few other hoops before hacking across the vpn to the production server is remote enough to put a long way down my list. >> >> And, of course, I'm lucky enough not to have to support 1903 vintage IBM boat anchors (: >> >> >> Steve >> >Just to follow this up from this morning... > >>From Logcheck... >Jul 15 07:16:54 server sshd[8129]: Failed password for invalid user hipcomix from 207.210.107.2 port 34553 ssh2 >Jul 15 07:16:54 server sshd[8132]: Failed password for root from 207.210.107.2 port 34566 ssh2 >Jul 15 07:16:55 server sshd[8134]: Failed password for invalid user jpeger from 207.210.107.2 port 34582 ssh2 >Jul 15 07:16:55 server sshd[8139]: Failed password for invalid user favs from 207.210.107.2 port 34606 ssh2 >and a few more... > >>From Denyhosts... >Date: Tue, 15 Jul 2008 07:17:00 +1200 > >Added the following hosts to /etc/hosts.deny: > >207.210.107.2 (unknown) > > >Steve > > >_______________________________________________ >NZNOG mailing list >NZNOG(a)list.waikato.ac.nz >http://list.waikato.ac.nz/mailman/listinfo/nznog Ref#: 41006

1 0

Re: [nznog] Compromised websites
by Scott Weeks 14 Jul '08

14 Jul '08

------- criggie(a)criggie.dyndns.org wrote: ------------ From: Criggie <criggie(a)criggie.dyndns.org> And if you're not watching/analyzing your logs, its very easy to miss someone trying passwords. <snip> Who's going to notice an extra 400 bytes/sec on a busy link, other than by monitoring logs for denied requests? -------------------------------------------------------- Depending on which program you use, you can set a max number of attempts by clients on the FTP server. scott

1 0

Kiwicon CFP 2k8 - Update
by Simon Howard 10 Jul '08

10 Jul '08

-----------------------------------------------------------------------] _.-.. __ .__ .__ ,'9 )\)`-.,.--. | | _|__|_ _ _|__| ____ ____ ____ 2k8 `-.| `. | |/ / \ \/ \/ / |/ ___\/ _ \ / \ \, , \) | <| |\ /| \ \__( <_> ) | \ `. )._\ (\ |__|_ \__| \/\_/ |__|\___ >____/|___| / |// `-,// \/ \/ \/ ]|| //" "" "" BAAAAAAaaaa!!11 [-------------------------------------------------- www.kiwicon.org----] Holy sheepshit, internets! Blanket-Man[1] has wrung out his loin cloth and is ready to fly-tackle more nerds with large egos and irc handles. Yes, it's time to open up your ~/haxing folder and get your talk together for Kiwicon 2k8! We've put out the black t-shirts, and deflated some satellite radomes, so where, as our more criminal yet fetchingly bikini clad cousins might say, the bloody hell are you? The Kiwicon Crüe is proud to announce the call for presenters for the second installment of New Zealand's very own security conference: Kiwicon 2k8. [CFP Update] Despite being a community con, Kiwicon is now pleased, if not delighted to the point of gratuitous Morris dancing to be able to offer financial support for travel to a limited number of speakers. More details are available in the Submission section below. We've already had a number of great talks submitted, and slots are filling fast. Those of you attending cons this year will already be aware of the number of Kiwis presenting - AusCERT, Shakacon, Syscan, Blackhat, Defcon, Ruxcon - you should see these guys in their natural habitat. They drop more 0day, wear tighter pants, and are 30% more likely to coyly flutter their eyelashes at you. [About] Kiwicon2k8 is intended to be an informal conference, drawing on the wider security community of Australia and New Zealand. It will be held in Wellington, New Zealand, on the weekend of the 27th and 28th of September, 2008. Kiwicon's focus is on sharing information; ideas, code, and good whisky, in a rabelaisan carnival of security, nerdery, and *nix beards. Last year, the inaugural Kiwicon ended up being kind of a big deal: highlights included tmasky's mighty Crackstation, the debut of Beau Butler as an "ethical hacker" making Microsoft "look like turkeys", and of course the Kiwicon Hax0r Quiz, with the winner taking the grand prize of An Illustrated Guide to the Commoner Skin Diseases. Hope it came in handy for the post-con diagnosis phase, dude. This year, Kiwicon's own Bogan is already making anti-virus vendors quake in their little signature-laden booties at Defcon's Race to Zero, and the cauldron of 0h-0h-0hday in Brett Moore's secret Insomnia lair is bubbling over with pernicious brew. If you missed last Kiwicon (not "professional enough"? couldn't convince your boss it wasn't a hoax?) then find one of the 230+ people who were there and ask them if they're just-not-gonna-bother this year. [Venue] Our hosts for the weekend will, once again, be Victoria University of Wellington. If you have any memory of last year's Kiwicon, then it'll look disturbingly familiar. The campus has the advantage of being close to the center of the city and its' various amenities. This includes cheap accommodation, good coffee, and, more importantly, several good pubs serving good, non-Australian, beer. [Costs] Kiwicon2k8 is a non-profit, non-commercial, non-corporate-funded event. Attendance for the entire weekend will cost $50 for employed individuals (self-employed and salaried). There is a discounted rate of $30 for students and the unemployed. GST receipts can be issued upon request. If your management can't be convinced of the value of something that only costs $50, we're happy to issue you with some kind of personalised limited edition invitation in crayon, glitter pen, and macaroni (spray-painted gold for that luxe look) for the low enterprise-only price of $500. [Topics] Suggested topics include but are not limited to: - Crowd Control Techniques and Panic Modeling - Information Warfare / Industrial Espionage - Malware (Viruses, Spam, Phishing, Botnets) - Cellular Networks (GSM,GPRS,CDMA,3G,4G) - Application Security, Testing, Fuzzing - Government Spy Networks / Surveillance - Nanotechnology / Quantum Computing - Access Control and Authentication - Wireless / Bluetooth / Infrared - Social Engineering / Trolling - Breaking EAL Certified Kit - Forensics / Antiforensics - Banking / ATMs / Carding - Exploitation Techniques - Layer 1/2/3 Nastiness - Reverse Engineering - Phreaking / VoIP - Virtualisation - Web Security - Lockpicking - Biometrics - Hypnosis - Crypto - Ohday - 23 There is no pre-determined talk length but we ask that speakers limit their presentation to an hour, including some question time. Kiwicon is a non-profit organisation, so generally funding is not available for travel and accommodation. However, we have a limited number of travel support packages available: 1 x NZ$1500 for a speaker from outside Australasia or the South Pacific 1 x NZ$750 for a speaker from Australia or the South Pacific 3 x NZ$250 for speakers from New Zealand These are available only to full length (>45min) speakers paying their own way. No speaking-in-a-corporate-capacity, no company logos on the slides and no industry weaseling. These stipends are for amateurs, crackpots, ecclesiasticals, students and other miserable doss-down-under-the-motorway-bridge-oh-my-goodness-two-cardboard-boxes-just-for-me? riff-raff. If you look too much like you should be hanging out between the pages of Men's Style magazine (and we know who you are), then we reserve the right to pick someone a trifle more threadbare. Organiser decision is final, no correspondence will be corresponded, and Sharrow has to think your existence does not constitute a putrefying abscess in the nostril of humanity. If you are a corporate sellout, however, a formal letter will be provided for employer leverage. Either way, unless you're a complete jackoff, people will try and buy you beer. To submit a presentation to Kiwicon2k8, send an email to cfp(a)kiwicon.org with the following information: Name or Handle: Country of Residence: Employer (if applicable): Presentation Title: Presentation Length: Presentation Synopsis: Brief Bio: Do Want Fat Cash: [Yes/No] ( If yes, pick one of the above support options, and explain how poor you are, and why you're worth spending our money on. Be creative. Poetry is acceptable? ) [CFP Submissions] Please submit your CFP by email to cfp(a)kiwicon.org, no later than 8:47pm NZST, Sunday 17th August 2008. There will be two rounds of selection, with the first half of the talks chosen in early August, so submit early for a better chance of acceptance. [Contacts & Further Information] Email us: kiwicon(a)kiwicon.org Check the site: http://www.kiwicon.org/ Drop by silc: silc.isig.org.nz:2706/kiwicon Join the list: kiwicon-subscribe(a)lists.isig.org.nz Greetz and thanks to all who helped make Kiwicon 2k7 the awesomeness it was, we'll see you fuckers again this year. Thick, meaty props to Pipes for stepping up and making 2k7 happen. We would miss you, but Sharrow's just as tall, and better looking. Sorry pal. -- The Kiwicon Crüe, 2k8 - Bogan, Metlstorm & Sharrow. \m/ [1] http://en.wikipedia.org/wiki/Ben_Hana

1 0

Dunedin Frequency 5735
by Dan Clark 08 Jul '08

08 Jul '08

Gidday Guys, anyone got anything new on 5735GHz in and around Dunedin CBD last 24 hours? Regards Dan Clark

10 11

DNS Vulnerability
by Jamie Baddeley 08 Jul '08

08 Jul '08

Vulnerability Summary: Deficiencies in the DNS protocol and common DNS implementations facilitate a DNS cache poisoning attack that affects BIND, Microsoft Windows DNS services and CISCO IOS. The vulnerability has been assigned the following Common Vulnerability and Exposure number: CVE-2008-1447 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 Note: Authorative name servers are not affected. Impact criticality: CCIP assess the impact of this vulnerability to be VERY HIGH. CCIP is unaware of any active exploit code for this vulnerability. Type of fix available: Microsoft has released a patch for this in their latest updates. More information can be found at http://www.microsoft.com/technet/security/bulletin/MS07-062.mspx. CCIP understands that other vendors will be releasing updates shortly. BIND have released a notification which is located at http://www.isc.org/index.pl?/sw/bind/index.php CISCO have also released a notification which can be accessed at http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml

2 1

Re: [nznog] DNS Vulnerability
by Ewen McNeill 08 Jul '08

08 Jul '08

In message <1215550691.3987.44.camel(a)titan>, Jamie Baddeley writes: >Vulnerability Summary: >Deficiencies in the DNS protocol and common DNS implementations >facilitate a DNS cache poisoning attack that affects BIND, Microsoft >Windows DNS services and CISCO IOS. See also, eg, http://isc.sans.org/diary.html?storyid=4687 which has some sane discussion of the issue (which basically seems to boil down to insufficient randomness in queries allowing spoofed replies, given the lack of any actual properly deployed security in DNS). Amongst other things they suggest patching any recursive/caching DNS servers with vendor patches at the soonest suitable patch window. The priority for patching other things depends on their reliance on DNS and protection gained from other DNS servers -- for instance things which only rely on DNS to look up internal management network names from a DNS server which is already patched are probably a much lower priority than the recursive DNS servers for your customers. (And while, eg, Cisco have a patch out for IOS, I'd imagine most routers/switches are not configured to offer recursive DNS or otherwise using the DNS functionality in IOS in a way that puts them at much risk.) Also for recursive DNS servers for customers see the note at the end of the isc.sans.org page (link above) about a beta version of BIND9 with performance improvements for high query load recursive servers. Ewen

1 0

APRICOT 2009: Call for Papers
by Gaurab Raj Upadhaya 02 Jul '08

02 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 18-27 February 2009, Manila, Philippines http://www.apricot2009.net Call for Papers The APRICOT 2009 Program Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2009. Full CFP available at : http://www.apricot2009.net Please submit proposals online at http://submission.apricot.net/paper/user/login.php?event=13 CONFERENCE MILESTONES - --------------------- Call for Papers Opens: 1 July 2008 Deadline for Speaker Submissions: 30 September 2008 First Draft Program Published: 15 October 2008 Final Program Published: 15 December 2009 Final Slides Received: 15 January 2009 Additional Information ______________________ APRICOT Program will be organized in three parts, including workshops, tutorials and the conference. APNIC Policy SIG and Annual Members Meeting will be held subsequently. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions. APRICOT is a TECHNICAL conference so marketing and commercial content is not allowed within the program. Speakers from developing countries may be eligible for the APRICOT Fellowship Program. More information on the APRICOT Fellowship program can be found at the APRICOT 2009 website at http://www.apricot2009.net/ Thanks. APRICOT Program Committee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhsZNIACgkQSo7fU26F3X21cgCgiTw0kXxmySOQwl4383LVHXID wPkAoKQMj28KautqgXUH5bkxqtmiUieZ =VSDe -----END PGP SIGNATURE-----

1 0

NZRR Route Registry Update
by NZRR Database Notifications 02 Jul '08

02 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Limited - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 120.136.48.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: benny.treefoot(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080516 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Limited - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.193.144.0/21^21-29, 116.199.208.0/21^21-29, 120.136.48.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: benny.treefoot(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080703 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Vector, did you try turning it off and then on again
by Bill Walker 02 Jul '08

02 Jul '08

Thats the best reply so far. We have just proposed triple redundancy to a customer. Fibre wireless and satellite the ongoing costs aren't too bad it's the setup costs that are a killer. 10 mbp satellite gear isn't cheap. If you've got the money it's the way to go. .... Bill Walker Sent from my phone. -----Original Message----- From: "John Russell" <jsr(a)jsr.com> To: "NZNOG" <nznog(a)list.waikato.ac.nz> Sent: 1/07/2008 11:41 p.m. Subject: Re: [nznog] Vector, did you try turning it off and then on again On [Various Times], [Many People Wrote] wrote: > [Words] A 9 hour outage seems long, but it's hardly absurd. Though we haven't seen a cause report from Vector yet, if it was spade fade, 9 hours is pretty good. I wasn't on call when it broke, but my colleague who was tells me he was told "Hardware Failure" was the problem. If something like a 6509 plane died, I can see how you might hit 9 hrs: The thing faults, alarms go off, customers call, the on-duty tech at Vector has to do some basic diagnosis, wave his hands in the air and run around like a monkey for a bit, call the on-call call engineer. Then that engineer has to wake up and/or finish his beer and get home from the pub, then do some more diagnostics, see the dead module and then do that thing where you put your hands flat on your forehead and drag them down your face while going "Gahhhhh". Then he gets to go pull a spare from stores, or call Cisco for a part and then THEY get to kick off THEIR internal process to get the thing to you. Then there's truck time to the site, waiting for an elevator to L48 of the sky tower that isn't already full of tourists in orange jumpsuits ready to jump off and/or carts full of crab canapes, swaping out the dead unit, sanity checking the restored services and making config changes if required, etc. And all that is just if everything does go to plan, and you don't find out that your spare hardware is in the lab, and the lab is locked and the guy who has the key has gone fishing, or that Cisco have already given their only spare WS-X6516 to someone else, and so on and so on. So, anyway, thing is, 9hrs, sure. However it really shouldn't matter that much. The ISP network I am currently fussing over, for example, has vector connectivity to the Sky Tower, which carries APE and some other stuff. This all broke when Vector went down. Domestic traffic, however, simply switched over to other peering links, as it should because it is, you know, The Internet. Some Vector-only stuff broke, of course, but core services just failed over and carried on. If your network connection is absolutely critical for your business, and it's wholly dependent on one vendor, you should perhaps rethink your approach. Talk to your ISP, explain that you need redundancy in your connection. Chuck in something like a DSL connection beside that Vector link. Ask your ISP about sourcing you a router than can connect to both, and setting up BGP or MPLS-based failover to your secondary link in the event that your Vector link fails. Now your connection is vendor independent (if not ISP-independent - if they fail, you fail. Try to pick an ISP that Does Not Fail Much). If you can't get DSL, ask your ISP about Wireless or IPStar or something similar. If you can fail from optical to satellite, that's pretty good diversity. And it's not complicated to do. You may not get the same performance, of course, but you'll have _a_ connection, which is better than _no_ connection, especially if it's only for a short time. This setup won't, of course, solve the problem of a local power cut killing your Vector link. I'm not even certain why we're discussing that. Talk to Vector and your electrician to get a cable run from your generator and/or UPS-backed distribution board to wherever your building vector switch is. Plug the switch into it. And you're done. It's a one-off cost, and likely not a large one. Even without a UPS, the worst that can happen is that the switch powers down when the cut takes place, then boots back up when your generator starts. A few minutes, tops. If you _don't have_ a generator, and your building power is out, I guess you'll be sitting in the dark, looking at your blank screen, and won't care if your internet connection is down. This is a perfect opportunity to go to the pub, and have a drink with the Vector engineer. Assuming he's awake. JSR -- John S Russell Big Geek. Doing Geek Stuff. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1526 - Release Date: 30/06/2008 8:43 a.m.

5 5

NZRR Route Registry Update
by NZRR Database Notifications 01 Jul '08

01 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9245 descr: advertised to AS9439 by Compass Communications - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 116.90.132.0/24^24-29, 202.36.121.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080213 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9245 descr: advertised to AS9439 by COMPASS NZ - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 120.136.0.0/21^21-29, 123.108.144.0/21^21-29, 116.90.128.0/23^23-29, 116.90.132.0/23^23-29, 202.174.6.0/23^23-29, 116.90.131.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080702 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 01 Jul '08

01 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9245 descr: advertised to AS9560 by Compass Communications - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 116.90.132.0/24^24-29, 202.36.121.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080213 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9245 descr: advertised to AS9560 by COMPASS NZ - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 120.136.0.0/21^21-29, 123.108.144.0/21^21-29, 202.174.6.0/23^23-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080702 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Vector, did you try turning it off and then on again
by Matthew Poole 30 Jun '08

30 Jun '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Naylor wrote: | OK MAN CPEs are tricky. A cheap UPS is useless. The line interactive | type do let thru spikes and surges and if your CPE device has a cheap | switching PSU it will often lock up, die, or do nasty things. So to get | a decent UPS (ie rectifier followed by inverter) you need to spend over | $1k. | And given that Vector were using, at the time, Cisco 29xxG's (I think. Pretty sure they were just dumb L2 switches) for CPE, a $1k UPS would almost double the equipment cost per install. That's not inconsiderable. | Then you have batteries and maintenance. A typical power company (I used Which was really my point. Keeping a lot (and it'll number in the hundreds for Vector) of UPS's up and running isn't a trivial ask. The cost would be phenomenal, and every time batteries need to be changed it's an outage for the CPE that's on the end of it. *SNIP* | If you want to help your MAN supplier deliver a better performance and | you run a nice UPS, then offer to give them some of your 230V off your | UPS. Then you know that they have power at your end. And if you have a | diesel as well....... | | Its a nice cheap solution, and you know the performance of their backup. | Yeah, I think that was kind of what Vector were hoping for. But a lot of their terminating switches are buried in basement rooms to which only the building manager has a key. I know that we had quite a few instances of banging heads on walls trying to get access to put our kit in with Vector's, because the keys to the appropriate room were hard to locate. - -- Matthew Poole "Don't use force. Get a bigger hammer." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIaWaWTdEtTmUCdpwRAvxSAKDIVU4tPqlHaZxpDSbZkk5s6XfwXgCeP99z rgL579ASX+9AcBjhAlgC56g= =sQy1 -----END PGP SIGNATURE-----

17 21

Re: [nznog] Vector, did you try turning it off and then on again
by Richard Naylor 30 Jun '08

30 Jun '08

At 01:15 p.m. 30/06/2008, Pshem Kowalczyk wrote: <snip> >Updates 4h into the problem saying - no ETA and about 2h later - it >will be fixed tomorrow are just not enough. The fact that it was >virtually impossible to get hold of anyone that actually had a clue is >not something that an average business is willing to accept. If a network connection is that important to the "average" business, then it should do something about it. What worries me is that people on this list think that a network operator should be infallible. If the Internet is that important to your business, then have more than one provider. If you have clue, you'll use one with a different layer 3, 2, 1, or maybe even 0 route topology. Its far simpler to have multiple providers and networks than paying a fortune to have some undeliverable level of reliability. And besides *you* have control over it. My business relies heavily on the Internet. We use 5 providers for our network and around 5 for the services. We mix dsl with wireless (3 forms), we have 4 satellite links, fiber and are known to run our own cable when we can't get what we want where we want it. A Km or two is no real issue. If a company uses a UPS for its computer, why doesn't it invest in a second link. Even crappy dsl will at least keep something going. Rich

5 7

Upcoming APNIC policy implementations
by Elly Tawhai 30 Jun '08

30 Jun '08

________________________________________________________________________ Upcoming APNIC policy implementations ________________________________________________________________________ On 4 August 2008, APNIC will implement two policy proposals that reached consensus at the APNIC 25 Policy SIG in Taipei, Taiwan in February 2008. The APNIC Executive Council (EC) endorsed the proposals during their May 2008 meeting. The two policy changes are: - Changing the minimum IPv4 allocation size to /22 This change will make it easier for small ISPs to receive direct allocations from APNIC. - Adding an alternative IPv6 initial allocation criteria This change will make it easier for more ISPs to receive IPv6 allocations from APNIC by enabling current LIRs with IPv4 allocations to receive IPv6 initial allocations without a plan for making 200 assignments. To view the history of these policy proposals, see: prop-053: Changing minimum IPv4 allocation size to /22 http://www.apnic.net/policy/proposals/prop-053-v003.html prop-057: Proposal to change IPv6 initial allocation criteria http://www.apnic.net/policy/proposals/prop-057-v002.html Kind regards, Elly ________________________________________________________________________ Elly Tawhai email: hostmaster(a)apnic.net Senior Internet Resource Analyst, APNIC sip: hostmaster(a)voip.apnic.net http://www.apnic.net/helpdesk phone: +61 7 3858 3188 fax: +61 7 3858 3199 ________________________________________________________________________ Hope to see you at APNIC 26 in Christchurch, New Zealand 25 - 29 August 2008 http://www.apnic.net/meetings/26/

1 0

ICANN New TLD's
by Chris Hodgetts 30 Jun '08

30 Jun '08

No one here has commented, (Unless my mail filter rules are a little broken at the moment) What are peoples thoughts?

3 2

The New Zealand Network Operators' Group
by Donald Neal 30 Jun '08

30 Jun '08

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. It consists of the subscribers to this mailing list. The group is intended to facilitate discussion among operators of networks in New Zealand on matters relevant to network operators as described in the list's Acceptable Use Policy. That policy appears later in this posting. Conference We hold New Zealand's only technical networking conference. See http://www.nznog.org/?page_id=4 for details of conferences from 2004 to 2008. Work is now under way in preparation for the next conference, to be held in the North Island in the last week of January 2009. Other Meetings See http://thursdaynightcurry.com/ if you live in or near Auckland or Wellington (or Hamilton?) Operators' Contact List See http://www.nznog.org/?page_id=6 for operational contact details for most New Zealand ISP's. These are intended for use by other network operators, not by most customers. Internet Exchanges See http://www.nzix.net/ for details of exchanges in operation. About This Mailing List This list has between 900 and 1000 addresses subscribed. You may only post to the list from a subscribed address. A number of people subscribe addresses which do not receive email purely to allow posting from them. You may choose to receive postings as they come in, or just to receive daily "digests". See the bottom of the page http://list.waikato.ac.nz/mailman/listinfo/nznog/ to change the form in which you receive postings. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by employees of APN Online, Citylink, and The University of Waikato. None of these organisations, nor any administrator, is responsible for its content. NZNOG Mailing List Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 4. Postings to multiple mailing lists are discouraged. 5. Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 6. Blatant product or service marketing is unacceptable. 7. Postings of a political, philosophical or legal nature are discouraged. 8. Postings to the list should be in ASCII or MIME encoded as text/plain. Attachments should not be sent to the list. To present a document, a suitable URL may be referred to. For documents of general interest, the use of proprietary file formats is discouraged. 9. Breaches of list etiquette should be dealt with privately with the offending list user, and should not result in complaints being sent to the list. 10. A person repeatedly breaching list etiquette shall receive warnings from the list administrator. A further breach after the second such warning within thirty days shall result in the offender being unsubscribed from the list. Other action may also be taken to block postings to the list by the offender. Any such unsubscription is to be immediately announced to the list. Mailing List Archives A full archive is available at http://list.waikato.ac.nz/pipermail/nznog/ . Any message sent to the list will be archived and made available on the web automatically. Changes are not made to the archive on request, though the administrators remain happy to assist the Office of the Privacy Commissioner should any complaint be laid with that office. One way to search the archive is to use google and prefix your search with site:list.waikato.ac.nz . Subscribing to the List See http://list.waikato.ac.nz/mailman/listinfo/nznog to subscribe. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins -- Donald Neal | "Careful design and strict discipline are Research Officer | necessary to prevent this sort of mess WAND | from escaping the development laboratory The University of Waikato | and infesting the production environment." | - D. Russell

1 0

Re: [nznog] Vector, did you try turning it off and then on again
by jamie baddeley 30 Jun '08

30 Jun '08

I'm with Richard here on getting in touch with reality. I always like to quote a report written by the Yankee Group. Yeah I know reports like these written by these professional 'opinionators' at are questionable at best, but one of the things they quantify which is interesting to me is a 31% attribution to human error. I'll give them the benefit of the doubt. http://www.cisco.com/warp/public/437/services/rt59/documents/yankee_report.… The reason why that is significant is the only way you'll get over that is institutional diversity. Change the associated humans and you'll avoid a 31% contributor to the cause of your potential downtime in your future. Not to mention all the other causes. I've had this argument before. http://list.waikato.ac.nz/pipermail/nznog/2005-June/010170.html Another point of reference I have is a conversation with someone involved with APNIC (previously was with Telstra) back in '99 who had the view the boils down to this: "Why does a telco waste money on making their network 5 nines, when they'll never practically realise that? Why does a customer spend money on that? Why doesn't a customer spend money of parallel sourcing 2 x '3 nines' networks and combining that together with the knowledge that they'll actually truly realise a 5 nines solution?" Now of course the customer being able to achieve that is dependent on their own internal reliability, but you're all at 5 nines availability yourselves right guys? Course you are. Silly me. That's why there's been little noise. Now, back on topic. The failure over the weekend was I presume not due to operator error. But if you've developed a strategy to deal with operator error, you've probably also dealt with an outage that is a little bit longer than normal. And in that case you're probably feeling cool right now. Otherwise you're a little hot under the collar. Nevermind, lesson learnt. Jamie -----Original Message----- From: Richard Naylor [mailto:richard.naylor(a)r2.co.nz] Sent: Monday, 30 June 2008 6:34 p.m. To: Pshem Kowalczyk; Chris Hodgetts Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Vector, did you try turning it off and then on again At 01:15 p.m. 30/06/2008, Pshem Kowalczyk wrote: <snip> >Updates 4h into the problem saying - no ETA and about 2h later - it >will be fixed tomorrow are just not enough. The fact that it was >virtually impossible to get hold of anyone that actually had a clue is >not something that an average business is willing to accept. If a network connection is that important to the "average" business, then it should do something about it. What worries me is that people on this list think that a network operator should be infallible. If the Internet is that important to your business, then have more than one provider. If you have clue, you'll use one with a different layer 3, 2, 1, or maybe even 0 route topology. Its far simpler to have multiple providers and networks than paying a fortune to have some undeliverable level of reliability. And besides *you* have control over it. My business relies heavily on the Internet. We use 5 providers for our network and around 5 for the services. We mix dsl with wireless (3 forms), we have 4 satellite links, fiber and are known to run our own cable when we can't get what we want where we want it. A Km or two is no real issue. If a company uses a UPS for its computer, why doesn't it invest in a second link. Even crappy dsl will at least keep something going. Rich _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3 2

streaming Olympics coverage in early August
by Simon Blake 29 Jun '08

29 Jun '08

Hi all CityLink will be assisting TVNZ with their online coverage of the Beijing games next month. The exact coverage hasn't been finalised yet, but we're expecting that TVNZ will run approximately four coverage streams - live encodings of TV1 and TVNZ sports extra (from Freeview), and two further channels that will be online only. Each will be Windows Media streams at ~90Kb/s, ~384Kb/s, and 1.5-2Mb/s, and if we can get our act together there may be an experimental HD Freeview coverage stream at 5-6Mb/s. So, a significant amount of content, much of which won't be available from traditional telly. Predicting usage for this sort of gig is difficult, particularly when access to this content by customers of some providers (Vodafone, Orcon) won't come off their data cap. We're assuming there will be heavy demand, so we're aiming to have StreamingNet (our anycast CDN) deliver aggregate 5-10Gb/s peak domestic bandwidth. Therefore, those running eyeball networks should be thinking about how best to get at this content. If your IX connections are full (or nearly full), then now may be a good time to organise an upgrade. Cheers Simon

1 0

ICANN New TLD's
by Chris Hodgetts 29 Jun '08

29 Jun '08

No one here has commented, (Unless my mail filter rules are a little broken at the moment) What are peoples thoughts?

10 9