- NZNOG - lists.nznog.org

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