- NZNOG - lists.nznog.org

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