- NZNOG - lists.nznog.org

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

30 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: CHIX peering at '218.100.24.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24388 accept ANY AND NOT fltr-bogons export: to AS24388 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: SIX peering at '218.100.25.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24387 accept ANY AND NOT fltr-bogons export: to AS24387 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

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

30 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: SIX peering at '218.100.25.2' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24387 accept ANY AND NOT fltr-bogons export: to AS24387 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: CHIX peering at '218.100.24.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24388 accept ANY AND NOT fltr-bogons export: to AS24388 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR --- OBJECT BELOW CREATED: route-set: AS24388:RS-ROUTES:AS23754 descr: Route set advertised to AS24388 by CityLink - AS23754 members: 202.8.44.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

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

30 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: DPE peering at '218.100.23.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24384 accept ANY AND NOT fltr-bogons export: to AS24384 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: SIX peering at '218.100.25.2' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24387 accept ANY AND NOT fltr-bogons export: to AS24387 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR --- OBJECT BELOW CREATED: route-set: AS24387:RS-ROUTES:AS23754 descr: Route set advertised to AS24387 by CityLink - AS23754 members: 202.8.44.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

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

30 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: route-set: AS24384:RS-ROUTES:AS23755 descr: Route set advertised to AS24384 by CityLink - AS23755 members: 202.8.44.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

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

30 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route: 202.8.44.0/22 descr: Route for CityLink - AS23754 origin: AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR REPLACED BY: route: 202.8.44.0/22 descr: Route for CityLink - AS23754 origin: AS23754 notify: rpsl-admin(a)nzix.net notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR --- OBJECT BELOW CREATED: route-set: AS24384:RS-ROUTES:AS23754 descr: Route set advertised to AS24384 by CityLink - AS23754 members: 202.8.44.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

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

30 Mar '05

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

1 0

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

29 Mar '05

Hi guys - this isn't strictly operational but I think it's an appropriate audience. As per the subject, I'm after current info about experiences with MFAT over the export of strong crypto, either as software, or embedded in hardware. The online references I can find (Some listed below) are reasonably old and I was hoping there had been some change. (I quote from a 1997 letter from Sec Foreign affairs and trade - Mr Borrie) "This sort of product (encrpytion software) is considered a "dual use" good in terms of the New Zealand Export Controls which means that they are able to be adapted for military, terrorist or criminal use" (I could adapt a plastic spoon for criminal use - but that's beside the point!) Source : http://www.cs.auckland.ac.nz/~pgut001/policy/mfat_2r.html I looked at the MFAT site and they still list encryption software on their "New Zealand Strategic Goods List Index of Controlled Goods" page. Source : http://www.mfat.govt.nz/foreign/dis/nzsgl/pages/laste.html So I guess my question is does anyone know if they have relaxed their approach to 3DES (or even AES-xxx) given that these 'technologies' are freely available internationally, and that 128bit encryption has been effectively opened way up by international adoption in browsers? I'm happy to summarise if there's a bit of feedback. Cheers - Neil Gardner. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

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

29 Mar '05

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

1 0

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

28 Mar '05

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

1 0

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

22 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2128] Routing updates for APE Route Servers (fwd) - Date: Wed, 23 Mar 2005 16:49:23 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0503231649060.23389(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR

1 0

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

22 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2129] Routing updates for WIX Route Servers (fwd) - Date: Wed, 23 Mar 2005 16:48:32 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0503231648120.23389(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR

1 0

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

21 Mar '05

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

18 22

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

21 Mar '05

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

1 0

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

20 Mar '05

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

2 1

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

20 Mar '05

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

4 3

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

20 Mar '05

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

1 0

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

18 Mar '05

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

4 5

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

17 Mar '05

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

1 0

ConceptNET AS17474
by Craig Spiers 17 Mar '05

17 Mar '05

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

1 0

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

17 Mar '05

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

1 0

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

17 Mar '05

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

1 0

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

17 Mar '05

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

1 0

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

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2108] Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:22:12 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181521560.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS17474 descr: Route set advertised to AS9439 by ConceptNET - AS17474 members: 202.150.96.0/20^20-29, 203.97.44.0/24^24-29, 202.49.250.0/24^24-29, 202.50.176.0/24^24-29, 202.127.8.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17474 descr: advertised to AS9439 by Craig Spiers - AS17474 members: 202.150.96.0/19^19-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

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

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2107] Routing updates for APE Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:21:36 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181521180.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/20^20-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.50.176.0/24^24-29, 202.7.6.32/29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/19^19-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.7.5.32/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

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

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2105] AutoReply: Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:20:32 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181520070.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9889 descr: Route set advertised to AS9439 by Maxnet - AS9889 members: 202.14.217.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.50.167.0/24^24-29, 202.89.32.0/19^19-29, 210.55.29.0/24^24-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.110.0/24^24-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

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

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2103] Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:18:45 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181518250.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

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

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2102] Routing updates for APE Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:18:10 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181517410.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

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

17 Mar '05

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

1 0

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

17 Mar '05

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

1 0

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

17 Mar '05

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

1 0

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

17 Mar '05

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

3 2

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

16 Mar '05

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

3 2

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

16 Mar '05

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

2 1

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

15 Mar '05

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

1 0

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

14 Mar '05

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

1 1

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

14 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2078] Routing updates for WIX Route Servers (fwd) - Date: Tue, 15 Mar 2005 11:52:52 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503151152250.14480(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18406 descr: advertised to AS9439 by FX Networks - AS18406 members: 202.53.176.0/20^20-29, 202.7.4.72/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18406 descr: advertised to AS9439 by FX Networks - AS18406 members: 202.53.189.0/24^24-29, 161.29.254.0/23^23-29, 202.7.4.72/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050315 source: NZRR --- PREVIOUS OBJECT: route: 202.7.4.72/29 descr: Route for FX Networks - AS18406 descr: WIX experimental block origin: AS18406 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.7.4.72/29 descr: Route for FX Networks - AS18406 origin: AS18406 notify: rpsl-admin(a)nzix.net notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050315 source: NZRR

1 0

nznog06
by Simon Lyall 14 Mar '05

14 Mar '05

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

1 0

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

14 Mar '05

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

1 0

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

13 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2073] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Mon, 14 Mar 2005 16:30:40 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503141630100.13184(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29, 202.7.5.32/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR

1 0

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

13 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2072] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Mon, 14 Mar 2005 13:20:22 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503141320030.12596(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17474 descr: Route set advertised to AS9560 by ConceptNET - AS17474 members: 202.49.250.0/24, 202.50.176.0/24, 202.127.8.0/22, 202.150.96.0/20, 203.97.44.0/24, 203.21.31.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040304 changed: rpsl-admin(a)nzix.net 20040325 changed: rpsl-admin(a)nzix.net 20040617 changed: rpsl-admin(a)nzix.net 20040625 changed: rpsl-admin(a)nzix.net 20040813 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/20^20-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.50.176.0/24^24-29, 202.7.6.32/29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 202.150.96.0/20 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 202.150.96.0/20 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 202.127.8.0/22 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 202.127.8.0/22 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 203.97.44.0/24 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 203.97.44.0/24 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 202.50.176.0/24 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 202.50.176.0/24 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR

1 0

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

11 Mar '05

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

2 1

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

10 Mar '05

>>>> Jeremy Brooking <godfather(a)mafia.org.nz> 11/03/2005 10:44:58 a.m. >>Mark Foster wrote: >> Any ISPs who have run semi-transparent caching like to stick up their >> hands as to the sheer _volume_ of logging data collected relative to their >> customer base? And indicate exactly how long they archive those logs for, >> and how accessible they are??? > >Lots. > >No long. Ah, this is obviously some strange use of the word exactly that I wasn't previously aware of. (Apologies to Arthur Dent) Cheers - N. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

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

10 Mar '05

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

4 6

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

08 Mar '05

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

4 4

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

08 Mar '05

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

2 1

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

08 Mar '05

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

4 4

Telecom ADSL Testing equipment
by neil gardner 07 Mar '05

07 Mar '05

Hi there - if there's anyone on this list that can perform ADSL line testing at a pretty low level, please urgently get in touch with me via email. I am looking to monitor _exactly_ what is going on between our wall jack and the DSLAM. I have tried channels and not gotten very far. This is to troubleshoot an issue (Line condition) which may be able to hang a certain DSL chipset. Thanks - Neil Gardner Senior Tester Allied Telesyn Research NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

WorldxChange Prefix List Update
by Gordon Smith 07 Mar '05

07 Mar '05

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

1 0

DNS entries
by Webmaster 07 Mar '05

07 Mar '05

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

2 1

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

06 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: Notification of NZRR Database changes (fwd) - Date: Mon, 7 Mar 2005 14:29:34 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503071427520.4454(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: WIX peering at '202.7.0.123' descr: see Citylink RT job #2009 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR REPLACED BY: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: WIX peering at '202.7.0.123' descr: see Citylink RT job #2009 descr: PNIX peering at '218.100.21.10' descr: see Citylink RT job #1487 descr: APE peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS17705 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 import: from AS9281 accept ANY AND NOT fltr-bogons export: to AS9281 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR

1 0