- NZNOG - lists.nznog.org

RE: [nznog] NZ IP-Range
by James J. Guidera 29 Jun '05

29 Jun '05

Thanks for the script Paul, might have look into the software and IP2location for the windows based machines, and script for linux. James ________________________________ From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Thursday, 30 June 2005 9:30 a.m. To: James J. Guidera; NZNOG(a)list.waikato.ac.nz Subject: Re: [nznog] NZ IP-Range I got this script from Paul of linuxsystems, grabs the APNIC IP database and compiles a list of NZ ip ranges: #!/usr/local/bin/php <?php $in_file = "ftp://ftp.apnic.net/pub/apnic/dbase/data/country-ipv4.lst"; // $in_file = "country-ipv4.lst"; $out_file = "nzipranges.txt"; $handle_input = @fopen($in_file,"r") or die("Unable to open $in_file\n\n"); $handle_output = fopen($out_file, "w"); $now = date ("r"); fwrite ($handle_output,"# Generated: $now\n\n"); while (!feof($handle_input)) { $buffer = fgets($handle_input); if ( ereg ( "nz", $buffer) ) { // echo $buffer; $this_range = trim(preg_replace ( "#([\d\.]+) \- [\d\.]+ : [\d\.]+(\/\d+) .+#","$1$2", $buffer )); fwrite ($handle_output,"\n" . $this_range); } } fclose($handle_input); fwrite ($handle_output,"\n"); fclose($handle_output); ?> ----- Original Message ----- From: James J. Guidera <mailto:james(a)miracle.co.nz> To: NZNOG(a)list.waikato.ac.nz Sent: Thursday, June 30, 2005 9:00 AM Subject: [nznog] NZ IP-Range Just a quick question, Is there a singular complete list of NZ ip range?? I am wanting to allow only NZ traffic access to servers. Thanks James Guidera Systems Engineer Miracle Electronics Ltd Ph:+64-4-385-1293 Cel: +64-21-705-614 ________________________________ _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

RE: [nznog] NZ IP-Range
by Mark Karena 29 Jun '05

29 Jun '05

Not sure if there is a single list within the community but there are places that sell IP<-> location software that pulls info from APNIC, ARIN etc. Here is one place. http://www.ip2location.com/?AfID=23224 HTH, ------------------------------------------- Mark Karena Administrator ENLIGHTEN HOSTING (07) 853 6060 (021) 141 3792 _____ From: James J. Guidera [mailto:james(a)miracle.co.nz] Sent: Thursday, 30 June 2005 9:00 a.m. To: NZNOG(a)list.waikato.ac.nz Subject: [nznog] NZ IP-Range Just a quick question, Is there a singular complete list of NZ ip range?? I am wanting to allow only NZ traffic access to servers. Thanks James Guidera Systems Engineer Miracle Electronics Ltd Ph:+64-4-385-1293 Cel: +64-21-705-614

1 0

Re: [nznog] Technical Announcement
by Webmaster 28 Jun '05

28 Jun '05

>>> Barry Murphy <barry(a)unix.co.nz> 06/29/05 2:38 PM >>> > For providers not connected to the peering exchanges > will the content be delivered from the USA? Yes, at the 'standard' rate of 16 or 24 kbs. This rate is on a par with other Public Broadcasters. Peering ISPs get higher rates from the local servers. > This would mean those providers will only get the USA > content and wont be allowed to hear the copyright audio? NZ Restricted audio, actually. We use the exchange infrastructure to limit the distribution of some content. At the start there won't be any NZ restricted content (apart from Enzology). We expect demand for the service to be quite high, and don't want to have to sort between help desk calls from consumers who's ISPs do not peer and people who have a genuine problem. R.

3 2

RE: [nznog] Technical Announcement
by Regan Murphy 28 Jun '05

28 Jun '05

>>For providers not connected to the peering exchanges such as telecom and telstra The way I see it is that while these two providers are connected to the one or more exchanges, its just that they don't openly peer with everybody at the exchanges. Therefore they may choose to peer directly with radionz at one of these exchanges thus enabling the content to be provided to their subscribers. -- Regan -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Wednesday, 29 June 2005 2:38 p.m. To: Webmaster; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Technical Announcement Hi, For providers not connected to the peering exchanges such as telecom and telstra, will the content be delivered from the USA? I'm guessing this is the case so you don't have to purchase domestic links from those providers. This would mean those providers will only get the USA content and wont be allowed to hear the copyright audio? Thanks Barry P.S. www.ispmap.co.nz is backup and running people, sorry the hardware died and took a while to replace. ----- Original Message ----- From: "Webmaster" <Webmaster(a)radionz.co.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Wednesday, June 29, 2005 2:24 PM Subject: [nznog] Technical Announcement > Hi, > > Radio New Zealand has recently installed content servers at the > Auckland (APE), Wellington (WIX), and Palmerston North (PNIX) internet > exchanges. We also have a server located in California, USA to serve > content to New Zealanders overseas. > > These servers have been deployed within the R2 infrastructure and will > be used for the soon-to-be-launched on-demand and simulcast audio > service. > There will be a range of on-demand content from programmes broadcast > on both networks, and we are hoping to provide live streams of > National Radio and Concert FM (subject to resolving some outstanding > copyright issues). When the service commences we expect about 60 hours > of new content to be available each week. The servers will also be > used by Radio NZ International for their on-demand and simulcast audio. > > All streams will initially be 16 kbs maximum, and this may increase to > 24 kbs once we have a handle on traffic flows. Everyone will be able > to access content at this rate. > > We have chosen to deploy a multi-homed architecture for the following > reasons: > 1. Greater diversity and redundancy than a single site/provider > architecture. > 2. Reduced network latency for improved streaming performance. > 3. Shortest path for broadband consumers (reducing network congestion > for Operators). > 4. Scalability, allowing us to add servers at new exchanges in the > future. > 5. To minimise national transit costs for the ISP's of customers using > the content. > 6. Lowest cost to serve content. > > The servers have a globally consistent anycast IP address which will > be advertised at each exchange to ensure that the content is delivered > from the nearest server to the consumer. > > As new exchanges are installed throughout the country we intend to > deploy content servers at them, subject to certain minimum criteria > being met. This also includes MUSH style networks outlined in the NZ > Government's Digital Strategy. > > In order to get the best performance we recommend that you peer > directly with the anycast routers at all the exchanges where you have > connectivity. > > For those who wish to peer locally an enhanced service is available > from the NZ exchange-based content servers. Maximum data rates will > increase to 32 or 48 kbs for on-demand content and 48 or 64 kbs for > live streams. The live simulcasts (when available) will be available > in stereo at these rates. > > Where content is limited to NZ for copyright reasons there will be no > international route, meaning customers of non-peering ISPs will not be > able to access the content. This is currently the case with the > Enzology series (www.radionz.co.nz/enzology/) > > Please contact our peering coordinator at peering(a)radionz.co.nz if you > need to establish a peering session with our content servers. > > We will be maintaining a list of peers and a help page on our new > website so that consumers can be informed about how to access the > enhanced service. > > Operators may expect increased help desk activity due to their > customers not being able to access NZ restricted content, or asking > for access to the enhanced service. > > We are publishing our intentions to this list in advance of the launch > so that Operators can prepare for what we expect will be a very > popular service with the 686,000 people who listen each week to > National Radio and Concert FM. > > We expect to go live in 2-3 weeks. > > > regards, > > > Richard Hulse > New Media Manager > Radio New Zealand > > _______________________________________________ > 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

1 0

Technical Announcement
by Webmaster 28 Jun '05

28 Jun '05

Hi, Radio New Zealand has recently installed content servers at the Auckland (APE), Wellington (WIX), and Palmerston North (PNIX) internet exchanges. We also have a server located in California, USA to serve content to New Zealanders overseas. These servers have been deployed within the R2 infrastructure and will be used for the soon-to-be-launched on-demand and simulcast audio service. There will be a range of on-demand content from programmes broadcast on both networks, and we are hoping to provide live streams of National Radio and Concert FM (subject to resolving some outstanding copyright issues). When the service commences we expect about 60 hours of new content to be available each week. The servers will also be used by Radio NZ International for their on-demand and simulcast audio. All streams will initially be 16 kbs maximum, and this may increase to 24 kbs once we have a handle on traffic flows. Everyone will be able to access content at this rate. We have chosen to deploy a multi-homed architecture for the following reasons: 1. Greater diversity and redundancy than a single site/provider architecture. 2. Reduced network latency for improved streaming performance. 3. Shortest path for broadband consumers (reducing network congestion for Operators). 4. Scalability, allowing us to add servers at new exchanges in the future. 5. To minimise national transit costs for the ISP's of customers using the content. 6. Lowest cost to serve content. The servers have a globally consistent anycast IP address which will be advertised at each exchange to ensure that the content is delivered from the nearest server to the consumer. As new exchanges are installed throughout the country we intend to deploy content servers at them, subject to certain minimum criteria being met. This also includes MUSH style networks outlined in the NZ Government's Digital Strategy. In order to get the best performance we recommend that you peer directly with the anycast routers at all the exchanges where you have connectivity. For those who wish to peer locally an enhanced service is available from the NZ exchange-based content servers. Maximum data rates will increase to 32 or 48 kbs for on-demand content and 48 or 64 kbs for live streams. The live simulcasts (when available) will be available in stereo at these rates. Where content is limited to NZ for copyright reasons there will be no international route, meaning customers of non-peering ISPs will not be able to access the content. This is currently the case with the Enzology series (www.radionz.co.nz/enzology/) Please contact our peering coordinator at peering(a)radionz.co.nz if you need to establish a peering session with our content servers. We will be maintaining a list of peers and a help page on our new website so that consumers can be informed about how to access the enhanced service. Operators may expect increased help desk activity due to their customers not being able to access NZ restricted content, or asking for access to the enhanced service. We are publishing our intentions to this list in advance of the launch so that Operators can prepare for what we expect will be a very popular service with the 686,000 people who listen each week to National Radio and Concert FM. We expect to go live in 2-3 weeks. regards, Richard Hulse New Media Manager Radio New Zealand

2 1

Telstra Problems
by Lyndon 27 Jun '05

27 Jun '05

I took a traceroute this morning as Telstra were fixing the issue, it was indeed interesting. First 3 hops are removed (my firewall, local router and next hop). I am connected by Cable Modem. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * 20 ms 20 ms ge-0-2-0-1.xcore1.acld.telstraclear.net [203.98.50.251] 8 153 ms 153 ms 154 ms so.jb.wils.telstraclear.net [203.98.42.66] 9 155 ms 156 ms 154 ms GigabitEthernet3-0.GW1.LAX1.ALTER.NET [157.130.245.21] 10 148 ms 147 ms 147 ms 0.so-0-0-0.XL1.LAX1.ALTER.NET [152.63.112.218] 11 156 ms 157 ms 154 ms 0.so-1-1-0.XL1.LAX7.ALTER.NET [152.63.57.78] 12 154 ms 153 ms 155 ms 0.so-6-0-0.BR1.LAX7.ALTER.NET [152.63.112.41] 13 148 ms 148 ms 146 ms so-2-0-0.gar1.LosAngeles1.Level3.net [209.0.227.37] 14 148 ms 149 ms 146 ms so-0-1-0.bbr2.LosAngeles1.Level3.net [4.68.96.89] 15 167 ms 169 ms 168 ms as-2-0.bbr2.SanJose1.Level3.net [4.68.128.157] 16 167 ms 168 ms 168 ms ae-23-54.car3.SanJose1.Level3.net [4.68.123.109] 17 217 ms 213 ms 213 ms unknown.Level3.net [64.152.102.58] 18 205 ms 207 ms 205 ms po3-0.gw1.akl1.asianetcom.net [202.147.55.213] 19 206 ms 204 ms 204 ms ip-202-147-45-74.asianetcom.net [202.147.45.74] 20 206 ms 205 ms 206 ms 203-109-156-100.ihug.net [203.109.156.100] 21 206 ms 204 ms 205 ms oldresolver3.ihug.co.nz [202.36.94.1] Cheers L

1 0

RE: [nznog] TelstraClear/ICONZ Fault (IHUG as well?)
by Simon Allard 27 Jun '05

27 Jun '05

There was earlier, we had to shut down our BGP session to TCL because of some weirdness in the BGP advertisements from TCL. It has been resolved now and the BGP session was brought back up. > -----Original Message----- > From: Tony Wicks [mailto:nzog(a)road.gen.nz] > Sent: Tuesday, 28 June 2005 9:55 a.m. > To: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] TelstraClear/ICONZ Fault (IHUG as well?) > > No issues to Ihug via TCL Auckland. > > > [root(a)fire root]# traceroute ihug.co.nz > traceroute to ihug.co.nz (203.109.252.75), 30 hops max, 38 byte packets > 1 router2 (203.97.9.132) 0.982 ms 1.136 ms 0.993 ms > 2 203.97.85.221 (203.97.85.221) 25.973 ms 27.754 ms 25.487 ms > 3 ge9-0-954.u11.pnr.telstraclear.net (218.101.61.41) 25.982 ms > 30.724 ms 30.487 ms > 4 g1-0-927.u11.tspn.telstraclear.net (218.101.61.6) 27.482 ms > 30.195 ms 29.486 ms > 5 g1-926.u12.brh.telstraclear.net (218.101.61.35) 26.982 ms 27.230 > ms 26.486 ms > 6 lnk1-ihug-ge-1-0-1642.u12.telstraclear.net (203.98.18.162) 28.482 > ms 30.234 ms 25.486 ms > 7 203-109-156-97.ihug.net (203.109.156.97) 35.982 ms 36.202 ms > 45.986 ms > 8 ihug.co.nz (203.109.252.75) 26.974 ms 28.200 ms 25.985 ms > [root(a)fire root]# > Simon wrote: > > Michael Bordignon wrote: > > > >>> Since then we have about 55% packet loss, with ICONZ as at 12:05 > >> > >> > >> saying that they have not been given an ETA by TelstraClear. > >> > >>> 12 hours of substandard performance with no ETA seems a bit poor to > >> > >> > >> me. > >> > >>> If anyone has any updates on this please feel free to let me know. > >> > >> > >> > >> Same here - unusable. > > > > > > I am possibly seeing the same problem here? we are on tesltraclear DSL > > and cant get to any of IHUG's network... Anyone seeing this same issue > > this morning? Other major ISP's are fine. > > > > _______________________________________________ > > 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

1 0

RE: [nznog] TelstraClear/ICONZ Fault
by Michael Bordignon 27 Jun '05

27 Jun '05

> Since then we have about 55% packet loss, with ICONZ as at 12:05 saying that they have not been given an ETA by TelstraClear. > 12 hours of substandard performance with no ETA seems a bit poor to me. > If anyone has any updates on this please feel free to let me know. Same here - unusable. Michael

5 5

RE: [nznog] Trademe problems ?
by Jay Rama 27 Jun '05

27 Jun '05

Hi Simon, Telstra/Paradise are currently having some DNS issues, there is a quickfix in place, but I believe problems still persist... Regards, Jay ________________________________ From: Simon Byrnand [mailto:simon(a)igrin.co.nz] Sent: Tue 28/06/2005 9:19 a.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Trademe problems ? Hi All, Anyone else seeing problems getting to trademe this morning ? Seems to die somewhere between global gateway and telstraclear... Regards, Simon _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Trademe problems ?
by Simon Byrnand 27 Jun '05

27 Jun '05

Hi All, Anyone else seeing problems getting to trademe this morning ? Seems to die somewhere between global gateway and telstraclear... Regards, Simon

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 26 Jun '05

26 Jun '05

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 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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS24324 descr: Route set advertised to AS9560 by BCL - AS24324 members: 202.49.128.0/24^24-29, 202.49.135.0/24^24-29, 202.49.133.0/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: sainesh.singh(a)bclnz.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050610 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Broadcast Communications Ltd - AS24324 members: 202.49.128.0/21^21-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: sainesh.singh(a)bclnz.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050627 source: NZRR

1 0

APNIC Updates @ Telstra
by Jonathan Brewer 26 Jun '05

26 Jun '05

Hi Folks, Would someone at Telstra capable of performing updates to Telstra-managed AS9436 please contact me off-list? Thanks, Jonathan Brewer

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 23 Jun '05

23 Jun '05

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 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. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64609 descr: advertised to AS9439 by WIXanycast - AS64609 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 20050228 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64609 descr: advertised to AS9439 by WIXanycast - AS64609 members: 202.7.6.0/23^23-29, 202.7.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: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050624 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 198.32.71.0/24^24-29, 202.7.5.0/24^24-29, 202.7.6.0/24^24-29, 203.118.144.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050621 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.7.6.0/23^23-29, 198.32.71.0/24^24-29, 202.7.5.0/24^24-29, 203.118.144.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: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050624 source: NZRR

1 0

TelstraClear/ICONZ Fault
by Chris Woodrow 22 Jun '05

22 Jun '05

Apparently TelstraClear made some 'changes' to the primary ICONZ WGTN-AUCK circuit around midnight last night. Since then we have about 55% packet loss, with ICONZ as at 12:05 saying that they have not been given an ETA by TelstraClear. 12 hours of substandard performance with no ETA seems a bit poor to me. If anyone has any updates on this please feel free to let me know. Regards Chris Woodrow BDT

1 0

Re: [nznog] Anyone awake at Ihug NOC/Security?
by Mark Foster 21 Jun '05

21 Jun '05

Glen Wilson wrote: *snip* > I enquired about your email today and was told that you had lodged a fault > regarding smtp relay attempts in which the offending ip was not an Ihug > ip and the issue was dropped. It was also brought to my attention > that in a follow up email from you to the abuse mailbox stated the > following,... > > "If I don't get some sort of acknowledgement of my reports soon I will > start dropping ihug IP ranges at the highest supernet I can see... " Unfortunately you're taking my frustration and desire-to-get-SOME-sort-of-response out of context, and its a shame you did this on NZNOG. I don't make a habit of misreporting complaints, and i'm wary of the fact that as an end user (at least in the capacity I was reporting this particular abuse case in) I don't exactly have any 'clout'. So I was simply reporting a fact - that my frustration level was such that i'd rather add all of ihug to my RBL than deal with the ongoing virus payload that was (apparently) being ignored. I have sent another response offlist but I felt the need to make it clear that I am not a cry-wolf type and am familiar with the concepts of dns lookup and whois. ;-) Good luck to those at ihug with the thankless task of clearing that backlog! Mark.

5 4

RE: [nznog] Anyone awake at Ihug NOC/Security?
by Blair Robson 21 Jun '05

21 Jun '05

It was just a suggestion, that email was a few days old and none of you guys had responded (obviously cos it was sorted) - I was just trying to help. >> All your comments are just rumour and speculation. Yeah, absolutely I don't _know_ anything and I said that. Again just a suggestion. _b -----Original Message----- From: Simon Allard [mailto:simona(a)staff.iinet.net.au] Sent: Wednesday, 22 June 2005 9:23 a.m. To: Blair Robson; nznog(a)list.waikato.ac.nz Subject: RE: [nznog] Anyone awake at Ihug NOC/Security? Blair. Please don't comment on ihug matters which you know nothing about. All your comments are just rumour and speculation. None of the senior type jobs have gone. Yes some have left for other jobs, but they have all been replaced with new staff. abuse(a)iinet.net.au has no visibility into the ihug NZ network, so they will be no help to you. abuse(a)ihug.co.nz is the correct email to use. For the record, Mark was contacted minutes after his email and his problem was sorted. Cheers Simon Allard IHUG Security Monkey > -----Original Message----- > From: Blair Robson [mailto:blair.robson(a)ihug.co.nz] > Sent: Wednesday, 22 June 2005 2:52 a.m. > To: jon.brewer(a)att.net; 'Mark Foster'; nznog(a)list.waikato.ac.nz > Subject: RE: [nznog] Anyone awake at Ihug NOC/Security? > > Seriously - try abuse(a)iinet.net.au , explain that you have tried > contacting > abuse(a)ihug.co.nz (I assume you have?) > I don't know weather that will work or not, but I do know that nearly all > the senior people at Ihug in NZ are gone..And I think you will find Simon > no > longer works for Ihug. > As far as I can gather everything is being run or in the process of being > run from Perth now. > > Blair > > -----Original Message----- > From: jon.brewer(a)att.net [mailto:jon.brewer(a)att.net] > Sent: Tuesday, 21 June 2005 3:25 p.m. > To: Blair Robson; 'Mark Foster'; nznog(a)list.waikato.ac.nz > Subject: RE: [nznog] Anyone awake at Ihug NOC/Security? > > We too need a reply from Ihug security, and have unanswered mail in to > noc(a)ihug.net - address from Simon Lyall's NOC Contact List. Is there a > better address? > > To air some dirty laundry, 203-173-155-220.bliink.ihug.co.nz has generated > 30 GB of http traffic in the past month for one of our customers - > repeatedly downloading one file. (2400 times at last count) Our customer > would rather like it to stop. > > JB > > -------------- Original message from "Blair Robson" > <blair.robson(a)ihug.co.nz>: -------------- > > > > abuse(a)iinet ? > > > > > > > > -----Original Message----- > > From: Mark Foster [mailto:blakjak(a)blakjak.net] > > Sent: Wednesday, 15 June 2005 5:05 p.m. > > To: nznog(a)list.waikato.ac.nz > > Subject: [nznog] Anyone awake at Ihug NOC/Security? > > > > Repeat emails over the last week or two to abuse@ and noc@ havn't had > any > > sort of response or acknowledgement - can someone from Ihug NOC or > > security please contact me offlist. > > > > Thanks > > Mark. > > > > _______________________________________________ > > 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 > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Re: [nznog] Anyone awake at Ihug NOC/Security?
by Glen Wilson 21 Jun '05

21 Jun '05

Glen Wilson Network Operations Manager Ihug Ltd, Auckland, New Zealand www.ihug.co.nz On Wed, 22 Jun 2005, Glen Wilson wrote: > > Again I clarify that noc(a)ihug and abuse(a)ihug remain the appropriate > channels. The mailbox is currently backlogged by several weeks, for the > benefit of the list if there are any urgent issues please feel free to > raise them with me directly (off list) for adequate responce. > > Your points are valid, but as the abuse autoresponder states, not all > emails warrent a reply. > > I can assure you that the matter was looked into and recommendations > were made to the responsible parties to improve the process. > > Abuse emails are treated seriously, however genuine cases of abuse are > dealt with faster than complaints of portscans, relay attempts and > blackice alarm logs. > > I enquired about your email today and was told that you had lodged a fault > regarding smtp relay attempts in which the offending ip was not an Ihug > ip and the issue was dropped. It was also brought to my attention > that in a follow up email from you to the abuse mailbox stated the > following,... > > "If I don't get some sort of acknowledgement of my reports soon I will > start dropping ihug IP ranges at the highest supernet I can see... " > > I recognise that current response times to abuse emails is somewhat > lacking but may I presume to recommend a more professional approach in > future Mark. > > Further comments should be off list. > > Regards > > Glen Wilson > Network Operations Manager > Ihug Ltd, Auckland, New Zealand > www.ihug.co.nz > > On Wed, 22 Jun 2005, Mark Foster wrote: > > > Glen - > > I dare say that instead of 'habitual abuse emailer' you might call me > > 'someone who's not willing to simply ignore situations for which ISPs > > and end users should actually be responsible'. > > > > And in case you missed what I stated in my original email, I had tried > > both addresses. Repeatedly. Over WEEKS. > > > > Further I suggest that the 'I'm having the same problem too' format of > > responses to my post to NZNOG might imply that maybe you need to examine > > your own internal processes before you decide to get snarky on a public > > mailing list. > > > > If Ihug abuse team actually acknowledged complaints and committed to > > actioning them within a specific timeframe - as many ISPs do - I would > > not have felt the need to post to NZNOG - which was an act of desparation. > > > > I've been responsible for the abuse@ mailboxes for 3 different ISPs in > > the past and funnily enough, each of those ISPs took abuse reports > > seriously. Nomatter how much they might have wanted to killfile reports > > from particularly frequent reporters. :-) > > > > So I hope you have a great day, Glen. :-) > > > > Mark. > > > > PS: In case anyone hasn't registered it, Simon Lyall's NOC Contact List > > at http://www.usenet.net.nz/noc is pretty damn useful. Most of the time. > > :) [And isn't related to Simons past employment with Ihug.] > > > > Glen Wilson wrote: > > > > > noc(a)ihug.co.nz or abuse(a)ihug.co.nz. > > > > > > As a habitual abuse emailer, Mark Foster knows the appropriate channels. > > > > > > > > > Glen Wilson > > > Network Operations Manager > > > Ihug Ltd, Auckland, New Zealand > > > www.ihug.co.nz > > > > > > On Wed, 22 Jun 2005, Blair Robson wrote: > > > > > > > > >>Seriously - try abuse(a)iinet.net.au , explain that you have tried contacting > > >>abuse(a)ihug.co.nz (I assume you have?) > > >>I don't know weather that will work or not, but I do know that nearly all > > >>the senior people at Ihug in NZ are gone..And I think you will find Simon no > > >>longer works for Ihug. > > >>As far as I can gather everything is being run or in the process of being > > >>run from Perth now. > > >> > > >>Blair > > >> > > >>-----Original Message----- > > >>From: jon.brewer(a)att.net [mailto:jon.brewer(a)att.net] > > >>Sent: Tuesday, 21 June 2005 3:25 p.m. > > >>To: Blair Robson; 'Mark Foster'; nznog(a)list.waikato.ac.nz > > >>Subject: RE: [nznog] Anyone awake at Ihug NOC/Security? > > >> > > >>We too need a reply from Ihug security, and have unanswered mail in to > > >>noc(a)ihug.net - address from Simon Lyall's NOC Contact List. Is there a > > >>better address? > > >> > > >>To air some dirty laundry, 203-173-155-220.bliink.ihug.co.nz has generated > > >>30 GB of http traffic in the past month for one of our customers - > > >>repeatedly downloading one file. (2400 times at last count) Our customer > > >>would rather like it to stop. > > >

2 1

RE: [nznog] Anyone awake at Ihug NOC/Security?
by Blair Robson 21 Jun '05

21 Jun '05

Seriously - try abuse(a)iinet.net.au , explain that you have tried contacting abuse(a)ihug.co.nz (I assume you have?) I don't know weather that will work or not, but I do know that nearly all the senior people at Ihug in NZ are gone..And I think you will find Simon no longer works for Ihug. As far as I can gather everything is being run or in the process of being run from Perth now. Blair -----Original Message----- From: jon.brewer(a)att.net [mailto:jon.brewer(a)att.net] Sent: Tuesday, 21 June 2005 3:25 p.m. To: Blair Robson; 'Mark Foster'; nznog(a)list.waikato.ac.nz Subject: RE: [nznog] Anyone awake at Ihug NOC/Security? We too need a reply from Ihug security, and have unanswered mail in to noc(a)ihug.net - address from Simon Lyall's NOC Contact List. Is there a better address? To air some dirty laundry, 203-173-155-220.bliink.ihug.co.nz has generated 30 GB of http traffic in the past month for one of our customers - repeatedly downloading one file. (2400 times at last count) Our customer would rather like it to stop. JB -------------- Original message from "Blair Robson" <blair.robson(a)ihug.co.nz>: -------------- > abuse(a)iinet ? > > > > -----Original Message----- > From: Mark Foster [mailto:blakjak(a)blakjak.net] > Sent: Wednesday, 15 June 2005 5:05 p.m. > To: nznog(a)list.waikato.ac.nz > Subject: [nznog] Anyone awake at Ihug NOC/Security? > > Repeat emails over the last week or two to abuse@ and noc@ havn't had any > sort of response or acknowledgement - can someone from Ihug NOC or > security please contact me offlist. > > Thanks > Mark. > > _______________________________________________ > 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

7 6

RE: [nznog] Help with configuring router
by Lesley Walker 21 Jun '05

21 Jun '05

As you were. I found out what my problem was. Sorry for the distraction, I no longer need help. > I need some help with setting up a borrowed Network iQ 1000 series > router. (Also labelled securicor 3net if that helps) Lesley

1 0

PS: RE: [nznog] Help with configuring router
by Lesley Walker 21 Jun '05

21 Jun '05

> Replies off-list, please. Or phone me or Rob on this number: > Phone 64 4 384 4153 Thanks in anticipation. Lesley

1 0

Help with configuring router
by Lesley Walker 21 Jun '05

21 Jun '05

I need some help with setting up a borrowed Network iQ 1000 series router. (Also labelled securicor 3net if that helps) I have got as far as connecting to the serial port, watching it boot up and produce the login prompt, then it doesn't seem to respond to input, and hangs my Hyperterm (sorry!) session. I'm told the config has been set back to factory defaults, but the person who loaned it to me is in the middle of a crisis and can't help me set it up. If anyone could spare a few minutes to point me in the right direction I would be very grateful. I have all the config info I need, I just can't talk to it. (This is a temporary replacement for a very dodgy router that's providing our internet connection, and quite urgent) Replies off-list, please. Lesley Walker Datamine Limited - turning numbers into people 103 Ghuznee Street PO Box 11-452 Wellington, New Zealand Phone 64 4 384 4153 http://www.datamine.co.nz

1 0

Re: Paradise MX , was: [nznog] Anyone awake at Ihug NOC/Security?
by Ewen McNeill 21 Jun '05

21 Jun '05

In message <Pine.LNX.4.56.0506221253110.2350(a)green.darkmere.gen.nz>, Simon Lyall writes: >Does anyone know why pop3.paradise.net.nz doesn't seem to listen on port >25? [1] I wouldn't normally mind but it is listed as the primamry MX for >the domain. > >[1] - Since Monday at least, might be a lot longer. It's been like that for a year.[0] The response I got when I reported it said "We have permanently blocked SMTP requests to pop3.paradise.net.nz.". After some discussion, and me suggesting some more sensible approaches to route their mail,[1] they eventually said: "Despite how our mail system may look to the outside world it is functioning in a manner that we require at this particular stage of development." >From where I sit it still looks fairly clueless to firewall your primary MX off from the world. But I concluded then that I would be best served by excluding the instances of "failed connection to pop3.paradise.net.nz" from my log reports and forgetting about it. If you're able to get hold of someone clueful at Paradise and get them to fix it, I'll be grateful too.[2] Ewen [0] I know this because I found the auto-response to my ticket reporting the problem, and it's dated 21 June 2004. [1] Eg, modern mailers mail forwarding from their preferred MX to pop3.paradise.net.nz when appropriate, split DNs, etc. [2] The wellylug mailing list I host has several @paradise.net.nz addresses subscribed to it, so I get instances of this in my log pretty much daily.

1 0

IANA IPv4 allocations and bogon updates: 74/8, 75/8, 76/8, 189/8, 190/8
by Rob Thomas 21 Jun '05

21 Jun '05

-----BEGIN PGP SIGNED MESSAGE----- [ Apologies to those of you who receive this note in multiple forums. ] Hi, all. The numerous Team Cymru bogon projects have been updated as of 17 JUN 2005 to reflect the following IANA allocation made on 17 JUN 2005: 074/8 Jun 05 ARIN (whois.arin.net) 075/8 Jun 05 ARIN (whois.arin.net) 076/8 Jun 05 ARIN (whois.arin.net) 189/8 Jun 05 LACNIC (whois.lacnic.net) 190/8 Jun 05 LACNIC (whois.lacnic.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-template.htm> Secure JUNOS BGP Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter- Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Bogus ASN monitoring - <http://www.cymru.com/BGP/asnbogusrep.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thank you for your continued support. Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQrjLPlkX3QAo5sgJAQFHwAP/Z8KrLp9id6PD51KNEjAlveJCxRnvP4ev RofqRMex1SB5itogkB4O6JmrpSqIjqgM2GsnAUREZr5/r2ekdAZwejT85zHftl92 3ExvEec3P2PVDdfWF5v9TSVWfzwwbMW2HWwymzUYT7klWpjblcUUPdAWl+khD+FU /C8cCA2b8qk= =JvMq -----END PGP SIGNATURE-----

1 0

Thanks to TelstraClear for providing service during the major outage on Monday
by Adrian Smith 21 Jun '05

21 Jun '05

The National Library of New Zealand would like to thank TelstraClear New Zealand for providing a quick alternate National and International Internet service to us by setting up a BGP routing/Peering connection over our existing CityLink Network connections to bypass the major Telecom network outage on Monday. Our organisation was back up on the Internet several hours before the Telecom Network failure was restored. Due to the nature of Mondays Telecom Network failure we lost both our primary and backup Internet connections at 10:49am, leaving only our CityLink connection working, and peering with the CityLink WIX route servers, which still provided some 300 routes to us. After an hour of not being able to get any news on the cause and duration of the Telecom outage we approached one of TelstraClear's Internet BGP routing wizards and asked how can we route past this problem, he advised us to talk to their wholesale people. After explaining the situation to wholesale, authorisation was given to one of their Internet BGP routing wizard's to make it happen. Within a short time BGP Peering was set-up and implemented over the phone, and our full National and International Internet service was fully restored over CityLink to TelstraClear. We do not have any sort of contract with TelstraClear. The point here is that although TelstraClear stopped peering at WIX :( they are still connected to the CityLink Network :) and still connect to customers over it. We would not have had this option open to us if we were not already connected and using the CityLink Network and CityLink's Neutral Peering Exchange. http://www.citylink.co.nz/community/peering.html So Thanks to TelstraClear for providing a temporary Internet pipe with no notice; and Thanks also to the CityLink team /NGI/MORST Advanced Network for running some Internet BGP routing courses last week. The information was put into action on our router to bypass Monday's problem. http://www.ngi.org.nz/ http://www.morst.govt.nz/?CHANNEL=IT+INFRASTRUCTURE&PAGE=IT+Infrastructure The recently released Government Digital Strategy http://www.digitalstrategy.govt.nz/ encourages co-operation and collaboration in as many ways possible between all New Zealand people, and organisations both Government and private sector. When the many technical people on this NZNOG list receive this email, please take it to your leaders and explain the many benefits of Internet Peering at Neutral Internet Peering Exchanges to create a fully meshed, distributed Internet for New Zealand. Digital Strategy Launch http://www.r2.co.nz/20050516/ recording from Parliament. When the big one hits New Zealand and we have a full-scale major civil defence emergency it will be far too late for the very capable technical people in each of the organisations to implement Internet peering. They will not be able to use the phone networks due to outages and overloading, and the current New Zealand Internet will fail because peering was not put in place and working. It is in the interest of every single New Zealander that every New Zealand Telco, ISP and organisation connects their networks to the nearest Neutral Internet Peering Exchange and starts peering; and helps to create a real New Zealand Internet. The original Internet was designed for this very reason for the US Defence Department to prevent a total failure of communications during major infrastructure outages and emergencies. There would also be benefits for the Telco's and ISP's if this peering was already in place before the Telecom outage on Monday. It may have been a non-event, when both fibres were cut, the Telecom network could have re-routed traffic around the damage over TelstraClear's equally capable backbone network. Even if Telecom had to pay TelstraClear for the temporary transit traffic, it would have probably been a far less cost to pay both financially and politically. And the major disruptions caused to a lot of people waiting at airports, unable to use EFTPOS networks etc. may have been avoided, and Telecom customers would still have trust in them to provide Internetworking services. This would also work in reverse should such an event hit TelstraClear's network. So come on New Zealanders, please get the important message and do something about this situation today. Without realising it, you may save lives in the future because the NZ Internet does not break, just because a couple of fibre optic cables get cut by accident or equally by a natural disaster event. To all journalists on this list, please feel free to put this full message in as many papers, magazines and web sites as possible. With a further message to encourage every New Zealander who reads it, to email their ISP and request that their ISP set-up Internet Peering at a Neutral Internet Peering Exchange to create a robust New Zealand Internet. Come on Kiwi's, lets just do it. Adrian Smith, Network Specialist, National Library of New Zealand >>> Michael Newbery <Michael.Newbery(a)team.telstraclear.co.nz> 20/06/2005 17:26:36 >>> At 5:01 PM +1200 20/6/05, Andy Linton wrote: >So is this a good time to ask about the design of a network that concentrates >so much of its core service in Auckland? Is TelstraClear's network design any >better? I'd like to think so. :) For a start, it takes more than two fibre cuts in the North Island to disrupt us (that's new since you fled Andy :) Currently the core network is distributed and I prefer to follow that mantra whenever possible, though sometimes resources are naturally 'clumpy' (is that a word?) -- Michael Newbery IP Architect TelstraClear Limited Tel: +64-4-920 3102 Mobile: +64-29-920 3102 Fax: +64-4-920 3361 _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Outage update from Telecom
by Juha Saarinen 20 Jun '05

20 Jun '05

This is what they're telling us at the moment: ---------------------------------------------------------------------- Telecom technicians have identified the two locations where the North Island Telecom network has today been damaged and are working to repair them. It is anticipated that a patch will be in place by late this afternoon, enabling the restoration of services. A large number of mobile, Internet and other data services have been affected. In addition, many voice calls on fixed lines are congested. The outage has been affecting customers since late this morning. Telecom is working to repair the outage as soon as possible. Telecom regrets the inconvenience to customers and will provide more information throughout the day. The outage, which occurred at 10.48am today, was caused by physical damage to the network on both the east and west coast sections of the network. Technicians are currently working on repairing both the eastern fibre break which is in the Rimutaka area, and the western break in south Taranaki. The outage is affecting calls to Telecom’s own call centres, causing overloading. Telecom is asking customers to be patient. We will provide more information as soon as possible. For more information, please contact: Sarah Berry Media Relations Executive 04 498 9481 027 470 7900 Phil Love Senior Media Relations Executive 04 498 9155 027 277 8496 Melanie Marshall 04 498 9272 027 452 6231 John Goulter Public Affairs & Government Relations Manager 04 498 9369

15 24

Anyone awake at Ihug NOC/Security?
by Mark Foster 20 Jun '05

20 Jun '05

Repeat emails over the last week or two to abuse@ and noc@ havn't had any sort of response or acknowledgement - can someone from Ihug NOC or security please contact me offlist. Thanks Mark.

2 1

Re: [nznog] Outage update from Telecom
by Ewen McNeill 20 Jun '05

20 Jun '05

In message <Pine.LNX.4.56.0506201840470.8951(a)blue.darkmere.gen.nz>, Lin Nah writes: >http://y3m.net/files/audio/telecom.fault.interview-2005-06-20.mp3 >http://y3m.net/files/audio/telecom.fault.weldon-2005-06-20.mp3 Thanks for recording these and making them available. The spin of both appears to be that this was an unforseeable event, which is difficult to accept. Unlikely, perhaps, but not unforseeable (imagine one break, then look for single points of failure that are exposed by that break). The stock exchange in particular appears not to have done a particularly thorough single-points-of-failure analysis, or deliberately chosen not to attempt to eliminate some of them. For instance it appears that they have a single transit provider, a single firewall, etc -- the failure of any of which will take them "off the air". The same appears to be true of many other systems, some of which can probably not afford to eliminate all the single points of failure (eg, EFTPOS in a small business, even small business DSL), and some of which probably should (eg, aircraft control). It's also a reminder that as much as a provider may claim n-9s reliability for their network, at some level using a single provider for all traffic still represents a single point of failure for your own infrastructure, however unlikely it might seem. Another completely independent provider at least gives you a statistically less correlated set of risk; although ensuring it's completely independent can be non-trivial. Still, given a 99.999% guarentee, and 4.5 hours of downtime (10:48 through 16:18), that means it'll be 4.5 hours / (1/100000) / 24 / 365.25 = 51.3 years until the next outage.... >Let's not forget that TelstraClear and many other ISPs in NZ resell >Telecom (either wholesale or UBS). TCL has patches of their own network >(eg Chch and wgtn are two examples). However the last mile home for >majority of NZers is still Telecom. The "last mile" isn't so much of a problem providing that the single-provider portion really is issolated to the "last mile". If the handoff of each of those "last mile" connections is fairly local to the users, and there's redundant, independent, backhaul from there to the other infrastructure, then a "core network" failure in one provider need not necessarily take out all those users. If there's only a single handoff between the provider and the reseller then obviously it's much more vulnerable as now much larger portions of the providers network must remain operational for those end users to stay working. Hopefully a single-point-of-failure analysis will guide a design which allows as much of the network to remain functional as possible even in the face of several failures. Andy's points of multiple network exchanges, in multiple locations, is of course one good mitigating strategy. Finally it's a reminder that sometimes having the "redundant" part of your network down requires high priority attention; your systems might still be working, but if you're now only one failure away from a total failure it's not a situation you want to be in for long. (From what I heard the first break in Telecom's situation occured yesterday, and was still being worked on today. Not fatal in itself, but without that failure still being present the hungry backhoe wouldn't have caused as much chaos.) Ewen

2 1

[Fwd: Re: [nznog] Outage update from Telecom]
by Mark Foster 19 Jun '05

19 Jun '05

[meant to send to all of list, sorry... redirected:] > So is this a good time to ask about the design of a network that concentrates > so much of its core service in Auckland? Is TelstraClear's network design any > better? > > How many regional providers were unable to talk to others in the same region > because everything (?) is hauled back to Auckland? > Before you follow this train of thought too far - reverse it. For arguements sake: I'm in Auckland, able to talk to the rest of the world - but nowhere south of Palmy. So what about things hauled back to Wellington? ;-) So the bigger picture question should be 'how many providers have sufficient redundancy to provide services in both locations independent of eachother for any given period?' Obviously theres some outages you just can't protect yourself from - but backup plans and DR plans should incorporate other means of getting info from A to B. Corporates etc with multiple offices can't just be dependant on their PON or DSL. They need to be prepared to make a point-to-point dialup, or an ISP dialup at both ends, in order to be able to communicate critical data at least. (How many companies build their SME LAN's behind a DSL link but business grinds to a halt when they can't get their email because the local exchange had a DSL whoopsie? How hard is it to keep a pay-per-hour dialup plan with an alternate ISP?) Ok, upscale slightly. Corporates and PON with big VPN/WAN environments get more complex. But there are ways. GPRS, Mobile Jetstream? Dialup again, with a VPN client? How many businesses retain 'manual' procedures? Fax machines? Fax-over-Cellular? With ISPs its obviously a different can of worms, but the easiest thing to do is to have what essentially translates into two datacentres - or options on two physically diverse routes to your main datacentre from the other. I don't know if theres enough diversity of choice in the market to let the end usr dictate much of this? The other consideration is that for some businesses - and some scales of bandwidth requirement - its not economical, nor feasible, to have a fully disaster-tolerant network. But its interesting to see how we function when the manure hits the turbine, and to see how many people have actually thought it through that far. Mark.

1 0

RE: [nznog] Outage update from Telecom
by Gavin Legge 19 Jun '05

19 Jun '05

likewise. wgtn-acld frame ckt up and running. -----Original Message----- From: Craig Humphrey [mailto:Craig.Humphrey.Work(a)paradise.net.nz] Sent: Monday, 20 June 2005 3:50 p.m. To: 'NZNOG List' Subject: RE: [nznog] Outage update from Telecom We're back too. _____ From: Drew.Collins(a)apn.co.nz [mailto:Drew.Collins(a)apn.co.nz] Sent: Monday, June 20, 2005 3:24 PM To: Juha Saarinen Cc: NZNOG List Subject: Re: [nznog] Outage update from Telecom We have some of our links coming back up at the moment. So hopefully TNZ has fixed some of the problems. -- This message has been scanned for viruses and dangerous content by <http://www.mailscanner.info/> MailScanner, and is believed to be clean. MailScanner thanks transtec <http://www.transtec.co.uk/> Computers for their support. Supplied by ITS-HelpDesk. ext 4001 helpdesk(a)irl.cri.nz

5 4

RE: [nznog] Outage update from Telecom
by Gavin Legge 19 Jun '05

19 Jun '05

Well - ok. Thought it may be helpful.. I'll drop it. - back to lurking. -----Original Message----- From: James Tyson [mailto:james(a)giantrobot.co.nz] Sent: Monday, 20 June 2005 4:31 p.m. To: nznog Subject: Re: [nznog] Outage update from Telecom Do we really need all the "me too"'s? --- James Tyson He's just this guy you know. http://helicopter.geek.nz/ _______________________________________________ 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. MailScanner thanks transtec Computers for their support. MailScanner Supplied by ITS-HelpDesk. ext 4001 or email helpdesk(a)irl.cri.nz--

1 0

RE: [nznog] Outage update from Telecom
by Gavin Legge 19 Jun '05

19 Jun '05

Our wgtn->chch link was fine as well.. I guess it was below the 'fibre cut's' ??? -----Original Message----- From: Dan Clark [mailto:dan(a)synaptic.net.nz] Sent: Monday, 20 June 2005 4:21 p.m. To: Craig Humphrey Cc: NZNOG(a)list.waikato.ac.nz Subject: Re: [nznog] Outage update from Telecom maybe you went out over microwave? what sort of latency did you experience? Craig Humphrey wrote: > POP, PON, NGN, TLA of the week... we're on it, and we're back. > > BTW we were told that the barer lines to the South Island were down, > but it turns out our Welly office never lost connectivity with our > Christchurch office... (though did experience increased packet loss) > > ------------------------------------------------------------------------ > *From:* James William Butler [mailto:muh47_6(a)hotmail.com] > *Sent:* Monday, June 20, 2005 4:07 PM > *To:* NZNOG(a)list.waikato.ac.nz > *Subject:* RE: [nznog] Outage update from Telecom > > Anyone on Telecom PON have their links up yet? > > > > > > James Butler > > NewJobz > > > > > ---------------------------------------------------------------------- > -- > > *From:* Craig Humphrey [mailto:Craig.Humphrey.Work(a)paradise.net.nz] > *Sent:* Monday, June 20, 2005 3:50 PM > *To:* 'NZNOG List' > *Subject:* RE: [nznog] Outage update from Telecom > > > > We're back too. > > > >----------------------------------------------------------------------- >- > >_______________________________________________ >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 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. MailScanner Supplied by ITS-HelpDesk. ext 4001 or email helpdesk(a)irl.cri.nz--

2 1

I think a rubber band just fell off.
by jamie.baddeley＠vpc.co.nz 19 Jun '05

19 Jun '05

any one else seeing a *large* number of Telecom NZ outages? FR/PON/DSL/Dial etc etc jamie

19 25

RE: [nznog] I think a rubber band just fell off.
by Philip D'Ath 19 Jun '05

19 Jun '05

In fact this was a clever move by Telecom to prevent there share price sliding with everyone wanting to sell up at the same time. :-) -----Original Message----- > "The fault, which happened around 10am, also crashed the New Zealand > Stock Exchange..." This is hyperbole, surely? I'd be fairly shocked if the NZSE internal systems themselves could be "crashed" by a fault in an external vendor. Access to the system from external points may be impacted, of course, but even then I'd have to do the Dance of Stupid[1] if the NZSE public and secure networks only used a single network provider for everything.

1 0

Fwd: UPDATE – OUTAGE ON TELECOM NETWORK
by Ian McDonald 19 Jun '05

19 Jun '05

---------- Forwarded message ---------- From: media(a)telecom-media.co.nz <media(a)telecom-media.co.nz> Date: 20-Jun-2005 13:19 Subject: UPDATE – OUTAGE ON TELECOM NETWORK To: imcdnzl(a)gmail.com UPDATE – OUTAGE ON TELECOM NETWORK Telecom technicians have identified the two locations where the North Island Telecom network has today been damaged and are working to repair them. It is anticipated that a patch will be in place by late this afternoon, enabling the restoration of services. A large number of mobile, Internet and other data services have been affected. In addition, many voice calls on fixed lines are congested. The outage has been affecting customers since late this morning. Telecom is working to repair the outage as soon as possible. Telecom regrets the inconvenience to customers and will provide more information throughout the day. The outage, which occurred at 10.48am today, was caused by physical damage to the network on both the east and west coast sections of the network. Technicians are currently working on repairing both the eastern fibre break which is in the Rimutaka area, and the western break in south Taranaki. The outage is affecting calls to Telecom's own call centres, causing overloading. Telecom is asking customers to be patient. We will provide more information as soon as possible. For more information, please contact: Sarah Berry Media Relations Executive 04 498 9481 027 470 7900 Phil Love Senior Media Relations Executive 04 498 9155 027 277 8496 Melanie Marshall 04 498 9272 027 452 6231 John Goulter Public Affairs & Government Relations Manager 04 498 9369 This message was sent to you because your email address is on the Telecom media releases mailing list. To be removed from this mailing list please visit http://www.telecom-media.co.nz/lists/?id=869&e=im IMPORTANT: Security is limited with current Internet email technology. If you have doubts about the contents or source of this message, please verify that this release comes from Telecom New Zealand by checking the Telecom website at: http://www.telecom-media.co.nz/releases.asp

1 0

Telecom has it as well
by Russell Sharpe 19 Jun '05

19 Jun '05

http://www.telecom-media.co.nz/releases_detail.asp?id=3190 <http://www.telecom-media.co.nz/releases_detail.asp?id=3190&page=index> &page=index

1 0

Fwd: SIGNIFICANT OUTAGE ON TELECOM NETWORK
by Ian McDonald 19 Jun '05

19 Jun '05

Official statement from Telecom.... ---------- Forwarded message ---------- From: media(a)telecom-media.co.nz <media(a)telecom-media.co.nz> Date: 20-Jun-2005 12:35 Subject: SIGNIFICANT OUTAGE ON TELECOM NETWORK To: imcdnzl(a)gmail.com SIGNIFICANT OUTAGE ON TELECOM NETWORK An outage on the Telecom network has been affecting a large number of customers since late this morning. Telecom is working to repair the outage as soon as possible. Telecom regrets the inconvenience to customers and will provide more information as soon as possible. The outage, which occurred at 10.48am today, has been caused by two separate incidents affecting different parts of the network. Internet, mobile and landline calls are affected. Technicians are currently working on repairing one of the fibre breaks which is in the Rimutaka area. Once it has been repaired the majority of services will be restored. Technicians are investigating the other fault and will repair it as soon as possible. The outage is affecting calls to Telecom's own call centres, causing overloading. Telecom is asking customers to be patient. We will provide more information as soon as possible. For more information, please contact: Sarah Berry Media Relations Executive 04 498 9481 027 470 7900 Phil Love Senior Media Relations Executive 04 498 9155 027 277 8496 Melanie Marshall 04 498 9272 027 452 6231 John Goulter Public Affairs & Government Relations Manager 04 498 9369 027 232 4303 This message was sent to you because your email address is on the Telecom media releases mailing list. To be removed from this mailing list please visit http://www.telecom-media.co.nz/lists/?id=869&e=im IMPORTANT: Security is limited with current Internet email technology. If you have doubts about the contents or source of this message, please verify that this release comes from Telecom New Zealand by checking the Telecom website at: http://www.telecom-media.co.nz/releases.asp

1 0

RE: [nznog] I think a rubber band just fell off.
by Peter Thompson 19 Jun '05

19 Jun '05

According to a tech that someone in our NMC spoke to, the problem is with a RAN at Mayoral drive in Auckland CBD. Pete -----Original Message----- From: Simon Blake [mailto:simon(a)citylink.co.nz] Sent: Monday, 20 June 2005 11:24 a.m. To: jamie.baddeley(a)vpc.co.nz Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] I think a rubber band just fell off. They appear to have fallen off Citylink in Wgtn as well. Anybody from Telecom got an ETA? Cheers Si On Mon, Jun 20, 2005 at 11:15:05AM +1200, jamie.baddeley(a)vpc.co.nz said: > any one else seeing a *large* number of Telecom NZ outages? > > FR/PON/DSL/Dial etc etc > > > > jamie > > _______________________________________________ > 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

1 0

Help requested - Netscreen IP Sec VPN over DSL
by Felix Tsang 19 Jun '05

19 Jun '05

Can anyone please give me a pointer as to why I am having big problems with using a Safenet VPN client (conecting to) -> Netscreen VPN/FW appliance via Jetstart / UBS / Jetstream ? This is happening on multiple disassociated / unrelated networks. I am using mostly Dynalink RTA300 DSL Modems, and Netscreen 5XT / GT boxes. I believe it is something to do with the NZ DSL network as this type of VPN setup has worked well for over 1/2 years until it start to become more and more unreliable. Can anyone help or suggest a solution? Thanks for your time. Cheers Felix Tsang ULTRATECH Ltd Cell Phone: (64) 29 241 0185 Phone: (64 9) 309 8393 Fax: (64 9) 309 8393 Email: felix(a)ultratech.co.nz

2 2

RE: [nznog] I think a rubber band just fell off.
by Gavin Legge 19 Jun '05

19 Jun '05

Yeah - IRL just lost auckland FR. Wgtn/chch is still fine. -----Original Message----- From: jamie.baddeley(a)vpc.co.nz [mailto:jamie.baddeley(a)vpc.co.nz] Sent: Monday, 20 June 2005 11:15 a.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] I think a rubber band just fell off. any one else seeing a *large* number of Telecom NZ outages? FR/PON/DSL/Dial etc etc jamie _______________________________________________ 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. MailScanner thanks transtec Computers for their support. MailScanner Supplied by ITS-HelpDesk. ext 4001 or email helpdesk(a)irl.cri.nz--

2 1

RE: [nznog] Help requested - Netscreen IP Sec VPN over DSL
by Felix Tsang 19 Jun '05

19 Jun '05

Thanks Tracy, Yes the MTU size could very well be the issue. Just as of Friday, the VPN's came up again through no apprent reason. I have confirmed thru trial that the max MTU size I can put thru the DSL link is 1418 bytes. I'll just have to wait till the VPN's drop again to do the MTU test. Hopefully it'll point to something. Cheers -----Original Message----- From: Tracy Briscoe [mailto:tbriscoe(a)clear.net.nz] Sent: Friday, 17 June 2005 10:05 p.m. To: 'Felix Tsang' Subject: RE: [nznog] Help requested - Netscreen IP Sec VPN over DSL Hi Felix Have you looked at using the 'set flow tcp-mss' on the Netscreen? (http://www.qorbit.net/nn/Dec-2002/0254.html gives some details). We had the problem where a client could access their LAN ok via a dialup connection, but as soon as they started using mobile jetstream, things just broke. If I remember correctly set flow tcp-mss or set flow tcp-mss 1300 was the fix. The client has a Netscreen 5 with a Speed Touch Pro ADSL router, then is using Netscreen remote as the VPN client (Rebadged Safenet VPN client). -Tracy B

1 0

RE: [nznog] I think a rubber band just fell off.
by Simon Allard 19 Jun '05

19 Jun '05

Yea, we are. Lost a huge amount of UBS users and a lot of our SI pops. > -----Original Message----- > From: jamie.baddeley(a)vpc.co.nz [mailto:jamie.baddeley(a)vpc.co.nz] > Sent: Monday, 20 June 2005 11:15 a.m. > To: nznog(a)list.waikato.ac.nz > Subject: [nznog] I think a rubber band just fell off. > > any one else seeing a *large* number of Telecom NZ outages? > > FR/PON/DSL/Dial etc etc > > > > jamie > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

RE: [nznog] Help requested - Netscreen IP Sec VPN over DSL
by Philip D'Ath 19 Jun '05

19 Jun '05

I wear the other hat (use hardware VPN). We run large numbers of VPNs over DSL (Telecom and TelstraClear) and don't experience any issues. It wont be the hardware used in the Exchanges (baring a hardware issue, such as a bad port). Assuming your ISP is not running out of bandwidth, it wont be your ISP. Your first guess, the DSL router at the CPE end is the most likely culprit. If your using UDP encapsulation you may find it is deleting the NAT translations. If you have an option to turn on ISAKMP keep alives, try that. -----Original Message----- > Can anyone please give me a pointer as to why I am having big problems > with using a Safenet VPN client (conecting to) -> Netscreen VPN/FW appliance via > Jetstart / UBS / Jetstream ? This is happening on multiple disassociated / > unrelated networks. ... Its just barely possible that this also applies to the hardware used in the exchanges and ISPs.

1 0

Re: [nznog] Help requested - Netscreen IP Sec VPN over DSL
by neil gardner 19 Jun '05

19 Jun '05

I used to be Netscreen support for Renaissance NZ and while I saw a few strange issues I never saw a problem with IPSEC VPNs specifically over ADSL. Without knowing where the device in question was sourced from, I can't be totally specific, but assuming it was purchased through a NZ retailer / SI / Supplier, You should get in touch with them - and if you have no luck, phone Lan1 or Renaissance. Remember that the suppliers generally only provide support to resellers, but they both have some talented people that might help you out - I know both have operated some form of professional services department at some point. I'd echo Steve's general thoughts that it's more likely to be a router issue than an ADSL issue (unless you're trying to do something over PON or whatever Telecom call that now). Best of luck. N. Neil Gardner Product Manager - Product Line Management Allied Telesyn Research Ltd New Zealand +64 3 339-9509 (ph) +64 3 339-3001 (fax) >>> Steve Wray <stevew-lists(a)catalyst.net.nz> 20/06/2005 8:00 a.m. >>> Felix Tsang wrote: > Can anyone please give me a pointer as to why I am having big problems with > using a Safenet VPN client (conecting to) -> Netscreen VPN/FW appliance via > Jetstart / UBS / Jetstream ? This is happening on multiple disassociated / > unrelated networks. > > I am using mostly Dynalink RTA300 DSL Modems, and Netscreen 5XT / GT boxes. > I believe it is something to do with the NZ DSL network as this type of VPN > setup has worked well for over 1/2 years until it start to become more and > more unreliable. Can anyone help or suggest a solution? I've recently been doing some research trying to isolate a problem with a clients multiple Linux-based IPSec VPNs running through consumer-grade ADSL routers. (I would guess that your Safenet/Netscreen devices are using some form of IPSec VPN). My findings were unusual; the more recent the model of ADSL router used, the more unreliable the VPNs became when under load. For me, this was only the case when running multiple VPNs. Older model ADSL routers performed admirably (the Nokia M1122 was fantastic) while later model ADSL routers ranged from some models reliably crashing after 30 seconds of load to other models seeming ok on the bench but performing very badly in the field. Some brands actually got worse with more recent firmware upgrades or chipsets. Some googling revealed that there may be problems routing ESP traffic for multiple IPSec VPNs through cheaper, less well engineered ADSL routers. I am guessing that modern consumer grade ADSL routers fall into the "less well engineered than they used to be" category. Its just barely possible that this also applies to the hardware used in the exchanges and ISPs. Just a guess. For what its worth, we are moving away from IPSec to openvpn. Unfortunately, once you've bought into a hardware VPN solution, it becomes somewhat harder to make that sort of change... _______________________________________________ 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.

2 1

OT datacenter racks
by Barry Murphy 16 Jun '05

16 Jun '05

Hey guys, I know this is a bit off topic, but did I mention it's Friday and time to drink BEER! Can someone reply to me off list if they provide rack space (full racks) with swipe card access and layer 2 to APE in Auckland. I know maxnet does this and they the only ones I know about that have swipe cards, but their pricing is a bit up there so am looking for alternatives. Thanks Barry

1 0

Webcasting Update - UK Lions Rugby
by Richard Naylor 14 Jun '05

14 Jun '05

Wearing my R2.co.nz hat..... Several of the Radio stations that R2 carries, are doing live commentaries of the Rugby games involving the UK Lions. We are experiencing viewer/listener numbers roughly 3 times our usual "high-water" mark and are aware that the stations (and presumably ISPs) are getting some complaints about the streams buffering or not being accessible. The mid week games seem to produce the highest load, probably because TV3 isn't carrying delayed broadcasts of these matches, so radio is the only "free to air " option, other than Sky which isn't free of course.. International fans have no choice at all and the streams are their only source of live comentary As our servers are still somewhat under loaded (the streams are only 16kbps each) and many complaints are from overseas, we are making some changes over the next week in anticipation of the Test matches and likely audience numbers. We have for some months now been spreading load between WIX and APE connected servers. Today we have started altering our routing and will be directing all connection requests that are not from APE or WIX peers, to servers in the USA. Some traffic will still be available via our existing international bandwidth, but this seems to be the major congestion point. The USA servers are cheaper than increasing our bandwidth and also allows us to serve overseas clients more efficiently. We are talking in the 10,000s of clients - these are not small events. I'm sorry if Operators Help Desks have already been receiving calls of complaint. Peered Operators won't have noticed any effect. Non-peered Operators probably have. The introduction of the US servers, should reduce these calls, although you may see an increase in international traffic. It should be minor as each stream is quite small, but please take this as a warning - we are seeing high client numbers - much much higher than the LOTR Premiere (numerically we do a higher figure daily now). Peering at APE or WIX will of course reduce this international bandwidth. If Operators need help peering at APE or WIX, Andy at CityLink is happy to assist. Be aware the tests are getting closer...... If time allows we will commission a server at PNIX next week. Operators close to Palmerston North should consider peering there to save national bandwidth. These changes are pretty well permanent, although may be adjusted slightly or optimized. Later in the month there will be some more content released, which is expected to raise traffic levels even higher. These streams will not be small. Thanks for your time. Rich

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 09 Jun '05

09 Jun '05

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 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. --- OBJECT BELOW CREATED: aut-num: AS24324 as-name: NZRR-AS24324 descr: BCL descr: APE peering at '192.203.154.20' descr: see Citylink RT job #2568 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24324 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: sainesh.singh(a)bclnz.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050610 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS24324 descr: Route set advertised to AS9560 by BCL - AS24324 members: 202.49.128.0/24^24-29, 202.49.135.0/24^24-29, 202.49.133.0/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: sainesh.singh(a)bclnz.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050610 source: NZRR

1 0

random versus deterministic netflow sampling
by Rich Groves 07 Jun '05

07 Jun '05

Hello All: I wanted to ask what version of Netflow sampling the bulk of NZ networks employ today. If Netflow is not used is it due to its overhead on equipment and or its complexity to administer? Thanks Rich Groves WAND Research Group

2 1

TelstraClear 'transit' service
by Lincoln Reid 06 Jun '05

06 Jun '05

Hi, Many thanks for all the replies to my request for Microwave operators in Lower Hutt. Unfortunately the operator of the network we were having issues with remains a complete mystery, so we have changed polarity to resolve our issue. Secondly has anyone here requested TelstraClear's paid domestic peering product ( er transit, whatever ) delivered across Citylink in Wellington? I would be interested in hearing of your experience. It seems that due to a complete lack of rate limiting on their Citylink facing interface they are unwilling to deliver the capacity we have requested. If we were willing to buy 1000mbit of capacity ( or whatever their Citylink port runs at ) we could avoid this little problem for them =) Regards, -- Lincoln Reid Systems Engineer LinuxNet - AS18119 lincoln(a)linuxnet.co.nz Phone: +64 4 939 2200 Fax: +64 4 939 2201

1 0

New microwave kit in Lower Hutt
by Lincoln Reid 30 May '05

30 May '05

Hi, Could anyone who I haven't talked to yesterday who has installed any 5.8Ghz microwave equipment in the Lower Hutt CBD in the last week or so get in touch with either me or Daniel on our office number 04 9392200. Regards, -- Lincoln Reid Systems Engineer LinuxNet - AS18119 lincoln(a)linuxnet.co.nz Phone: +64 4 939 2200 Fax: +64 4 939 2201

1 0

Fw: [nznog] Computerworld Gupta story pulled?
by Paul_Brislen＠computerworld.co.nz 30 May '05

30 May '05

Hi All, Before conspiracy theorists start chiming in ... We've pulled the story because it was about matters before the youth court. The story was originally posted accidentally, which is why it's now been removed (at our decision, I should add). Computerworld, obviously, is more interested in technical and regulatory matters rather than the legal process now unfolding. I suspect this is also well off topic for NOG anyway. I do, however, feel the need for a beer Cheers, Paul

2 2

RE: [nznog] Computerworld Gupta story pulled?
by Donald Neal 30 May '05

30 May '05

________________________________ From: Paul_Brislen(a)computerworld.co.nz [mailto:Paul_Brislen(a)computerworld.co.nz] Sent: Tuesday, 31 May 2005 12:15 p.m. To: nznog(a)list.waikato.ac.nz Subject: Fw: [nznog] Computerworld Gupta story pulled? [...] We've pulled the story because it was about matters before the youth court. The story was originally posted accidentally, which is why it's now been removed (at our decision, I should add). Computerworld, obviously, is more interested in technical and regulatory matters rather than the legal process now unfolding. I suspect this is also well off topic for NOG anyway. IANAL, so I don't have an opinion on how much legal trouble people can get into by posting to this thread, but it is definitely off topic. - Donald Neal Donald Neal | "The way we do quality of Technical Specialist | service in the Internet Operations Engineering | today is don't drop Integration & Services Divn. | any packets." Alcatel NZ Ltd | - Barry Ravendran Greene "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

Computerworld Gupta story pulled?
by Simon Lyall 30 May '05

30 May '05

Did anyone get a copy of this before it was deleted? Searching for "sahil gupta charges" on google news brings the following: State throws the book at 027 hacker Computerworld New Zealand, New Zealand - 11 hours ago The National Enforcement Unit (NEU) of the Ministry of Economic Development has laid a further thirteen new charges against the teenager accused of breaking into Telecom's 027 voice mail system The teenager was arrested by the police with 19-year-old former ISP operator Sahil Gupta of Hamilton two weeks ago in conjunction with 027 hacking ... Computerworld understands the new charges are unrelated to the 027 affair, and are and are the result of prior activities by the teenager -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

3 2

How Si cleans up his backyard........
by Richard Naylor 30 May '05

30 May '05

Paste this URL into your media player...... mms://l1.r2.co.nz/20050530/tinakori.wmv

6 6

RE: [nznog] How Si cleans up his backyard........
by Allan Marsh 29 May '05

29 May '05

Noisy, no surely not....!!!! http://www.scoop.co.nz/stories/AK0504/S00066.htm ________________________________ From: Richard Naylor [mailto:richard.naylor(a)citylink.co.nz] Sent: Mon 30/05/2005 2:45 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] How Si cleans up his backyard........ At 02:23 PM 5/30/2005 +1200, Richard Naylor wrote: >Paste this URL into your media player...... > >mms://l1.r2.co.nz/20050530/tinakori.wmv Seems I touched a raw nerve....it appears the landing place of those logs is Andy's back yard.....and they operated all Saturday....and are quite err, noisy...... Seems to be quite a few folks with spare time - the server immediately picked up 10 viewers in that directory. And sorry to the folks with slower links - only did a 700k version. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog !DSPAM:429a7e95216801242621192!

1 0

Contractor needed in NZ
by Sam Sarkis 28 May '05

28 May '05

Hi All, Not sure if anyone would be interested but we have a need for a contractor for 1 month in NZ. This can be an Australian person that we fly over to NZ. The work is installing and configure Cisco Pix's and Cisco Wireless Access Points in around 20 locations. It is not difficult work but will require this person to have some experience with Cisco and will require you to have a drivers license. Must be able to work unsupervised and able to meet deadlines and complete the provided documentation. The pay will depend on the person. Please reply via email only off list if you are interested. Sam Sarkis United IP Director United IP Pty Ltd (Under new Management) Ph 61 2 8825 5586 Fax 61 2 8825 5577

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 25 May '05

25 May '05

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 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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.36.226.0/24^24-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.50.200.0/21^21-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.36.183.0/24^24-29, 202.27.208.0/24^24-29, 202.174.160.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050420 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.50.200.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.27.208.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050526 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 202.182.192.0/19^19-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.32.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.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: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050427 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 202.182.192.0/19^19-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 202.50.246.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.32.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.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: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050526 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 25 May '05

25 May '05

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 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. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.36.226.0/24^24-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.50.200.0/21^21-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.36.183.0/24^24-29, 202.27.208.0/24^24-29, 202.174.160.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050420 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.50.200.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.27.208.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050526 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 202.182.192.0/19^19-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.32.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.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: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050427 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 202.182.192.0/19^19-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 202.50.246.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.32.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.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: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050526 source: NZRR

1 0

Fwd: [Apnic-announce] APNIC New IPv6 address block(s)
by Nurani Nimpuno 24 May '05

24 May '05

Just fyi. Regards, Nurani Nimpuno APNIC Begin forwarded message: > From: John Tran <john(a)apnic.net> > Date: 24 May 2005 5:29:05 PM > To: apnic-announce(a)lists.apnic.net > Cc: apops(a)apops.net > Subject: [Apnic-announce] APNIC New IPv6 address block(s) > Reply-To: apnic-talk(a)apnic.net > > > Dear colleagues > > APNIC received the following IPv6 address block from IANA recently > and will be making allocations from this range in the near future. > > 2400:0000::/19 > > This announcement is being made for the information of the Internet > community, and so that network configurations such as routing filters > may be updated as appropriate. > > For more information on the resources administered by APNIC, see: > > http://www.apnic.net/db/ranges.html > > For information on the minimum allocation sizes within address ranges > administered by APNIC, see: > > http://www.apnic.net/db/min-alloc.html > > > Kind regards > > Son > > ____________________________________________________________________ > Resources Services Manager <Son(a)apnic.net> > Asia Pacific Network Information Centre phone: +61 7 3858 3100 > http://www.apnic.net fax: +61 7 3858 3199 > Helpdesk phone: +61 7 3858 3188 > email: helpdesk(a)apnic.net > Please send Internet Resource Requests to <hostmaster(a)apnic.net> > _____________________________________________________________________ > > _______________________________________________ > Apnic-announce mailing list > Apnic-announce(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-announce

1 0

Re: Jumbo Frames
by Richard Bateman 23 May '05

23 May '05

Hi All, Can anyone recommend a decent NZ available and low cost recommendation for an LNS that can take fast ethernet and, most importantly handle jumbo frames (MTU size > 1600)? Help would be greatfully received. Thanks, Richard

1 0

NGI International Connectivity
by Jonathan Brewer 22 May '05

22 May '05

Hi Folks, The international component of NGI is up for grabs. It would be great for New Zealand if as many capable ISPs as possible put in competitive bids. Due date for proposals is 7 June. While I cannot find the document on the MoRST site, it is available from GETS, ICN reference GM013391. >From the doc: "This document describes the requirements for the lease of managed international network services for the New Zealand Advanced Network. These requirements have been developed following a review of responses to an earlier request (April, 2005) by the Project for an International Connectivity Service The Project may also consider: . Offers for the purchase or lease of individual network components only. These may then be used by the Project to provide its own international network services. . Any alternative network solutions that offer improved cost, performance or other benefits. The Project welcomes innovative solutions or enhancements, including sponsored capacity for R+E purposes." Cheers, Jon

1 0

InternetNZ Governance Positions
by Keith Davidson 21 May '05

21 May '05

Pardon the slightly off topic intrusion all, InternetNZ is seeking applications from suitably qualified people for governance positions within the organisation. 3 members of the .nz Oversight Committee, and 2 directors of NZRS retire by rotation on 30 June 2005. All are eligible to re-stand for the positions. Full copies of the print advertisements and position descriptions can be found at www.internetnz.net.nz/vacancy/ Applications close Friday 3 June. There is no automatic entitlement to free beer (had to mention at least one word to avoid being completely off topic), but directors fees and honoraria are paid. Keith Davidson President - InternetNZ

1 0

FYI - Transfer of management
by Elly Tawhai 20 May '05

20 May '05

Hi, Following discussions between APNIC and NZTelecom, the following address ranges will be transfered from NZTelecom to APNIC's management from 1 July 2005: 202.27/16 202.37/16 202.36/16 202.49/16 202.50/16 As a result, a number of changes will come into effect for address space within these ranges. 1. Status To ensure that the management of this address space is consistent with other "swamp space" previously dealt with, the following business rule has been applied: Any range greater than /23 will be registered with the status "Allocated Portable" Any range of /23 or less will registered with the status "Assigned Portable" * Note, ranges with the status "Allocated Portable" are able to be sub-delegated to customers. 2. Mnt-by All maintainers referenced within the mnt-by attribute will be changed to APNIC-HM, as APNIC now protects all registrations of historical resources. For more information on this policy, please see section 4 of "Historical resource policies" at: http://www.apnic.net/docs/policy/historical-resource-policies.html#4 To ensure the integrity of information in the APNIC Whois Database, APNIC will not update historical information in the APNIC Whois Database until the resource holder: - establishes the organisation's right to the resources, and - enters a formal agreement with APNIC (either as a member or non-member account holder. If necessary, you can create a non-member account to manage your historical resources at: http://ftp.apnic.net/apnic/docs/historical-maintain-form Please note that APNIC non-members are subject to a US$100 annual account fee to cover APNIC's administrative costs. 3. Domain objects Domain objects of /24 have been created within APNIC whois database based on the zone data, which has been transfered. Please note, none of these changes will be made until 1 July 2005. If you have any further queries about how to make updates please do not hesitate to contact APNIC at <helpdesk(a)apnic.net>. Regards, APNIC Secretariat

3 2

Fw: [nznog] Police arrest two over 027 hack
by Dream Net Internet 19 May '05

19 May '05

----- Original Message ----- From: "Dream Net Internet" <sales(a)dreamnet.co.nz> To: "Barry Murphy" <barry(a)unix.co.nz> Sent: Friday, May 20, 2005 11:17 AM Subject: Re: [nznog] Police arrest two over 027 hack > for sure this problem should be solved so it is not possible or at least > not so damn easy. > > Anyone from Telecom got any comments? would be interested to know what is > going to be done about this. > > Regards > Adam Fenech > www.dreamnet.co.nz > 0800 484 393 > > WARNING This email contains information which is CONFIDENTIAL and may be > subject to LEGAL PRIVILEGE. If you are not the intended recipient you must > not peruse, use, disseminate, distribute or copy this email or > attachments. If you have received this in error please notify us > immediately by return email, 0800484393 and delete this email. Thank you. > ----- Original Message ----- > From: "Barry Murphy" <barry(a)unix.co.nz> > To: "Dream Net Internet" <sales(a)dreamnet.co.nz> > Sent: Friday, May 20, 2005 11:16 AM > Subject: Re: [nznog] Police arrest two over 027 hack > > >> The theory was already out there, I was just backing up that it does >> work, >> doesnt work on my 021 however. Proof of concept. >> >> This is a bug that should be rectified. >> >> Barry >> >> >> ----- Original Message ----- >> From: "Dream Net Internet" <sales(a)dreamnet.co.nz> >> To: "Barry Murphy" <barry(a)unix.co.nz>; "Simon Allard" >> <simon.allard(a)staff.ihug.co.nz>; <nznog(a)list.waikato.ac.nz> >> Sent: Friday, May 20, 2005 10:48 AM >> Subject: Re: [nznog] Police arrest two over 027 hack >> >> >>> thats not the greatest thing to post to a whole list :( >>> >>> Regards >>> Adam Fenech >>> www.dreamnet.co.nz >>> 0800 484 393 >>> >>> WARNING This email contains information which is CONFIDENTIAL and may be >>> subject to LEGAL PRIVILEGE. If you are not the intended recipient you >>> must >>> not peruse, use, disseminate, distribute or copy this email or >> attachments. >>> If you have received this in error please notify us immediately by >>> return >>> email, 0800484393 and delete this email. Thank you. >>> ----- Original Message ----- >>> From: "Barry Murphy" <barry(a)unix.co.nz> >>> To: "Simon Allard" <simon.allard(a)staff.ihug.co.nz>; >>> <nznog(a)list.waikato.ac.nz> >>> Sent: Friday, May 20, 2005 10:38 AM >>> Subject: Re: [nznog] Police arrest two over 027 hack >>> >>> >>> > It's quite simple, I stumbled onto it a few months back. >>> > >>> > I use voipjet voip provider which lets u set you callerid, I set it to >>> > 6427304xxxx ( my mobile number ) and tried to call myself to see what >>> > it >>> > would show as my callerid, however my phone didn't ring, it went into >>> > my >>> > voice mail. >>> > >>> > Since that day i've had a pin request when dialing into my voice mail. >>> > >>> > Regards >>> > Barry >>> > >>> > ----- Original Message ----- >>> > From: "Simon Allard" <simon.allard(a)staff.ihug.co.nz> >>> > To: <nznog(a)list.waikato.ac.nz> >>> > Sent: Friday, May 20, 2005 10:30 AM >>> > Subject: RE: [nznog] Police arrest two over 027 hack >>> > >>> > >>> >> >>> >> He was on 20/20 last night saying "I wasn't the person involved, but >>> >> I >>> > know >>> >> how it was done". >>> >> >>> >> >From what I could tell he had setup some type of Soft PABX (Probably >>> >> Asterisk), and was writing his own caller-id and putting them out >>> >> some >>> > sort >>> >> of ISDN/E1 connection. >>> >> >>> >> >>> >> >>> >> >>> >> > -----Original Message----- >>> >> > From: Dream Net Internet [mailto:sales(a)dreamnet.co.nz] >>> >> > Sent: Friday, 20 May 2005 10:17 a.m. >>> >> > To: Kevin Stewart; nznog(a)list.waikato.ac.nz >>> >> > Subject: Re: [nznog] Police arrest two over 027 hack >>> >> > >>> >> > Suhil again! wondered when we would hear about him again lol >>> >> > Regards >>> >> > Adam Fenech >>> >> > www.dreamnet.co.nz >>> >> > 0800 484 393 >>> >> > >>> >> > WARNING This email contains information which is CONFIDENTIAL and >>> >> > may >>> >> > be >>> >> > subject to LEGAL PRIVILEGE. If you are not the intended recipient >>> >> > you >>> > must >>> >> > not peruse, use, disseminate, distribute or copy this email or >>> >> > attachments. >>> >> > If you have received this in error please notify us immediately by >>> > return >>> >> > email, 0800484393 and delete this email. Thank you. >>> >> > ----- Original Message ----- >>> >> > From: "Kevin Stewart" <kevins(a)callplus.co.nz> >>> >> > To: <nznog(a)list.waikato.ac.nz> >>> >> > Sent: Friday, May 20, 2005 10:02 AM >>> >> > Subject: [nznog] Police arrest two over 027 hack >>> >> > >>> >> > >>> >> > > 19 year old Hamilton man named..... >>> >> > > >>> >> > > >>> >> > >>> > >> http://computerworld.co.nz/news.nsf/UNID/489D061905E8E697CC257005000CDA17? >>> >> > OpenDocument&pub=Computerworld >>> >> > > >>> >> > > >>> >> > > -- >>> >> > > Kevin Stewart >>> >> > > >>> >> > > Network Engineer >>> >> > > DDI ++ 64 9 919 6120 >>> >> > > Mobile ++ 64 21 885 505 >>> >> > > Email kevins(a)callplus.co.nz >>> >> > > >>> >> > > _______________________________________________ >>> >> > > 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 >>> >> >>> >> _______________________________________________ >>> >> 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

Peering BOF IX Meeting Minutes (fwd)
by Simon Lyall 19 May '05

19 May '05

To put something vaguely closer to on topic before Andy goes postal. Heres Bill Norton's ( you may remember him from previous network conferences) little summary of the Peering BOF at this week's nanog. The most interesting bit is the "Transit Survey" of prices for Tier1 interconnect. This is roughly how much it'll cost you if you move your site to the US and send your content to TelstraClear via a large US provider. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. ---------- Forwarded message ---------- From: William B. Norton <bill.norton(a)gmail.com> Subject: Peering BOF IX Meeting Minutes Peering BOF IX Meeting Minutes Seattle, WA May 16, 2005 7:30-9:00PM ...Transcribing my notes here for those who couldn't make the Peering BOF... comments/corrections to wbn(a)equinix.com or wbn(a)umich.edu A 5 Minute Plea for Multicast Peering ------------------------------------------------- Celeste Anderson (ISI/Los Nettos) spoke about the need for greater peering of native multicast routing. The audience commented that the volume of multicast traffic was still relatively small (a few T1's worth) in comparison to unicast traffic, and that there is still not significant customer demand to do so. We discussed the chicken and egg problems for a bit. Transit Survey ------------------------ A few people in the community suggested it would be good to get a sense of transit prices, to see if they were continuing to fall, remaining constant, or were rising back up. In previous white papers I had polled the Peering Coordinator Community to get a sense of transit prices for comparison against peering costs, so with this previous data and an audience survey we to take a stab. I asserted that with transit you often get what you pay for, and we were not interested in identifying the "lowest price", the "bottom feeder" price points that have no customer service, and that there is in fact a qualitative difference between transit services. I was looking for approximations of "Tier 1 ISP" pricing ? as expected, there was some debate here. To avoid the rathole of "Tier 1" etc. and to focus on "quality" of transit services for a quick price measure I pulled together some questions to disqualify some upstream providers from the survey: Q1: When you complain about packet loss to your Upstream, you are told A) I have Bob working on it, he will call you back in 15 minutes B) Call this other number (which rings busy) C) ?Let me put you on hold for an hour(Barry Manilow sings the songs that make the whole world sing) D) You should have sent your packets earlier I told folks if they answered "C" or "D" to please not answer the poll ? we were not interested in bottom feeder pricing for this poll. Q2: My Upstream Provider's Reliability is A) 6 9's B) Close to 6 9's C) Closer to 9 6's D) Don't know ? I'll let you know when they stay up long enough to measure. I told folks if they answered "C" or "D" to please not answer the poll? we were not interested in bottom feeder pricing for this poll. Q3: My Upstream Provider's Customer Service Makes Me Feel? A) Like a VIP B) Like a Nuisance C) Very, very unclean. D) Like I was just traded to another inmate for 2 packs of menthol cigarettes. I told folks if they answered "C" or "D" to please not answer the poll? we were not interested in bottom feeder pricing for this poll. Source: A couple of these questions/answers came from a Wired magazine article I read on the flight up, which referenced http://www.5ives.com. While not a particularly scientific survey, we did get 28 viable data points with the averages being: 10Mbps commit: $41.75/Mbps 100Mbps commit: $33.83/Mbps 1000Mbps commit: $20.73/Mbps 10000Mbps commit: $13.80/Mbps About 6 months or so ago I did a similar poll with the Peering Coordinator Community and the #s were around $85, $60, $45, $30, indicating that perhaps the transit prices have indeed fallen. If any of you are interested in the raw data (thanks to Eric Troyer for putting the data points into a spreadsheet) let me know and I'll email you the spreadsheet. Peering at 10G ? introduction to The Great (Public vs. Private) Peering Debate ---------------------------------------------------------------------------------------------------------------- The motivation for the Great Debate was a white paper I am working on called "The Great (Public vs. Private) Peering Debate: Peering at 10G" in which I documented the Peering Coordinator Community assertion and the math that the next best alternative to 10G Public Peering was many 1G Private Peering sessions. I walked through the models for both cases (10G Public and 1G Private) peering, specifying sample equipment (thanks ras!), cost estimates, etc. so we could compare the two alternatives side-by-side. There were many valid points raised during this discussion including: 1) In the modeling we were not including backbone costs, only IX and Peering equipment fees at one location, 2) There are other valid configurations of equipment, including removing the peering router and using switches by themselves (debate here as well), 3) There were a wide variety of redundancy configurations that could/should be considered as well in both cases. The nice thing about modeling this stuff is the ability to identify and discuss assumptions, to change #'s, to have something on the table to discuss, and it was a lively discussion before and after the BOF. The punch line for the current model I shared was that public peering at 10G and private peering at 1G both are very cost effective solutions, yielding less than $10/Mbps with a few gigabits of peering. Also, the more traffic peered, the more the cost of these two models of peering converged ? so Public vs. Private becomes an architectural / religious issue. This leads to the Great Debate ? when do people prefer Public Peering and when do they prefer Private Peering, and why? The Great (Public vs. Private) Peering Debate ------------------------------------------------------------------- I recruited Maurice Dean (who was the Peering Coordinator at Global Crossing and now at Google) to present and defend "The Strongest Arguments for Public Peering", and Peter Cohen (Peering Coordinator for Telia) to share "The Strongest Arguments for Private Peering". We used a modified Oxford Style Debate, providing each side three minutes for opening remarks, three minutes each to attack the other side's points and defend their own, a few minutes for the audience to ask clarification questions, and finally two minutes for the debaters to present summary remarks. The audience would then vote for "Who made the more compelling case." Maurice started out by pointing out that IXes today are not the IXEs of 1995, but rather are large and reliable infrastructure that provide access to a rich population of potential peers. Public peering provides instantaneous access to peers, provides aggregation benefits, ease of administration and is easy to scale peering capacity. He pointed also to the marketing benefits of public peering at the IXes. Peter opened by stating that Private Peering provided superior control over peering infrastructure. He went on that Private Peering scaled very well, that the same fiber pairs could be reused as both sides simply upgraded cards. Private Peering is simpler according to Peter since no NetFlow was needed, that there were not 20 peers all peering across the same 10G interface. For some he claimed ISPs, the only way to measure public peering traffic volume to a peer was to turn down a peering session and see the difference in traffic load. Maurice countered reinforcing that modern IXes have overcome the head of line blocking issues of the past and indeed scale very well, and in fact scale well even across a metro area. He defended the NetFlow attack by mentioning that some IXes have sFlow, providing public peering visibility on a per-peer traffic volume basis. Peter countered that Maurice was a "Stooly for the IXes", and depending on a single port for peering is asking for trouble. Further, participation in some IXes requires going to member meetings, and who has time for that. Finally that the added complexity of adding a public peering switch was problematic ? he used the analogy of air travel. "How many of you prefer a direct flight over one with connections?" The audience asked a variety of questions next but I did not jot them all down. A few points did come up though ? that circuit upgrades for private peering can take 6 months or more depending on which side is in a hurry to upgrade. Another point was that public peering was seen by some as easier to justify to their company since it would be used across many peers. The closing remarks were a rehash of the points above, but Maurice introduced a couple additional points ? that 90 day trials could be effectively done over a public peering fabric without additional costs to those attached, and that public peering fabrics enabled more opportunities (for peering? For add'l services? For transit sales?...not sure what he meant here). Peter reasserted that placing all the eggs in one public peering port was just asking for trouble. The audience next voted "Who presented the more compelling case?" We had to count twice because it was so close. The final results: Public Peering presented the more compelling case: 37 Private Peering presented the more compelling case: 33 Maurice Dean won the Great Peering Debate. White Paper Available -------------------------------- I captured these and other arguments for and against private peering in the white paper mentioned above ? I would love to have a few more reviewers give me some feedback/edits/etc. If you are interested in 10 Gigabit Ethernet Peering or the debate discussion, send me an email (wbn(a)equinix.com) with the Subject: "The Great (Public vs. Private) Peering Debate ? Peering at 10G" and I'll send you a copy. If you provide comments on the draft I will add you to the acknowledgements section of the next version of the document. We were running out of time so we moved quickly to Peering Personals, giving Peering Coordinators a chance to introduce themselves to the group. Peering Personals ? (jotted down everything on the sheets) -------------------------------------------------------------------------------------- Korea Telecom ? 4766 ? Bong-Hwa Song ? 40 Gbps Capacity, peering in Seattle PAIX, Palo Alto PAIX, EQLA, LINX, AMSIX, songbh(a)kt.co.kr AARNET ? 7575 ? Mark Prior ? Research Net, Seattle SIX, PAIX, LAIIX, LAAP, FixW, P|Wave, mark.prior(a)aarnet.edu.au Netflix ? Vish Y ? vish(a)netflix.com ? Selective peer Steve Gibbard ? PCH ? 42, 3856 ? Data Collection ? Open Peering 0 25 locations all over the world (SIX, EQLA, LAIIX, NYIIX, PAIXNY, EQASH,NOTA,?) Steve Gibbard ? Hurricane Electric ? 6939 ? scg(a)stevegibbard.com, peering(a)he.net ? 2700 routes, public but migrating to private at EQSJO, EQLA, EQCHI, EQDAL, EQASH, PAIXPA,NYIIX, LINX, AMSIX Brokaw Price ? Yahoo! ? 10310 ? OPEN ? peering(a)yahoo-inc.com Todd Underwood ? 64597 ? todd(a)renesys.com ? NOTA, LINX, Goofy peering, route collection only, store updates, Google ? Maurice Dean ? 15169 ? selective peering ? peering(a)google.com, NYIIX, EQ-CHI, EQCHI, EQASH, NOTA, PAIXPA,PAIXVA,1118th, TelX (60 Hudson)., LINX< AMSIX, LAIIX Akamai ? 12222 ? Patrick Gilmore ? 20940 outside U.S., OPEN and at every IX, content heavy, peering(a)akamai.com ESNET ? 293 ? Yvonne ? ipv4, ipv6, multicast, EQASH, EQSJO, MAEEast MAEWest, PAIX, AADS, FixW, Pacific NW Gigapop, peering(a)es.net, selective peering policy with AUP Celeste Anderson ? AS4, AS27, AS2152/2153, ISI/Los Nettos, research net, lots of eyeballs, LAIIX, LAAP, Pacific Wave, PAIX LA, Mostly OPEN~selective, eyeballs, peering(a)pacificwave.net, celestea(a)usc.edu, Matt Peterson ? SixApart , AS# pending, SIX, EQSJO, LiveJournal.com, matt(a)sixapart.com -------------------------------------------------------------------------------------------------------------- Hope this help! -- //------------------------------------------------ // William B. Norton <wbn(a)equinix.com> // Co-Founder and Chief Technical Liaison, Equinix, Inc. // GSM Mobile: 650-315-8635 // Skype, Y!IM: williambnorton

1 0

Police arrest two over 027 hack
by Kevin Stewart 19 May '05

19 May '05

19 year old Hamilton man named..... http://computerworld.co.nz/news.nsf/UNID/489D061905E8E697CC257005000CDA17?O… -- Kevin Stewart Network Engineer DDI ++ 64 9 919 6120 Mobile ++ 64 21 885 505 Email kevins(a)callplus.co.nz

4 4

Re: [nznog] Police arrest two over 027 hack
by Liz Q 19 May '05

19 May '05

On Fri, 20 May 2005 10:30, Simon Allard wrote: > He was on 20/20 last night saying "I wasn't the person involved, but I know > how it was done". Apparently it was him and his old friend ^God (will) Liz -- Everything goes wrong all at once.

1 0

RE: [nznog] Police arrest two over 027 hack
by Donald Neal 19 May '05

19 May '05

> > He was on 20/20 last night saying "I wasn't the person > involved, but I know > how it was done". > > >From what I could tell he had setup some type of Soft PABX (Probably > Asterisk), and was writing his own caller-id and putting them > out some sort > of ISDN/E1 connection. > For a number of reasons this would be a good place for this thread to end. - Donald Neal Donald Neal |"Sub judice - The Israeli Support Engineer |underground system" NGN Operations | 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] Automatic NZNOG On-topic Converter
by Tim John 19 May '05

19 May '05

_WAY_ to much time on your hands :) ... But then of course, you did mention beer ! Tim -----Original Message----- From: Andy Linton [mailto:asjl(a)citylink.co.nz] Sent: Thursday, 19 May 2005 5:51 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Automatic NZNOG On-topic Converter Hi there, Do you guys know about any server or add-on to MS Exchange that automatically converts off-topic requests into mail about Network Operations or if that's too hard, discussions about beer? andy _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Automatic PDF Converter
by Yehudi Binder 18 May '05

18 May '05

Hi there, Do you guys know about any server or add-on to MS Exchange that automatically converts e-mail attachments - doc, xls, etc. - to pdf before posting the e-mail? Thanks, Yehudi H. Binder IT Security Analyst Electronic Transaction Services Ltd This electronic message together with any attachments is confidential, and may be privileged. It is intended solely for the addressee. If you are not the intended recipient do not copy, disclose, or use the contents in any way and please notify us by return e-mail immediately, then destroy the message. ETSL is not responsible for any changes made to this message and/or any attachments after sending by ETSL.

4 3

Notification of NZRR Database changes
by NZRR Database Notifications 17 May '05

17 May '05

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 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. --- OBJECT BELOW CREATED: aut-num: AS17492 as-name: NZRR-AS17492 descr: Vector Communications descr: APE peering at '192.203.154.19' descr: see Citylink RT job #2404 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17492 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: matthew.oram(a)vectornetworks.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050518 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS17492 descr: Route set advertised to AS9560 by Vector Communications - AS17492 members: 202.126.192.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: matthew.oram(a)vectornetworks.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050518 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 May '05

17 May '05

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 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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by ihug - AS7657 members: 192.107.113.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.44.0/24^24-29, 202.36.94.0/23^23-29, 202.36.95.0/24^24-29, 202.36.230.0/24^24-29, 202.36.231.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.46.0/23^23-29, 202.49.63.0/24^24-29, 202.49.148.0/24^24-29, 202.49.148.0/23^23-29, 202.49.149.0/24^24-29, 202.49.178.0/24^24-29, 202.49.180.0/23^23-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.188.0/22^22-29, 202.50.255.0/24^24-29, 203.96.192.0/24^24-29, 203.96.192.0/19^19-29, 203.96.193.0/24^24-29, 203.96.212.0/23^23-29, 203.96.220.0/24^24-29, 203.96.223.0/24^24-29, 203.109.132.0/22^22-29, 203.109.133.0/24^24-29, 203.109.134.0/24^24-29, 203.109.135.0/24^24-29, 203.109.144.0/24^24-29, 203.109.144.0/20^20-29, 203.109.146.0/24^24-29, 203.109.150.0/24^24-29, 203.109.155.0/24^24-29, 203.109.157.0/24^24-29, 203.109.158.0/24^24-29, 203.109.163.0/24^24-29, 203.109.192.0/22^22-29, 203.109.192.0/21^21-29, 203.109.198.0/24^24-29, 203.109.199.0/24^24-29, 203.109.230.0/24^24-29, 203.109.233.0/24^24-29, 203.109.252.0/22^22-29, 203.109.253.0/24^24-29, 203.109.255.0/24^24-29, 203.118.128.0/20^20-29, 203.118.130.0/23^23-29, 203.118.132.0/23^23-29, 203.118.136.0/24^24-29, 203.118.144.0/24^24-29, 203.118.144.0/20^20-29, 203.118.147.0/24^24-29, 203.118.148.0/24^24-29, 203.118.150.0/24^24-29, 203.118.154.0/24^24-29, 203.118.155.0/24^24-29, 203.118.157.0/24^24-29, 203.118.158.0/24^24-29, 203.118.159.0/24^24-29, 203.118.160.0/20^20-29, 203.118.161.0/24^24-29, 203.118.164.0/22^22-29, 203.118.168.0/21^21-29, 203.118.176.0/24^24-29, 203.118.176.0/23^23-29, 203.118.177.0/24^24-29, 203.118.178.0/24^24-29, 203.118.179.0/24^24-29, 203.118.180.0/24^24-29, 203.118.181.0/24^24-29, 203.118.182.0/24^24-29, 203.118.183.0/24^24-29, 203.118.184.0/24^24-29, 203.118.185.0/24^24-29, 203.118.186.0/24^24-29, 203.118.187.0/24^24-29, 203.118.188.0/24^24-29, 203.118.189.0/24^24-29, 203.118.190.0/24^24-29, 203.118.191.0/24^24-29, 203.173.140.0/22^22-29, 203.173.146.0/23^23-29, 203.173.148.0/22^22-29, 203.173.152.0/22^22-29, 203.173.160.0/24^24-29, 203.173.161.0/24^24-29, 203.173.164.0/22^22-29, 203.173.168.0/23^23-29, 203.173.170.0/23^23-29, 203.173.172.0/22^22-29, 203.173.188.0/22^22-29, 203.173.192.0/19^19-29, 203.173.224.0/20^20-29, 203.173.240.0/21^21-29, 203.173.248.0/21^21-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29, 202.126.80.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by Ihug Ltd - AS7657 members: 203.118.128.0/18^18-29, 203.173.192.0/18^18-29, 203.96.192.0/19^19-29, 202.46.160.0/20^20-29, 202.126.80.0/20^20-29, 203.109.144.0/20^20-29, 203.173.144.0/20^20-29, 203.109.192.0/21^21-29, 203.173.136.0/21^21-29, 203.173.168.0/21^21-29, 202.50.188.0/22^22-29, 203.109.132.0/22^22-29, 203.109.252.0/22^22-29, 203.173.164.0/22^22-29, 203.173.188.0/22^22-29, 202.21.136.0/23^23-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.148.0/23^23-29, 202.49.180.0/23^23-29, 202.61.2.0/23^23-29, 203.173.160.0/23^23-29, 203.173.186.0/23^23-29, 192.107.113.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.63.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 203.109.163.0/24^24-29, 203.109.230.0/24^24-29, 203.109.233.0/24^24-29, 203.173.162.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050518 source: NZRR --- PREVIOUS OBJECT: route: 203.118.128.0/18 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 203.118.128.0/18 descr: Route for Ihug Ltd - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050518 source: NZRR --- PREVIOUS OBJECT: route: 202.36.230.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.36.230.0/23 descr: Route for Ihug Ltd - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050518 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 16 May '05

16 May '05

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 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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.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: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 203.97.42.0/24^24-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050517 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.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: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 203.97.42.0/24^24-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050517 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18406 descr: advertised to AS9439 by FX Networks - AS18406 members: 202.53.189.0/24^24-29, 161.29.254.0/23^23-29, 202.7.4.72/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050315 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18406 descr: advertised to AS9439 by FX Networks - AS18406 members: 161.29.254.0/23^23-29, 202.53.189.0/24^24-29, 161.29.192.8/29, 202.7.4.72/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050517 source: NZRR

1 0

RE: [nznog] ISP Jobs in NZ
by Steve Hawken 16 May '05

16 May '05

Hi, We are looking for a couple of network engineers in Auckland. We have two roles, one at tier 2 and one at tier 3. Anyone interested in working in the ISP / Telco space drop me an email. Cheers, Steve Steve Hawken Senior Network Engineer DDI ++ 64 9 919 6038 Mobile ++ 64 21 778 891 Email steveh(a)callplus.co.nz -----Original Message----- From: Ben O'Hara [mailto:bohara(a)gmail.com] Sent: Thursday, 12 May 2005 9:51 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] ISP Jobs in NZ Hi All, Im looking into maybe moving out to NZ from the UK for a year or so and wondering what the job prospects are like in the ISP industry? Ive previously worked fora large ISP here in the UK as a systems/network engineer and would prefer to get a job in the same sort of role over in NZ. Any tips, pointers etc gratefully appreciated. Whats the best area of the country for work? (im thinking Auckland or Wellington) Anything in the Gisborne region? (Ive got family there) Whats the pay like over there for sys/net eng positions? Regards Ben O'Hara _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog ----------------------------------------------------------------------------------------------- This message and any attachments contain privileged and confidential information. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immediately via email and then destroy this message and any attachments.

5 6

RE: [nznog] ISP Jobs in NZ
by Scott Walsh 12 May '05

12 May '05

Hi Ben, Right at the moment NZ has quite a low unemployment rate in most industries, including IT. A number of companies that I'm aware of are looking for staff and there are not that many people looking for job. So it is quite a good time to be looking for IT work in general (In fact we're looking for an entry-level/tier 1 network person at the moment, anyone interested get in touch). This also means of course IT pay rates are beginning to rise in order to try and attract staff. Both Wellington and Auckland have a number of IT jobs in general also Christchurch has quite a few. A lot of IT jobs are not advertised in NZ (1/2 - 2/3 according some of the recruitment agents), but of the ones that are more of them are listed on: http://it.jobstuff.co.nz/ http://www.nzherald.co.nz/ Those may give you an idea of the types of jobs going. The Herald tends to cover Auckland jobs, Stuff tends to cover Wellington and the rest of the country. Keep in mind when looking at pay rates, if you convert the pay to pounds in won't look that great but the costs of living are lower in NZ too. Thanks Scott Walsh Service Implementation Specialist Integrated Technology Services (ITS) IBM New Zealand Limited -----Original Message----- From: Ben O'Hara [mailto:bohara(a)gmail.com] Sent: Thursday, 12 May 2005 21:51 To: nznog(a)list.waikato.ac.nz Subject: [nznog] ISP Jobs in NZ Hi All, Im looking into maybe moving out to NZ from the UK for a year or so and wondering what the job prospects are like in the ISP industry? Ive previously worked fora large ISP here in the UK as a systems/network engineer and would prefer to get a job in the same sort of role over in NZ. Any tips, pointers etc gratefully appreciated. Whats the best area of the country for work? (im thinking Auckland or Wellington) Anything in the Gisborne region? (Ive got family there) Whats the pay like over there for sys/net eng positions? Regards Ben O'Hara _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Upcoming Live Webcasts
by Richard Naylor 12 May '05

12 May '05

Launch of the NZ Digital Strategy Sorry folks for the short notice - it sonly just starting to come together........<sigh> CityLink will be webcasting the Launch of the NZ Digital Strategy on Monday 16 May beginning at approximately 1400 hours. I believe the Launch is at the Beehive, with Minister David Cunliffe. We will not be on site for the event, just webcasting off a videoconference link. Our information about the event is currently very limited. Hopefully by Monday we will have a little more clue...... Operators may be interested in watching the event - it is of some relevance - and Help Desks may get calls requesting assistance. Broadcasters wanting a contribution feed should contact me. There will be high quality audio and video streams available for redistribution, but owing to the source from the site, this may be at reduced quality. The event will use servers in both AKL and WLG and will have international access (ie it is a not restricted webcast). The URL for the event is (ok - will be - when we know something we'll write it) http://www.r2.co.nz/20050516 For best performance ISPs are recommended to be peering at APE or WIX. The Tech Team at CityLink are able to assist if anyone wants to peer in a hurry. Thanks you for your co-operation. Rich

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 12 May '05

12 May '05

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 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. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by LinuxNet - AS18119 members: 192.107.113.0/24^24-29, 202.7.4.80/29, 202.7.6.32/28^28-29, 202.21.136.0/23^23-29, 202.36.44.0/24^24-29, 202.37.136.0/24^24-29, 202.49.249.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: lincoln(a)linuxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by LinuxNet - AS18119 members: 202.46.160.0/20^20-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.37.136.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.0/24^24-29, 202.7.4.80/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: soa(a)linuxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050513 source: NZRR

1 0

ISP Jobs in NZ
by Ben O'Hara 11 May '05

11 May '05

Hi All, Im looking into maybe moving out to NZ from the UK for a year or so and wondering what the job prospects are like in the ISP industry? Ive previously worked fora large ISP here in the UK as a systems/network engineer and would prefer to get a job in the same sort of role over in NZ. Any tips, pointers etc gratefully appreciated. Whats the best area of the country for work? (im thinking Auckland or Wellington) Anything in the Gisborne region? (Ive got family there) Whats the pay like over there for sys/net eng positions? Regards Ben O'Hara

1 0

Survey Results for 2006
by Simon Lyall 11 May '05

11 May '05

Results from the 2006 bit of the survey are below. I'll do the rest of the survey over the next few days. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. "I'm sick of you people, your just a bunch of fickle mush heads" - Joe Quimby. NZNOG 06 -------- 38 Forms were returned and 37 were counted towards the total. Not all questions were answered by everybody. My comments are in [] brackets. I have tried to get quotes that generally represent what most people are saying. 1. Are you likely to attend NZNOG 06. Yes: 33 No: 2 Maybe: 2 2. Are you likely to attend Linux.conf.au in Dunedin at the end of Jan 06? Yes: 19 No: 18 3. The following are venues/times that NZNOG might be held. Please rate how likely your are to attend and which you would prefer. [ Most people who expressed a preference said they could attend both. ] (a) Jan/Feb: 7 (b) Mar/Apr: 9 Either: 16 "Yeah, but we've held great conferences in the past without ICANN. I just think that the whole ICANN/Internetnz thing has the capability to hijack NZNOG. " "May not be able to go if it's a teaching time. " "I'm OK for either, unless of course the cost is going to be much higher. A bit higher would be OK if we're talking 50-80 more. " "Very unlikely to attend, unless conf was over easter stat holidays. " "Not if I have to pay. " "Option B. It'd be easier to get to both Linux.conf.au & NZNOG if there is a bit of a gap between them. " "I would almost certainly attend either one, given that both the conference and I would be in Wellington. I'd have a slight preference for March/April due to (a) more chance of overseas networking folks (better timing for network-related things, and fewer clashes), and (b) making it easier to "catch up" on work immediately after Linux.Conf.au in Dunedin. " " If it is directly after linux.conf.au this would be good for getting overseas visitors with Linux interests (more interesting to me than networking people maybe), however it could be harder for me to get time off to go to two events in a row. " " Likely to attend either; more preference for option (b) on the basis that I'm not going to attend most of the ICANN stuff, so more likely to get interesting diverse speakers for an ICANN + NZNOG combo. " 4. Please comment on the following, how you feel about them and how important these are to you. # International Speakers "Important, but we only need a 2 or 3, - or at least 1 a day. " "Really important, it's the overseas speakers which many attendees need to justify the expense to bill payers. " "Good to have some, bad to have many. " "This is a big plus - makes the *management* see value in the event. " "It's very valuable to have 2-3 international speakers so that NZNOG doesn't become isolated from what's happening in the outside world. " "Important to give flavor and to justify attendance to boss. Perhaps only 2 or 3 needed. " > Low cost ( < $500 for programme + accommodation) [ Many people said low cost was *very* important while a few were happy to pay more. Perhaps a "professional" option could be offered ( with what? ) ] "I'm not convinced cost is as much of a barrier as people claim - I think that old saw of people struggling to get sign off on a $400 conference, but getting a $2400 conference approved with no hassle is probably more true than people realise. " "Too cheap for the quality of speakers / programme " "The cheaper it is, the more people I can send along. " " Important. Expense = must justify to bean counters. Certainly individuals are less likely to attend if its expensive. " "Very, I can't afford 500 for a conference " "Low costs means easy to get work to pay for it. " "It's good. It encourages participation. Participation is good. " " Important that it is affordable for people who have to pay their own way. (IE, don't aim it only as a company-sponsored-attendance event) " "Not fantastically important to cut the price to the bone. A good conference for teachers can be several thousand dollars! " " Personal I'd be happy with the program as long as it was sub-$1000 (easyish to get work to pay for that). However it would be great to see the cost stay low so people can pay for themselves if they want and to make it easy for the small-mid size companies. " "Important (helps to get a much bigger audience), but I don't think it's the end of the world if it went over a little over $500. " "I suspect attendance in Wellington will be lower simply due to a number of people in Auckland being willing/able to drive to Hamilton, but not willing/able to take the time to drive/fly to Wellington. (Adding in flights to the "total cost" may also be valuable in planning.) " "Very important to me. The low cost is the one of the main reasons why I decided to attend. " "Important. Low cost enables unfunded people to appear and for other to not to have to go to high up the food chain to attend. " "Yes - I pay for it myself. " "Very important - $500 would be about my limit " Types of attendees ------------------ [ Just about everybody was happy with the follow sort of people attending. ] - Network Operators (people who type BGP commands) - Admins of large websites - Admins of Large mail servers - Security Admins at large sites - Large ISP technical personal - Small ISP technical personal - Network researchers - Small Hosting providers - Students - Wireless Operators "I would like to hear about large mail system scaling. " "Am more interested if it is someone from a large site. " " I'd also like to see Design Engineers as there are people who don't necessarily type the commands into the 'live' systems, but they _design_ the system. " [ Re Security Admins at large sites ] "Especially dealing with large customer volumes and/or traffic volumes. (e.g. Managed firewalls doing 1Gb/s for 30,000 customers.) " " Yes. Small hosting providers could be future big hosting providers one day. " [ Most people were happy with the following although some expressed reservations. ] - Network consultants "as long as they're geeks and not suits" - Programmers (Open source projects) " Maybe, if they work on projects relevant to network operators " - Government Policy people ( eg MOC, CCIP) " In moderation. They seem to add little value and observe a hell of a lot. " " Definitely would like to see more policy presence. Policy becomes law becomes our implementation pain. " - Vendor sponsored speakers "If they agree to be 95% non-commercial " "As long as they aren't just salesman fine by me." "Great way of getting a speaker that would be otherwise hard to get" The following were less popular. - Equipment Vendor salesman " I suspect allowing too many vendors along spoils the open nature of the NZNOG conference, however the occasional bit is fine by me. " " No, Spray them with mace at the door. We can go do vendor sex at every other conference... " - Script Kiddies Ooh, this could be fun. We could all bring a baseball bat and have a go. That would be GREAT! [ NOTE: Similar to the above was said by several people. ] Other things ------------ # Official event dinner [ The majority of people felt this was very important ] "This is critical, as it involves beer." "Do it right or not at all" # Curry Night [ Many people rated this as more important than the official dinner while others were uninterested. ] "I prefer the socialising to the actual food. Personally I hate curries, but in a case like this I'll put up with them to be able to meet the people there. " "Being the night before, many people must have been like myself and unavailable... " "Important, but showing the strain of size. " # Joe and Dean [ Popular with most people. ] "NZNOG without Joe and Dean is like a fish without a bicycle! Important - as a guideline for the types of people we need there " " WTF? Is this NZ Network Idol? Puhhleeaazzee.. I mean they're good dudes and stuff, but this is about peering and not hierarchy isn't it? " # Wireless Access at event [ About one third of people didn't care while the others all rated it as vital. ] "Required. I actually fixed stuff while I was in a conference." # Nearness to the office. [ Not important to most, see Wireless question above. ] "The office is the laptop where the network connection terminates, isn't it? " "Important that it isn't " # Vendor Booths [ Quite a few negative comments here. I think people would be happy to have a few booths if they (a) Contributed to the bottom line of the conference and (b) Were targeted at the audience and interesting. ] "Prefer not to have them" "A couple would be nice especially if they had cute gear and helped subsidize events. " # Breaks between talks [ People thought these were good, no real consensus on how long however. People liked the free soft drinks in 05 but weren't so hot on the finger food ] "Smoker" "Hmm - I think the current format works, but there needs to be a larger 'buffer' zone to be used for spillover at the end of interesting presentations. Maybe if it could be structured so the presentations ran through to 6:30pm ish? " "Should be longish, talk is important." "Definitely good. Half of NZNOG's value is social" "It's very useful to have 10-15 minutes between talks to grab the speaker and ask questions. At most pairs of talks run together. The Linux.Conf.au pattern seems to work reasonably well. (45 minute talks, 15 minutes gap, talk often runs a little into the gab.) " "A few more than '05 might be good " "Keep them brief, a couple of sessions, then a break, etc.. I badly need a good way to secure my laptop. " "Not too long. While talk is good having 45 minute breaks all day is overdoing it. Perhaps 20 minutes for morning and afternoon tea and an hour for lunch. " # Start and finish times each day. [ Several people requested a slightly later start on Day 1 for those traveling. In general people seemed happy with a 9-6 , with perhaps some less official things going a little later. Starting before 9 was unpopular. ] "9-5 is good. " "I'd prefer a later start, since as we all know, we geeks tend to stay up late each night " # Wider programme or narrowly focused on Network operators. [ Very mixed results here. Hard core network geeks said keep it narrow while most other people wanted it a little wider. There appeared to be less objection if "non core" talks were on tutorial or in a separate stream. ] "I would enjoy a wider programme, but due to my work Network design/operation/engineering/support would be more useful to my employer. " "Focused on networks. I.E. not general Linux stuff." "Wider/Diverse programme, but with a Network Operator thing " "Wide programs are good if there are a couple of streams, otherwise you sit through stuff that isn't interest to. " "It occurred to me that it may make sense to (a) revive SAGE-NZ (a "NZ branch" of the System Administrators Guide) and (b) have some sort of system administrators stream. Perhaps there could be a SAGE-NZ "miniconf" the day before/after? " "Since network operators can also have other roles (mainly in small companies), its nice to have the programme focused a bit wider than just network operations. " # Single or Multiple streams. [ No real consensus ] "I would prefer single streams - if we have enough content, run for more days." "Multiple is good, but maybe just 2, ended up with overlaps of 2 interesting topics last time " "Single is best if the topics are related. If the two streams were quite separate (ie. Administrative and Technical) streamed would be OK. " "Single if possible but multiple might be an option. Perhaps if there were multiple then people could pick beforehand what talks they were interested in and we could schedule the clashes so a minimal number of people were disappointed." # Recording and/or broadcast of Events. [ This was split into two. Almost everyone was in favour of recording and making the event available later especially if there were multiple streams. Several people suggested not broadcasting it however to encourage people to tune up to the actual conference. ] "Absolutely to both." "great to go back to parts missed, or confirm something" "If I can't get there in person I will *definitely* watch the streams, either live or delayed. They're a great way to increase participation... " "Makes it difficult to argue I have to go. :) " "Recording everything definitely, especially if there are multiple streams. Broadcast isn't as important since it encourages people to actually attend. " "a good thing, but need to be much better quality than '05. Also open standards are good - I don't like having to install proprietary software. " # Giveaways [ People seemed to think these were okay to have but not very important. especially they didn't seem to want (a) Junk or (b) Lots of money being spent on them. ] " Yes - especially if it involves beer. " " Freebies rock. " " To be honest I'd happily trade a lower conference fee for no giveaways, or just a T-shirt. If they're sponsored bits then fine, but otherwise I think the money is better spent on something else. " " Not important to me " # Misc "Thinking back to '04, the best thing I felt about it was that the residential nature of the con forced a bunch of people to communicate who wouldn't otherwise do so (especially in person). So things that aid that (curry night, distance from the office, breaks between talks, common accommodation) seem to me important. " 5. Please rate on the following topics and make other comments if you like. [ I have rated the topics as following. The first number is the average score the topic received, the second is the number of people giving it a score of 4 or 5 while the 3rd number is the number giving it a score of 1 or 2. Around 30 to 35 people voted each time. I have chopped the list of topics into 3 groups (feel free to shuffle each group up or down a topic or two). The first groups appears to have a lot of people very interested and not many people disinterested. The second group have less but still positive net interest. The 3rd group have below average interest a a larger number of people uninterested. I would guess we aim for large or multiple talks from the first group and single, lightning, streamed or no talks on the others. All depends on offers and speakers obviously. Oh and if you don't know what LAMP is: http://en.wikipedia.org/wiki/LAMP ] VOIP : 4.3 27 0 Network Monitoring : 4.0 25 2 Peering : 4.0 23 2 Lightning talks : 3.9 23 3 Network Design Philosophy : 3.9 22 2 Network Measurement : 3.9 21 3 Internet Exchange Updates : 3.9 20 3 Security and Encryption : 3.8 21 2 IPV6 : 3.7 21 4 DDOS : 3.7 17 3 WAN Solutions / VPNs : 3.6 15 4 BGP and other routing protocols : 3.5 16 6 ENUM : 3.5 15 6 Fibre Optics : 3.3 12 8 Wireless : 3.3 10 4 Spam : 3.3 13 9 APNIC : 3.1 7 8 Mail Servers : 3.0 12 9 Virtual Servers (eg Xen, UML) : 3.0 11 10 MPLS : 2.9 11 13 Government Policy : 2.9 10 13 LDAP : 2.8 7 11 Multicast : 2.8 9 13 Web Server Administration : 2.7 7 15 Asset Management for Network Hardware : 2.6 9 15 UltraWideband : 2.6 9 15 LAMP : 2.6 6 12 INOC-DBA : 2.6 5 14 DNSSEC : 2.5 8 7 PGP Key Signing party : 2.5 8 20 Other Talk topics suggested: DNS (general) Clustering/Redundant Network Design Latest Internet practices (shaping etc) "things with cool factor For example unique and clever solutions to difficult problems. I think the conference should continue to aim not at a demographic (large ISP or small ISP), but just encouraging people to think up really just, I dunno *struggles trying not to use a buzz word* clever, outside the box solutions to hard problems. " 5. Are you interested in giving a talk? [ Around 1/3 the people who replied to the survey indicated interest in giving a talk. Some of these will be approached. ] 6. Other stuff. [ further quotes from people ] Fix the catering. - I thought the lightening talks were interesting, but maybe just a couple of minutes too short to be cover a complete topic, maybe 10 mins not 5 ? - Would be nice to see the program go up a little earlier to allow staff to plan to go (ie: not adding tutorials after people had booked) I don't recall having any linux/unix specific material at NOG '05, which is a fundamental part of most ISP networks in NZ. While it's a huge topic I'd have liked to hear some linux/Unix/Solaris specific content (not installfests) Perhaps some discussions of the future of Internet in NZ, and some predictions on where the Internet is heading based on current trends. I believe you touched on a couple of these areas briefly, which was nice. Not Hamilton, and a different time in the year. While publishing the programme early is good perhaps not having the exact timetable up will discourage managers from only assigning time for people to go to specific events. Perhaps an official wiki for people to post stuff or Blog aggregator. Small prizes ( USB fobs) for each speaker to give away per talk might encouraged people to ask good questions. Some howto guides for using network tools like nagios would be cool. A talk or two about how people see the Internet going. People I'd like to see: Somebody from Southern Cross talking about the cables. Somebody from Weta talking about the server or storage farm. Somebody from a large ISP talking about traffic shaping People talking about large storage Area networks People from some large sites ( Xtra, stuff, herald) talking about how they look after the network, servers, site, etc. Some practical VOIP stuff. I like Tshirts better than those with collars. If its in Wellington make some plan for flying people in and out of Palmerston and bus transit between. I have a hobbyist interest in community and non-profit networking; I don't know how that subject could be integrated though.

6 7

Ghetto colocation in wellington
by Tim Nicholas 11 May '05

11 May '05

Hi all, Does anywhere know of anyone who does cheap nasty collocation hosting in or around Wellington? I'm thinking no backup power, tower style boxes allowed, that sort of thing. Connectivity doesn't have to be too flash but availability of 8 or 16 IP addresses would be ideal. Reply to me directly. If there are enough responses to warrant it I'll summarise for the list. Thanks, Tim -- Tim Nicholas || TJN Email: tim(a)nicholas.net.nz || Wellington, New Zealand http://tim.nicholas.net.nz/ || Cell/SMS: +64 21 337 204

4 3

Barracuda Spam Firewalls...
by Dan Clark 09 May '05

09 May '05

Hi Guys, Can anyone who is using Barracuda Spam Firewalls in a Production ISP environment please contact me. I'm interested to know if they work well with multiple virtual hosts/domain names? Do they work straight out of the box? Are they fast? Is anyone running more than one in multiple locations, clustered etc? Are there any problems you may have noticed after you turned it on? Kind Regards Dan Clark Technical Director Synaptic Ltd

1 0

Videos of NZNOG-05 Tutorials now available
by Richard Naylor 04 May '05

04 May '05

Videos of the Tutorials from NZNOG-05 are now available at http://www.r2.co.nz/20050203/ We have updated the page with links to the tutorials. At this stage they are not available for downloading - that would depend on (polite) demand. Thanks to Jamie and the others for recording the sessions. Rich

1 0

Seminar in Hamilton.
by Richard Nelson 04 May '05

04 May '05

Rich Groves was scheduled to give a presentation at NZNOG'05 but was unable to make it due to immigration processing delays. He is going to give a (similar) presentation to WAND this Friday at 2pm at the University of Waikato. Sorry for the short notice, but if anybody would like to come, you would be welcome. Title "Creating a Passive Network Analysis Framework to Glean Internet Weather" Bio: Rich Groves is a former Principal Network Engineer at America Online and Network Architect at MCI and is now a Technologist at Endace as well as researcher for WAND. If anybody wants to come, please email me directly so I can keep track of numbers and I'll send you room details. The abstract of his planned NZNOG'05 talk was: The purpose of this project is to create a generic passive network monitoring framework for use with highly trafficked TCP applications. I will talk in depth about key performance indicators that we will use to assess the health of AOL Client streams as well as AOL Instant Messenger and ICQ. The location to glean this data is a number of tap points in front of the AOL Instant Messenger service. This is a staggering 400+ million TCP connects per day and places a veritable "Internet Weather Report" at our fingertips of round trip times, packet loss, latency and stability. This monitoring infrastructure will work as an "early warning" of negative client and transit network performance. Some other uses for this will be understanding the effects of changes during maintenance windows as well as providing data to compute a "user frustration index" that will give us more insight into client performance than active war dialers have. Richard Nelson richardn(a)cs.waikato.ac.nz WAND Network Research Group

1 0

any help appreciated
by Brett Johanson 03 May '05

03 May '05

Hello Im looking into setting up a data center, and am looking to peer with the ape, i was wondering how i can do this i am also applying for some IP space from apnic and having a little trouble setting up the PERSOn as it keeps failing. Any Help on this matter would be appreciated i just really need to know what to do to peer with the ape router recommendations etc Cheers _________________________________________________________________ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html

6 7

Notification of NZRR Database changes
by NZRR Database Notifications 02 May '05

02 May '05

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 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. --- PREVIOUS OBJECT: filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes. filter: {1.0.0.0/8^+, 2.0.0.0/8^+, 5.0.0.0/8^+, 7.0.0.0/8^+, 23.0.0.0/8^+, 27.0.0.0/8^+, 31.0.0.0/8^+, 36.0.0.0/8^+, 37.0.0.0/8^+, 39.0.0.0/8^+, 41.0.0.0/8^+, 42.0.0.0/8^+, 49.0.0.0/8^+, 50.0.0.0/8^+, 73.0.0.0/8^+, 74.0.0.0/8^+, 75.0.0.0/8^+, 76.0.0.0/8^+, 77.0.0.0/8^+, 78.0.0.0/8^+, 79.0.0.0/8^+, 89.0.0.0/8^+, 90.0.0.0/8^+, 91.0.0.0/8^+, 92.0.0.0/8^+, 93.0.0.0/8^+, 94.0.0.0/8^+, 95.0.0.0/8^+, 96.0.0.0/8^+, 97.0.0.0/8^+, 98.0.0.0/8^+, 99.0.0.0/8^+, 100.0.0.0/8^+, 101.0.0.0/8^+, 102.0.0.0/8^+, 103.0.0.0/8^+, 104.0.0.0/8^+, 105.0.0.0/8^+, 106.0.0.0/8^+, 107.0.0.0/8^+, 108.0.0.0/8^+, 109.0.0.0/8^+, 110.0.0.0/8^+, 111.0.0.0/8^+, 112.0.0.0/8^+, 113.0.0.0/8^+, 114.0.0.0/8^+, 115.0.0.0/8^+, 116.0.0.0/8^+, 117.0.0.0/8^+, 118.0.0.0/8^+, 119.0.0.0/8^+, 120.0.0.0/8^+, 121.0.0.0/8^+, 122.0.0.0/8^+, 123.0.0.0/8^+, 124.0.0.0/8^+, 125.0.0.0/8^+, 126.0.0.0/8^+, 173.0.0.0/8^+, 174.0.0.0/8^+, 175.0.0.0/8^+, 176.0.0.0/8^+, 177.0.0.0/8^+, 178.0.0.0/8^+, 179.0.0.0/8^+, 180.0.0.0/8^+, 181.0.0.0/8^+, 182.0.0.0/8^+, 183.0.0.0/8^+, 184.0.0.0/8^+, 185.0.0.0/8^+, 186.0.0.0/8^+, 187.0.0.0/8^+, 189.0.0.0/8^+, 190.0.0.0/8^+, 197.0.0.0/8^+, 223.0.0.0/8^+} remarks: For the complete set of bogons, please see: fltr-martians - special use and reserved prefixes. fltr-bogons - fltr-unallocated + fltr-martian. http://www.cymru.com/Documents/bogon-list.html admin-c: RTH32-ARIN tech-c: RTH32-ARIN notify: radb(a)cymru.com notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-BOGON-FILTERS changed: rpsl-admin(a)nzix.net 20040819 source: NZRR REPLACED BY: filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes. filter: {1.0.0.0/8^+, 2.0.0.0/8^+, 5.0.0.0/8^+, 7.0.0.0/8^+, 23.0.0.0/8^+, 27.0.0.0/8^+, 31.0.0.0/8^+, 36.0.0.0/8^+, 37.0.0.0/8^+, 39.0.0.0/8^+, 42.0.0.0/8^+, 49.0.0.0/8^+, 50.0.0.0/8^+, 74.0.0.0/8^+, 75.0.0.0/8^+, 76.0.0.0/8^+, 77.0.0.0/8^+, 78.0.0.0/8^+, 79.0.0.0/8^+, 89.0.0.0/8^+, 90.0.0.0/8^+, 91.0.0.0/8^+, 92.0.0.0/8^+, 93.0.0.0/8^+, 94.0.0.0/8^+, 95.0.0.0/8^+, 96.0.0.0/8^+, 97.0.0.0/8^+, 98.0.0.0/8^+, 99.0.0.0/8^+, 100.0.0.0/8^+, 101.0.0.0/8^+, 102.0.0.0/8^+, 103.0.0.0/8^+, 104.0.0.0/8^+, 105.0.0.0/8^+, 106.0.0.0/8^+, 107.0.0.0/8^+, 108.0.0.0/8^+, 109.0.0.0/8^+, 110.0.0.0/8^+, 111.0.0.0/8^+, 112.0.0.0/8^+, 113.0.0.0/8^+, 114.0.0.0/8^+, 115.0.0.0/8^+, 116.0.0.0/8^+, 117.0.0.0/8^+, 118.0.0.0/8^+, 119.0.0.0/8^+, 120.0.0.0/8^+, 121.0.0.0/8^+, 122.0.0.0/8^+, 123.0.0.0/8^+, 173.0.0.0/8^+, 174.0.0.0/8^+, 175.0.0.0/8^+, 176.0.0.0/8^+, 177.0.0.0/8^+, 178.0.0.0/8^+, 179.0.0.0/8^+, 180.0.0.0/8^+, 181.0.0.0/8^+, 182.0.0.0/8^+, 183.0.0.0/8^+, 184.0.0.0/8^+, 185.0.0.0/8^+, 186.0.0.0/8^+, 187.0.0.0/8^+, 189.0.0.0/8^+, 190.0.0.0/8^+, 197.0.0.0/8^+, 223.0.0.0/8^+} remarks: For the complete set of bogons, please see: fltr-martians - special use and reserved prefixes. fltr-bogons - fltr-unallocated + fltr-martian. http://www.cymru.com/Documents/bogon-list.html admin-c: RTH32-ARIN tech-c: RTH32-ARIN notify: radb(a)cymru.com notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-BOGON-FILTERS changed: rpsl-admin(a)nzix.net 20040819 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 02 May '05

02 May '05

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 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. --- PREVIOUS OBJECT: aut-num: AS2687 as-name: NZRR-AS2687 descr: AT&T Global descr: WIX peering at '202.7.0.49' descr: see Citylink RT job #1979 descr: APE peering at '192.203.154.74' descr: see Citylink RT job #2334 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS2687 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS2687 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: greg.kapp(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050503 source: NZRR REPLACED BY: aut-num: AS2687 as-name: NZRR-AS2687 descr: AT&T Global descr: WIX peering at '202.7.0.49' descr: see Citylink RT job #1979 descr: APE peering at '192.203.154.74' descr: see Citylink RT job #2334 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS2687 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS2687 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: attnzdns(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050503 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 02 May '05

02 May '05

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 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. --- PREVIOUS OBJECT: aut-num: AS2687 as-name: NZRR-AS2687 descr: AT&T descr: APE peering at '192.203.154.74' descr: see Citylink RT job #2334 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS2687 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: Mark.Crawford(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050503 source: NZRR REPLACED BY: aut-num: AS2687 as-name: NZRR-AS2687 descr: AT&T Global descr: WIX peering at '202.7.0.49' descr: see Citylink RT job #1979 descr: APE peering at '192.203.154.74' descr: see Citylink RT job #2334 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS2687 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS2687 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: greg.kapp(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050503 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 02 May '05

02 May '05

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 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. --- PREVIOUS OBJECT: aut-num: AS2687 as-name: NZRR-AS2687 descr: AT&T Global descr: WIX peering at '202.7.0.49' descr: see Citylink RT job #1979 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS2687 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: greg.kapp(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: aut-num: AS2687 as-name: NZRR-AS2687 descr: AT&T descr: APE peering at '192.203.154.74' descr: see Citylink RT job #2334 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS2687 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: Mark.Crawford(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050503 source: NZRR

1 0

The New Zealand Network Operators' Group
by Donald Neal 01 May '05

01 May '05

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, which anyone is free to join. Conference Our next conference is expected to take place in Wellington in the first half of 2006. If you're interested inattending, you have replied to the survey, haven't you? Other Meetings See http://auckland.thursdaynightcurry.com/ or http://wellington.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://nzix.net/ for details of the Auckland, Palmerston North and Wellington exchanges, and some information on others under construction. About This Mailing List This list has around 800 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 "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

NZNOG Conference Survey.
by Simon Lyall 29 Apr '05

29 Apr '05

Below is a series of questions about NZNOG 05 and 06. Please fill out as many questions as you can and feel free to add extra comments wherever. The results will be used to decide when, where and how NZNOG 06 will be run. If you are short of time please fill out the 2006 questions first. Email the filled in version back to simon(a)darkmere.gen.nz . Email me if you have any questions. Answers will be kept confidential. Results will be summarized back to the list. Questions ========= About you --------- Which City/Country do you live/work in : What position do you work in : What does your job involve : Attendance ---------- Did you attend NZNOG 05 ? : Did you attend NZNOG 04 ? : Did you attend earlier NZNOGs? : If you didn't attended NZNOG 05: a. what reasons didn't your attend? b. What would have made you more likely to attend? NZNOG 05 -------- If you attended NZNOG 05 please answer the following questions. 1. Did your employer pay for all or part of the costs? Did they give you time to attend or did you have to take holidays? 2. Please comment on the following, how you feel about them and how important these are to you. General organization: Accommodation: Wednesday night dinner (curry): Thursday Dinner (Official dinner): Internet Access: Other: 3. The main presentations. Abstracts of the presentations and tutorials at nznog05 are at: http://www.nznog.org/tutorial.php http://www.nznog.org/abstract.php a. Can you list things in the programme or the conference that your especially liked. b. Can you list things in the programme or the conference that your especially disliked. c. Do you have any other comments about the programme or running of the conference. NZNOG 06 -------- 1. Are you likely to attend NZNOG 06. 2. Are you likely to attend Linux.conf.au in Dunedin at the end of Jan 06? 3. The following are venues/times that NZNOG might be held. Please rate how likely your are to attend and which you would prefer. a. Wellington in late Jan or Early Feb ( after linux.conf.au) Pro: Overseas people able to go to linux.conf.au and NZNOG Pro: Cheaper Accommodation and Venue Con: Clashes with NANOG or RIPE so harder to get overseas speakers b. Wellington in March or early April Pro: Less clashes with overseas events. Pro: Overseas people able to go to ICANN and NZNOG Con: Most expensive venue and accommodation. 4. Please comment on the following, how you feel about them and how important these are to you. International Speakers: Low cost ( < $500 for programme + accommodation): Types of attendees - Network Operators (people who type BGP commands): - Admins of large websites: - Admins of Large mail servers: - Security Admins at large sites: - Network consultants: - Large ISP technical personal: - Small ISP technical personal: - Programmers (Open source projects): - Script Kiddies: - Vendor sponsored speakers: - Network researchers: - Government Policy people ( eg MOC, CCIP): - Small Hosting providers: - Equipment Vendor salesman: - Students: - Wireless Operators: Official event dinner: Curry Night: Joe and Dean: Wireless Access at event: Nearness to the office: Vendor Booths: Breaks between talks: Start and finish times each day: Wider programme or narrowly focused on Network operators: Single or Multiple streams: Recording and/or broadcast of Events: Giveaways: 4. Please rate on the following topics and make other comments if you like. 5 is "Extremely interested" 3 is "Interested enough to attend" 1 is "I'll work on my minesweeper skills outside" Peering : DNSSEC : Internet Exchange Updates : INOC-DBA : APNIC : Virtual Servers (eg Xen, UML) : Lightning talks : PGP Key Signing party : Mail Servers : DDOS : Network Monitoring : LAMP : Measurement : Government Policy : Wireless : Spam : IPV6 : VOIP : ENUM : Multicast : BGP and other routing protocols : UltraWideband : MPLS : WAN Solutions / VPNs : Fibre Optics : LDAP : Network Measurement : Asset Management for Network Hardware : Network Design Philosophy : Security and Encryption : Web Server Administration : Other(s) (please add) : 5. Are you interested in giving a talk? Talks can be tutorials, 30m-2h presentations or 5-10 minutes lightning talks. Please let us know if you are interested in giving one and if possible what type and what topic(s). 6. Other stuff. Please add other comments, suggestions, feedback etc on what you would like for the 06 conference including possible speakers, talks, events and topics not mentioned above.

1 1

Notification of NZRR Database changes
by NZRR Database Notifications 26 Apr '05

26 Apr '05

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 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. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.16.0/21^21-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.12.248.0/21^21-29, 202.126.80.0/21^21-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.174.160.0/24^24-29, 202.182.192.0/19^19-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.86.0/23^23-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.49.62.0/24^24-29, 202.49.80.0/23^23-29, 202.49.89.0/24^24-29, 202.50.196.0/22^22-29, 202.50.200.0/21^21-29, 202.50.208.0/20^20-29, 202.50.246.0/24^24-29, 202.50.52.0/22^22-29, 202.50.87.0/24^24-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.6.84.0/24^24-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 202.182.192.0/19^19-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.32.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.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: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050427 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.16.0/21^21-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.12.248.0/21^21-29, 202.126.80.0/21^21-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.174.160.0/24^24-29, 202.182.192.0/19^19-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.86.0/23^23-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.49.62.0/24^24-29, 202.49.80.0/23^23-29, 202.49.89.0/24^24-29, 202.50.196.0/22^22-29, 202.50.200.0/21^21-29, 202.50.208.0/20^20-29, 202.50.246.0/24^24-29, 202.50.52.0/22^22-29, 202.50.87.0/24^24-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.6.84.0/24^24-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 202.182.192.0/19^19-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.32.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.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: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050427 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 21 Apr '05

21 Apr '05

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 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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by ihug - AS7657 members: 192.107.113.0/24, 202.21.130.0/24, 202.21.136.0/23^23-24, 202.36.44.0/24, 202.36.94.0/23^23-24, 202.36.230.0/23^23-24, 202.37.182.0/24, 202.49.33.0/24, 202.49.46.0/23^23-24, 202.49.63.0/24, 202.49.64.0/24, 202.49.140.0/24, 202.49.148.0/23^23-24, 202.49.176.0/23^23-24, 202.49.178.0/24, 202.49.180.0/23^23-24, 202.49.186.0/24, 202.49.249.0/24, 202.50.84.0/24, 202.50.103.0/24, 202.50.188.0/22^22-24, 202.50.255.0/24, 203.96.192.0/19^19-24, 203.109.128.0/17^17-24, 203.118.128.0/18^18-24, 203.173.128.0/17^17-24, 210.55.110.0/24, 210.55.184.0/24, 210.55.202.0/23^23-24, 210.55.248.0/21^21-24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by ihug - AS7657 members: 192.107.113.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.44.0/24^24-29, 202.36.94.0/23^23-29, 202.36.95.0/24^24-29, 202.36.230.0/24^24-29, 202.36.231.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.46.0/23^23-29, 202.49.63.0/24^24-29, 202.49.148.0/24^24-29, 202.49.148.0/23^23-29, 202.49.149.0/24^24-29, 202.49.178.0/24^24-29, 202.49.180.0/23^23-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.188.0/22^22-29, 202.50.255.0/24^24-29, 203.96.192.0/24^24-29, 203.96.192.0/19^19-29, 203.96.193.0/24^24-29, 203.96.212.0/23^23-29, 203.96.220.0/24^24-29, 203.96.223.0/24^24-29, 203.109.132.0/22^22-29, 203.109.133.0/24^24-29, 203.109.134.0/24^24-29, 203.109.135.0/24^24-29, 203.109.144.0/24^24-29, 203.109.144.0/20^20-29, 203.109.146.0/24^24-29, 203.109.150.0/24^24-29, 203.109.155.0/24^24-29, 203.109.157.0/24^24-29, 203.109.158.0/24^24-29, 203.109.163.0/24^24-29, 203.109.192.0/22^22-29, 203.109.192.0/21^21-29, 203.109.198.0/24^24-29, 203.109.199.0/24^24-29, 203.109.230.0/24^24-29, 203.109.233.0/24^24-29, 203.109.252.0/22^22-29, 203.109.253.0/24^24-29, 203.109.255.0/24^24-29, 203.118.128.0/20^20-29, 203.118.130.0/23^23-29, 203.118.132.0/23^23-29, 203.118.136.0/24^24-29, 203.118.144.0/24^24-29, 203.118.144.0/20^20-29, 203.118.147.0/24^24-29, 203.118.148.0/24^24-29, 203.118.150.0/24^24-29, 203.118.154.0/24^24-29, 203.118.155.0/24^24-29, 203.118.157.0/24^24-29, 203.118.158.0/24^24-29, 203.118.159.0/24^24-29, 203.118.160.0/20^20-29, 203.118.161.0/24^24-29, 203.118.164.0/22^22-29, 203.118.168.0/21^21-29, 203.118.176.0/24^24-29, 203.118.176.0/23^23-29, 203.118.177.0/24^24-29, 203.118.178.0/24^24-29, 203.118.179.0/24^24-29, 203.118.180.0/24^24-29, 203.118.181.0/24^24-29, 203.118.182.0/24^24-29, 203.118.183.0/24^24-29, 203.118.184.0/24^24-29, 203.118.185.0/24^24-29, 203.118.186.0/24^24-29, 203.118.187.0/24^24-29, 203.118.188.0/24^24-29, 203.118.189.0/24^24-29, 203.118.190.0/24^24-29, 203.118.191.0/24^24-29, 203.173.140.0/22^22-29, 203.173.146.0/23^23-29, 203.173.148.0/22^22-29, 203.173.152.0/22^22-29, 203.173.160.0/24^24-29, 203.173.161.0/24^24-29, 203.173.164.0/22^22-29, 203.173.168.0/23^23-29, 203.173.170.0/23^23-29, 203.173.172.0/22^22-29, 203.173.188.0/22^22-29, 203.173.192.0/19^19-29, 203.173.224.0/20^20-29, 203.173.240.0/21^21-29, 203.173.248.0/21^21-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29, 202.126.80.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 192.107.113.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 192.107.113.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.21.130.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.21.130.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.21.136.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.21.136.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.36.44.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.36.44.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.36.94.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.36.94.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.37.182.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.37.182.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.49.33.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.49.33.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.49.46.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.49.46.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.49.63.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.49.63.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.49.148.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.49.148.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.49.178.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.49.178.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.49.180.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.49.180.0/23 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.49.186.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.49.186.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.49.249.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.49.249.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.50.84.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.50.84.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.50.103.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.50.103.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.50.188.0/22 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.50.188.0/22 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 202.50.255.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.50.255.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 203.96.192.0/19 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 203.96.192.0/19 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 210.55.110.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 210.55.110.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route: 210.55.184.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 210.55.184.0/24 descr: Route for ihug - AS7657 origin: AS7657 notify: rpsl-admin(a)nzix.net notify: michael.zhang(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050419 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.16.0/21^21-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.12.248.0/21^21-29, 202.126.80.0/21^21-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.174.160.0/24^24-29, 202.182.192.0/19^19-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.86.0/23^23-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.49.62.0/24^24-29, 202.49.80.0/23^23-29, 202.49.89.0/24^24-29, 202.50.196.0/22^22-29, 202.50.200.0/21^21-29, 202.50.208.0/20^20-29, 202.50.246.0/24^24-29, 202.50.52.0/22^22-29, 202.50.87.0/24^24-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.6.84.0/24^24-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050419 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 138.235.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.16.0/21^21-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.12.248.0/21^21-29, 202.126.80.0/21^21-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.174.160.0/24^24-29, 202.182.192.0/19^19-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.86.0/23^23-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.49.62.0/24^24-29, 202.49.80.0/23^23-29, 202.49.89.0/24^24-29, 202.50.196.0/22^22-29, 202.50.200.0/21^21-29, 202.50.208.0/20^20-29, 202.50.246.0/24^24-29, 202.50.52.0/22^22-29, 202.50.87.0/24^24-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.6.84.0/24^24-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050422 source: NZRR

6 7

ICONZ prefix update 20050422
by John Johnston 20 Apr '05

20 Apr '05

AS: 4770 APE: 192.203.154.44 WIX: 202.7.1.1 Hey all, For all those that peer direct with ICONZ there is another update. Please apply the full list as there have been a few additions. Current list is attached or goto http://www.iconz.net/prefix Regards John Johnston Network Engineering Manager ICONZ New Zealand Limited DDI: +64 9 977 3500 FAX: +64 9 977 3535 Mobile: 021 277 5692 Email: john.johnston(a)iconz.net 0800 THE NET www.iconz.net

1 0

RIPE NCC to begin allocating from 87/8
by leo vegoda 20 Apr '05

20 Apr '05

Dear Colleagues, This announcement is being sent to multiple lists. I apologise for duplicates. The RIPE NCC received the IPv4 address range 85.0.0.0 - 88.255.255.255 (85/8, 86/7 and 88/8) from the IANA in April 2004. We began making allocation from 85/8 in August 2004 and from 86/8 in March, this year. We expect to start making allocations from 87/8 in the next few weeks. We have been announcing two prefixes from 87/8: 87.192.0.0/16 and 87.255.248.0/21, which originated in AS12654. These announcements have now been withdrawn as we will start to allocate from this /8. We are currently announcing two prefixes from 88/8, from which we will allocate in a few months. Those announcements are: 88.192.0.0/16 and 88.255.248.0/21, originating in AS12654. Details of the BGP announcements, reachability tools and other information are available on our web site at: http://www.ris.ripe.net/debogon/debogon.html You may want to update any filters you have in place. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 19 Apr '05

19 Apr '05

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 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. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64562 descr: advertised to AS9439 by Liverton Limited - AS64562 members: 210.48.106.96/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: james.scott(a)liverton.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050113 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64562 descr: advertised to AS9439 by Liverton Limited - AS64562 members: 202.160.49.32/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: james.scott(a)liverton.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050420 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS24005 descr: advertised to AS9439 by SafeNZ Networks Limited - AS24005 members: 203.98.6.0/24^24-29, 203.97.68.0/28^28-29, 219.88.140.0/24^24-29, 60.234.32.0/23^23-29, 219.88.140.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: tonyw(a)tonyw.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS24005 descr: advertised to AS9439 by safenz networks limited - AS24005 members: 203.98.6.0/24^24-29, 203.97.68.0/28^28-29, 219.88.140.0/24^24-29, 60.234.32.0/23^23-29, 202.137.240.0/21^21-29, 202.50.252.0/24^24-29, 203.167.254.0/24^24-29, 203.167.255.0/24^24-29, 203.97.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: tonyw(a)tonyw.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050420 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 18 Apr '05

18 Apr '05

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 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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050419 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050419 source: NZRR

1 0

HEADS UP - Webcasting Activity -> V8 debate
by Richard Naylor 17 Apr '05

17 Apr '05

It appears that R2.co.nz will be webcasting the Public Meeting to discuss the proposal that Wellington Host a leg of the V8 Supercar Championships. The meeting is tomorrow night 19 April at 7pm The webcast server will be located on WIX and network operators may experience a frenzy of petrolheads wanting to watch their team win. Or hassling their Help Desks that nothing works. Operators not currently peering at WIX should contact CityLink if they would like assistance with peering. WARNING - we have included a 2Mbps stream for broadcast use. Broadcast operators should contact me if they have any special requirements. Thank you for your co-operation. Richard aka richard.naylor(a)r2.co.nz

1 0

Jetstream Partnering Program
by Blair Harrison 17 Apr '05

17 Apr '05

Hi All, I'm just wondering if there are any ISPs out there still on the Jetstream Partnering Program who haven't signed the WSA or made other arrangements for their Jetstream customers yet? Offlist replies are fine :) Regards, Blair Harrison Systems Administrator WISE Net | http://wise.net.nz

1 0

ICONZ prefix update 2005-04-18
by John Johnston 17 Apr '05

17 Apr '05

AS: 4770 APE: 192.203.154.44 WIX: 202.7.1.1 Hey all, For all those that peer direct with ICONZ here is an update Add prefix 202.126.80.0/21 Current list is attached or goto http://www.iconz.net/prefix Regards John Johnston Network Engineering Manager ICONZ New Zealand Limited DDI: +64 9 977 3500 FAX: +64 9 977 3535 Mobile: 021 277 5692 Email: john.johnston(a)iconz.net 0800 THE NET www.iconz.net

1 0

OT: Anyone on the list from AU?
by Barry Murphy 16 Apr '05

16 Apr '05

Hey guys, Sorry for this post, but is anyone on this list situated in Oz? I'm currently building an ISPmap for Oz and require a help/regional admin in Oz to help update the map. Thanks Barry

1 0

IANA IPv4 allocations and bogon update: 41/8
by Rob Thomas 13 Apr '05

13 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- [ Apologies to those of you who receive this note in multiple forums. ] Hi, team. The numerous Team Cymru bogon projects have been updated as of 13 APR 2005 to reflect the following IANA allocation made on 12 APR 2005: 041/8 Apr 05 AfriNIC (whois.afrinic.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-template.htm> Secure JUNOS BGP Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter- Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter- loose.htm> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter- strict.htm> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Bogus ASN monitoring - <http://www.cymru.com/BGP/asnbogusrep.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thank you for your continued support. Rob. - -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty); -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQl578FkX3QAo5sgJAQEBUQQAhxlGUyzcvxzHVF2/PHZt27K04nSCxSWu k0G70eCN6QRib3h9HIlz3GCu24aBPJMcM+zH6SOGjydVHsDFJFFGuw42HcTWAttV 35nbzeN4jqBQQZGtel3he+lNPcd60uHloE3za/4F6P/flBrl2S3peoCo4TpxDnfe RoBcAod+aTQ= =74Xj -----END PGP SIGNATURE-----

1 0

DNS + IPv6
by Philip D'Ath 10 Apr '05

10 Apr '05

I'm doing some work with IPv6 at the moment, and one of the upcoming tasks I'm going to need to do is get a couple of IPv6 DNS servers online. Can someone tell me if the NZ SRS supports IPv6 glue records? Specifically, can I register the AAAA NS records?

3 2

Re: [nznog] Trade Me peering via the APE and WIX route servers
by Andy Linton 07 Apr '05

07 Apr '05

Trademe are announcing their network to both APE and WIX. Their preference is to route packets via the WIX as they're based in Wellington so we've path stuffed the APE announcement so that dual APE/WIX homed entities favour the WIX. This is also so that paths can be symmetric as return packets from Trademe will favour the WIX where they can. Some of you who peer at the APE and WIX may still be favouring announcements from your upstream provider and in many cases these will be links that you pay charges which are related to usage in some way. If I were in your shoes I'd be constructing some BGP policy tweaks to favour APE routes over routes from a link I was paying for regardless of AS path. I've added two community strings to the announcements of 202.21.128.0/24 via AS24078 which may help: 24078:9439 announced via WIX 24078:9560 announced via APE

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 07 Apr '05

07 Apr '05

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 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. --- PREVIOUS OBJECT: aut-num: AS24078 as-name: NZRR-AS24078 descr: TradeMe descr: APE peering at '192.203.154.18' descr: see Citylink RT job #2209 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24078 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050408 source: NZRR REPLACED BY: aut-num: AS24078 as-name: NZRR-AS24078 descr: TradeMe descr: APE peering at '192.203.154.18' descr: see Citylink RT job #2209 descr: WIX peering at '202.7.1.67' descr: see Citylink RT job #359 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24078 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24078 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050408 source: NZRR

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 07 Apr '05

07 Apr '05

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 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. --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS24078 descr: Route set advertised to AS9560 by TradeMe - AS24078 members: 202.21.128.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: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050408 source: NZRR

1 0

Russell Brown interviews Raymond O'Brien
by Simon Lyall 06 Apr '05

06 Apr '05

from TelstraClear on peering. http://www.darkmere.gen.nz/temp/rb_raymondobrien-2005-04-06.mp3 -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

2 1

RE: [nznog] Seminar on UWB
by Donald Neal 05 Apr '05

05 Apr '05

> -----Original Message----- > From: Steve Phillips [mailto:steve(a)focb.co.nz] > Sent: Wednesday, 6 April 2005 9:05 p.m. > To: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Seminar on UWB > > > wasn't this posted earlier today ? > At the time I acted on the request I received to post it, I hadn't noticed that it had already been posted. My apologues for any confusion caused. - Donald Neal Donald Neal |"Do not use your laptop in a wet Support Engineer |environment unless it operates on NGN Operations |batteries." 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

Seminar on UWB
by Donald Neal 05 Apr '05

05 Apr '05

This announcement is posted on behalf of the Ministry for Economic Development. - - - - - Dear industry colleagues, Ultra Wide Band (UWB) is a new wireless technology developed to transmit large amounts of data over very short distances. UWB devices are designed to operate at very low power levels, enabling them in theory, to share spectrum with traditionally licensed services over a wide range of frequencies without adverse impact to those services. Potential applications of UWB are high-speed wireless networking in the workplace or at home, ground penetrating radar for geological surveys and search and rescue, wall penetrating imaging in construction, vehicular radar for collision avoidance, medical imaging, and hand-held communication and measurement systems. The Ministry is in the process of preparing an engineering discussion paper seeking submissions from the industry and stakeholders, on spectrum allocation and technical standards for UWB devices. In conjuction with this paper, the Ministry is planning to hold seminars in Auckland and Wellington to clarify and discuss issues raised. The details of the seminars are given below: Auckland 10 am Friday 15 April 2005 Stamford Plaza 22 Albert St, Auckland Central Wellington 10 am Wednesday 20 April 2005 Rangi Marie Room 1 Te Papa Cable st Wellington Confirmation of your attendance together with your choice of venue should be sent to <mailto:radiospectrum(a)med.govt.nz> mailto:radiospectrum(a)med.govt.nz Please feel free to circulate this message to any additional persons who you feel may have an interest in this topic. The Ministry expects to publish the discussion paper prior to the seminar dates. Kind Regards, Chris Perera Senior Planning Analyst Radio Spectrum Policy & Planning The Ministry of Economic Development 33, Bowen St, Wellington, New Zealand DDI: +64-4-462 4279 Fax: +64-4-499 0969 email: <mailto:chris.perera(a)med.govt.nz> chris.perera(a)med.govt.nz http://www.govt.nz - connecting you to New Zealand central & local government services Any opinions expressed in this message are not necessarily those of the Ministry of Economic Development. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivery to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Please contact the sender and delete the message and any attachment from your computer. "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."

3 2

Seminar on UWB (fwd)
by Jamie Curtis 05 Apr '05

05 Apr '05

Forwarded by request from Chris Perera (a speaker at the last NZNOG conference for those of you not there). ---------- Forwarded message ---------- Date: Wed, 6 Apr 2005 11:01:33 +1200 From: Chris Perera <chris.perera(a)med.govt.nz> Subject: Seminar on UWB Dear industry colleagues, Ultra Wide Band (UWB) is a new wireless technology developed to transmit large amounts of data over very short distances. UWB devices are designed to operate at very low power levels, enabling them in theory, to share spectrum with traditionally licensed services over a wide range of frequencies without adverse impact to those services. Potential applications of UWB are high-speed wireless networking in the workplace or at home, ground penetrating radar for geological surveys and search and rescue, wall penetrating imaging in construction, vehicular radar for collision avoidance, medical imaging, and hand-held communication and measurement systems. The Ministry is in the process of preparing an engineering discussion paper seeking submissions from the industry and stakeholders, on spectrum allocation and technical standards for UWB devices. In conjuction with this paper, the Ministry is planning to hold seminars in Auckland and Wellington to clarify and discuss issues raised. The details of the seminars are given below: Auckland 10 am Friday 15 April 2005 Stamford Plaza 22 Albert St, Auckland Central Wellington 10 am Wednesday 20 April 2005 Rangi Marie Room 1 Te Papa Cable st Wellington Confirmation of your attendance together with your choice of venue should be sent to <mailto:radiospectrum(a)med.govt.nz> mailto:radiospectrum(a)med.govt.nz Please feel free to circulate this message to any additional persons who you feel may have an interest in this topic. The Ministry expects to publish the discussion paper prior to the seminar dates. Kind Regards, Chris Perera Senior Planning Analyst Radio Spectrum Policy & Planning The Ministry of Economic Development 33, Bowen St, Wellington, New Zealand DDI: +64-4-462 4279 Fax: +64-4-499 0969 email: <mailto:chris.perera(a)med.govt.nz> chris.perera(a)med.govt.nz http://www.govt.nz - connecting you to New Zealand central & local government services Any opinions expressed in this message are not necessarily those of the Ministry of Economic Development. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivery to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Please contact the sender and delete the message and any attachment from your computer.

1 0

RFC1918 Addresses in routing paths
by Jonathan Brewer 04 Apr '05

04 Apr '05

Hi Folks, I am wondering about the etiquette of reporting RFC1918 addresses back to hosts performing a traceroute. Example below: Hostname 1. ourhost.ourprovider.net.nz 2. f3-0-2.core1.wlg.ourprovider.net.nz 3. f0-0-4.core3.wlg.ourprovider.net.nz 4. f4-0-5.core2.akl.ourprovider.net.nz 5. g1-0-1396.u12.brfd.otherprovider.net.nz 6. g1-0-1043.u12.brh.otherprovider.net.nz 7. 10.65.32.1 8. 10.65.32.250 9. 10.69.0.2 10. a12-3-23.u21.tar.otherprovider.net.nz 11. fa7-4-1042.bigrouter.otherprovider.net.nz 12. otherhost.otherprovider.net.nz Any comments on this practice? Cheers, Jon ------------------------------------ Araneo Limited info (at) araneo.net.nz 5th Floor Central House 26 Brandon Street Wellington, New Zealand tel: +64-4-473-3932 fax: +64-4-472-0960 http://www.araneo.net.nz ------------------------------------

7 7

Notification of NZRR Database changes
by NZRR Database Notifications 31 Mar '05

31 Mar '05

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 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. --- OBJECT BELOW CREATED: aut-num: AS24386 as-name: NZRR-AS24386 descr: Networker descr: APE peering at '192.203.154.15' descr: see Citylink RT job #2115 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24386 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: simon(a)networker.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050401 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS24386 descr: Route set advertised to AS9560 by Networker - AS24386 members: 203.109.148.24/29, 203.109.194.16/28^28-29, 203.118.128.32/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: simon(a)networker.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050401 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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 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. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: SIX peering at '218.100.25.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24387 accept ANY AND NOT fltr-bogons export: to AS24387 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: SMARTLINX3 peering at '218.100.26.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24385 accept ANY AND NOT fltr-bogons export: to AS24385 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR --- OBJECT BELOW CREATED: route-set: AS24385:RS-ROUTES:AS23754 descr: Route set advertised to AS24385 by CityLink - AS23754 members: 202.8.44.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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 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. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: CHIX peering at '218.100.24.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24388 accept ANY AND NOT fltr-bogons export: to AS24388 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: SIX peering at '218.100.25.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24387 accept ANY AND NOT fltr-bogons export: to AS24387 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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 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. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: SIX peering at '218.100.25.2' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24387 accept ANY AND NOT fltr-bogons export: to AS24387 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: CHIX peering at '218.100.24.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24388 accept ANY AND NOT fltr-bogons export: to AS24388 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR --- OBJECT BELOW CREATED: route-set: AS24388:RS-ROUTES:AS23754 descr: Route set advertised to AS24388 by CityLink - AS23754 members: 202.8.44.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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 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. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: DPE peering at '218.100.23.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24384 accept ANY AND NOT fltr-bogons export: to AS24384 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: SIX peering at '218.100.25.2' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24387 accept ANY AND NOT fltr-bogons export: to AS24387 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR --- OBJECT BELOW CREATED: route-set: AS24387:RS-ROUTES:AS23754 descr: Route set advertised to AS24387 by CityLink - AS23754 members: 202.8.44.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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 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. --- OBJECT BELOW CREATED: route-set: AS24384:RS-ROUTES:AS23755 descr: Route set advertised to AS24384 by CityLink - AS23755 members: 202.8.44.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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 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. --- PREVIOUS OBJECT: route: 202.8.44.0/22 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 REPLACED BY: route: 202.8.44.0/22 descr: Route for CityLink - AS23754 origin: AS23754 notify: rpsl-admin(a)nzix.net notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR --- OBJECT BELOW CREATED: route-set: AS24384:RS-ROUTES:AS23754 descr: Route set advertised to AS24384 by CityLink - AS23754 members: 202.8.44.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

IANA IPv4 allocations and bogon update: 73/8
by Rob Thomas 30 Mar '05

30 Mar '05

-----BEGIN PGP SIGNED MESSAGE----- [ Apologies to those of you who receive this note in multiple forums. ] Hi, team. The numerous Team Cymru bogon projects have been updated as of 30 MAR 2005 to reflect the following IANA allocation made on 30 MAR 2005: 073/8 Mar 05 ARIN (whois.arin.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-template.htm> Secure JUNOS BGP Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Bogus ASN monitoring - <http://www.cymru.com/BGP/asnbogusrep.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thank you for your continued support. Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQks9clkX3QAo5sgJAQFCHgP/V6mR3gVMiNQ5bvkfSgsT5nkIw0bn2BJA nE4qKGQrB22WL6t83PMsMONjW7GvHJA7Ds4DVgVggTUBJ/SqupM1xQ3SBwEokHcW oydTMiUrsS1dmZMdoLoSHNdGC6hLciTgYayIO/EBI9IGoQYdR/swzgjzHXkLWghO 0C67MWkIT7M= =+ixP -----END PGP SIGNATURE-----

1 0

Wassenaar Agreement and strong crypto exports
by neil gardner 29 Mar '05

29 Mar '05

Hi guys - this isn't strictly operational but I think it's an appropriate audience. As per the subject, I'm after current info about experiences with MFAT over the export of strong crypto, either as software, or embedded in hardware. The online references I can find (Some listed below) are reasonably old and I was hoping there had been some change. (I quote from a 1997 letter from Sec Foreign affairs and trade - Mr Borrie) "This sort of product (encrpytion software) is considered a "dual use" good in terms of the New Zealand Export Controls which means that they are able to be adapted for military, terrorist or criminal use" (I could adapt a plastic spoon for criminal use - but that's beside the point!) Source : http://www.cs.auckland.ac.nz/~pgut001/policy/mfat_2r.html I looked at the MFAT site and they still list encryption software on their "New Zealand Strategic Goods List Index of Controlled Goods" page. Source : http://www.mfat.govt.nz/foreign/dis/nzsgl/pages/laste.html So I guess my question is does anyone know if they have relaxed their approach to 3DES (or even AES-xxx) given that these 'technologies' are freely available internationally, and that 128bit encryption has been effectively opened way up by international adoption in browsers? I'm happy to summarise if there's a bit of feedback. Cheers - Neil Gardner. 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

[enum-sg] Request to be invited to a workshop on ENUM policy for New Zealand (Draft)
by Peter Macaulay 29 Mar '05

29 Mar '05

In Auckland, on April 13 2005, at SkyCity, InternetNZ is hosting a one day workshop on ENUM policy for New Zealand. Chaired by Tony Holmes, a globally known speaker on ENUM issues, the workshop is for all those who will be involved in decisions about implementation of ENUM in New Zealand, or who have a commercial or technical interest. InternetNZ is in the process of developing some components for an ENUM trial which will be shown at a later workshop. More details will be published in the next few days, and will be echoed on the InternetNZ website. Places are limited. Please respond to office(a)internetnz.net.nz so your request can be considered. DRAFT AGENDA: Desired Outcome: A foundation and way forward for trialling ENUM in New Zealand 1. INTRODUCTIONS 2. AIM OF THE WORKSHOP To determine: - Why should there be a trial - what questions are we setting out to answer? - What are the objectives of the trial? - What needs to happen before a trial can take place? - Who needs to be involved in a trial? - Who will administer the trial? - What are the deliverables of the trial? 3. THE DELEGATION OF 4.6.e164.arpa - Tony Holmes: UK Experience 4. EXPERIENCE OF OTHER TRIALS - Tony Holmes: Experience of UK and other jurisdictions 5. MAXIMISING BENEFITS FROM STANDARDS - Tony Holmes: Overview of the role of standards to be applied in a trial 6. UNIVERSAL COMMUNICATIONS IDENTIFIERS (UCI) and PERSONAL USER AGENTS (PUA) - Micheal Sutton. An Overview of the assignment 7. SOME ADDITIONAL PERSPECTIVES - Regulatory perspectives - Variations on the use of .arpa for ENUM that are occurring in the US and the UK 8. THE WAY FORWARD FOR NZ - issues - what needs to be done - who needs to be involved - actions - timeframe 9. Concluding Summation -- *Peter Macaulay* /Executive Director/ *InternetNZ */Direct +64 4 495 2113 Skype petermacaulay Mobile +64 21 488 485 / _______________________________________________ enum-sg mailing list enum-sg(a)internetnz.net.nz http://farsight.internetnz.net.nz/mailman/listinfo/enum-sg

1 0

HEADS UP - Upcoming webcast
by Richard Naylor 28 Mar '05

28 Mar '05

Evening All, This is a slightly late-ish advisory that R2.co.nz will be webcasting the NZ Secondary Schools Rowing Championships from Lake Kaipiro on 8 and 9 April. The webcast servers are located at both APE and WIX and network operators may experience a frenzy of teenagers wanting to watch their team win. Or hassling their Help Desks that nothing works. Operators not currently peering at APE or WIX should contact CityLink if they would like assistance with peering. During the webcast, we will be attempting to do the event live, as well as uploading a recorded version of each race, so that folks can relive those few moments of glory. This will add to the potential traffic experienced on the day(s). Thank you for your co-operation. Richard aka richard.naylor(a)r2.co.nz

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 22 Mar '05

22 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2128] Routing updates for APE Route Servers (fwd) - Date: Wed, 23 Mar 2005 16:49:23 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0503231649060.23389(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.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: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 22 Mar '05

22 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2129] Routing updates for WIX Route Servers (fwd) - Date: Wed, 23 Mar 2005 16:48:32 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0503231648120.23389(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.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: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR

1 0

telecom planning to break VoIP over its network?
by Joe Abley 21 Mar '05

21 Mar '05

http://www.pbs.org/cringely/pulpit/pulpit20050317.html "And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."

18 22

SANOG 6 in Thumpu, Bhutan, 16-23 July 2005
by Joe Abley 20 Mar '05

20 Mar '05

SANOG VI 16-23 July, 2005 Thimphu, Bhutan SANOG VI Program and Fellowship Announcement SANOG VI program and agenda are now published on <http://www.sanog.org/sanog6/>. SANOG VI is being held in Thimphu, Bhutan from 16-23 July, 2005. You can refer to <www.sanog.org/sanog6/> for details. Program and Agenda SANOG VI program incorporates the following: Three hands-on workshops (16-20 July 2005) - IP Services Workshop - ISP Routing and BGP Multihoming Workshop - ISP and NSP Security Workshop, Tutorials (21-22 July 2005) - BGP and High Availability Routing Workshop by Juniper - VOIP and SIP Deployment - ISP and Network Security - IP Networks and Wireless Architecture - Netflow / Flowtools - DNS and DNSSec deployment Birds-of-a-Feather (22 July 2005) - Regional Updates BoF - APNIC BoF Full Day Conference Program (23 July 2005) - Routing and Internet Operations - Network Architecture and - Application Deployment Additional Programs: (21-23 July 2005) - APNIC Regional policy update - APNIC hostmaster Consultation SANOG VI Fellowship Annoucement SANOG VI is also pleased to annouce the fellowship program with support of the Internet Society and Network Startup Resource Center (NSRC). SANOG VI fellows will received a maximum of USD 500 towards air fare and local accomodation during the event. You can find more information about the fellowship program from the SANOG Fellowship Site at <http://www.sanog.org/fellowship/>. SANOG VI Call for Papers SANOG VI Call for papers for the conference is available online at <http://www.sanog.org/sanog6/cfp.htm>. Everyone is Welcome We expect a huge turn out from the region at this SANOG meeting owing to the popularity at previous meets. With more involvement of APNIC in the content of overall program, We hope you would be able to make it to this meeting. The meeting is open to everyone from the operational community, and thus anyone who wants to find out more about Internet operations in South Asia is welcome. You can register for SANOG by sending in the form available at <www.sanog.org/sanog6/> or using the online registration system. Registrations from inside Bhutan can be paid by cheques.

1 0

RE: [nznog] telecom planning to break VoIP over its network?
by Philip D'Ath 20 Mar '05

20 Mar '05

Perhaps you missed the billion dollar announcement they made sometime ago how they are building a new all IP network, and are phasing out most of the old PSTN exchanges. From memory, something like 700 of them are scheduled to be decommissioned. -----Original Message----- Perhaps I phrased that a little off, what I was meaning to insinuate was that they wouldn't be ditching the ole PSTN anytime soon. But hey *shrug* there are alot of varying ideas on that aswell. -Richard _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

OT: WTD: Cisco expert for short job in Sydney, .au.
by Zach Bagnall 20 Mar '05

20 Mar '05

Hey all. We're sending a router (Cisco 831) to a datacentre in Sydney, and need someone to install on site, establish connectivity, and get an IPSec tunnel up. The router has been configured for NAT and IPSec here in NZ, but obviously not tested in the live environment. Probably an hour or so to get connectivity up, and a few more to liase with the techs on the other end of the VPN in order establish that connection. Hoping to get this done in the week following Easter. Any (off-list) personal recommendations appreciated. Zach.

4 3

RE: [nznog] telecom planning to break VoIP over its network?
by Olof Olsson 20 Mar '05

20 Mar '05

All, I believe the only "things" that Telecom have done to-date are: 1. To change the ADSL modulation speed to each subscribers "plan speed" + ATM overhead. For example, the 256/128 kbps plan has an ADSL modulation speed of 320/160 kbps (downstream/upstream). 2. Always have ADSL interleaving on, with a relatively long interleaving delay. Interleaving is used between the ADSL modem and the DSLAM to improve error correction performance against burst errors. The above means: *** An interleaving delay of approximately 28 ms is introduced *** A serialisation delay of approximately 3-50 ms is introduced (64 - 1024 byte packets). In other words, the total one-way latency is approximately 36 - 83 ms depending on packet size. Jitter will of course increase as latency increses. (Packets arriving behind large packets etc.) Which is bad for VoIP. The question is: did Telecom do this to make VoIPoUBS harder to implement? (The latency and jitter could be significantly reduced by lowering the interleaving delay and by not limiting ADSL modulation rates. Interleaving is not needed if the subscribers local loop is of a reasonable quality.) --Olof

1 0

RE: [nznog] telecom planning to break VoIP over its network?
by Philip D'Ath 18 Mar '05

18 Mar '05

This sounds like a porky to me. That's a lot of effort to go to. Telecom are a revenue generating company. Do you spend lots of try trying to devise methods to stop protocols working that you likely to be using yourself long term, or stick to spending your money on developing new products to generate more money. -----Original Message----- From: Joe Abley [mailto:jabley(a)isc.org] Sent: Friday, 18 March 2005 1:26 p.m. To: nznog Subject: [nznog] telecom planning to break VoIP over its network? http://www.pbs.org/cringely/pulpit/pulpit20050317.html "And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice." _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

4 5

RE: [nznog] telecom planning to break VoIP over its network?
by Philip D'Ath 17 Mar '05

17 Mar '05

Its quite the opposite actually. It's much better to drop VoIP packets on VoIP codec streams (aka RTP streams) than it is to queue them. From my experience you can loose about 30% of the packets on a G.711 RTP stream within minimal impact on the voice itself. Queuing them on the other hand causes the jitter buffers to start extending themselves to compensate in the variations in latency caused by the buffer. This leads to a lag between when you speak and you hear the other person responding on the other end responding to you. I find rate limiting works best for UDP and traffic shaping works best for TCP. ps. UDP streaming applications don't re-transmit packets. If your doing something real time and you loose the packet, you loose the packet. This can lead to the video becoming jumpy, or the audio breaking up. -----Original Message----- From: Erin Salmon - Unleash Computers Ltd [mailto:erin(a)unleash.co.nz] Sent: Friday, 18 March 2005 2:40 p.m. To: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] telecom planning to break VoIP over its network? In regards to Craig Spiers' comments, I doubt Telecom would see any amount of processing power as justification not to render VoIP useless on their networks. 20,000 Skype users must be hurting them. I think you can be 99.9% confident that IDGs statements about UBS are correct. Try using a VoIP application on a UBS line, especially during peak times, and you'll see what I mean. In order to cap the speed to 256kbps Telecom does just drop packets. I understand this is a limitation of the current hardware at the exchanges, and that it will be replaced at some point in the future by equipment which can queue packets instead (probably when they roll out ADSL2+). While queuing packets isn't fantastic for VoIP either, it's a step forward from dropping them altogether. Queuing is certainly more efficient for ordinary TCP and even streamed UDP traffic, because data doesn't need to be resent from the source. NZ needs some competition in the Telco market.

1 0

ConceptNET AS17474
by Craig Spiers 17 Mar '05

17 Mar '05

For those of you peering with ConceptNET please update your prefix lists. Changes: Updated 202.150.96.0/20 to 202.150.96.0/19 (currently advertised as 2x /20) Full Prefix List: ip prefix-list conceptnet-domestic-ape description ConceptNET Domestic Routes VIA APE <craig(a)concept.net.nz> ip prefix-list conceptnet-domestic-ape seq 5 permit 202.150.96.0/19 ip prefix-list conceptnet-domestic-ape seq 10 permit 202.127.8.0/22 ip prefix-list conceptnet-domestic-ape seq 15 permit 203.97.44.0/24 ip prefix-list conceptnet-domestic-ape seq 20 permit 202.7.5.32/29 ip prefix-list conceptnet-domestic-ape seq 25 permit 202.7.6.32/29 Regards, Craig - ConceptNET

1 0

Upcoming Webcasts on R2.co.nz
by Richard Naylor 17 Mar '05

17 Mar '05

After a hectic few weeks of webcasts, heres whats coming, so that you can be prepared. Saturday 26 March - a wedding in Carterton. Not expected to cause any major traffic flows. But I'm sure they'll drink beer at the reception (just to keep this on topic). Theres lots of video of the past few events going up at the moment. We hope this will include footage of the 30minute "World of Bendon" dance routine from Girl's Day Out. (is that in our terms of reference ? do I get extra bonus points ?) rich

1 0

Re: Re: [nznog] telecom planning to break VoIP over its network?
by Ian McDonald 17 Mar '05

17 Mar '05

> So why would Telecom behave any different in a LLU world? Because they would have to. > Sure, pick a > metric and we'll be a modest percentage better off, however people will still > be complaining, and we still won't have what we really want. > Depends what you mean by modest percentage. The whole point of LLU is that other companies can start using their own equipment - and they do. Witness the growth in Australia, USA and the UK where LLU along with a heavy regulation environment is seeing much higher speed delivered to users then here in NZ. > Spend the time, effort and money on building networks, not chasing, > implementing and then fighting to actually get something useful from LLU. > I'm an observer, not an ISP but understand what you are saying here. I agree we won't be the same as other countries due to our geography but at least we would achieve real results in Auckland.... (which is not where I live). > Cheers, > Jonny. > > I'll stop here now before it goes (any further) into a flame war. Ian

1 0

Re: Re: [nznog] telecom planning to break VoIP over its network?
by Jonny Martin 17 Mar '05

17 Mar '05

> Of course Telecom will object against LLU as it DOES hurt their bottom > line and they are owned by shareholders. It really has to be a policy > decision by the government. So why would Telecom behave any different in a LLU world? Sure, pick a metric and we'll be a modest percentage better off, however people will still be complaining, and we still won't have what we really want. Spend the time, effort and money on building networks, not chasing, implementing and then fighting to actually get something useful from LLU. Cheers, Jonny.

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2108] Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:22:12 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181521560.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS17474 descr: Route set advertised to AS9439 by ConceptNET - AS17474 members: 202.150.96.0/20^20-29, 203.97.44.0/24^24-29, 202.49.250.0/24^24-29, 202.50.176.0/24^24-29, 202.127.8.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17474 descr: advertised to AS9439 by Craig Spiers - AS17474 members: 202.150.96.0/19^19-29, 202.127.8.0/22^22-29, 203.97.44.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: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2107] Routing updates for APE Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:21:36 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181521180.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/20^20-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.50.176.0/24^24-29, 202.7.6.32/29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/19^19-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.7.5.32/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2105] AutoReply: Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:20:32 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181520070.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9889 descr: Route set advertised to AS9439 by Maxnet - AS9889 members: 202.14.217.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.50.167.0/24^24-29, 202.89.32.0/19^19-29, 210.55.29.0/24^24-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.110.0/24^24-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.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: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2103] Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:18:45 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181518250.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2102] Routing updates for APE Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:18:10 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181517410.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Re: RE: [nznog] telecom planning to break VoIP over its network?
by Jonny Martin 17 Mar '05

17 Mar '05

> NZ needs some competition in the Telco market. I have to disagree with that. There is only one steady state equilibrium in a traditional telco market. We have that already. What we need are more _alternatives_ to telcos. Get out there and build some network. It's not that hard :) Cheers, Jonny.

1 0

Updating the APE and WIX route servers
by Andy Linton 17 Mar '05

17 Mar '05

Can I remind you that when you want us to make changes to the filters which control what you can announce on the exchanges you need to complete the forms at: APE http://ape.nzix.net/cgi-bin/ChangeRoutes.cgi WIX http://wix.nzix.net/cgi-bin/ChangeRoutes.cgi Please note that if you want changes at both exchanges you need to ask explicitly by completing *both* forms. We won't attempt to use telepathy as part of this process.

1 0

ICONZ Prefix list update - 2005-03-18
by John Johnston 17 Mar '05

17 Mar '05

AS: 4770 APE: 192.203.154.44 WIX: 202.7.1.1 Hey all, For all those that peer direct with ICONZ here is an update. Current list is attached or goto http://www.iconz.net/prefix Regards John Johnston Network Engineering Manager ICONZ New Zealand Limited DDI: +64 9 977 3500 FAX: +64 9 977 3535 Mobile: 021 277 5692 Email: john.johnston(a)iconz.net 0800 THE NET www.iconz.net

1 0

Anycast and how it can work for you
by Barry Murphy 17 Mar '05

17 Mar '05

Hey Guys, Just wondering how many providers other than citylink adapt anycast into their network. I decided to write something here to explain to others what it is and how I've implemented it. To start, I run www.fast.co.nz which provides _free_ downloads of open source ISOs and websites. Since certain ISPs decided to depeer the ISP that was hosting my server couldn't fit the bill for this free content, even though it was saving the providers international bandwidth, thus I incorporated anycast. I have a server in Wellington connected to WIX and another on APE. Both servers advertise the IP range 202.7.6.32/29, ovcourse the Auckland server to APE and the Wellington server to WIX, Citylink then advertise the same range at a datacenter in the USA. If a users provider is connected to one of the above exchanges, they are connected to the Server closest to them, if they don't peer at either exchange they are sent to the USA server Where in my case they are forwarded to http://peer.fast.co.nz . In a commercial environment such as Trademe this could be implemented to save money. Trademe Could run it's servers in Wellington the same way they are now, and server the content to anyone That peers at the WIX, they can then advertise the same ip range in the USA and mirror the servers or maybe just an image server for the .jpg, .gif, .png images etc. How does this save money having servers in the USA, well to rent colo space and a p4 2.8gig Server in the USA costs me as little as $80 p/m for 1tb, that's right 1024Gigs worth of data And the connection is very stable. For commercial companies such as Trademe they may require a Little more bandwidth than a TB and support 24/7 etc, so they may pay tops $400 p/m, this would Be a LOT cheaper than buying additional circuits from providers in NZ. How this would effect providers that have depeered? Well lets take stuff for example, we know They push close to 25Mb/s at times, lets add Trademe and say they push 50Mb/s , well this would Mean that the providers that don't peer will be spending a couple hundred thousand $ to provide The content to their users, it would be cheaper for them to just peer. The above is just an explanation of anycast and how it could be used to serve your websites or A way to better manage your network. Any views written to the NZNog are always the view of my own And not those of my peers or employers. Regards Barry

3 2

Recovery of unused address space-implementation
by Elly Tawhai 16 Mar '05

16 Mar '05

Hi, Just forwarding this annoucement made about the Recovery of unused address space-implementation for those from NZ not subscribed to Apnic-announce mailing list. Regards, Elly APNIC * To: apnic-announce(a)apnic.net * Subject: [apnic-talk] [Apnic-announce] Recovery of unused address space -implementation * From: APNIC Secretariat <secretariat(a)apnic.net> * Date: Fri, 18 Feb 2005 11:53:47 +1000 * Cc: * List-archive: <http://www.apnic.net/mailing-lists/apnic-talk> * List-help: <mailto:apnic-talk-request(a)lists.apnic.net?subject=help> * List-id: General discussions on APNIC <apnic-talk.lists.apnic.net> * List-post: <mailto:apnic-talk(a)lists.apnic.net> * List-subscribe: <http://mailman.apnic.net/mailman/listinfo/apnic-talk>,<mailto:apnic-talk-request(a)lists.apnic.net?subject=subscribe> * List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/apnic-talk>,<mailto:apnic-talk-request(a)lists.apnic.net?subject=unsubscribe> * Reply-to: apnic-talk(a)apnic.net * Sender: apnic-announce-bounces(a)lists.apnic.net * User-agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) Dear colleagues, In March 2005, the APNIC Secretariat will implement the policy, "Recovery of unused address space". The policy is described in section 5 of "Policies for historical Internet resources in the APNIC Whois Database" at: http://www.apnic.net/docs/policy/historical-resource-policies.html#5 This policy implements the consensus decision reached at APNIC 17 and endorsed by the Executive Council on 14 May in relation to proposal prop-017-v001. Details of the original proposal and links to discussions are available at: http://www.apnic.net/docs/policy/proposals/prop-017-v001.html For more information about this policy, please see the "Guide to the recovery of unused address space" at: http://www.apnic.net/docs/policy/historical-recovery-guide.html If you have questions about this policy, please contact the APNIC helpdesk at: Email: helpdesk(a)apnic.net Phone: +617 3858 3188 Fax: +617 3858 3199 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 ----------------------------------------------------------------------

3 2

peering discussion on the radio with Russell OConnell
by Barry Murphy 16 Mar '05

16 Mar '05

Original mp3 was taken from http://www.95bfm.com/hardnews.php however I cannot locate it now: http://anycast.fast.co.nz/extras/russelloconnell-2005-03-16-bfm.mp3 (For ape or wix connected users only) Regards Barry

2 1

University of Auckland peering at the APE
by Andy Linton 15 Mar '05

15 Mar '05

Their peering session has been up now for about three hours. If you're an APE route server peer and you route to them via more expensive 'Domestic Transit Services' you may want to architect a different solution. They're announcing 130.216.0.0/16. If you are connected to the APE switch fabric and you're not peering with the route servers we'd be happy to help.

1 0

Routes from Ihug and possibly others
by Barry Murphy 14 Mar '05

14 Mar '05

Hey there, I've had a few reports from ihug customers trying to get to the following IP ranges that fall off APE: 202.7.6.32/29 - WIX Only 202.7.5.32/29 - APE Only 202.7.6.32/29 - ANYCAST (advertised at both exchanges) These ranges are provided by citylink for an APE only and anycast range, if your accepting routes from the route-servers, please check your filters and allow traffic for the above 3 ranges. These IP's pass traffic for the www.fast.co.nz project with opensource mirrors and downloads, if you want your users to be able to receive these downloads in the cheapest and quickest possible way, then fix it :) Thanks Barry

1 1

Notification of NZRR Database changes
by NZRR Database Notifications 14 Mar '05

14 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2078] Routing updates for WIX Route Servers (fwd) - Date: Tue, 15 Mar 2005 11:52:52 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503151152250.14480(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18406 descr: advertised to AS9439 by FX Networks - AS18406 members: 202.53.176.0/20^20-29, 202.7.4.72/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18406 descr: advertised to AS9439 by FX Networks - AS18406 members: 202.53.189.0/24^24-29, 161.29.254.0/23^23-29, 202.7.4.72/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050315 source: NZRR --- PREVIOUS OBJECT: route: 202.7.4.72/29 descr: Route for FX Networks - AS18406 descr: WIX experimental block origin: AS18406 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.7.4.72/29 descr: Route for FX Networks - AS18406 origin: AS18406 notify: rpsl-admin(a)nzix.net notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050315 source: NZRR

1 0

nznog06
by Simon Lyall 14 Mar '05

14 Mar '05

In the next little while we'll probably do a survey on nznog05 and what people want from nznog06. 1. If anybody has any topics, talsk or areas they would like to suggest for nznog06 can they please email me. I can add these to the survey to gague the level of interest for them. 2. One way we might do the survey is via a webpage like: http://www.nanogpc.org/survey/public/survey.php?name=npc_0205 If somebody is setup to host, create one of these ( with at least a human-readable result output) can they email me please. If not we'll do it via email or perhaps a site like www.surveygalaxy.com . -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

NetSmart APE prefix list update
by Paul Horak 14 Mar '05

14 Mar '05

If you peer with NetSmart at APE (ASN 10200) please note the following changes: Added 202.37.168.0/24 Full list 202.27.83.0/24 202.36.75.0/24 202.37.168.0/24 If you don't peer with us but want to I would be pleased to hear from you. :-) Cheers, Paul NetSmart Ltd http://www.netsmart.co.nz/, Level 2, Regency House, 1 Elizabeth Street, P O Box 15020, Tauranga, New Zealand Tel: 07 5711367 Fax: 07 5711372

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 13 Mar '05

13 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2073] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Mon, 14 Mar 2005 16:30:40 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503141630100.13184(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29, 202.7.5.32/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 13 Mar '05

13 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2072] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Mon, 14 Mar 2005 13:20:22 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503141320030.12596(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17474 descr: Route set advertised to AS9560 by ConceptNET - AS17474 members: 202.49.250.0/24, 202.50.176.0/24, 202.127.8.0/22, 202.150.96.0/20, 203.97.44.0/24, 203.21.31.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040304 changed: rpsl-admin(a)nzix.net 20040325 changed: rpsl-admin(a)nzix.net 20040617 changed: rpsl-admin(a)nzix.net 20040625 changed: rpsl-admin(a)nzix.net 20040813 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/20^20-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.50.176.0/24^24-29, 202.7.6.32/29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 202.150.96.0/20 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 202.150.96.0/20 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 202.127.8.0/22 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 202.127.8.0/22 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 203.97.44.0/24 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 203.97.44.0/24 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 202.50.176.0/24 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 202.50.176.0/24 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR

1 0

Cisco 2948G-L3...... I wonder if I could trouble someone out there.........
by Joe Gilliam 11 Mar '05

11 Mar '05

Well, I need some help. I found your list by googling and what I saw seemed to be pretty good. First of all, I am not a Cisco person. I don't know enough to do what I really want to do with this switch. My side of the world is the Administration of a large PACS System. I am not a part of the Network admin. Just the Apps side. But I am an MCSE and I can usually get myself out of trouble. UNTIL I GOT THIS DARN SWITCH....... I know enough to get in the switch, log in as the exec from the console and maybe change a few things here and there. I know this is an older CatOS type switch. But, I don't know many of the serious commands. OK, All I want is to change the setup so this switch will be a basic Layer 2 switch with all ports active, set to 10/100 Auto. And I want to configure an uplink port. And I want to turn on and off DHCP, like a light switch. I want to use this little jewel for lan parties. (FOR FUN, NOT FOR WORK!) Does someone out there have a place where I can get example configs, or even a manual so I can learn the CatOs or maybe even give me some pointers of how to configure the thing? This is the first time I have posted here, and haven't seen any traffic from the site. I just subscribed. So if this request is something you guys don't like to see, I won't bug you again. I am just looking for a little guidence. I can't seem to find anyone around here in Kansas that admits to knowing anything about this switch. Thanks in advance......... Joe Gilliam Wichita, Kansas

2 1

Re: [offlist] Re: [nznog] Ispmap / wix / ape - Slightly OT
by neil gardner 10 Mar '05

10 Mar '05

>>>> Jeremy Brooking <godfather(a)mafia.org.nz> 11/03/2005 10:44:58 a.m. >>Mark Foster wrote: >> Any ISPs who have run semi-transparent caching like to stick up their >> hands as to the sheer _volume_ of logging data collected relative to their >> customer base? And indicate exactly how long they archive those logs for, >> and how accessible they are??? > >Lots. > >No long. Ah, this is obviously some strange use of the word exactly that I wasn't previously aware of. (Apologies to Arthur Dent) 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.

1 0

Re: [offlist] Re: [nznog] Ispmap / wix / ape - Slightly OT
by Mark Foster 10 Mar '05

10 Mar '05

On Wed, 9 Mar 2005 11:34:09 +1300 (NZDT), "Alastair Johnson" <aj(a)sneep.net> wrote : > Nathan Ward wrote: > > > Simon Lyall wrote: > > >>It breaks a few places that use the IP address to auth http sessions, > >>apparently some sites don't believe these weird cookie thingies are ready > >>for prime time. > >> > >> > > Hmm. This would be a problem if your requests for the same site were > > going to different proxy servers. > > I don't think that happens with Foundys, by default. If it does, it's > > easily 'fix'-able. > > We had an issue at Maxnet that was a site which broke in this manner. > Essentially they 'authenticated' the customer off the IP address of the > proxy, which using WCCP was reasonably static unless a proxy failed. > However, after the initial authentication, it then redirected them to an > SSL site on 443/tcp, which obviously was not going through the transparent > cache farm, and the customer was (correctly) not configured to use a > cache. > > So the request suddenly came from the customer's IP address. Result: The > site would refuse to allow them in. > > A stupid way of doing it, and we solved the problem by excluding the site > from the cache. For the life of me, I can't remember what it was, but I > recall the site was black and popular. I think it might have been some > games thing. > The other negative of Non-Transparent-Proxying that this brings to mind is the relative difficulty that ISPs have identifying persons who abuse web based services (websites, forums, et al) - The logs which collect 'cache?.xyz.co.nz' aren't exactly going to give the ISP information used to resolve user accounts and specific individuals. And most ISPs with the above issue don't log their proxies either, or if they do, can only log for a short period of time due to the sheer volume of log data created. So TransProxying, or none at all, would be my personal choice. (I hear that in at least one cases the amount of $ saved by transproxying was being re-spent in maintaining the boxes themselves - so they were pulled out due to lack of value vs inconvenience. And theyre now saving money.) Mark. All IMHO, as usual.

4 6

Re: [offlist] Re: [nznog] Ispmap / wix / ape - Slightly OT
by Nathan Ward 08 Mar '05

08 Mar '05

David Robb wrote: > On Wed, 9 Mar 2005, Nathan Ward wrote: > >> IMO, using cache's in fully transparent mode is a rather broken thing >> to do, unless you cache on your entire border.. > > Ever tried to architect a network to do that? :) > We tried. It's easier to deal with the occasional network that breaks. Really? I imagine that there would be lots of breakage in this area, especially during failures (your's, or other's) or routing that lacks clue. When you are caching fully transparently, do the Foundry's only send the HTTP return packets to the caches if they are part of a cached session? That would limit some problems, but obviously not all, and wouldn't fix this one. How do you detect that there is a problem network? That relies on customers, right? Do they really call and complain enough? I know my Mother would just put any failures like that down to "The Internet is broken again". Why don't you cache semi-transparently? (IE, connections to web servers come from the external IP address of the proxy server). I'm not aware of any real life cases of that breaking things, and as far as I am aware, it's what most NZ providers do.. Feel free to prove me wrong here, of course. -- Nathan Ward

4 4

A good reliable local NTP server to use?
by Simon Buchanan 08 Mar '05

08 Mar '05

Can anyone let me know of a good reliable local(NZ) NTP server to use? We are connected to APE... Thanks Simon -- Operations Manager - Networker. Creative Broadband Services. Web: www.networker.co.nz Eml: simon(a)networker.co.nz Tel: +64-21-348884

2 1

Ispmap / wix / ape - Slightly OT
by Barry Murphy 08 Mar '05

08 Mar '05

Hey guys, I've added some extra details (AS, APE, WIX) to ispmap on page: http://www.ispmap.co.nz/searchisp.php . I was going to gather the data off www.ape.net.nz and www.wix.net.nz however through Telstra Clear I cannot load these sites as they go international. So I ask if people can submit their ISP (if you peer at WIX / APE). ISPNAME: WIX: Yes/No APE: Yes/No If you work for the provider: YES/NO Thanks Barry

4 4

Telecom ADSL Testing equipment
by neil gardner 07 Mar '05

07 Mar '05

Hi there - if there's anyone on this list that can perform ADSL line testing at a pretty low level, please urgently get in touch with me via email. I am looking to monitor _exactly_ what is going on between our wall jack and the DSLAM. I have tried channels and not gotten very far. This is to troubleshoot an issue (Line condition) which may be able to hang a certain DSL chipset. Thanks - Neil Gardner Senior Tester Allied Telesyn Research 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

WorldxChange Prefix List Update
by Gordon Smith 07 Mar '05

07 Mar '05

Would all direct peers please update their prefix lists as follows: ip prefix-list wxnz-networks permit 202.182.192.0/19 le 24 ip prefix-list wxnz-networks permit 58.28.0.0/16 le 24 Added: ip prefix-list wxnz-networks permit 58.28.0.0/16 le 24 For those who are not direct peering and wish to, email peering(a)wxnz.net IPv6 national peering is also available Cheers, Gordon

1 0

DNS entries
by Webmaster 07 Mar '05

07 Mar '05

When a DNS transfer is made to a new host what is 'normal' practice among operators in regards to the old record? Do you delete it immmediately, wait a specified time and then delete it, or wait to hear from the customer? Thanks. Richard

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 06 Mar '05

06 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: Notification of NZRR Database changes (fwd) - Date: Mon, 7 Mar 2005 14:29:34 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503071427520.4454(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: WIX peering at '202.7.0.123' descr: see Citylink RT job #2009 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR REPLACED BY: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: WIX peering at '202.7.0.123' descr: see Citylink RT job #2009 descr: PNIX peering at '218.100.21.10' descr: see Citylink RT job #1487 descr: APE peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS17705 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 import: from AS9281 accept ANY AND NOT fltr-bogons export: to AS9281 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 06 Mar '05

06 Mar '05

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 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. --- PREVIOUS OBJECT: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: PNIX peering at '218.100.21.10' descr: see Citylink RT job #1487 descr: APE peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 import: from AS9281 accept ANY AND NOT fltr-bogons export: to AS9281 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR REPLACED BY: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: WIX peering at '202.7.0.123' descr: see Citylink RT job #2009 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR --- PREVIOUS OBJECT: route: 203.96.157.0/24 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR REPLACED BY: route: 203.96.157.0/24 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS17705 descr: Route set advertised to AS9439 by Inspire Net - AS17705 members: 203.79.88.0/24^24-29, 203.79.89.0/24^24-29, 203.96.157.0/24^24-29, 203.114.128.0/18^18-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 06 Mar '05

06 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2003] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Mon, 7 Mar 2005 11:42:37 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503071141330.4454(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29, 202.7.5.32/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR

1 0

telstra clear
by Garrett Stoupe 06 Mar '05

06 Mar '05

Has anyone experienced network / internet related problems since Telstra clear de peered itself from wix? We are using a woosh wireless business connection, and we are experiencing some slowness, even with google. The problems started happening when Telstra clear de peered from wix It would be interesting to see if anyone else is experiencing any problems Garrett Stoupe Network And Database Administrator Cabbage Tree Press garretts(a)te.co.nz www.te.co.nz www.jobzone.co.nz www.nzcarbuys.co.nz

2 2

OT: Seeking a Book
by Anaru Hartley 05 Mar '05

05 Mar '05

Hello All, I have been looking for a way to progress my career in the Telecommunications Industry and a good friend of mine suggested that I read this particular book. I was hoping one of you individuals would be able to put me in the direction of one or might be able to lend me a copy of it. Here is a picture of the books cover: http://www50.brinkster.com/photochopnz/top.jpg Thanks in advance!

2 2

Cisco 2600 LNS help.
by Neil Fincham 05 Mar '05

05 Mar '05

Hi all, On of my clients has had a bit of a disaster and lost their config for a Cosco 2600 that they were using as an LNS for telstraclear's network, I have put the basic information back in (IP, Routes etc) but my cisco speek for LNS and Radius is non existant. Could someone cut and paste the relevent bits out of one of their routers (minus passwords and such) and send it to me. As you can imagine this is quite urgent and help would be greatly appreiciated, this is what I have at the moment;- L2TP#write terminal Building configuration... Current configuration : 1642 bytes ! version 12.3 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname L2TP ! boot-start-marker boot-end-marker ! ! voice-card 0 dspfarm no local-bypass ! aaa new-model ! ! aaa authentication login default local aaa authentication ppp default local aaa authentication ppp vpdn group radius aaa authorization network default group radius aaa accounting network default start-stop group radius aaa session-id common ip subnet-zero ! ! ! ! ip name-server 203.97.37.1 vpdn enable ! vpdn-group 1 accept-dialin protocol l2tp virtual-template 1 terminate-from hostname sp_lac ! no ftp-server write-enable ! ! ! ! ! ! ! ! ! ! ! ! syscon password XXX syscon community XXX ! ! controller E1 0/1 ! ! ! interface FastEthernet0/0 ip address XXX.XXX.XXX.XXX 255.255.255.248 speed auto half-duplex no mop enabled ! interface Serial0/0 no ip address shutdown ! interface FastEthernet0/1 description connected to EthernetLAN ip address XXX.XXX.XXX.XXX 255.255.255.248 duplex auto speed auto ! interface Virtual-Template1 ip unnumbered FastEthernet0/1 peer default ip address pool default ppp authentication chap vpdn ppp multilink ! ip classless ip route 0.0.0.0 0.0.0.0 XXX.XXX.XXX.XXX permanent ip route 203.98.24.0 255.255.255.0 XXX.XXX.XXX.XXX permanent ip route 203.98.25.0 255.255.255.0 XXX.XXX.XXX.XXX permanent no ip http server ! ! snmp-server community public RO snmp-server enable traps tty snmp-server manager ! radius-server host XXX.XXX.XXX.XXX auth-port 1812 acct-port 1813 radius-server key XXXXXXXXXX ! control-plane ! ! ! ! ! ! ! ! line con 0 line aux 0 line vty 0 4 ! ! ! end Thanks for any help. No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.6.2 - Release Date: 4/03/2005

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 03 Mar '05

03 Mar '05

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 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. --- OBJECT BELOW CREATED: aut-num: AS24347 as-name: NZRR-AS24347 descr: Intergen descr: WIX peering at '202.7.0.121' descr: see Citylink RT job #1990 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24347 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dwayne.bace(a)intergen.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS24347 descr: Route set advertised to AS9439 by Intergen - AS24347 members: 202.126.80.0/21^21-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dwayne.bace(a)intergen.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR

1 0

tradme etc
by Simon Lyall 03 Mar '05

03 Mar '05

Interestign wee article: http://www.nzherald.co.nz/index.cfm?c_id=5&ObjectID=10113474 Somebody might know this fior sure but doesn't AT&T (trademe's upstream) connect to APE? Just I can't see trademe's routes being advertised there. -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.

7 6

How fair practice is this; is it spam? - Orcon Response
by Craig Whitmore 03 Mar '05

03 Mar '05

This has been posted on Behalf of Orcon MD by Craig Whitmore --- There appears to have been a serious mis-understanding between Barry and Orcon on this matter Orcon has NOT spammed Barry's customers, and Barry's post is very mis-leading. I will clarify Orcon's position, and lay out the facts, and then I suggest that Barry and Orcon take this matter offline as it is not something that needs to be discussed in NZNOG. Orcon has not, and never will: a) Spam potential customers seeking to provide them services b) Poach customers deliberately from wholesale customers, as a significant portion of our revenue comes from wholesale. What has happened is that our marketing department has been in MUTUAL contact with the owner of a single website, and came to an arrangement whereby we would receive free advertising on the person's website in return for providing free web-hosting and domain name registration. Our marketing department was not aware that this website owner was actually a customer of a customer of Barry's. The website owner has contacted their provider (a customer of a Barry's), and told them that they were moving to us, and the provider and Barry have come to the knee-jerk reaction that we are trying to poach customers. This is absolutely NOT the case. Once Barry made us aware of the issue, Barry's account manager tried to point out that end users are free to choose whichever web hosting provider they want, and that sometimes we lose customers to our wholesale hosting customers and vice-versa - this does NOT mean we are poaching customers or spamming people. However, our account manager communicated this to Barry in a less than elegant manner, and via email, after I had specifically asked that Barry be called so that the situation could be discussed and explained rationally. It is NOT our desire that Barry be upset, This is a SINGLE website owner who had prior discussions with our marketing department, and this conflict has only just been brought to our attention. Thanks for reading NZNOGer's - thanks for your time. Regards Seeby Woodhouse MD Orcon Internet -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Friday, March 04, 2005 2:23 PM To: nznog(a)list.waikato.ac.nz Subject: [nznog] How fair practice is this; is it spam? ok.... how fair is this... I purchase telehousing from orcon and register domains through them. They have spammed one of my customers offering to host their website free of charge in return for advertising space on their website. After hearing this I emailed my account manager at orcon and this was his response. "As Im sure you are aware, Orcon also runs hosting, and as such, from a marketing perspective we have to treat other web hosting companies as competition, even if they are buying wholesale services from us. All other ISP's do the same - Telecom actively market to our customers for all ISP services even though we purchase a massive amount of wholesale services off them. " Is this spam/fair practice? Seeing as they could obtain a list of these domains in their database (as they're the registrar for this domain) Kindest Regards Barry Murphy _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

problems with NTP on bigben?
by Simon Blake 03 Mar '05

03 Mar '05

Anybody else observed that bigben gained about 19 years at about 1:25pm this arvo? $ date Tue Jan 1 14:54:33 NZDT 2002 $ /usr/sbin/ntpdate -q truechimer.waikato.ac.nz server 130.217.76.32, stratum 2, offset -0.001089, delay 0.04276 1 Jan 14:49:38 ntpdate[17537]: adjust time server 130.217.76.32 offset -0.001089 sec $ /usr/sbin/ntpdate -q bigben.clix.net.nz server 203.167.224.60, stratum 1, offset 619315199.998172, delay 0.03613 1 Jan 14:49:55 ntpdate[17540]: step time server 203.167.224.60 offset 619315199.998172 sec - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

13 20

How fair practice is this; is it spam?
by Barry Murphy 03 Mar '05

03 Mar '05

ok.... how fair is this... I purchase telehousing from orcon and register domains through them. They have spammed one of my customers offering to host their website free of charge in return for advertising space on their website. After hearing this I emailed my account manager at orcon and this was his response. "As Im sure you are aware, Orcon also runs hosting, and as such, from a marketing perspective we have to treat other web hosting companies as competition, even if they are buying wholesale services from us. All other ISP's do the same - Telecom actively market to our customers for all ISP services even though we purchase a massive amount of wholesale services off them. " Is this spam/fair practice? Seeing as they could obtain a list of these domains in their database (as they're the registrar for this domain) Kindest Regards Barry Murphy

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 03 Mar '05

03 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1987] Routing updates for APE Route Servers (fwd) - Date: Fri, 4 Mar 2005 13:10:15 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503041309040.991(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR

1 0

The Impact of the Reworked TTL Field on Regional IP Allocations
by Jim Fleming 02 Mar '05

02 Mar '05

The Impact of the Reworked TTL Field on Regional IP Allocations The TTL Field (or Hop Count) is normally 8-bits wide. Some operating systems start it with a value of 255 (all 1s) and some with 64 and other smaller values. In order to improve services for broad-band users, there is a benefit in **reducing** the size of the TTL Field from 8-bits to 4-bits. That limits the maximum number of hops to 15. Equipment that auto-encapsulates can work around this by moving a packet a long distance and then removing a wrapper and allowing it to have some of the hops near the source and some near the destination. Reducing the TTL Field to 4-bits frees up 4-bits for address expansion. With two of those bits for the Source and two bits for the Destination, the entire legacy Internet plus three more equal size address spaces can be supported, without changing the existing protocol header size. One could view that as a planar Internet or a 4-story office building. Existing allocations of address space could all be viewed as from one plane or one could map regions to the 4 planes, allowing a region to expand to space used by another region because the extra bits prevent collisions and provide unique allocations. Another approach is to use the 4 planes for local networks, VPNs, a wireless extranet, and the legacy Internet (core). In a restricted approach only intra-plane traffic is allowed. A totally open approach would allow any node to address any other node. This would be like any location in the 4-story office being able to connect with any other, rather then be restricted to intra-floor-only connections. A more conservative approach is simply to zero the left-most 4 bits and reserve (save) the other three planes for future generations, once equipment is better able to route and process the reworked TTL Field. Current market trials and tests with broad-band-only subscribers will help to determine which approach has the most benefit. IP address allocations are already being red-lined for re-allocation and use in other planar nets because they can not be reached in 15 hops from/to certain regions of the world. Since there may not be any bandwidth to those regions anyway, it does not matter because the laws of physics will prevent broadband services from becoming available in one region with the same level of service observed in another region. Voice services are of course "the killer apps" and place great demands on the aging best-effort transports. As new equipment is provisioned it can be done with an awareness of the benefits of using a smaller TTL Field. Some might argue that 15 hops is stilll too many and one or two more bits should be removed leaving a 7 hop or a 3 hop limit. The 7 hop approach only frees up 1 more bit and it can be combined with the unused 49th bit to add another entire bit to both the source and destination fields. The 3 hop approach makes one look sooner at the needed equipment to bypass the aging legacy core. Having 6 added bits for addressing and 8 planar levels can have more long-term benefits and there can still be a short-term work-around because the 3-bits of the destination address field can be allowed to be processed by *existing* TTL algorithms and packets then transform their addressing as they pass thru the core network. The address bits can then be used to prioritize delivery by allowing packets that come from a long distance to be processed before those that come from closer locations. They appear to be going to different destinations by looking at the changed TTL value as an address. Since packets now travel greater distances with less decrements of the hop-count the 7 hop approach may be the best compromise. Eventually, the free-market place will decide. People can not make "governance" decisions based on 20 year old designs and how they are applied in regions of the world that have no bandwidth. That is the lowest-common-denominator approach advocated by The Big Lie Society. As people have seen, that prevents a nation from Running at the speed of light. Jim Fleming A.Net

4 3

Read-Only BLOB (packet) Additions to the IP Protocol
by Jim Fleming 02 Mar '05

02 Mar '05

Read-Only BLOB (packet) Additions to the IP Protocol An analysis of many packets of data show that the same binary content appears over and over. This is especially the case when a smaller and smaller size BLOB is considered. For example, a 512 byte (octet) BLOB contains 4096 bits (ones or zeroes) and there can be a large number of **unique** BLOBs, in fact, approximately (1.0443888814131525066917527107166e+1233). If users are able to create (own?) any number of the unique BLOBs and then place them in a public cache (library), then new broadband modems can pull those BLOBs in and attach them to packet headers. Since the BLOBS are read-only and never change, once created, they can each have their own IP address as the "source". The destination address is the end-user's system. One obvious BLOB is a 512 byte BLOB of all zeroes. Another obvious one is all ones. Those can be two of the possible BLOBS. If a 32-bit index (handle) is used to specify a unique BLOB, then there can be exactly 4,294,967,296. It might take several BLOBS to hold commonly communicated binary content. Also, several BLOBS may be needed if graphics/voice/sound is recorded vs. text. Compression can be allowed because the BLOB is just 512 bytes of arbitrary ones and zeroes. Also, careful attention to repetition in tones (like dial-tone in VOIP) can result in the same BLOB being used over and over with no clicks or gaps noticed between BLOBs. With that as a bit of an intro, no pun intended, some "Internet Governance" questions come to mind. 1. Who owns the content of the BLOBs ? 2. If it costs $1 dollar (OZ dollars) to "register" a unique BLOB who collects that $4,294,967,296 ? 3. How and where will the BLOBs be cached ? 4. Do the users really care where they come from as long as their broad-band system works "better" ? 5. Are people concerned that the same BLOB may appear over and over, creating boring content ? 6. Are people concerned that a small error could become part of a read-only archive and live for a long time ? 7. As a follow-on to #6, would another BLOB be allowed ? to fix that error ? 8. Is first-come-first-serve the best way to sell off the BLOBs? 9. Should existing archives and databases be encoded first ? at no charge ? 10. Once one BLOB address space is used up, should another be opened up ? 11. Will there be vanity-value in owning a BLOB ? Is the one-millionth BLOB special ? 12. Will BLOBs that can be compressed be favored ? 13. Should there be an age-limit to register a BLOB ? For the curious, the entire BLOB cache would be 2,199,023,255,552 bytes without compression. An ISP can cache the entire BLOB space and do inserts in the last mile of the broad-band connection. The broad-band "modem" can of course cache a working set of the most common BLOBs. Is this bit torrent at the IP level ? http://bittorrent.com/ Jim Fleming A.Net

3 2

ICONZ Prefix list update - 2005-03-03
by John Johnston 02 Mar '05

02 Mar '05

AS: 4770 APE: 192.203.154.44 WIX: 202.7.1.1 Hey all, For all those that peer with ICONZ here is yet another update. Current list is attached or goto http://www.iconz.net/prefix Regards John Johnston Network Engineering Manager ICONZ New Zealand Limited DDI: +64 9 977 3500 FAX: +64 9 977 3535 Mobile: 021 277 5692 Email: john.johnston(a)iconz.net 0800 THE NET www.iconz.net

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 02 Mar '05

02 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Thu, 3 Mar 2005 13:21:39 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503031320190.31409(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS2687 descr: Route set advertised to AS9439 by AT&T Global - AS2687 members: 152.158.254.0/24^24-29, 152.158.255.0/24^24-29, 202.14.142.0/24^24-29, 202.27.160.0/24^24-29, 202.36.68.0/24^24-29, 202.36.69.0/24^24-29, 202.36.80.0/24^24-29, 202.36.195.0/24^24-29, 202.37.93.0/24^24-29, 202.37.254.0/24^24-29, 202.46.160.0/20^20-29, 202.49.144.0/24^24-29, 202.50.137.0/24^24-29, 202.135.20.0/24^24-29, 202.135.34.0/24^24-29, 202.135.38.0/24^24-29, 202.135.48.0/24^24-29, 202.135.49.0/24^24-29, 202.135.62.0/24^24-29, 202.135.85.0/24^24-29, 202.135.107.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.182.0/24^24-29, 202.135.185.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 203.163.68.0/24^24-29, 203.163.70.0/24^24-29, 203.163.71.0/24^24-29, 203.163.86.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.119.0/24^24-29, 219.88.103.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: greg.kapp(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS2687 descr: Route set advertised to AS9439 by AT&T Global - AS2687 members: 152.158.254.0/24^24-29, 152.158.255.0/24^24-29, 202.14.142.0/24^24-29, 202.27.160.0/24^24-29, 202.36.68.0/24^24-29, 202.36.69.0/24^24-29, 202.36.80.0/24^24-29, 202.36.195.0/24^24-29, 202.37.93.0/24^24-29, 202.37.254.0/24^24-29, 202.46.160.0/20^20-29, 202.49.144.0/24^24-29, 202.50.137.0/24^24-29, 202.135.20.0/24^24-29, 202.135.34.0/24^24-29, 202.135.38.0/24^24-29, 202.135.48.0/24^24-29, 202.135.49.0/24^24-29, 202.135.62.0/24^24-29, 202.135.85.0/24^24-29, 202.135.107.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.182.0/24^24-29, 202.135.185.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 203.163.68.0/24^24-29, 203.163.70.0/24^24-29, 203.163.71.0/24^24-29, 203.163.86.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.119.0/24^24-29, 219.88.103.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: attnzdns(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050303 source: NZRR

1 0

RE: [nznog] VON anyone?
by Mark Frater 02 Mar '05

02 Mar '05

Ahh flames... Spin.. Crash.. Burn.. Die.. Before the flames grow higher, humble apologies for html.. etc. < does no sig on this one make up for it?> --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.775 / Virus Database: 522 - Release Date: 8/10/2004

1 0

VON anyone?
by Mark Frater 02 Mar '05

02 Mar '05

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #1983] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Wed, 2 Mar 2005 20:02:24 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503022001510.30819(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:rs-routes:AS9889 descr: Route set for AS9889 members: 202.14.217.0/24, 202.27.204.0/24, 202.36.70.0/24, 202.37.72.0/24, 202.37.181.0/24, 202.50.167.0/24, 202.89.32.0/19^19-24, 210.55.29.0/24, 210.55.100.0/22^22-24, 210.55.104.0/22^22-24, 210.55.110.0/24, 210.55.155.0/24, 210.55.169.0/24, 210.55.214.0/24, 210.55.230.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: alastair.johnson(a)maxnet.co.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20031016 changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.230.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.230.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.214.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.214.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.169.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.169.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.155.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.155.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.104.0/22 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.104.0/22 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.100.0/22 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.100.0/22 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.37.181.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.37.181.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.37.72.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.37.72.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.36.70.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.36.70.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.27.204.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.27.204.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.89.32.0/19 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.89.32.0/19 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

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 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. --- PREVIOUS OBJECT: aut-num: AS3856 as-name: NZRR-AS3856 descr: PCH2 descr: APE peering at '192.203.154.253' descr: see Citylink RT job #1924 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS3856 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: aut-num: AS3856 as-name: NZRR-AS3856 descr: PCH2 descr: APE peering at '192.203.154.254' descr: see Citylink RT job #1924 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS3856 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

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 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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS3856 descr: advertised to AS9560 by Packet Clearing House - AS3856 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.0/23^23-29, 206.220.228.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS3856 descr: Route set advertised to AS9560 by PCH2 - AS3856 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

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 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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS42 descr: advertised to AS9560 by Packet Clearing House - AS42 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS42 descr: Route set advertised to AS9560 by PCH1 - AS42 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR

1 0

Spam levels in the last 24 hours?
by neil gardner 01 Mar '05

01 Mar '05

Hi guys - Has anyone else noticed a huge increase in Spam levels in the last 24 or so hours? This is only from 2-3 accounts on 2 ISPs (Orcon and Paradise), but I have gone from seeing 1-2 per day to about 30 making it past the (ISP based) filters in the last 24 hours. Interested to hear from mail admins as to whether this is just me being unlucky, or if there's something screwy happening here... Cheers - Neil G 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 6

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Wed, 2 Mar 2005 18:56:43 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503021854360.30667(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS42 descr: advertised to AS9560 by Packet Clearing House - AS42 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS3856 descr: advertised to AS9560 by Packet Clearing House - AS3856 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.0/23^23-29, 206.220.228.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR

1 0

Peering exchange in the Wairarapa?
by Blair Harrison 01 Mar '05

01 Mar '05

Hi Guys, I'm just wondering if there is any interest at all in having a peering exchange of some kind in the Wairarapa. I know I've been thinking about such a beast for a while, but at the moment there's only a couple of ISP-like entities (that I know of) who might possibly be interested. WISE Net would be happy to house such a beast if it could be shown that there was sufficient interest, although I'm not sure we're exactly what you might call neutral territory :) So really what I'm asking is, is there anyone else out there? Do you want to peer with us? With others? Have you got a network you want to connect to others with in the Wairarapa at a central place? Raise your hands now, or forever shall your cat5 be under-utilised :) Cheers, Blair Harrison Systems Administrator WISE Net | http://wise.net.nz

4 3

I-Root Server avaiable at the WIX
by Andy Linton 28 Feb '05

28 Feb '05

There is now an instance of an anycast I-Root name server attached to the WIX. Those peering with the WIX route servers should be seeing an announcment for 192.36.148.0/24. From Wellington I'm seeing RTTs like this: $ ping 192.36.148.17 PING 192.36.148.17 (192.36.148.17) 56(84) bytes of data. 64 bytes from 192.36.148.17: icmp_seq=1 ttl=252 time=3.90 ms 64 bytes from 192.36.148.17: icmp_seq=2 ttl=252 time=1.12 ms 64 bytes from 192.36.148.17: icmp_seq=3 ttl=252 time=1.73 ms 64 bytes from 192.36.148.17: icmp_seq=4 ttl=252 time=2.07 ms 64 bytes from 192.36.148.17: icmp_seq=5 ttl=252 time=1.18 ms 64 bytes from 192.36.148.17: icmp_seq=6 ttl=252 time=1.62 ms 64 bytes from 192.36.148.17: icmp_seq=7 ttl=252 time=1.80 ms 64 bytes from 192.36.148.17: icmp_seq=8 ttl=252 time=1.92 ms 64 bytes from 192.36.148.17: icmp_seq=9 ttl=252 time=1.43 ms --- 192.36.148.17 ping statistics --- 9 packets transmitted, 9 received, 0% packet loss, time 8080ms rtt min/avg/max/mdev = 1.125/1.867/3.905/0.782 ms and from a host in Auckland which doesn't see the announcement I see: $ ping 192.36.148.17 PING 192.36.148.17 (192.36.148.17): 56 data bytes 64 bytes from 192.36.148.17: icmp_seq=0 ttl=55 time=257.7 ms 64 bytes from 192.36.148.17: icmp_seq=1 ttl=55 time=255.9 ms 64 bytes from 192.36.148.17: icmp_seq=2 ttl=55 time=255.9 ms 64 bytes from 192.36.148.17: icmp_seq=3 ttl=55 time=256.8 ms 64 bytes from 192.36.148.17: icmp_seq=4 ttl=55 time=256.2 ms 64 bytes from 192.36.148.17: icmp_seq=5 ttl=55 time=257.9 ms 64 bytes from 192.36.148.17: icmp_seq=6 ttl=55 time=259.5 ms 64 bytes from 192.36.148.17: icmp_seq=7 ttl=55 time=256.5 ms 64 bytes from 192.36.148.17: icmp_seq=8 ttl=55 time=257.2 ms --- 192.36.148.17 ping statistics --- 9 packets transmitted, 9 packets received, 0% packet loss round-trip min/avg/max = 255.9/257.0/259.5 ms Thanks to InternetNZ who funded this and to Packet Clearing House and Autonomica for making it happen. Enjoy!

9 13

RE: [nznog] I-Root Server avaiable at the WIX
by Matt Mariu 28 Feb '05

28 Feb '05

I sort of came along late in the 'news' game when the Major Telco's decided to de-peer.. To that effect, Does anyone out there have a solid explanation from them as to why they chose to do what they Did ? Joe, You used to work @ Clear.. Surely you have inside knowledge :) Sorry if this is old news, if theres a link, post it please. -----Original Message----- From: Keith Davidson [mailto:keith(a)wise.net.nz] Sent: Tuesday, 1 March 2005 14:19 To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] I-Root Server avaiable at the WIX Hmmm, so the aberrant nature of peering in NZ rears its ugly head... Seems strange that the telcos would prefer to route offshore at a financial and a performance cost, rather than peer in NZ and give their users faster speeds and cost reductions... Keith Davidson

2 1

RE: [nznog] I-Root Server avaiable at the WIX
by neil gardner 28 Feb '05

28 Feb '05

>But it still says on Paradises website: > >Citylink Traffic is calculated in the same way as JetStart Traffic, with the >exception of traffic delivered through the Wellington Internet Exchange >(WIX), which is completely free! And there's nothing inaccurate about that is there? They just don't send any more traffic over WIX - but if they did - it would be free. :-) Anyway, good to see they aren't letting elegant solutions get in the way of MORE MONEY!!! 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.

1 0

IPv6 national peering
by Leigh Smith 27 Feb '05

27 Feb '05

Hi all Just to let the people that are interested in IPv6 WorldxChange are now peered at the APE a second peer point will be available soon 2001:7fa:4:c0cb::9a03 AS 17435 Regards Leigh

1 0

IPV6, Cisco
by Philip D'Ath 26 Feb '05

26 Feb '05

After much torment this weekend I have managed to get IPv6 running nicely on a low end Cisco DSL router (Cisco 837). If anyone wants an IPv6 connection at home (and a /48 block of real world IPv6 address space) to experiment with, say yourself some grief and start with this. http://www.ifm.net.nz/cookbooks/ipv6configwizard.html Now if we can just get a critical mass of users we might be able to tempt an ISP to offer native connections ... and actually use Joe's IPv6 F root server.

1 0

RE: [nznog] IPv6, NAT-PT
by Philip D'Ath 26 Feb '05

26 Feb '05

I'm talking about using NAT-PT to allow a native ipv6 network to talk to an ipv4 network. Without some kind of protocol translation (aka PT) ipv6 can't talk to ipv4. The reason this has to be done is because you can't buy an ipv6 connection to an ISP in NZ yet. -----Original Message----- From: Cameron Kerr [mailto:cameron(a)humbledown.org] Sent: Saturday, 26 February 2005 2:27 p.m. To: Philip D'Ath Cc: nznog Subject: Re: [nznog] IPv6, NAT-PT On 26/02/2005, at 1:25 PM, Philip D'Ath wrote: > I'm trying to get NAT-PT support working on a Cisco DSL router to > support native ipv6 clients behind it. I've done a lot of searching, > and can't find the answers to what I'm doing wrong. I have two > problems. Why are you using NAT with IPv6? There is very little reason pros for using IPv6 with NAT, and many cons. Afterall, NAT is just a hack for IPv4 to prevent address exhaustion. IIRC, ISPs are not to give out single IP addresses, but rather /64 allocations. Anyone care to correct me on this? -- Cameron Kerr Telecommunications Teaching Fellow & SysAdmin ckerr(a)cs.otago.ac.nz

7 15

Paradise bouncing emails?
by PhoneNet 25 Feb '05

25 Feb '05

Anyone else getting complaints from customers re email destined for Paradise accounts being bounced? Ian

3 2

RE: [nznog] IPv6, NAT-PT
by Philip D'Ath 25 Feb '05

25 Feb '05

I'm not wishing to get access to ipv6 content at this stage (but will of course eventually want to do this). I'm wanting to start using ipv6 internally. Once we are using it, I'll probably start some of our clients using it later this year. Once enough people are using it hopefully some ISP will start offering native ipv6 connections, because they will have a business case to do so. Hence, the desire to use NAT-PT, otherwise I'll be stuck running dual stacks. -----Original Message----- From: Joe Abley [mailto:jabley(a)isc.org] Sent: Saturday, 26 February 2005 4:57 p.m. To: Philip D'Ath Cc: nznog; Cameron Kerr Subject: Re: [nznog] IPv6, NAT-PT On 25 Feb 2005, at 20:39, Philip D'Ath wrote: > I'm talking about using NAT-PT to allow a native ipv6 network to talk > to an ipv4 network. Without some kind of protocol translation (aka > PT) > ipv6 can't talk to ipv4. The reason this has to be done is because > you can't buy an ipv6 connection to an ISP in NZ yet. Most people running v6 are only using their v6 access to reach content served over v6. Most of the mechanisms suggested to allow a v6-only host to access v4 content remain undeployed. If you want to reach v6 content, the easiest thing to do is find an ISP who can give you v6 transit. In the absense of local carriers with dual-stack edge routers (i.e. in the case of most of the planet) the way you do this is terminate a tunnel somewhere. Joe

1 0

IPv6, NAT-PT
by Philip D'Ath 25 Feb '05

25 Feb '05

I'm trying to get NAT-PT support working on a Cisco DSL router to support native ipv6 clients behind it. I've done a lot of searching, and can't find the answers to what I'm doing wrong. I have two problems. First, I can't get them to grab additional parameters from DHCP. I'm using: ipv6 dhcp pool dhcppool dns-server ::210.55.12.1 - I know the above is not likely to answer AAAA requests, but I plan to use DNS-ALG domain-name local.arpa Interface Ethernet0 ipv6 enable ipv6 nd other-config-flag ipv6 dhcp server dhcppool The second problem is I can't NAT-PT to work at all. It doesn't even attempt to do translations. Snippits I'm using are: Interface Dialer0 description ipv4 Interface connecting to Internet ipv6 nat Interface Ethernet0 description ipv6 Interface connection to local lan (aka LINK-LOCAL) ipv6 address 3FFE:AAAA:BBBB:1::9/64 - An address copied from an example, hope to use LINK-LOCAL addresses later ipv6 enable ipv6 nat ipv6 nat translation udp-timeout 600 ipv6 nat v6v4 source list pt-list1 interface Dialer0 overload ipv6 nat prefix 3FFE:B00:1::/96 ipv6 access-list pt-list1 permit ipv6 3FFE:AAAA:BBBB:1::/64 any

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 24 Feb '05

24 Feb '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1958] Routing updates for WIX Route Servers (fwd) - Date: Fri, 25 Feb 2005 17:41:59 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0502251727510.24165(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by LinuxNet - AS18119 members: 192.107.113.0/24^24-29, 202.7.4.80/29, 202.21.136.0/23^23-29, 202.36.44.0/24^24-29, 202.37.136.0/24^24-29, 202.49.249.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: lincoln(a)linuxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050222 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by LinuxNet - AS18119 members: 192.107.113.0/24^24-29, 202.7.4.80/29, 202.7.6.32/28^28-29, 202.21.136.0/23^23-29, 202.36.44.0/24^24-29, 202.37.136.0/24^24-29, 202.49.249.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: lincoln(a)linuxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 24 Feb '05

24 Feb '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1951] Routing updates for APE Route Servers (fwd) - Date: Fri, 25 Feb 2005 16:57:10 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0502251654230.24165(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: Route set for AS4770 members: 138.235.0.0/16, 192.107.113.0/24, 192.173.16.0/21, 198.32.66.0/24, 199.212.90.0/23, 199.212.92.0/23^23-24, 202.6.84.0/24, 202.12.70.0/24, 202.12.248.0/21, 202.14.100.0/24, 202.21.130.0/24, 202.21.136.0/23, 202.36.155.0/24, 202.36.157.0/24, 202.36.32.0/24, 202.36.36.0/22, 202.36.44.0/24, 202.36.45.0/24, 202.36.76.0/23, 202.37.136.0/24, 202.37.140.0/22, 202.37.144.0/21, 202.37.163.0/24, 202.37.197.0/24, 202.37.200.0/22, 202.37.224.0/21, 202.37.232.0/24, 202.37.240.0/23, 202.37.252.0/23, 202.37.76.0/24, 202.37.85.0/24, 202.41.136.0/22, 202.41.140.0/24, 202.49.62.0/24, 202.49.89.0/24, 202.49.249.0/24, 202.50.87.0/24, 202.50.246.0/24, 202.55.96.0/20, 202.74.224.0/21, 203.9.179.0/24, 203.9.180.0/24, 205.233.128.0/21, 205.233.136.0/23, 205.233.243.0/24, 210.185.0.0/18, 210.48.0.0/17, 210.54.136.0/22, 210.54.140.0/24, 210.54.160.0/19, 210.55.182.0/23, 210.55.24.0/22, 210.55.253.0/24, 210.56.32.0/20 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john.johnston(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20030407 changed: rpsl-admin(a)nzix.net 20040629 changed: rpsl-admin(a)nzix.net 20040831 changed: rpsl-admin(a)nzix.net 20040930 changed: rpsl-admin(a)nzix.net 20050224 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: Route set for AS4770 members: 138.235.0.0/16, 192.107.113.0/24, 192.173.16.0/21, 198.32.66.0/24, 199.212.90.0/23, 199.212.92.0/23^23-24, 202.6.84.0/24, 202.12.70.0/24, 202.12.248.0/21, 202.14.100.0/24, 202.21.130.0/24, 202.21.136.0/23, 202.36.155.0/24, 202.36.157.0/24, 202.36.32.0/24, 202.36.36.0/22, 202.36.44.0/24, 202.36.45.0/24, 202.36.76.0/23, 202.37.136.0/24, 202.37.140.0/22, 202.37.144.0/21, 202.37.163.0/24, 202.37.197.0/24, 202.37.200.0/22, 202.37.224.0/21, 202.37.232.0/24, 202.37.240.0/23, 202.37.252.0/23, 202.37.76.0/24, 202.37.85.0/24, 202.41.136.0/22, 202.41.140.0/24, 202.49.62.0/24, 202.49.89.0/24, 202.49.249.0/24, 202.50.87.0/24, 202.50.246.0/24, 202.55.96.0/20, 202.74.224.0/21, 203.9.179.0/24, 203.9.180.0/24, 205.233.128.0/21, 205.233.136.0/23, 205.233.243.0/24, 210.185.0.0/18, 210.48.0.0/17, 210.54.136.0/22, 210.54.140.0/24, 210.54.160.0/19, 210.55.182.0/23, 210.55.24.0/22, 210.55.253.0/24, 210.56.32.0/20 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john.johnston(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20030407 changed: rpsl-admin(a)nzix.net 20040629 changed: rpsl-admin(a)nzix.net 20040831 changed: rpsl-admin(a)nzix.net 20040930 changed: rpsl-admin(a)nzix.net 20050224 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 24 Feb '05

24 Feb '05

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 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Fri, 25 Feb 2005 11:03:24 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0502251102510.23787(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, 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 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.6.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

Email hammering from mta20X-rme.xtra.co.nz
by Simon Buchanan 24 Feb '05

24 Feb '05

Hi there, im wondering if anyone could point me in the rite direction here. Starting last night we have been hammered by xtra's mail servers from the email address haggis(a)guard.co.nz... Has any body on the list had simlar problems... How can i follow this up? Suggestions please :) Regards, Simon

3 2

RE: [nznog] (OT) Fax spam (Anti-spam legislation update)
by Regan Murphy 24 Feb '05

24 Feb '05

>You will need: > >* An older fax machine that scans the document slowly as it sends it >* A vivid marker >* Some sellotape This is the age of technology. Surely a few lines of code, a modem and some fax protocols could achieve the same result. Maybe you could even redirect your email spam junk folders to your fax spammer to give it a nice twist. ;) -- Regan

2 1

RE: [nznog] Anti-spam legislation update
by Jonathan Woolley 24 Feb '05

24 Feb '05

> The bill will apply to e-mails, text messaging and instant messaging > requiring that senders of multiple commercial electronic marketing > messages only send them to people who have agreed to get them. Senders > of promotional electronic messages will be required to stop sending > messages if recipients decide to opt out. Won't this result in most people getting more spam? 1. Spammer sends spam 2. You 'opt-out' 3. He tells his 20 spam buddies (who may or may not be in NZ and come under fancy new law) that it's an active email address with a real person at the other end 4. His 20 spam buddies give you 20 times the spam Even worse: 1. International spammer sends spam looking like it comes from NZ 2. Joe public 'opts-out' 3. International spammer spams twice as hard and tells his buddies Or am I missing something???

4 5