- NZNOG - lists.nznog.org

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