- NZNOG - lists.nznog.org

Audio Streaming
by Webmaster 28 Sep '05

28 Sep '05

Radio NZ is nearing the end of the testing phase of the live audio streams of National Radio and Concert FM. As a result of feedback from the tests we have removed the 16 kbs cap from our US server. This means that the streams can go up to 48 kbs stereo (National Radio) and 64 kbs (Concert FM) for ALL end users regardless of their location. At present about 40% of the traffic from this server is NZ bound. The streams are also available via NZ exchange points should operators wish to avoid the more expensive international route. regards, Richard Hulse

1 0

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

25 Sep '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:AS23754 descr: advertised to AS9439 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, 203.118.144.0/24^24-29, 202.7.4.32/28^28-29, 203.97.231.224/28^28-29, 203.79.85.80/29, 203.109.195.72/29, 210.48.103.0/29, 210.48.103.112/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 20050708 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23754 descr: advertised to AS9439 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, 203.118.144.0/24^24-29, 202.7.4.32/28^28-29, 202.7.7.88/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 20050926 source: NZRR

1 0

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

25 Sep '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:AS7696 descr: Route set advertised to AS9439 by OneSquared - AS7696 members: 202.160.112.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: sam(a)onesquared.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050905 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS7696 descr: advertised to AS9439 by OneSquared - AS7696 members: 202.160.112.0/21^21-29, 202.135.231.144/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: sam(a)onesquared.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050926 source: NZRR

1 0

What would the NZ numbers be?
by Juha Saarinen 22 Sep '05

22 Sep '05

http://computerworld.co.nz/news.nsf/netw/40778CA910E0E6B4CC25707D007A6977 Anyone know? -- Juha

1 0

Orcon support email - auto reply. Anyone from orcon listening??
by Gavin Legge 22 Sep '05

22 Sep '05

Yeah it's still coming through - if anyone at orcon is on here - they may want to unsub there support address so it does not auto reply all the time to the poster. The following came from support(a)orcon.net.nz in reply to my post... <include message> Thankyou for emailing Orcon customer support. Your email has been received and will be processed as quickly as possible, however we are experiencing some delays at present due to high customer demand so it may take up to 96 hours to get an initial response. We've just implemented a new ticketing system to allow better tracking of customer enquiries and orders - and your email has been assigned the identifier: FZT-83853-666. Please ensure you keep this ticket ID in the subject line of any related replies. Warm regards, Orcon Customer Support. Auckland: (09) 444-4414 Freephone: (0508) 4ORCON 8am - 8pm Monday-Friday 11am - 8pm Saturday/Sunday and public holidays -------------------------------------------------------------- In the interim, please check out the following items which may allow you solve your problem on your own: GENERAL: * Basic configuration settings http://www.orcon.net.nz/help/settings/nz/ DIALUP * Current pricing plans and signup http://www.orcon.net.nz/products/dialup/ DSL * Want to upgrade to Orcon's new BitStream 256k service ($49.95/month) http://www.orcon.net.nz/shortcut/getbitstream * Current pricing plans http://www.orcon.net.nz/products/jetstream/ * Experiencing high ping times/latency? See the following link for information http://www.orcon.net.nz/help/kb/ADSL/latency BILLING * Frequently asked questions about your billing http://www.orcon.net.nz/help/billing/ If any of the above links help answer the query you just emailed us, if possible please do us the courtesy of emailing us saying the problem is "resolved" so we can attend to other customer's queries. --- Kind Regards Gavin Legge Security Officer [Linux Systems Administrator] g.legge(a)irl.cri.nz 04 931 3131 (ext 4131) 021 905 461 This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.

1 0

Re: [nznog] Vodafone dial pattern - another change ?
by Gavin Legge 22 Sep '05

22 Sep '05

I used to work for a telco and on many occasions observed overlap sending on ISDN's working fine. This while watching test instruments across live lines. - so yeah - it's used out there for sure... Go for it. -----Original Message----- From: Ian Batterbee [mailto:ian.batterbee(a)aut.ac.nz] Sent: Friday, 23 September 2005 1:16 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Vodafone dial pattern - another change ? >Surely the delay thing is why most VoIP type systems accept something >such as "#" as an "I've finished inputting my number, please dial it" >indicator ? > > Although we do operate a VoIP system, that's largely irrelevant, because our previous PBX (Ericsson MD110) had all the patterns configured into it as well, so we would have been in the same situation. Users don't expect to have to dial a # at the end of their number, and we shouldn't expect them to have to do so. >Is the 5 seconds tuneable ? "wait 5 seconds till the 5th digit has been >entered then change this to 3 seconds till the 7th digit then change >this to 1 second" > The 5-second delay is coming from TelstraClear.. so no, we can't tune it. They're waiting for another digit, and when I posted about last month, it was because TCL's pattern was actually incorrect, and was waiting for extra digits that would never come, resulting in an unncessary 5 second setup delay to a large number of 021 numbers. This has since been corrected. A number of PBX systems validate the numbers so that they can match and therefore route them down the most appropriate route. Our (Cisco) PBX comes with patterns for most countries, which simplifies the task of setting up a new system. While I agree NZ's plan is relatively simple, other countries are not, and that's probably the reason they do it that way. There is the possibilty that we could enable overlap sending.. which I believe means that you send each digit as it is dialled, rather than all at once in an ISDN SETUP message - as it gives the telco the option to send back 'more needed', or 'that's enough digits'.. but.. I'm reluctant to turn it on without some proper testing first. Thanks to Barry who found the info I needed, and finally, to those of you who do validate the numbers locally, and who were forced into silence before posting anything by Steve's helpful comments, here are the new patterns: 021 0221 XXXX 021 0222 XXXX I believe there may be more coming. _______________________________________________ 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-- This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.

2 1

Re: [nznog] Vodafone dial pattern - another change ?
by Ian Batterbee 22 Sep '05

22 Sep '05

>Surely the delay thing is why most VoIP type systems accept something >such as "#" as an "I've finished inputting my number, please dial it" >indicator ? > > Although we do operate a VoIP system, that's largely irrelevant, because our previous PBX (Ericsson MD110) had all the patterns configured into it as well, so we would have been in the same situation. Users don't expect to have to dial a # at the end of their number, and we shouldn't expect them to have to do so. >Is the 5 seconds tuneable ? "wait 5 seconds till the 5th digit has been >entered then change this to 3 seconds till the 7th digit then change >this to 1 second" > The 5-second delay is coming from TelstraClear.. so no, we can't tune it. They're waiting for another digit, and when I posted about last month, it was because TCL's pattern was actually incorrect, and was waiting for extra digits that would never come, resulting in an unncessary 5 second setup delay to a large number of 021 numbers. This has since been corrected. A number of PBX systems validate the numbers so that they can match and therefore route them down the most appropriate route. Our (Cisco) PBX comes with patterns for most countries, which simplifies the task of setting up a new system. While I agree NZ's plan is relatively simple, other countries are not, and that's probably the reason they do it that way. There is the possibilty that we could enable overlap sending.. which I believe means that you send each digit as it is dialled, rather than all at once in an ISDN SETUP message - as it gives the telco the option to send back 'more needed', or 'that's enough digits'.. but.. I'm reluctant to turn it on without some proper testing first. Thanks to Barry who found the info I needed, and finally, to those of you who do validate the numbers locally, and who were forced into silence before posting anything by Steve's helpful comments, here are the new patterns: 021 0221 XXXX 021 0222 XXXX I believe there may be more coming.

1 0

Vodafone dial pattern - another change ?
by Ian Batterbee 22 Sep '05

22 Sep '05

In the last 24 hours I've heard from multiple sources that Vodafone is now using 8 digit prepay numbers - the numbers I was given that were reported 'not working' (because our PBX didn't match all the digits) were both 021-0222xxxx, ie, 8 digits after the 021. I know I asked about this only one month ago, but back then 021[012] only appeared to require 6 further digits, and not 7. I've just tried calling both 0222xxxx numbers from my vodafone mobile, and they they both rang. I tried leaving the last digit off, and they both failed, so it does suggest that things have changed. Does anyone know what's going on, and/or what the correct prefix for this number pattern is ? If I change my end to match 0210 plus 7, it will introduce a 5 second delay into any numbers that only have 6 digits after the 0210 -- Ian Batterbee, CCNP Senior Network/Comms Technician Auckland University of Technology

6 8

Want to sell the syntax S648 motherboard
by Kevn Wong 21 Sep '05

21 Sep '05

Dear sir, Now we have some syntax Syntax S648 motherboard in stock, they are all new original retail box unopen products. our offer is US$25.00/Pcs, if you are interesting in them, please feel free to contact me, thanks. Have a nice day Best Regards Kevin http://www.syntaxusa.com/catalog/product_info.php?cPath=44_46&products_id=68 Description ・ Intel Motherboard S648 Special Features ・ Socket 478 board that supports Intel Pentium 4 processor up to 533Mhz FSB ・ Integrated with the most advanced technologies - SiS MuTIOL media I/O Magic Setting, USB 2.0 (SiS 963) ・ USB 2.0 ・ Supports Ultra DMA 133/100 Specifications - Processors ・ Socket 478 for Intel Pentium 4 processor ・ FSB 533/400 MHz ・ Supports Hyper-Threading Technology - Chipset ・ North Bridge: SiS 648 ・ South Bridge: SiS 963 - Memory ・ 3 DDR DIMM sockets Support ・ 3 x 2.5V DDR SDRAMs (DDR266/DDR200) or ・ 2 x 2.5V DDR SDRAMs (DDR333) ・ Max. 3GB (2GB only for DDR333) - Graphics ・ 8X AGP - Sound ・ Compliant with AC97 2.2 specification - LAN ・ RealTek RTL8100/B 10/100 Mbps Fast Ethernet Controller - IDE ・ 2 UltraDMA 133/100/66/33 - USB ・ 6 USB 2.0 - Expansion Slots ・ 1 AGP 8X ・ 5 PCI ・ 1 CNR - Back Panel I/O Ports ・ 1 PS/2 Mouse ・ 1 PS/2 Keyboard ・ 1 Parallel ・ 2 Seria ・ Game port ・ 1 LAN ・ 2 USB ・ 1 Line-in ・ 1 Line-out ・ 1 Mic-in - Internal I/O Connectors ・ 2 USB 2.0 headers support additional 4 USB ports ・ Front Panel MIC/Line out header ・ SIR header ・ HDD LED, Reset switch, Power switch headers ・ ATX power connector ・ CPU/Power/Case fan Connectors - BIOS ・ Award 2MB flash EEPROM ・ Supports Plug and Play 1.0A, AMP 1.2, multi boot, DMI ・ Support ACPI V1.0 specification - Form Factor ・ ATX - Board Size ・ 12" x 9.6" (305mm x 244mm) - RTC & Battery ・ SiS 963 built-in 256 bytes of CMOS SRAM ・ With CMOS hardware clear jumper

1 0

Re: [nznog] Further Analysis of Election Night
by Regan Murphy 21 Sep '05

21 Sep '05

I'm with xtra for DSL at home. I don't seem to transit via the US to get content from the r2 servers. -----Original Message----- From: Dan Clark [mailto:dan(a)synaptic.net.nz] Sent: Thursday, 22 September 2005 6:59 p.m. To: Richard Naylor Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Further Analysis of Election Night mostly Xtra customers connecting to the US server no doubt? Dan

4 3

Further Analysis of Election Night
by Richard Naylor 21 Sep '05

21 Sep '05

Further analysis of the Election period webcast ----------------------------------------------- We have now had some time to analyse log files from the election period. The following observations are made. It should be understood that there were 4 servers, USA - 1 AKL - 2 (CityLink and TVNZ) WLG - 1 We have not had access to the TVNZ log files and so the following comments are based on analysis of 3 servers only. These servers were carrying 62% of the load (by traffic) It also needs to be understood that these servers were not set up solely for the election event and carried on handling day to day 24x7 streaming. So in looking at log files, there are many streams and services (such as on demand video or audio files) which were operating regardless of the election. Equally many of the stations which we stream had no particular coverage of the election and carried on their usual Saturday night programmes. As a result some analysis requires a little local knowledge to make sense. In addition, R2 was providing on-demand services to 3 political parties involved in the election. Several parties had closing video clips or focussed their multi-media assets for the closing stages of the campaign. This produced extra traffic on election day. In some cases a surprising number of hits. We also carried a number of election related events such as The Labour Party Election Campaign launch The InternetNZ ICT Candidates debate Election Fiscal Update (access via Scooop.co.nz) Several Press Briefings by the PM (access via Scoop.co.nz) Candidate debates (access via RadioNZ.co.nz) As a result a very rough estimate is that the last month has seen server traffic double. On election night, over 40 countries accessed the 3 CityLink servers. They were NZ 36% Australia 12% US 8% UK 2.5% France 1.5% Canada Japan Netherlands Singapore Switzerland Germany Czech Republic Italy Brazil Thailand Poland Malaysia Austria Saudi Arabia Israel India Hungary Taiwan Turkey Spain Slovakia Belgium Sweden Denmark Norway Fiji Azerbaijan United Arab Emirates Russia Philippines The top 15 countries all accessed over 1GBytes of data Of great interest to us is the access to the USA server as its usage is designed to handle international interest under a strategy of locating servers as close to the clients as possible, so that over time, higher quality material (audio or video) can be delivered. The USA server received connections from NZ 30% Australia 20% USA 10% UK 3.7% Japan 1.5% Singapore 1.3% With 3 servers located in NZ, there was no need for traffic from the US server to NZ. This is caused solely by poor peering by NZ ISPs. It represents some 10Mbps of traffic.

3 3

Useful BGP tool
by Gordon Smith 21 Sep '05

21 Sep '05

A little something that's quite useful for looking at route advertisement trends over time. It complements the use of route-servers quite well when looking at BGP path changes internationally. Found the link on NANOG http://bgpinspect.merit.edu/

2 1

Re: [nznog] [afnog] ARIN to allocate from 74/8 & 75/8
by Rob Thomas 20 Sep '05

20 Sep '05

Hi, Randy. ] but, as you seem to understand, that's only half the story. luckily, ] the other, more useful, half is easily testable if arin/cymru would ] just follow the long-discussed path. We couldn't agree more! That's why we stood up the following three pingable IP addresses prior to announcing the test prefixes. 74.63.1.2 75.127.1.2 76.191.1.2 Sorry those weren't announced sooner! Thanks, Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999.

1 0

Woosh prefix update
by Nathan Ward 20 Sep '05

20 Sep '05

We are now advertising an additional prefix to our APE and WIX connected peers, including the route servers for these exchanges. I also ask that anyone not currently accepting up to 24 bit long prefixes in our advertisements, to please do so. We have no need to advertise these now, but we'd like to have the option available if needed, yadda yadda. The new prefix is 203.211.64.0/20. So, in the end it should look something like: ip prefix-list woosh-in seq 5 permit 202.74.192.0/19 le 24 ip prefix-list woosh-in seq 10 permit 203.211.64.0/20 le 24 Other potentially useful details follow: ASN 17412 APE IP 192.203.154.49 WIX IP 202.7.0.50 For those of you who are not currently peering with us and would like to arrange direct peering sessions, please contact me offlist, or on +64-9-522-3699, ext 618. -- Nathan Ward

2 1

Election Night Statistics
by Richard Naylor 20 Sep '05

20 Sep '05

Election Night Webcasting Statistics On Election night, 2005, CityLink/R2 was involved in assisting a number of broadcasters with their streaming requirements. This was in addition to the normal webcasting activites being carried out with other TV and radio stations. Particular focus was placed on TV-One (TVNZ) TV-3 NewstalkZB National Radio The streaming was carried out using servers located in Auckland, Wellington and Palo Alto (USA). Encoding was carried out by TVNZ and CityLink/R2. In terms of number of viewers, the 2003 Lord of the Rings premiere has been regarded as the biggest event webcast to date. The election night figures passed that by approximately 50%. On election night, some servers used anycast routing to spread traffic between servers, so that viewers connected to the server closest to them by Internet topology. Because not all servers used anycasting, we experienced congestion on the link feeding the US based server. As a result, some viewers used the link to NZ servers, further overloading the International capacity. In hindsight, we should have fed the US server via an alternate route to ensure the quality of its streams. In terms of traffic, the average bandwidth being consumed was Auckland (2 servers) = 110 Mbps Wellington (1 server) = 50 Mbps USA (1 server) = 50 Mbps Total average bandwidth = 210 Mbps Peaks were of course much higher. Estimates are that approximately 450Gbytes of data was transferred during the event of 6 hours. 98% of this data was carried by the anycast routing architecture. At 10 cents per megabyte this data represents approximately $45,000. CityLink delivered this event for free as a public service. Lessons Learned Our experience suggests that for large events, anycast routing delivers high performance. However, the source feed to the US servers needs to be isolated from any other traffic into or out of NZ. We could have done this using our satellite capacity or by strictly enforcing anycast routing. This would have meant that NZ ISPs not peering at NZ Internet exchanges would have to bring significant traffic into NZ on their International circuits.

1 0

Re: [nznog] New phish - Westpac
by Nic Wise 20 Sep '05

20 Sep '05

> BNZ tried using certs in 2000 for IB for public - was a > nightmare - far too early for browser compatibility usual > portability of certs etc. Ah, I might have had my banks mixed up. > And of course, and this will come > as a surprise to some, certs aren't very good for > authentication remember - their power in is in persistently > marking transactions/data or whatever That BNZ system was > tried to get round key loggers but as you say anything that > needs specific machine setups/configs will fail for retail > banking. And there are screen grabbers now anyway. Oh, I found that even without the threat of phishers etc, the pain of using it (Even after I installed Java) was just too high. > 2-factor also does not solve the problem and can introduce > more. Netcode relies on a now-defunct, unsupported product > from RSA - it was dropped from the RSA product line due to > the issues with SMS delivery and security - ask yourself how > secure the SMS network is, would you know, do you know ? I Well, personally, I'd find it more secure that not having it at all. Without something like it, anyone can get in with my username + pwd. With it, atleast if they ALSO intercept my cell transmission, they can get it for what, 10 mins (assuming they have my UN+PW as well). That's a fairly small window, and better than the current situation. > would be more concerned about that than anything. Also, the > banks cannot control SMS delivery nor guarantee anything and > therefore don't like it. 2 factor is relatively complex to > manage in big deployments, expensive (relatively compared to > a password) and probably overkill for retail but spot on for > business - which of course you'll know has been used in for a > number of years now by most banks.... I think ASB got around that by having something in there saying "if you don't get the text within X mins, call us on 0800 WHATEVER, quote ID 123456 and we'll check your details like we normally do". > Remember though - you can use a computer - most people who > use retail Internet Banking can't - IB is the pinnacle of > their PC knowledge VERY good point. Smartcards + reader look interesting, but there again - hardware compatability. Does it works on a Mac? Does it work on my mothers old P166 without USB? Etc. > And anyway banks don;t make any money from retail banking so > until phishing and e-banking scams become sufficiently common > they still pale in comparison to manual frauds. The real > answer is to remove some functionality but of course we'd all > moan...Free beers for life for the person that cracks the > portability vs security conundrum ! Very true. As long as they keep refunding people when they get all their money nicked, it's not THAT huge a long-term problem. Short term, and for the person who's cash is (for a while) gone, it's a bit of a stresser. :) Good discussion to have, me thinks, especially given the types of people on this list. :) Now, lunch and Beer :) Is it Friday yet? N

1 0

Re: [nznog] New phish - Westpac
by Nic Wise 20 Sep '05

20 Sep '05

> I'm not a application Security expert, but why can the banks > issue a authentication Certificate, and only allow > connections to those who are authenticated? > Certs would help, but they are a PITA to get working reliably. I know of one place that does use them (www.vir.co.nz - only for dealers) - but Banks are very much mass-market, and mom-and-pop would have a lot of troulbe working it out. I think one of the banks (ANZ??) tried it a while back. Not sure what they use now tho. The worst I have used was BNZ - they had a Java applet, and you had to CLICK on your password, on a keyboard on the screen. Wow, how secure, if someone is shoulder surfing, or capturing mouse clicks. And, it was just crap to use, especially if you didn't have Java (you just couldn't get in without Java!) 2-factor authentication is one of the few ways they could tighten up on security. ASB already does this, to some extent, with NetCode (ditto BankDirect - same company tho). They send you a text to confirm (you have to enter the code in the text) if the amount is over a specific value ($2500 per day). Works great. Why not do it on ALL transactions under a certain value (eg, $50)? Want to log in and check accounts? Fine. Usename + password. Want to move money? You then MUST use 2-factor authentication. I'd say that 99% of people with computers, also have cellphones, so text messages is a good way. Going overseas? Get one of those fancy SecureID cards on loan. I'm SURE that a load of people on this list know those cards - credit card sized "random" number generators on their keyrings. Same idea could be implemented for LESS cost than the banks usually loose.... Of course, the banks have to be motivated to do it.... And they are not, really, at the moment. It might still give the phishermen entry, but only within a VERY small window (60 seconds to 5 mins, usually), which would solve most of the problems. Of course, you'd need to sync it up with the Beer Tap at the pub somehow..... Maybe give the "keys" away free with every pint sold? Righto. Back to work :) Nic -- Nic Wise - Senior Developer - Microsoft MVP (.NET) t. +64.21.676.418 w. http://www.aftermail.com/ e. nic.wise(a)aftermail.com b. http://www.fastchicken.co.nz/blog/

4 4

Re: [nznog] New phish - Westpac
by David Robb 20 Sep '05

20 Sep '05

On Mon, 19 Sep 2005, Jeremy Strachan wrote: > > Given the alternative is our users bank accounts being cleaned out - I'm > all for Telco and/or ISP's blocking access to the site. So you say it's ok for bank phishing. What about ebay/trademe/other auction/sales sites? What if it were for Live Journal? --David

15 20

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

19 Sep '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:AS23655 descr: advertised to AS9439 by Snap Internet Limited - AS23655 members: 132.181.0.0/16^16-29, 202.124.96.0/19^19-29, 203.97.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050913 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23655 descr: advertised to AS9439 by Snap Internet Limited - AS23655 members: 132.181.0.0/16^16-29, 202.124.96.0/20^20-29, 203.97.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 203.96.112.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050920 source: NZRR

1 0

Price list from kevin
by Kevn Wong 18 Sep '05

18 Sep '05

Dear sir, How is your weekend? I'm kevin from Pcarcher data Technology Ltd. We are a manufacturer and Exporter from china, we make and sell the VGA Card and networking products. We have our own factory, the factory are with 4 STM product line, and all products go out the door of factory after double QA and QC, so we can deliever the goods to our client within 4 working day after we get client's payment, and we can supply 13 months warranty to our client, hope that we can do the business with you, I believe we will become your good supplier, and supply the best products and service to you. Enclosed is our price list of these products, please check it, hope that you can find some you products which you like, looking forward to hearing from you again, anyways thanks for your support. My msn is w_qifan(a)hotmail.com. Cisco 1721 US$300.00/Pcs WS-C2950-24 US$310.00/Pcs WS-C2950T-24 US$450.00/Pcs 2610XM US$700.00/Pcs 2620XM US$710.00/Pcs 2621XM US$710.00.Pcs BTW now we have the DI-524 and DI-624 in stock, they are original products, and our offer are follows, please check it. DI-524 US$29.0/Pcs 54Mbps http://www.dlink.com/products/?pid=316 DI-624 US$40.5/Pcs 108Mbps http://www.dlink.com/products/?pid=6 Have a nice day Best Regards Kevin Pcarcher Data Tehcnology Ltd Room 2106, BaoAn Plaza, ShenNan Road,Shen Zhen City,China Tel: +86 755 82818860 Fax: +86 755 82818640

2 1

Re: [nznog] New phish - Westpac
by Simon Allard 18 Sep '05

18 Sep '05

> > Phising is no different to putting a skimmer and camera onto an ATM > machine and stealing the card details and pin numbers. Infact, how many of you check for skimmers and cameras before putting your card into an ATM or make sure the clerk behind the desk doesn't skim your credit card before giving it back? I would say not many people would. How is that any different from an average internet person and a phising website?

1 0

Re: [nznog] New phish - Westpac
by Simon Allard 18 Sep '05

18 Sep '05

> > You will need to come into the branch and do it there. > > > > If you do follow links and get stung then we'll treat it along the same > lines > > as "so you met this guy in a pub and he said 'can I borrow your ATM card > and > > pin number for ten minutes'.....". You can't compare a Phising site to that. The user doesn't know they are entering details into a trojaned website. Phising is no different to putting a skimmer and camera onto an ATM machine and stealing the card details and pin numbers.

1 0

Re: [nznog] New phish - Westpac
by Joel Van Velden 18 Sep '05

18 Sep '05

> >> >> Wait until the phishers catchup with the normal spammers and make the > IP >> of their websites move every 10 minutes. Personally I'm surprised it >> hasn't happened already, certainly it will happen if people get > efficient >> at blocking single IPs. > > That's why it's better done at the ISP level. > > If they have web caches which transparently proxy everything. (dunno how > many isp's still do this). But the URL itself can be blocked rather than > the IP. > > Carriers shouldn't block IP's IMHO. Can't ISP's just intercept http traffic destined for phishers' sites (based on url matching, not ip) and display a nice html message to the user how their bank account would have been cleaned out if it hadn't been for their nice friendly isp? :) Certainly blatantly blocking ip's at carrier level is rather nasty. what happens if that IP is a large virtual host server? Replacing content (as above) at least allows you to make it obvious to all users whats happening. -Joel > > Simon Allard > ihug Limited > > P +64 9 962 9827 > M +64 21 456 412 > E simon.allard(a)staff.ihug.co.nz > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > >

2 1

Re: [nznog] New phish - Westpac
by Simon Allard 18 Sep '05

18 Sep '05

> I don't buy this line of reasoning any more. Don't open attachments > from people you don't know. Don't open attachments from people you do > know. Don't open attachments that have innocent looking icons like a > text file. Don't preview emails that have attachments. Now we're in an > arms race where trying to send any email attachments around the internet > is a sure fire way of getting someone to blackhole your entire email for > "malicious content"[1]. Even experienced users running around with all > the latest antivirus and ad zappers and everything can *still* > occasionally get infected with spyware.[2] How do you expect users to > keep up? I agree with this comment. If user education worked, ISP's wouldn't be hit with high call volumes when the big viruses hits. ISP's wouldn't need to have big virus/spam servers in front of their mail farms. Too many stupid users, and when those stupid users become educated, there are new stupid users who take their place. It's a never ending cycle. Every time a user rings the helpdesk, it hits the ISP's bottom line, hence why a lot of ISP's are in favour of blocking phising/virus ports etc. But I don't understand why carriers block stuff. Simon Allard ihug Limited P +64 9 962 9827 M +64 21 456 412 E simon.allard(a)staff.ihug.co.nz > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Re: [nznog] New phish - Westpac
by Gordon Smith 18 Sep '05

18 Sep '05

It's a typical spammer setup that's using zombies to provide DNS. Makes it more difficult to shut them down. The web server is located in India. We've already notified them of the compromised host, and also asked joker.com to pull the domains. Both this domain, and the domains that the nameservers respond to, are bogus. I'm not going to hold my breath waiting for joker to act though :-) Cheers, Gordon

5 5

Re: [nznog] New phish - Westpac
by Gavin Legge 18 Sep '05

18 Sep '05

<start drivvel> well well we have come full circle.. So who's going to gauge what will and wont get through ay. I'm all for letting people choose themselves. If they don't like what they see - they can unplug. It's a big scary world out there ay... It's like the isp's/transport providers are the highways. If people wanna walk out in front of a car on your highway (even though it's obviously a big truck that's gonna run them down badly disguised as a phishing scam.. - well - they have been warned. They had to learn to walk in real life- maybe they should learn to 'walk' in 'our virtual world' ie fall over some of the pitfalls - just like we all have done at some time.. You cant protect everyone all the time. So many standards of wrong and right and possibly no right answer. </end drivvel> This is the bit where I go quiet again - after all I don't even work for an ISP any more! Shudder... -----Original Message----- From: David Robb [mailto:ender(a)paradise.gen.nz] Sent: Monday, 19 September 2005 4:28 p.m. To: Russell Sharpe Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] New phish - Westpac On Mon, 19 Sep 2005, Russell Sharpe wrote: > I guess from a morality point of view... > Is it in an ISP's best interest to protect its customers interests? If you want to involve morality... many people don't like pornography. There's lots of it out there. Should we block it? --David _______________________________________________ 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-- This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.

1 0

Re: [nznog] New phish - Westpac
by neil gardner 18 Sep '05

18 Sep '05

>>>> Andy Linton <asjl(a)citylink.co.nz> 19/09/2005 4:15 p.m. >>> >> So you say it's ok for bank phishing. What about ebay/trademe/other >> auction/sales sites? > >Perhaps the correct response is some (more) user education and then allow >evolution to take over - those people who are too stupid to work this out lose >all their money and then they can't use the Internet any more. While ISPs will >lose revenue from them they're probably the ones who cause 90% of the help >desk calls and so profitability goes up and we all get more time for beer. On a more general level it's a simple economic problem and we shouldn't be expending that much energy into finding a technical solution. The current level of bank fraud is _obviously_ acceptable to the banking institutions (1)... When it becomes unacceptable then we'll see more secure (yes, less convenient) methods of conducting e-banking. We'll probably also see the banks seriously publicise the issues and most importantly, we'll see the banks start shying away from accepting financial responsibility for these phished transactions - currently they wear most of the losses. Regards Neil Gardner (1) They are obviously acceptable because we haven't seen the banks go ballistic to close this down from their end - don't think they don't know how, or can't afford it... It's just more trouble than it's currently worth. If we keep trying to solve the problem from a technical perspective, the attacks just get better, and the banks get to sit (relatively) idly by and not have to solve the root problems. Neil Gardner Product Manager - Product Line Management Allied Telesyn Research Ltd New Zealand +64 3 339-9509 (ph) +64 3 339-3001 (fax) NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

Re: [nznog] New phish - Westpac
by Simon Allard 18 Sep '05

18 Sep '05

> > Wait until the phishers catchup with the normal spammers and make the IP > of their websites move every 10 minutes. Personally I'm surprised it > hasn't happened already, certainly it will happen if people get efficient > at blocking single IPs. That's why it's better done at the ISP level. If they have web caches which transparently proxy everything. (dunno how many isp's still do this). But the URL itself can be blocked rather than the IP. Carriers shouldn't block IP's IMHO. Simon Allard ihug Limited P +64 9 962 9827 M +64 21 456 412 E simon.allard(a)staff.ihug.co.nz

1 0

Re: [nznog] New phish - Westpac
by Simon Allard 18 Sep '05

18 Sep '05

> > > traceroute secwestpac.com > traceroute to secwestpac.com (210.212.134.2), 64 hops max, 44 byte packets > 1 drew.router.bw (10.4.6.254) 0.709 ms 0.474 ms 0.533 ms > 2 dsl.bw (10.10.69.254) 1.703 ms 1.554 ms 1.505 ms > 3 219-88-160-1.jetstream.xtra.co.nz (219.88.160.1) 139.575 ms 73.358 > ms 143.285 ms > 4 203.96.122.59 (203.96.122.59) 77.224 ms 184.149 ms 105.514 ms > 5 fid-int.tkbr4.global-gateway.net.nz (202.50.245.198) 60.790 ms > 65.843 ms 59.394 ms > 6 vlan-283.tkbr4.global-gateway.net.nz (202.50.245.197) 59.068 ms > 58.437 ms 59.557 ms > 7 210.55.202.65 (210.55.202.65) 59.215 ms !H * 59.743 ms We have also killed the routes to the sites on our borders. Simon Allard - CCNA Senior Systems Programmer ihug Limited P +64 9 962 9827 M +64 21 456 412 E simon.allard(a)staff.ihug.co.nz

1 0

Sponsorship - packages or tiers?
by Lin Nah 18 Sep '05

18 Sep '05

I do admit that I don't know much about this and some of my conclusions are based on observations of what other conferences / events have done. So feel free to shoot parts or any of this down if need be. Tiers of sponsors: The reason why I say we are too small to have tiers of sponsors is because essentially the number of sponsors we can have in a small event such as this is small. To me tiers of sponsor implies the sort you see at the ballet etc where it says if you pay a certain amount you are listed as a sponsor at that level. This however doesn't specify what they are sponsoring. ie we'd be out there each of us asking ppl to sponsor $x for Tier1 and sponsor y for tier 2. With those sorts of sponsorships (form what I have seen) there is a list of perks they get with it. eg tier 1 = 3delegates, logo on bag and shirt, etc. Tier 2 = 2 delegates and logo on notepad To have this we'd have to have ability to work towards obtaining enough sponsors, and figure out what to do if we don't get enough. I know that's like normal sponsorship. Howver it is a bigger risk if some or many of our potential big sponsors decide to go for a lower tier. So instead of tiers, we have a shopping list of stuff we want and find sponsors for a combination of them. The reason why we would package them is because some stuff is more "sexy" and so more easy to find a sponsor. The idea with the package is to ensure at the end of the day we aren't left with a list of the stuff that is hard to find a sponsor for and yet is important for the conference. It is also harder perhaps to find sponsors for an overseas speaker as the $ amounts are higher For example it won't be hard to sell the idea of sponsoring a bar tab but you may find it harder to get someone to sponsor stuff like the AV gear (mics, laser pointers etc). It will be like tiers of sponsors in the fact they are sponsoring $x means we give them certain benefits. With each item in the shopping list we should perhaps add a certain markup to cover costs of some of the other non sponsorable stuff. or make sure they sponsor more than one thing. eg speaker + AV hire. Bandwidth + bags The thing with the big ticket items is we should try to give them something in return. Something that their management can understand as a return. Some of those speakers can speak on more than one topic. So we could perhaps ask them to also do a public lecture (perhaps at a uni campus somewhere) and an interview with idg or herald technology. Thus the sponsor has a bigger exposure for that amount given. List of items that are sponsorable Overseas Speaker(s) - Travel & Accommodation Local Speaker(s) - Travel & Accommodation Venue costs (room hire) Main Dinner Bar Tab Bag (generic term - could be backpack/satchel/folder etc) Lunch Bandwidth Networking (wireless hubs) Streaming AV Gear (mics, data projectors, laser pointers) Coke Fridge. Fridge hire & filling it with drinks (we perhaps get stickers for each can with the sponsor's logo? or just a poster on the fridge door, say size of door with sponsor's logo) First night dinner (usually not part of nznog) Costs So far all I have is what has been posted to this list I have no idea what other sutff cost in the past but things like t-shirt and bag, I could easily ring round for quotesi f need be. Bandwidth: 2005: The conference network carried just over 32GB of traffic, including the video streaming, but not traffic to www.nznog.org. Coke: 2005: 495 cans of soft drink (incl 275 coke and 100 diet coke), 2004: 420 cans soft drink (there was fridge filled with coke, diet coke, sprite, fanta, and other soft drinks. No V or red bull) Tea, Coffee, OJ, Biscuits 2005: over 60L of juice and nearly 4kg of ground coffee. 2004: 80 ltrs OJ (morning tea/coffee and lunch) Food bill: 2004: $5800 (I am not sure what that included. Tony - did this include dinner or just lunch, morning tea&coffee) Bar Tab 2005: $1500 ($1000 by 2day and $500 by WAND) 2004: $1000 2002: $1000 Anyway I am sure there are ppl in here who are more experienced than I about these sorts of things. Do we want tiers of sponsors as in look for people to contribute certain sums of money? eg $10000, $5000, $1000. OR do we want sponsors to sponsor specific items. ie all stuff we need is listed as sponsorable items? regards lin

1 1

Subject: Changes to registration of .govt.nz domains
by keith.mclean＠ssc.govt.nz 18 Sep '05

18 Sep '05

Hello NZNOG, As part of the moderation of the .govt.nz domain, the State Services Commission (SSC) has become a .nz registrar. On October 3rd any new .govt.nz domains will need to be created through the SSC registrar at <http://www.dns.govt.nz/>. Over the next few months, the existing .govt.nz domains will be transferred to the new registrar. We will make contact with existing registrars and registrants of .govt.nz names before any transfer occurs. No delegation will change during the transfer. If you are providing name-service for a .govt.nz name this should continue, as should any billing for this service. The SSC Registrar will not complete with other .nz registrars in non-government namespaces. Further details are available on the website at <http://www.dns.govt.nz/terms_and_conditions.php> If you have any concerns about the upcoming transfers, please contact transfers(a)dns.govt.nz or call 0508 GOVTNZ (468869) Unfortunately moderation rules prohibit the registration of beer.govt.nz, but consumption is acceptable. Regards Keith McLean Keith McLean, State Services Commission. DDI (04) 495 2861.Mobile (027) 6096779 Caution: If you have received this message in error please notify the sender immediately and then delete this message.

1 0

linux.jetstreamgames.co.nz
by Matthew Poole 18 Sep '05

18 Sep '05

Does anyone on here know the status of this server? Is it down for good, or just for protracted maintenance? Thanks -- Matthew Poole "Don't use force. Get a bigger hammer."

1 0

New phish - Westpac
by Alastair Johnson 18 Sep '05

18 Sep '05

Morning If anyone from Westpac Security monitors NZNOG, and for those that want to update their mail rulesets appropriately, there appears to be a new phish this morning for Westpac. I've received 6 in the last 10 minutes. All originate from 219.128.152.213, a Chinanet host or 82.229.209.178. The body refers people to http://secwestpac.com/IOLB/newSession . The hostname is similar to their correct "sec.westpac.co.nz". The domain hasn't yet been pushed into WHOIS, but is in the GTLD servers. The body of the message is HTML, with Westpac graphics. The text is: Processing error We were unable to process your recent transactions on your account. To ensure that your account is not suspended, please update your information Headers below. aj From - Mon Sep 19 10:28:31 2005 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: <update(a)westpac.co.nz> X-Original-To: aj(a)sonic.sneep.net Delivered-To: aj(a)sonic.sneep.net Received: by sonic.sneep.net (Postfix, from userid 668) id 8E13A21CFB; Mon, 19 Sep 2005 10:19:50 +1200 (NZST) Received: from smtp01.maxnet.net.nz (smtp01.maxnet.net.nz [202.89.32.6]) by sonic.sneep.net (Postfix) with ESMTP id B9D3E21CEE for <aj(a)sneep.net>; Mon, 19 Sep 2005 10:19:39 +1200 (NZST) Received: from mailfilter01.maxnet.net.nz (mailfilter01.maxnet.net.nz [202.89.32.8]) by smtp01.maxnet.net.nz (Postfix) with ESMTP id 323D2406A2E for <aj(a)sneep.net>; Mon, 19 Sep 2005 10:21:14 +1200 (NZST) Received: from stolichnaya.maxnet.net.nz (stolichnaya.maxnet.net.nz [209.123.221.169]) by mailfilter01.maxnet.net.nz (Postfix) with ESMTP id CF02384E40 for <aj(a)win.co.nz>; Mon, 19 Sep 2005 10:21:55 +1200 (NZST) Received: from -1211395320 (cha92-7-82-229-209-178.fbx.proxad.net [82.229.209.178]) by stolichnaya.maxnet.net.nz (Postfix) with SMTP id DA3B65325E0 for <aj(a)win.co.nz>; Mon, 19 Sep 2005 10:19:37 +1200 (NZST) Received: from westpac.co.nz (142870456 [137878400]) by cha92-7-82-229-209-178.fbx.proxad.net (Qmailv1) with ESMTP id A18855DD6F for <aj(a)win.co.nz>; Sun, 18 Sep 2005 14:46:52 -0700 Date: Sun, 18 Sep 2005 14:46:52 -0700 From: Update <update(a)westpac.co.nz> X-Mailer: The Bat! (v2.00.6) Personal X-Priority: 3 Message-ID: <4793089069.20050918144652(a)westpac.co.nz> To: Aj <aj(a)win.co.nz> Subject: Anti-fraud notification MIME-Version: 1.0 Content-Type: multipart/related; boundary="----------572BB2C4F688976"

2 1

Inaugural Cisco User Group Meeting
by Philip D'Ath 16 Sep '05

16 Sep '05

I'm establishing a Cisco User Group in Auckland. The inaugural meeting is taking place Wednesday 12th October. Further details can be found at: http://www.nzcug.org.nz/ I could really do with a mailing list. Any volunteers to host this? Off course, offlist replies.

1 0

[removal of service on OLD ip address for "B"]
by bmanning＠vacation.karoshi.com 16 Sep '05

16 Sep '05

good afternoon, back on 14 january 2004, we provided notification that the "B" root server address was being renumbered. this renumbering occured 28 january 2004. we have continued to run root service on the old address since then to ease transition for those who might have needed more time to make the change. please ensure that you have a current "root.hints" or "cache.db" file. The Current version may be downloaded from: http://www.internic.net/zones/named.root we have requested and received permission to terminate root service on the old IP address for the "B" root server and plan to do so on 01 january 2006. if there are concerns or questions, please let us know. --bill manning for <hostmaster(a)b.root-servers.net>

1 0

Global Gateway issue today
by Barry Murphy 15 Sep '05

15 Sep '05

Hi, I was aware of an issue on orcons Global-gateway issue today where both national and international was basically unusable for about 3 hours. I'm trying to find out if anyone else was effected as my flat mate who who manages a banks network (which I prefer not to mention) but they were told for 3 hours that the problem was within their network. I'm aware of 1 other company that connects direct to global-gateway that was effected. Please reply off list and if people are interested I'll send a summary. Thanks Barry

1 0

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

13 Sep '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:AS64564 descr: advertised to AS9439 by ATP - AS64564 members: 202.68.88.0/26^26-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 20050914 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64564 descr: advertised to AS9439 by ATP - AS64564 members: 202.68.88.0/26^26-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: gavin.mincher(a)datacraft.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050914 source: NZRR

1 0

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

13 Sep '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:AS64564 descr: advertised to AS9439 by ATP - AS64564 members: 202.66.88.0/26^26-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 20050914 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64564 descr: advertised to AS9439 by ATP - AS64564 members: 202.68.88.0/26^26-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 20050914 source: NZRR

1 0

NZNOG 06 update
by Simon Lyall 12 Sep '05

12 Sep '05

Just a quick update, it has been 3 weeks since the call for papers. 1. Wednesday SIG Day So far we have not had any interest/offers/plans for the Wednesday which we've previously given over to streamed sessions. If you wish to do something that day please contact us fairly soon. Possibly we might end up having the conference over all 3 days (or perhaps streaming the Wednesday morning only). 2. Sponsorship. We are currently preparing a list of sponsorship options for perspective sponsors. If you are interested in sponsoring NZNOG 2006 ( via Money, Speakers, Goods, Money, Services or Money ) then please contact sponsorship(a)nznog.org. 3. Talks We have had several good talk proposals already and are in process or arranging others. Please make sure you submit proposals before the deadline to have a good chance of getting in. Don't forget you can do a lightning talk if you don't want to do a full one. Or you can do like WAND did this year and split a 1 hour talk slot across several talks by members of your team. Or something else perhaps. Email talks(a)nznog.org . 4. Website We have a initial website up ( http://www.nznog.org ) with some information on 2006 (Thanks Mark) . This site will be expanded/replaced in a few weeks/months but it is there to give the 2006 conference an initial presence. 5. Feedback/Questions. Email any feedback or questions to info(a)nznog.org , or email me directly if you're shy. -- 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

Upcoming Live Webcasts
by Richard Naylor 12 Sep '05

12 Sep '05

14 September - Maori Language Week Awards - http://www.r2.co.nz/20050914 25 September - World Mountain Running Championships - http://www.r2.co.nz/20050925 A few challenges with getting connectivity, but otherwise nothing too major happening.

1 0

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

12 Sep '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:AS23655 descr: Route set advertised to AS9439 by Snap Internet - AS23655 members: 132.181.0.0/16^16-29, 202.124.96.0/20^20-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050721 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23655 descr: advertised to AS9439 by Snap Internet Limited - AS23655 members: 132.181.0.0/16^16-29, 202.124.96.0/19^19-29, 203.97.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050913 source: NZRR

1 0

Fast UpLink ( OT)
by bigalownz 10 Sep '05

10 Sep '05

Due to my normal ihug bliink only being 128k up I'm looking for a ISP etc that can help me with a fast up link so I can send data (5GB) to San Diego - California one time a week for the next year I worked it out if would take me 60 - 70 hours to send it on my ihug bliink Thanks

7 6

Notification of NZRR Database changes
by NZRR Database Notifications 08 Sep '05

08 Sep '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, 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, 192.173.24.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 20050721 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, 202.59.4.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, 192.173.24.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.johnston(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050909 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 08 Sep '05

08 Sep '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: 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, 192.173.24.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 20050721 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, 202.59.4.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, 192.173.24.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.johnston(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050909 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 08 Sep '05

08 Sep '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:AS24005 descr: Route set advertised to AS9560 by SafeNZ - AS24005 members: 202.137.240.0/21^21-29, 203.98.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 20050909 source: NZRR

1 0

Live Audio Streams
by Webmaster 06 Sep '05

06 Sep '05

Radio NZ has commenced a public test of our live streams from our current web site. This is being done so that we can fine tune the system prior to the launch of the new web site. Here is a list of what is available: Service Max. Data Rate Mode National Radio 48 kbs Stereo Concert FM 64 kbs Stereo RNZ International 48 kbs Mono www.radionz.co.nz/audio/ We have also posted on demand audio of the Radio NZ Election debates. There has been considerable interest in the programmes posted to date. www.radionz.co.nz/election2005/ regards, Richard Hulse

3 2

128k beer?
by Blair Harrison 05 Sep '05

05 Sep '05

Slow day.. Gotta be on topic, surely.. It's a mock Tui Ad :) http://jedi.net.nz/128kbroadband.jpg Cheers, Blair

1 0

ISPs offering transit service via the APE
by Andy Linton 04 Sep '05

04 Sep '05

A good number of ISPs use the APE for transit between each other either by using the APE route servers to exchange routes on a multilateral basis and/or direct bilateral arrangements. A smaller number offer transit services directly to customers using our fabric in Auckland. In Wellington, we have a list of those who offer services (ahttp://www.citylink.co.nz/community/isps.html) and I'd like to build a similar one for Auckland. Contact me off list if you want to be included. I'll owe a beer to the first person to respond. (:-)

1 0

Jetstreamgames FreeBSD distfiles
by Barry Murphy 04 Sep '05

04 Sep '05

Hey there, I can't recall who looks after jetstreamgames, but I recall the person being on this list. It would seem since the weekend that the distfiles have disappeared for FreeBSD, any chance of these re-appearing? ftp://linux.jetstreamgames.co.nz/dist/freebsd/ports/distfiles/ Thanks Barry

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 04 Sep '05

04 Sep '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: AS7696 as-name: NZRR-AS7696 descr: OneSquared descr: WIX peering at '202.7.0.137' descr: see Citylink RT job #3156 descr: APE peering at '192.203.154.25' descr: see Citylink RT job #3088 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS7696 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS7696 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: sam(a)onesquared.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050905 source: NZRR REPLACED BY: aut-num: AS7696 as-name: NZRR-AS7696 descr: OneSquared descr: WIX peering at '202.7.0.137' descr: see Citylink RT job #3156 descr: APE peering at '192.203.154.25' descr: see Citylink RT job #3088 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS7696 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS7696 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: sam(a)onesquared.net notify: noc(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050905 source: NZRR

1 0