- NZNOG - lists.nznog.org

The New Zealand Network Operators' Group
by Donald Neal 31 Oct '04

31 Oct '04

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. At present it consists of the subscribers to this mailing list, which anyone is free to join. Meetings Our next annual conference is to be hosted by the WAND group in Hamilton on February 2nd to 4th, 2005. See http://www.nznog.org/ for more information, including the Call For Presentations. All offers to present should really be in by now. Also see http://auckland.thursdaynightcurry.com/ if you live in or near Auckland or Wellington. Operators' Contact List See http://www.usenet.net.nz/noc/ 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.ape.net.nz/ for details of the Auckland Peering Exchange and those connected there. See http://www.wix.net.nz/ for the Wellington Internet Exchange. About This Mailing List This list has slightly over 700 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 Alcatel NZ Ltd, Citylink and Telecom. 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 |Palmersdale: Are you in charge here? Technical Specialist |The Doctor: No, but I'm full of Operations Engineering | ideas. Integration & Services Division +----------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

1 0

Ihug Prefix list update
by Sainesh Singh 28 Oct '04

28 Oct '04

Please update domestic filters for Ihug. APE details: AS7657 192.203.154.36 192.203.154.37 Updated list can be found at: http://www.ihug.net/ihug-prefix-list and is included below. Cheers, Sainesh Singh Ihug Engineering ip prefix-list ihug-networks permit ip prefix-list ihug-networks description ihug peering prefix-list contact: noc(a)ihug.co.nz : Updated 2004-10-29 ip prefix-list ihug-networks permit 192.107.113.0/24 ip prefix-list ihug-networks permit 202.21.130.0/24 ip prefix-list ihug-networks permit 202.21.136.0/23 le 24 ip prefix-list ihug-networks permit 202.36.44.0/24 ip prefix-list ihug-networks permit 202.36.94.0/23 le 24 ip prefix-list ihug-networks permit 202.36.230.0/24 ip prefix-list ihug-networks permit 202.36.231.0/24 ip prefix-list ihug-networks permit 202.37.182.0/24 ip prefix-list ihug-networks permit 202.49.33.0/24 ip prefix-list ihug-networks permit 202.49.46.0/23 le 24 ip prefix-list ihug-networks permit 202.49.63.0/24 ip prefix-list ihug-networks permit 202.49.64.0/24 ip prefix-list ihug-networks permit 202.49.140.0/24 ip prefix-list ihug-networks permit 202.49.148.0/23 le 24 ip prefix-list ihug-networks permit 202.49.176.0/23 le 24 ip prefix-list ihug-networks permit 202.49.178.0/24 ip prefix-list ihug-networks permit 202.49.180.0/23 le 24 ip prefix-list ihug-networks permit 202.49.186.0/24 ip prefix-list ihug-networks permit 202.49.249.0/24 ip prefix-list ihug-networks permit 202.50.84.0/24 ip prefix-list ihug-networks permit 202.50.103.0/24 ip prefix-list ihug-networks permit 202.50.188.0/22 le 24 ip prefix-list ihug-networks permit 202.50.255.0/24 ip prefix-list ihug-networks permit 203.96.192.0/19 le 24 ip prefix-list ihug-networks permit 203.109.128.0/17 le 24 ip prefix-list ihug-networks permit 203.109.130.0/24 ip prefix-list ihug-networks permit 203.109.132.0/22 ip prefix-list ihug-networks permit 203.109.133.0/24 ip prefix-list ihug-networks permit 203.109.134.0/24 ip prefix-list ihug-networks permit 203.109.135.0/24 ip prefix-list ihug-networks permit 203.109.144.0/20 ip prefix-list ihug-networks permit 203.109.157.0/24 ip prefix-list ihug-networks permit 203.109.192.0/21 ip prefix-list ihug-networks permit 203.109.198.0/24 ip prefix-list ihug-networks permit 203.109.199.0/24 ip prefix-list ihug-networks permit 203.109.230.0/24 ip prefix-list ihug-networks permit 203.118.128.0/18 le 24 ip prefix-list ihug-networks permit 203.118.144.0/20 ip prefix-list ihug-networks permit 203.118.160.0/20 ip prefix-list ihug-networks permit 203.118.164.0/22 ip prefix-list ihug-networks permit 203.118.168.0/21 ip prefix-list ihug-networks permit 203.173.128.0/17 le 24 ip prefix-list ihug-networks permit 203.173.164.0/22 ip prefix-list ihug-networks permit 203.173.168.0/23 ip prefix-list ihug-networks permit 203.173.170.0/23 ip prefix-list ihug-networks permit 203.173.172.0/22 ip prefix-list ihug-networks permit 203.173.192.0/19 ip prefix-list ihug-networks permit 203.173.224.0/20 ip prefix-list ihug-networks permit 203.173.240.0/21 ip prefix-list ihug-networks permit 210.55.110.0/24 ip prefix-list ihug-networks permit 210.55.184.0/24 ip prefix-list ihug-networks permit 210.55.202.0/23 le 24 ip prefix-list ihug-networks permit 210.55.248.0/21 le 24

3 2

FW: [Apnic-announce] Final Stage: Early Registration Transfer Project(ERX)
by Nurani Nimpuno 28 Oct '04

28 Oct '04

Message forwarded from the APNIC-announce mailing list. Kind regards, Nurani Nimpuno APNIC -----Original Message----- From: apnic-announce-bounces(a)lists.apnic.net [mailto:apnic-announce-bounces(a)lists.apnic.net] On Behalf Of APNIC Secretariat Sent: 29 October 2004 14:43 To: apnic-announce(a)apnic.net Subject: [Apnic-announce] Final Stage: Early Registration Transfer Project(ERX) Dear Colleagues The four Regional Internet Registries (RIRs) are about to enter the final stage of the Early Registration Transfer (ERX) project. This project is a coordinated effort to move whois records for address space registered before the advent of the RIRs to the whois database of the RIR in whose region the registrant is based. In this final stage of the project, whois records for registrations within 192.0.0.0/8 are being moved from the ARIN database. If you operate a network in 192.0.0.0/8 and have: - registration information in more than one RIR database, or - have a postal address that lies outside the RIR's service region you will receive a mail regarding its registration. The mail explains in which database we believe the registration is meant to reside. The message also explains how to indicate which contact information should be recorded. You can find out more about the ERX project at the following URLs: http://www.apnic.net/db/erx/ http://www.arin.net/registration/erx/ http://www.lacnic.net/en/erx.html http://www.ripe.net/projects/erx/ Kind regards ______________________________________________________________________ APNIC Secretariat <secretariat(a)apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 ---------------------------------------------------------------------- _______________________________________________ Apnic-announce mailing list Apnic-announce(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-announce

1 0

Contact Details for ATT NZ
by Craig Whitmore 28 Oct '04

28 Oct '04

Hi there I am looking for the NZ Technical Contact for AT&T in NZ (regards to Internet). Can anyone help me (please reply off list). It doesn't seem to be on http://www.usenet.net.nz/noc/index.html Regards, Craig Whitmore

1 0

WIX Peering
by Craig Spiers 28 Oct '04

28 Oct '04

Anyone out there on wix, who isn't currently peering at the route server's for some reason, and would like to setup direct peering, chuck me an email :-) Cheers Regards, Craig - ConceptNET

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 28 Oct '04

28 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Fri, 29 Oct 2004 12:26:49 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410291218530.3561(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by Citylink - AS23754 members: 198.48.0.0/22^22-24, 202.8.44.0/22^22-24, 203.118.144.0/24, 202.7.5.0/24, 202.7.6.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by Citylink - AS23754 members: 198.48.0.0/22^22-24, 202.8.44.0/22^22-24, 202.7.5.0/24, 202.7.7.0/24, 203.118.144.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 28 Oct '04

28 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Fri, 29 Oct 2004 11:47:13 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410291145340.3438(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23755 descr: advertised to AS9439 by Citylink - AS23755 members: 202.7.4.0/24^24-29, 202.7.6.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: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23755 descr: advertised to AS9439 by Citylink - AS23755 members: 202.7.4.0/24^24-29, 202.7.7.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 mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR --- PREVIOUS OBJECT: route: 202.7.4.0/24 descr: Route for Citylink - AS23755 origin: AS23755 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR REPLACED BY: route: 202.7.4.0/24 descr: Route for Citylink - AS23755 origin: AS23755 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR --- PREVIOUS OBJECT: route: 202.7.6.0/24 descr: Route for Citylink - AS23755 origin: AS23755 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR REPLACED BY: route: 202.7.6.0/24 descr: Route for Citylink - AS23755 origin: AS23755 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR --- OBJECT BELOW CREATED: route: 202.7.7.0/24 descr: Route for Citylink - AS23755 origin: AS23755 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 28 Oct '04

28 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Fri, 29 Oct 2004 11:27:06 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410291126030.3438(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW CREATED: route: 202.7.6.0/24 descr: Route for Citylink - AS23754 origin: AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by CityLink - AS23754 members: 198.48.0.0/22^22-24, 202.8.44.0/22^22-24, 203.118.144.0/24, 202.7.5.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by Citylink - AS23754 members: 198.48.0.0/22^22-24, 202.8.44.0/22^22-24, 203.118.144.0/24, 202.7.5.0/24, 202.7.6.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 28 Oct '04

28 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Fri, 29 Oct 2004 11:22:53 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410291122070.3438(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW CREATED: route: 202.7.6.0/24 descr: Route for Citylink - AS23755 origin: AS23755 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR

1 0

MCI/Voyager offer free global transit from APE
by Andy Linton 28 Oct '04

28 Oct '04

I'm trying to get hold of someone at MCI/Voyager to get them to stop advertising the APE block, 192.203.154.0/24, globally. It's generating a whole heap of extraneous noise on the APE and we want it to stop. For details see: http://www.ris.ripe.net/cgi-bin/lg/index.cgi?rrc=RRC001&query=1&arg=+192.20…

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1429] New objects for inclusion in NZRR (fwd) - Date: Thu, 28 Oct 2004 14:30:40 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281429180.5844(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW CREATED: route: 202.135.38.0/26 descr: Route for SolNet Solutions - AS64580 origin: AS64580 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: eric.duggan(a)solnetsolutions.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Thu, 28 Oct 2004 14:22:08 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281420390.5844(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23754 descr: Route set for Citylink to APE members: 203.118.144.0/24, 198.48.0.0/22, 202.8.44.0/22^22-24, 202.7.5.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR mnt-by: MAINT-NZRR-NZ notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz changed: rpsl-admin(a)nzix.net 20031118 changed: rpsl-admin(a)nzix.net 20040303 changed: rpsl-admin(a)nzix.net 20040406 changed: rpsl-admin(a)nzix.net 20040629 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by CityLink - AS23754 members: 198.48.0.0/22^22-24, 202.8.44.0/22^22-24, 203.118.144.0/24, 202.7.5.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 202.7.5.0/24 descr: Route for CityLink - AS23754 origin: AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR

1 0

ADSL @ Home
by Geraint Jones 27 Oct '04

27 Oct '04

I got a charming email from extra informing me that their flat rate customers charged @ 69.95 will be going from 256kbit to 2mbit in the next month, the first I heard of it was the email. Was anyone aware this was going to happen and it was just me having my head in the sand or is this as unexpected as I find it. Geraint Jones Systems Administrator French Maid Foods Limited www.french-maid.net <http://www.french-maid.net/> Tel: +64 (0)4 568 2687 Fax: +64 (0)4 568 2345 Mob: +64 (0)21 739 240 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

6 5

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Thu, 28 Oct 2004 14:01:56 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281401420.5844(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW DELETED: route: 210.48.101.64/27 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Thu, 28 Oct 2004 13:59:44 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281356090.5844(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW DELETED: route: 202.53.189.128/29 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR --- OBJECT BELOW DELETED: route: 202.174.161.0/24 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR --- OBJECT BELOW DELETED: route: 210.48.109.224/27 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR

1 0

RE: [nznog] ADSL @ Home
by Geraint Jones 27 Oct '04

27 Oct '04

/me brushes the sand off his ears ;-P Geraint Jones Systems Administrator French Maid Foods Limited www.french-maid.net Tel: +64 (0)4 568 2687 Fax: +64 (0)4 568 2345 Mob: +64 (0)21 739 240 -----Original Message----- From: Drew Broadley [mailto:drew(a)corrupt.co.nz] Sent: Thursday, October 28, 2004 1:24 PM To: Geraint Jones Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] ADSL @ Home Geraint Jones wrote: > I got a charming email from extra informing me that their flat rate > customers charged @ 69.95 will be going from 256kbit to 2mbit in the > next month, the first I heard of it was the email. Was anyone aware this > was going to happen and it was just me having my head in the sand or is > this as unexpected as I find it. Is this really on-topic ? Answer: yes, your head is in the sand, http://www.telecom-media.co.nz/releases_detail.asp?id=3096 :) - Drew This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1422] Changes to AS64598 (fwd) - Date: Thu, 28 Oct 2004 12:28:34 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281227470.5286(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64598 descr: Route set advertised to AS9439 by Araneo - AS64598 members: 202.53.189.128/29, 202.174.161.0/24^24-29, 210.48.109.224/27^27-29, 210.48.101.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: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64598 descr: advertised to AS9439 by Araneo - AS64598 members: 210.48.109.104/29, 210.48.109.112/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 210.48.109.104/29 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1421] Changes to AS64597 (fwd) - Date: Thu, 28 Oct 2004 12:27:23 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281226020.5286(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64597 descr: Route set advertised to AS9439 by Araneo at RNZ - AS64597 members: 210.48.109.224/27 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: jon.brewer(a)att.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040801 changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64597 descr: advertised to AS9439 by Araneo - AS64597 members: 202.53.189.128/29, 210.48.101.64/27^27-29, 210.48.109.224/27^27-29, 202.174.161.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: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 202.53.189.128/29 descr: Route for Araneo - AS64597 origin: AS64597 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 210.48.101.64/27 descr: Route for Araneo - AS64597 origin: AS64597 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 210.48.109.224/27 descr: Route for Araneo - AS64597 origin: AS64597 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 202.174.161.0/24 descr: Route for Araneo - AS64597 origin: AS64597 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR

1 0

Re: [nznog] ADSL Rate Limiting on the line.
by neil gardner 23 Oct '04

23 Oct '04

Well, I've never met Bruce, and I do read Aardvark most days, but I think it would be good to get someone that really _knows_ what the impact of reducing the line speed on latency will be. We have a few dslams here for testing but they're been used for real work right now. Anyone _know_ what the effect will be? Cheers - Neil G >>> Richard Nelson <richardn(a)cs.waikato.ac.nz> 22/10/2004 12:44:56 p.m. >>> Maybe you misread it, there is a 'but' in the sentance: "This will likely increase latency for all but those on the full-speed JetStream plans ..." Richard. Craig Spiers wrote: > Hi guys, > > > > Reading todays article on http://www.aardvark.co.nz/ he raves on about > 'increased latency' > > > > Would I be right in saying the latency would only increase on lower speed > jetstream plans - as it takes longer for the packets to pass over a smaller > pipe. > > > > Why is he talking about it increasing latency on full rate jetstream plans? > > > > Cheers > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

4 4

Weekend reading on Exchanges
by Andy Linton 21 Oct '04

21 Oct '04

Here's a paper on IXes you might like to read: Prescriptive Policy Guide for Developing Nations Wishing to Encourage the Formation of a Domestic Internet Industry http://www.pch.net/resources/papers/policy-guide/policy-guide.html

1 0

FW: Westpac: SERVICE MESSAGE
by Barry Murphy 21 Oct '04

21 Oct '04

Just received: Return-Path: <www(a)forcartex.com.tw> Delivered-To: unix.co.nz-barry(a)unix.co.nz Received: (qmail 57023 invoked from network); 22 Oct 2004 00:25:24 -0000 Received: from www(a)forcartex.com.tw by firewall.unix.co.nz by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4396. Clear:RC:0(219.88.242.3):. Processed in 0.334605 secs); 22 Oct 2004 00:25:24 -0000 X-Qmail-Scanner-Mail-From: www(a)forcartex.com.tw via firewall.unix.co.nz X-Qmail-Scanner: 1.22 (Clear:RC:0(219.88.242.3):. Processed in 0.334605 secs) Received: from unknown (HELO dbmail-mx3.orcon.net.nz) (219.88.242.3) by smtp.unix.co.nz with SMTP; 22 Oct 2004 00:25:24 -0000 Received: from mail.unix.co.nz (firewall.unix.co.nz [219.88.241.242]) by dbmail-mx3.orcon.net.nz (8.13.1/8.13.1/Debian-14) with SMTP id i9M0PONQ030574 for <blacklabel(a)orcon.net.nz>; Fri, 22 Oct 2004 13:25:25 +1300 Received: (qmail 57013 invoked by uid 89); 22 Oct 2004 00:25:23 -0000 Delivered-To: barry(a)southafrica.co.nz Received: (qmail 57007 invoked from network); 22 Oct 2004 00:25:22 -0000 Received: from www(a)forcartex.com.tw by firewall.unix.co.nz by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4396. Clear:RC:0(211.22.18.59):. Processed in 0.985909 secs); 22 Oct 2004 00:25:22 -0000 X-Qmail-Scanner-Mail-From: www(a)forcartex.com.tw via firewall.unix.co.nz X-Qmail-Scanner: 1.22 (Clear:RC:0(211.22.18.59):. Processed in 0.985909 secs) Received: from unknown (HELO mail.forcartex.com.tw) (211.22.18.59) by smtp.unix.co.nz with SMTP; 22 Oct 2004 00:25:21 -0000 Received: from localhost (localhost.forcartex.com.tw [127.0.0.1]) by mail.forcartex.com.tw (Postfix) with ESMTP id B207F12BC24 for <barry(a)southafrica.co.nz>; Fri, 22 Oct 2004 08:25:18 +0800 (CST) Received: from mail.forcartex.com.tw ([127.0.0.1]) by localhost (www.forcartex.com.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10715-03 for <barry(a)southafrica.co.nz>; Fri, 22 Oct 2004 08:25:18 +0800 (CST) Received: by mail.forcartex.com.tw (Postfix, from userid 80) id 4D67012BCA8; Fri, 22 Oct 2004 08:24:21 +0800 (CST) To: barry(a)southafrica.co.nz Subject: Westpac: SERVICE MESSAGE MIME-Version: 1.0 Content-type: text/html; charset=iso-8859-1 From: Westpac New Zealand <service(a)westpac.co.nz> Reply-To: service(a)westpac.co.nz X-Mailer: PHP/4.3.8 Message-Id: <20041022002421.4D67012BCA8(a)mail.forcartex.com.tw> Date: Fri, 22 Oct 2004 08:24:21 +0800 (CST) X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on dbmail-mx3 X-Virus-Scanned: by amavisd-new at forcartex.com.tw X-Amavis-Alert: BAD HEADER Improper use of control character (char 0D hex) in message header 'MIME-Version': MIME-Version: 1.0\r\n Received-SPF: none (dbmail-mx3.orcon.net.nz: 219.88.241.242 is neither permitted nor denied by domain of forcartex.com.tw) receiver=dbmail-mx3.orcon.net.nz; client-ip=219.88.241.242; helo=mail.unix.co.nz; envelope-from=www(a)forcartex.com.tw; x-software=spfmilter 0.93 http://www.acme.com/software/spfmilter/; X-Virus-Status: Clean X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on firewall.unix.co.nz X-Spam-Level: X-Spam-Status: No, hits=0.9 required=5.0 tests=BAYES_50,HTML_MESSAGE, HTML_TITLE_UNTITLED,MIME_HTML_ONLY autolearn=no version=2.64 _____ From: Westpac New Zealand [mailto:service(a)westpac.co.nz] Sent: Friday, 22 October 2004 1:24 p.m. To: barry(a)southafrica.co.nz Subject: Westpac: SERVICE MESSAGE <http://www.westpac.co.nz/w_nz.gif> Dear Westpac customer, Recently there has been a large number of identity theft attempts targeting Westpac customers. In order to safeguard your account, we require that you confirm your banking details. This process is mandatory, and if not completed within the nearest time your account may be subject to temporary suspension. To securely confirm your Westpac account details, please fill in the form that will follow after signing in at: http://www.westpac.co.nz/personal/Checking/OnlineBanking/Internet_Banking/in dex.cfm <http://www.saracie.org/secure/online/adtrack/IOLB/newSession/nz.htm> Thank you for your prompt attention to this matter and for using Westpac! Westpac Banking Corporation ABN 33 007 457 141, incorporated in Australia (New Zealand division). CopyrightC1999-2004 Westpac Banking Corporation

3 2

ADSL Rate Limiting on the line.
by Craig Spiers 21 Oct '04

21 Oct '04

Hi guys, Reading todays article on http://www.aardvark.co.nz/ he raves on about 'increased latency' Would I be right in saying the latency would only increase on lower speed jetstream plans - as it takes longer for the packets to pass over a smaller pipe. Why is he talking about it increasing latency on full rate jetstream plans? Cheers

2 2

Unsubscription from NZNOG
by Donald Neal 21 Oct '04

21 Oct '04

After repeatedly making postings to this list which were not compatible with the list's acseptable use policy, Michael Hallager has been unsubscribed from the NZNOG list. I have received a number of complaints about his behaviour. My thanks to those subscribers for not sending their complaints to the list. - Donald Neal NZNOG Mailing List Administrator Donald Neal |Presbyopia - inability to see what Technical Specialist | bishops are for. Operations Engineering | Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

1 0

Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by neil gardner 20 Oct '04

20 Oct '04

>>> Stephen Ridley <stephen.ridley(a)k.co.nz> 21/10/2004 11:00:01 a.m. >>> >And the latency is somewhat better than what we used to get from the jetstream >link: >traceroute to xtra.co.nz (202.27.184.102), 30 hops max, 38 byte packets > 1 a.a.a.a (a.a.a.a) 0.926 ms 0.864 ms 0.922 ms > 2 b.b.b.b (b.b.b.b) 8.465 ms 8.123 ms 12.425 ms > 3 cs2-e4-7-acld.auckland.clix.net.nz (203.97.9.98) 8.771 ms 9.305 ms 9.286 ms > 4 g1-0-927.u11.tspn.telstraclear.net (218.101.61.6) 11.422 ms 10.660 ms 10.282 ms > 5 xtra.ape.net.nz (192.203.154.60) 14.338 ms 10.610 ms 10.278 ms > 6 v512.XTRAK2-B1.xtra.co.nz (202.27.176.226) 11.048 ms 10.160 ms 10.023 ms We don't need no Interleaving We don't need no surf control No dark deals screwing VOIP Telcos, leave them bits alone Hey, Telcos! Leave them bits alone! All in all it's just another service to fall All in all, you're just a consumer that's going to get screwed by corporate greed and can't do a damn thing about it at all! (Apologies to Pink Floyd and for the number of syllables in the last line :-) N. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

5 4

RE: [nznog] FYI: Telecom changes the ADSL playing field again...
by Steve Schmidt 20 Oct '04

20 Oct '04

The question will be "Free" for how much longer? I have heard rumors that Citylink may have some new tricks up their sleeve (free to comment, open for blasting) to try and maintain free peering exchanges but it will ultimately come down to all the "other" isp's ensuring that they continue to peer at the exchanges. (note: MCI/Voyager just completing their own peering hub and peering arrangements are now being "reviewed") TCNZ are reviewing. TCL have already made their intentions clear. (pardon the pun :-) -----Original Message----- From: Richard Patterson [mailto:richard(a)helix.net.nz] Sent: Thursday, 21 October 2004 10:28 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] FYI: Telecom changes the ADSL playing field again... J S Russell wrote: > >Doesn't this kinda defeat the whole point of having a seperate realm for >JSG, then? That full-speed business was the only thing that made it >interesting. If your connectivity to it is the same as your connectivity >to any other normally-peered (Hi TelstraClear!) New Zealand game server, >why bother maintaining it as a seperate realm you need to re-login to >access? It was worth the bother to re-login when it got you decent speeds, >but without them it's just a pain in the ass. You may as well just lift >the access lists and put allow access to these machines from the general >internet. Or is that what's happening anyway? I remember hearing something >recently about JSG going away. > > > > > Well it won't count to your usage cap. Your 10Gb Usage cap. Including NATIONAL Traffic National traffic thats delivered over the public peering exchanges. Thats ~free anyway. </rant> _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it.

9 19

RE: [nznog] FYI: Telecom changes the ADSL playing field again...
by Donald Neal 20 Oct '04

20 Oct '04

Subscribers to this list should by now be well aware that the Acceptable Use Policy begins "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." This does include, for example, discussion of the way QoS features are used in carrier-class networks. But ADSL-related threads on this list have a record of quickly becoming irrelevant to the list's purpose. Let's try and keep this on topic, please. - Donald Neal NZNOG list administrator Donald Neal |Presbyopia - inability to see what Technical Specialist | bishops are for. Operations Engineering | Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

1 0

FYI: Telecom changes the ADSL playing field again...
by Craig Humphrey 20 Oct '04

20 Oct '04

This just came up in the NZ ADSL list: http://www.telecom.co.nz/content/0,3900,204368-201502,00.html Many of you (who work for ISPs) are probably already aware of this, but here's a quick summary: 1. Telecom moving the rate-limiting to the DSLAM and implementing new backend QoS. 2. Telecom apparently (pointed out by an NZ ADSL user) introducing a further 30ms of latency to ADSL connections (presumably due to new QoS). 3. JetStream Games realm and Remote.Office connections will now be limited to connection plan speed (due to the limiting being done at the DSLAM). Yes, this will impact the usage of the jetstreamgames.co.nz and ftp.paradise.net.nz(?) game/linux/bsd mirrors. Note: this is just a mixture of my interpretation and info garnered from NZ ADSL. I/we could be completely wrong :) Later'ish Craig

9 8

Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by neil gardner 20 Oct '04

20 Oct '04

>>> Barry Murphy <barry(a)unix.co.nz> 21/10/2004 10:23:04 a.m. >>> >Telstra Clear already do this with their tempest service, if you purchase a >256k connection, check your router status and you'll see you are connected at >288k. They at least give 32k leaway. Not really - that 288k is 288k of ATM bandwidth... It translates (as best I can figure) to 31.32Kb/sec or 250.56kbits of real world transfer... So you're actually getting more than 256kbits of raw traffic, it's the TCP overheads that bring the number below 256. Cheers - Neil G (Reference : http://www.broadbandreports.com/information/kb/maximum+DSL+speeds/ATM) quoted below maximum DSL speeds Maximum DSL speed is a function of distance, the gauge (thinness) of the phone wire used in your locale, and the DSL technology employed. The fastest DSL now commonly available is ADSL, and it offers maximum download speeds of up to 7.1mbps and around 1.1m upload. Most residential ADSL is limited to 90-680k for download, depending on the Telco. SDSL currently has a max of 1.5mbps, but that is both up and down (symmetric). Other common rates are (in k bits per second) 640k/90k, 1600k/90k, 680k/680k for ADSL. Rule of thumb for converting speeds to something easier to understand: take the k bps, and divide by 10. This is the maximum transfer K per second you are ever likely to see in a browser download window. More accurately, divide by 8 and take off 13%, which is overhead from tcp/ip and, more importantly, ATM overhead. (DSL lines use ATM as an underlying data-transport protocol). Modems range from 2-5k a second, DSL lines from 10-500k a second, office computer interconnections are usually either (best case) 800k a second (10mbit) or 8000k a second (100mbit switched). NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by Michael Hallager 20 Oct '04

20 Oct '04

> This makes a lot of sense, though, technically. Why connect the user at > 8Mbits/sec down and churn out a boatload of RF bollocks from the copper, > when they're only buying a 256Kbits/sec "broadband" connection? May as > well make it 256Kbits/sec right at the start. This will probably enhance > overall network stability somewhat. It does lead automatically to point 3, > however... Good point. Here I have to use two micro filters in series to have a useable phone. (On the ADSL line). Anyone else have this experience? Michael Hallager

1 0

RE: [nznog] FYI: Telecom changes the ADSL playing field again...
by Regan Murphy 20 Oct '04

20 Oct '04

>From: Juha Saarinen [mailto:juha(a)saarinen.org] >Sent: Thursday, 21 October 2004 9:39 a.m. > >What's so badly b0rk3d about DSLAM rate-limiting >and the new QoS implementation that causes latency >to jump like that? Anyone know? "QoS also provides mechanisms for the network to control the delay characteristics (both latency and jitter) of high-priority traffic. Together, prioritization and delay control enable the transmission of real-time voice and video streams." The key word there is "control" (not "reduce" or "limit"). Maybe the latency is applied by design rather than being a fault of the DSLAMs. -- Regan

1 0

Re: Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by Jonny Martin 20 Oct '04

20 Oct '04

> What's so badly b0rk3d about DSLAM rate-limiting and the new QoS > implementation that causes latency to jump like that? Anyone know? If they're dropping the DSL line rate down to plan speed then your bits will take longer to wander to the exchange. It makes quite a significant difference when moving from 8 odd Mbit/s down to 256kbit/s downstream. Can't really take jibes at Telecom for this. If they are taking this approach, then the slower line rates will also mean less RF inteference in the cable binders, which means more robust [albeit slow and piddly] DSL connections. This is how most, if not all, providers work in Australia. Cheers, Jonny.

1 0

RE: Voyager changing AS number
by Booker, Chris 19 Oct '04

19 Oct '04

Hi, Notification that AS4740 Voyager will change to AS703 (MCI Asia Pac) on Thursday 21/10/2004 at 05.30. I am writing to you as the contact point for peering between your AS and our legacy AS 4740 (Voyager) at the Auckland Peering Exchange. If you are not the best contact for peering in your organisation I would appreciate it if you could pass this e-mail on to the right person. MCI acquired Voyager some time ago and we have recently built a new hub in Auckland. We are migrating our peering links to the new site. As part of the move we would like to change the AS on our side to AS703. Our routing policy with respect to your AS will remain the same - we will treat you as a national peer. We will advertise our New Zealand prefixes to you and we will advertise your prefixes to our New Zealand customers. Our peering committee is currently reviewing our peering arrangements in New Zealand and you may hear from a member of our engineering team in the future with regards to that review. Our proposed date time for migration is this Thursday at 0500 New Zealand time. The only change required at your end should be for you to change the remote AS from 4740 to 703. Our IP address will remain the same. I'd appreciate it if you could contact me to let me know if this works for you. Thanks for your time. Regards Christopher Booker Implementation Engineering MCI Australia Email <mailto:chris.booker(a)au.mci.com> chris.booker(a)au.mci.com Tel: + 61 2 9434 5967 Fax: + 61 2 9434 5970

1 0

Invitation to Cisco ISP Update Seminar
by Arron Scott 19 Oct '04

19 Oct '04

Hi all I have asked the List owner for his opinion on whether this may be construed as sales content, so I hope this does not find dis-favour with anyone. Cisco has our primary ISP Consulting Engineer for Australia/New Zealand in Auckland next week, and would be please to invite any ISP staff to attend the following Product Update and Technology Seminar. Attendance is at no cost, and morning tea is included. Please RSVP to browns(a)cisco.com if you would like to attend. ISP's Technology Update Dear All Cisco systems is pleased to invite you a ISP Technology Update Date: Wednesday 27th October Time: 9am to 12.00 Location: Level 16, ASB Building , 135 Albert Street, Auckland During this update we will cover; . IOS software enhancements . 7301 and 7206 NPE-G1. . 10K with PRE-2. . BRAS and LNS Platform update . New RADIUS functionality . Policy management and integration . SSG enhancements . Netflow developments . Core routing update . CRS-1 and IOS-XR . 12000 update RSVP: browns(a)cisco.com We look forward to your participation Arron Scott (CCIE #4099) Phone: +64(9)3551951 Systems Engineer Mobile: +64(21)883163 Cisco Systems New Zealand Ltd. Fax: +64(9)3584442 Level 25, 135 Albert St, Auckland eMail: ascott(a)cisco.com

1 0

SPF Records
by Craig Whitmore 19 Oct '04

19 Oct '04

Hi folks. We have noticed a number of domains in NZ have entered in their NS's domain.co.nz IN TXT "v=spf1 mx -all" This means domain.co.nz will never attempt to send emails at all. (but valid emails are trying to be sent). I've talked to a couple of domain holders who had this and they've fixed them but most said it was done ages ago and they where playing and never expected it to catch on (but it has a lot looking at the number) We (Orcon) have started to use SPF (for testing inbound email) and found it helps with identifying spam. _ALOT_ of people have published valid SPF records. Thanks Craig Whitmore Orcon Internet

11 14

Re: [nznog] SPF Records
by Ewen McNeill 18 Oct '04

18 Oct '04

In message <200410190425.i9J4PvGX007457(a)mailserv.waikato.ac.nz>, "Barry Murphy" writes: >I've wanted to setup SPF in the past but have always wondered what happens >when you have a roaming user sending via paradise for example. The best solution for roaming users is (SASL authenticated) relaying via a central mail server that is listed with SPF. Most commonly used mail clients (and some mail servers) will do SASL authentication these days, and many MTAs can be configured to do SALS authenticated mail relaying. Pushing mail through a central mail server like this is also useful if you are doing other processing on that mail server (eg, statistics, storing copies of messages, etc). >Would one need to know every internet facing ip for all ISP's mailservers? SPF also allows for "include" options, so that you can include (by reference) the SPF records published by the ISPs that are being used. You could, eg, "include" the SPF records of all ISPs used by roaming users. It'd be looser than ideal, but still much better than nothing. If that still isn't sufficient (eg, you have roaming users doing direct-to-remote-server SMTP), you could perhaps list all those ISP dialup subnets (in CIDR fashion). Again this is not ideal, but narrowing it down to a few /22s or even /20s compared with "the whole internet" is still an improvement. With some combination of these it should be possible to list a "much better than nothing" SPF record and then focus on tidying things up so it can be tighter (perhaps eventually down to just "v=spf1 mx -all"). More details at the SPF wizard: http://spf.pobox.com/wizard.html?mydomain=example.com Ewen

1 0

RE: [nznog] Mailwasher and its Forged Bounces
by neil gardner 18 Oct '04

18 Oct '04

Longtime listener, first time poster (on this topic anyway) _IF_ it's possible to reliably (and easily) identify the MailWasher bounces, why not just use that to identify customers using it, and block them from your mail server for a while (Hell, even disable their account perhaps) BUT, and this is the important bit, Send an email to the MW developers telling them that as an ISP you are blocking customers that use their software in this way. Suggest that users of their software will find their Intarwebthingy disabled. Sure the developers may not like taking out neat features, but they probably won't like fielding calls from users who get their net killed because of their product either. Cheers - N. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

3 2

Mailwasher and its Forged Bounces
by Lennon - Orcon 18 Oct '04

18 Oct '04

I've been looking lately and a "large" number of double bounces to postermaster are caused by people who use "MailWashers" to Bounce Spam. I rmember the days when I could read every message to postmaster(a)isp.co.nz They are quite easy to spot as they all have the format of: mail.local: unknown name: username 550 username(a)domain.co.nz ... User unknown Coming from MAILER-DAEMON(a)domain.co.nz (usually the ISP's one) (and forging the email (which I presume is against all ISP's T&C) In mailwashers FAQ it says: ------- Do the spammers know I am bouncing email? No, spammers do not know you are bouncing messages. Bounced messages look just like a returned mail message you would receive if you sent an email to an incorrect address. --------- If I can tell if someone if using mailwasher.. why cannot the spammers? Even so I would think 99.9% of all emails bounced via this program don't get back to the spammers anyway (they don't use proper from addresses or use someone else's domain to send from (anyone in NZ using/looking at using SPF? to stop this type of thing) What I am trying to say (if not very well). What do people think of this feature of mailwasher. I've emailed the writer a few times for comments over the last few years and heard nothing from him. Have ISP's complained to uses using it? stopped people using it? or what? Thanks Craig Whitmore

12 19

Ihug Prefix list update
by Sainesh Singh 17 Oct '04

17 Oct '04

Please update domestic filters for Ihug. APE details: AS7657 192.203.154.36 192.203.154.37 Updated list can be found at: http://www.ihug.net/ihug-prefix-list and is included below. Cheers, Sainesh Singh Ihug Engineering ip prefix-list ihug-networks permit ip prefix-list ihug-networks description ihug peering prefix-list contact: noc(a)ihug.co.nz : Updated 2004-10-18 ip prefix-list ihug-networks permit 192.107.113.0/24 ip prefix-list ihug-networks permit 202.21.130.0/24 ip prefix-list ihug-networks permit 202.21.136.0/23 le 24 ip prefix-list ihug-networks permit 202.36.44.0/24 ip prefix-list ihug-networks permit 202.36.94.0/23 le 24 ip prefix-list ihug-networks permit 202.36.230.0/24 ip prefix-list ihug-networks permit 202.36.231.0/24 ip prefix-list ihug-networks permit 202.37.182.0/24 ip prefix-list ihug-networks permit 202.49.33.0/24 ip prefix-list ihug-networks permit 202.49.46.0/23 le 24 ip prefix-list ihug-networks permit 202.49.63.0/24 ip prefix-list ihug-networks permit 202.49.148.0/23 le 24 ip prefix-list ihug-networks permit 202.49.176.0/23 le 24 ip prefix-list ihug-networks permit 202.49.178.0/24 ip prefix-list ihug-networks permit 202.49.180.0/23 le 24 ip prefix-list ihug-networks permit 202.49.186.0/24 ip prefix-list ihug-networks permit 202.49.249.0/24 ip prefix-list ihug-networks permit 202.50.84.0/24 ip prefix-list ihug-networks permit 202.50.103.0/24 ip prefix-list ihug-networks permit 202.50.188.0/22 le 24 ip prefix-list ihug-networks permit 202.50.255.0/24 ip prefix-list ihug-networks permit 203.96.192.0/19 le 24 ip prefix-list ihug-networks permit 203.109.128.0/17 le 24 ip prefix-list ihug-networks permit 203.109.130.0/24 ip prefix-list ihug-networks permit 203.109.132.0/22 ip prefix-list ihug-networks permit 203.109.133.0/24 ip prefix-list ihug-networks permit 203.109.134.0/24 ip prefix-list ihug-networks permit 203.109.135.0/24 ip prefix-list ihug-networks permit 203.109.144.0/20 ip prefix-list ihug-networks permit 203.109.157.0/24 ip prefix-list ihug-networks permit 203.109.192.0/21 ip prefix-list ihug-networks permit 203.109.198.0/24 ip prefix-list ihug-networks permit 203.109.199.0/24 ip prefix-list ihug-networks permit 203.109.230.0/24 ip prefix-list ihug-networks permit 203.118.128.0/18 le 24 ip prefix-list ihug-networks permit 203.118.144.0/20 ip prefix-list ihug-networks permit 203.118.160.0/20 ip prefix-list ihug-networks permit 203.118.164.0/22 ip prefix-list ihug-networks permit 203.118.168.0/21 ip prefix-list ihug-networks permit 203.173.128.0/17 le 24 ip prefix-list ihug-networks permit 203.173.170.0/23 ip prefix-list ihug-networks permit 203.173.192.0/19 ip prefix-list ihug-networks permit 203.173.224.0/20 ip prefix-list ihug-networks permit 203.173.240.0/21 ip prefix-list ihug-networks permit 210.55.110.0/24 ip prefix-list ihug-networks permit 210.55.184.0/24 ip prefix-list ihug-networks permit 210.55.202.0/23 le 24 ip prefix-list ihug-networks permit 210.55.248.0/21 le 24

1 0

ACCC (Aus): Draft report on Internet Interconnection
by Simon Lyall 17 Oct '04

17 Oct '04

I havn't read it all yet but people may find it interesting. http://www.accc.gov.au/content/index.phtml/itemId/543536/ "The Australian Competition and Consumer Commission has issued a draft report seeking comment on whether internet interconnection arrangements should be subject to a two year period of monitoring..... " -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.

2 1

Updated monitoring pages from Team Cymru
by Rob Thomas 13 Oct '04

13 Oct '04

[ Apologies to those of you who receive this note in multiple forums. ] Hi, team. We are pleased to announce some updated monitoring, as well as some new monitoring, on our web site. This includes aesthetic fixes as well as increased visibility. Our DNS monitoring now has increased visibility as well as a new look and feel. Gone are the multiple pages for each zone, replaced with a single page that will have additional zones soon. You'll find it at the following URL. <http://www.cymru.com/DNS/dns.html> The times are DNS query response times, and the query responses are checked for correctness. Clicking on the query response time will bring you to a more detailed, graphical view of the query responses for the given pod and name server combination. We've updated our network monitoring to include several new components. This includes pod to pod ICMP, TCP, and UDP monitoring. It also includes traffic graphs for a select few Darknet pods, and our new Internet Garbage Meter. :) <http://www.cymru.com/Reach/index.html> For more on Darknets, from which our Darknet monitoring and Internet Garbage Meter are generated, please see our Darknet Project page at the following URL. <http://www.cymru.com/Darknet/> We hope you find this of use. Comments and suggestions are always welcome! Thanks! Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

Re: [nznog] ICONZ
by Michael Hallager 12 Oct '04

12 Oct '04

Their helpdesk has told me it is a BGP4 fault and it is at Orcon's end, which it appears is news to Orcon. > Call the helpdesk? Call the noc? Paths look fine to me in a traceroute from > both providers. Michael Hallager (SNIP)

2 1

Re: Re: [nznog] linux.jetstreamgames.co.nz
by Jonny Martin 12 Oct '04

12 Oct '04

> "WIX peers only" mirror, much like ftp.nz.debian.org? I notice the "your ISP > is broken" message is still broken: > Looks like peering with the APE route servers wont > actually fix it. "...MAY be able to fix this problem for you... at the APE OR the WIX" - doesn't seem to me that it's broken. Seems quite reasonable as a generic sorry-no-peering-at-the-appropriate-place-and-we're-not-paying-for-the-traffic message. Cheers, Jonny.

18 23

RE: [nznog] Windows Update Server Selection
by Craig Humphrey 12 Oct '04

12 Oct '04

We've worked with Akamai and the best I can ascertain is that it directs you to the "best" location, where best isn't always the physically nearest server, since it may not have the content you're after. I think it uses similar ideas to what some of the distributed p2p clients do. Get enough requests from a "region" and you move the content (or a copy of the content) closer to that region. But that's just my understanding. > -----Original Message----- > From: Craig Whitmore [mailto:lennon(a)orcon.net.nz] > Sent: Wednesday, October 13, 2004 1:24 PM > To: jon.brewer(a)araneo.net.nz > Cc: nznog(a)list.waikato.ac.nz > Subject: RE: [nznog] Windows Update Server Selection > > It is based on Akamai (where download.microsoft.com is > pointing). But for > some reason.. they seem to move it around ALL the time. Anyone from > Microsoft/Akamai comment/can find out WHY its switching > around all the time > (with us it changes every 20-30 mins.. NZ..Australia.. US.. > Australia....) > Instead of just going to the Akamai Servers in NZ > > Thanks > Craig Whitmore > Orcon Internet

1 0

An idea for discussion
by Michael Hallager 12 Oct '04

12 Oct '04

Hello all. Ever so often on NZNOG somebody posts a wanted or for sale message. I have just thought - would there be any interest in a seperate "marketplace" mailing list, to buy, sell, trade equipment specifically related to ISP's and networks? MTCW - Comments please. // Michael Hallager Director || Head geek || Making IT work. URL: http://www.networkstuff.co.nz networkStuff, NZ's leading online supplier of high quality new and used networking equipment. Phone: (09) 839-1000 (DDI) 0800 638-788 (Freecall) Fax: (09) 837-8100 0800 329-788 (Freefax) Mobile: 029 638-7883 (SMS, MMS and PXT supported)

4 4

ICONZ
by Michael Hallager 11 Oct '04

11 Oct '04

Hello all. Is anyone aware of any funkiness between Iconz and Orcon, somewhere around APE? Non APE paths work. APE paths don't. // Michael Hallager Director || Head geek || Making IT work. URL: http://www.networkstuff.co.nz networkStuff, NZ's leading online supplier of high quality new and used networking equipment. Phone: (09) 839-1000 (DDI) 0800 638-788 (Freecall) Fax: (09) 837-8100 0800 329-788 (Freefax) Mobile: 029 638-7883 (SMS, MMS and PXT supported)

4 3

Re: [nznog] Networkstuff promotion
by Michael Hallager 11 Oct '04

11 Oct '04

Repeat: NO ONE who got emailed today was added to any mailing list !! (Without requesting it). It was ONLY AN INVITATION to a small group of targetted people, who's email addresses were in my address book. Please people, with p-pills, mortgage applications, pirated MS software yada yada, why the need to take out your frustrations on a local known specialised e-commerce business? Despite having my email address all over the place, I receive maybe once a month only an unsolicited professional email offering me something relevant and I find many of these useful or I simply delete. I have publically apologised several times and still I get emails suggesting that I should "apologise". Could it be that this is way out of proportion? I am still sorry and disapointed that some people have taken this in an unintended way. Michael Hallager > Rather remove everyone you manually added to the mailing list and let them > find your website on their own, if they want to be added they will opt in. > > Barry > > -----Original Message----- > From: Michael Hallager [mailto:michael(a)networkstuff.co.nz] > Sent: Sunday, 10 October 2004 9:05 p.m. > To: nznog(a)list.waikato.ac.nz > Subject: [nznog] Networkstuff promotion > > Hello all. > > I have just gone through and added a few names to the no-contact list > although > only about 50% of the people posting so far in this subject so far were > ever > > emailed in the first place. At last count, about 5 or 6. > > The actions of some in threatening mail blocks and in continuing this on > NZNOG > has made it rather hard for me to asertain who would like to be added. > I have already discussed it with others, some who would rather keep > the pot boiling... for no obvious reason.... I have tried to sort this out > with as many people as possible. > > So I repeat - contact me directly with your details and it will happen. > > I sincerely apologise again to all who were offended. > > // Michael Hallager > Director || Head geek || Making IT work. > > URL: http://www.networkstuff.co.nz > networkStuff, NZ's leading online supplier of high quality new and used > networking equipment. > > Phone: (09) 839-1000 (DDI) 0800 638-788 (Freecall) > Fax: (09) 837-8100 0800 329-788 (Freefax) > Mobile: 029 638-7883 (SMS, MMS and PXT supported) > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog -- // Michael Hallager Director || Head geek || Making IT work. URL: http://www.networkstuff.co.nz networkStuff, NZ's leading online supplier of high quality new and used networking equipment. Phone: (09) 839-1000 (DDI) 0800 638-788 (Freecall) Fax: (09) 837-8100 0800 329-788 (Freefax) Mobile: 029 638-7883 (SMS, MMS and PXT supported)

7 12

Lucent Ascend & Telecom PR2
by Craig Spiers 11 Oct '04

11 Oct '04

Anyone know how to configure a telecom PR2 PRI on a lucent ascend ? Settings etc? Any funky things I should know? Cheers

1 0

RE: [nznog] Ameritrade.com smtp server issue
by Gordon Smith 11 Oct '04

11 Oct '04

Yeah, poor choice of terminology on my part perhaps. I was referring to the fact that a tier 1 provider was reachable via another tier 1 provider i.e. peered, so from the point of view of the endpoint traffic transits the first tier 1 to reach the second :-) Cheers, Gordon > -----Original Message----- > From: Hamish MacEwan [mailto:hamish.macewan(a)gmail.com] > Sent: Tuesday, 12 October 2004 11:45 a.m. > To: NZNOG(a)list.waikato.ac.nz > Subject: Re: [nznog] Ameritrade.com smtp server issue > > And because they don't need transit, they are top tier. It > is after all a self-fulfilling and self-referring definition. > > Hamish. > > On Mon, 11 Oct 2004 18:42:04 -0400, Joe Abley <jabley(a)isc.org> wrote: > > > > They are peers. It's because the top-tier operators peer that they > > don't need transit. > > > > > > Joe >

1 0

RE: [nznog] Sprintlink outage yesterday
by Tom Hibbert 11 Oct '04

11 Oct '04

By contrast 3 of our clients on Virtual ISP couldn't send a single packet past core2a.iconz.net.nz until at least 3pm... Oh well, there was nothing anyone could have done about a crashed router. Noone at ICONZ could have got things back on track any faster unless they teleported to the endpoint and hit reset themselves. Kudos to John J and Iconz NOC for their failover setup, its more than most ISPs I know can/will do. -----Original Message----- From: Jonathan Brewer [mailto:jon.brewer(a)worldnet.att.net] Sent: Tuesday, 12 October 2004 9:43 a.m. To: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] Sprintlink outage yesterday Folks, We were very impressed with the way ICONZ failed over from SprintLink to Global Gateway without significant disruption. We did receive a number of calls from our customers on ICONZ upstream, but all were to do with a lack of performance rather than a lack of connectivity. Cheers, Jonathan Brewer -----Original Message----- From: Tom Hibbert [mailto:tom(a)nsp.co.nz] Sent: Tuesday, 12 October 2004 9:01 a.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Sprintlink outage yesterday Hi all Seems like some of us were stung by a major outage affecting at least Iconz' upstream yesterday, but probably others were affected also. One of our largest customers - a power line service contractor covering 3/5 of the country - was severely stung by the routing issue yesterday as Contact Energy deliver their job notices through a mail sanitization house in the United States, who were attempting to route back through to New Zealand but were unable to do so. Fortunately Contact were contacted (pun unintentional) by their provider in the states who arranged a resolution by bouncing the mail off one of our boxes here. Thanks to them the outage as far as it affected Joe Public at his home and business was only about 2 hours... So what the hell happened? Obviously the problem was with the endpoint in the USA and therefore outside of anyone in NZ's responsibility... Tom Hibbert Technical Specialist Phone: +64-9-306-0230 Technical Helpdesk: +64-9-306-0234 Mobile: +64-274-307-784 Email: tom(a)nsp.co.nz Website: http://www.nsp.co.nz The information in this email and any attachments is confidential. This information may be subject to legal, professional, or other privilege. It must not be disclosed to any person without our authority. If you are not the intended recipient you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. Please return this message to the sender immediately and delete any and all copies from your system. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Sprintlink outage yesterday
by Tom Hibbert 11 Oct '04

11 Oct '04

Hi all Seems like some of us were stung by a major outage affecting at least Iconz' upstream yesterday, but probably others were affected also. One of our largest customers - a power line service contractor covering 3/5 of the country - was severely stung by the routing issue yesterday as Contact Energy deliver their job notices through a mail sanitization house in the United States, who were attempting to route back through to New Zealand but were unable to do so. Fortunately Contact were contacted (pun unintentional) by their provider in the states who arranged a resolution by bouncing the mail off one of our boxes here. Thanks to them the outage as far as it affected Joe Public at his home and business was only about 2 hours... So what the hell happened? Obviously the problem was with the endpoint in the USA and therefore outside of anyone in NZ's responsibility... Tom Hibbert Technical Specialist Phone: +64-9-306-0230 Technical Helpdesk: +64-9-306-0234 Mobile: +64-274-307-784 Email: tom(a)nsp.co.nz Website: http://www.nsp.co.nz The information in this email and any attachments is confidential. This information may be subject to legal, professional, or other privilege. It must not be disclosed to any person without our authority. If you are not the intended recipient you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. Please return this message to the sender immediately and delete any and all copies from your system.

5 5