- NZNOG - lists.nznog.org

RE: [nznog] Acceptable levels of Latency, Jitter and Packet loss on national links
by Craig Humphrey 27 Sep '04

27 Sep '04

That's all well and good, but since it's also the only "performance metrics" given in the contract, it's all I have to go on (hence soliciting references from existing customers). It would be nice to get an indication of what performance we can expect, not just "oh, it'll never get worse than this..." I've got a load of questions for the provider around these (and other) issues, so I'll just have to see what they come up with. Later'ish Craig > -----Original Message----- > From: Joe Abley [mailto:jabley(a)isc.org] > Sent: Tuesday, September 28, 2004 2:54 AM [snip snip] > It may actually be that the performance guarantee is a paper-dwelling > construct, and has little or no form in the actual network. > > I have certainly come across providers in my past for whom > performance > guarantees were necessary in order to be able to bid for > projects, but > the cost of deploying infrastructure to support the > guarantees was much > higher than just giving a few refunds now and then. As such the > guarantees didn't really exist outside the billing department. > > > Joe

1 0

RE: [nznog] Acceptable levels of Latency, Jitter and Packet loss on national links
by Donald Neal 26 Sep '04

26 Sep '04

> -----Original Message----- > From: Joe Abley [mailto:jabley(a)isc.org] > Sent: Monday, 27 September 2004 4:09 p.m. > To: Craig Humphrey > Cc: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Acceptable levels of Latency, Jitter and > Packet loss on national links > > > On 26 Sep 2004, at 22:25, Craig Humphrey wrote: > > > Latency Jitter IP Packet Loss > > "Realtime" <50ms <12.5ms <0.1% > > "Interactive" <75ms <50ms <0.1% > > "Business" <200ms <100ms <1.0% > > > > And yes, we're chasing references who are already using > this service. > > > > The reason for my dissatisfaction... Based on crude testing > with ping, > > we already get an average of 25ms latency over the 2Mbit/s fibre > > (during > > normal background load), and that's a round trip! So I'm > not sure how > > the above is really an improvement... > > What is the actual RTT over the ethernet service? Normal performance > and guaranteed performance seem very unlikely to be similar (or even > comparable within an order of magnitude). Among other reasons this is because normal performance is seen when things are normal. A provider's performance guarantee is presumably going to have a more demanding specification than just "you'll see numbers like this most of the time". - Donald Neal [All opinions mine only.] Donald Neal |World Domination is Technical Specialist |proceeding according to Operations Engineering |plan. - Andrew Tridgell Integration & Services Division +----------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

2 1

Acceptable levels of Latency, Jitter and Packet loss on national links
by Craig Humphrey 26 Sep '04

26 Sep '04

Hi People, We're about to upgrade our site to site 2Mbit/s frame relay WAN links (Akl, Wgn & Chc) to 10Mbit/s fibre into a central cloud, but I'm not entirely happy with the performance levels our provider is offering us. Below I've listed what's on offer, but I wanted to see what other providers consider to be deliverable levels for National links. All thoughts and comments welcome, probably off-list (to keep the noise down), and I can post a summary if people are interested. Latency Jitter IP Packet Loss "Realtime" <50ms <12.5ms <0.1% "Interactive" <75ms <50ms <0.1% "Business" <200ms <100ms <1.0% And yes, we're chasing references who are already using this service. The reason for my dissatisfaction... Based on crude testing with ping, we already get an average of 25ms latency over the 2Mbit/s fibre (during normal background load), and that's a round trip! So I'm not sure how the above is really an improvement... Soon'ish Craig

2 1

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

26 Sep '04

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 APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. --- PREVIOUS OBJECT: aut-num: AS24111 as-name: NZRR-AS24111 descr: NZwireless descr: initially peering at '202.7.1.69' descr: see Citylink RT job #929 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24111 notify: rpsl-admin(a)wix.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)wix.net.nz 20040810 source: NZRR REPLACED BY: aut-num: AS24111 as-name: NZRR-AS24111 descr: nzWireless descr: initially peering at '192.203.154.14' descr: see Citylink RT job #1236 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24111 notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)ape.net.nz 20040927 source: NZRR --- PREVIOUS OBJECT: route: 203.110.28.0/23 descr: Route for NZwireless - AS24111 origin: AS24111 notify: rpsl-admin(a)wix.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)wix.net.nz 20040810 source: NZRR REPLACED BY: route: 203.110.28.0/23 descr: Route for nzWireless - AS24111 origin: AS24111 notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)ape.net.nz 20040927 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS24111 descr: Route set advertised to AS9560 by nzWireless - AS24111 members: 203.110.28.0/23^23-24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)ape.net.nz 20040927 source: NZRR

1 0

RE: [nznog] nznog research group for NGI?
by Donald Neal 26 Sep '04

26 Sep '04

> -----Original Message----- > From: Daniel Lawson [mailto:daniel(a)wand.net.nz] > Sent: Thursday, 23 September 2004 9:41 a.m. > To: jon.brewer(a)worldnet.att.net; nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] nznog research group for NGI? [...] > The NZ Advanced Network is not about reading webpages. It's not about > downloading mp3s or using Kazaa. It's about shipping multi-gigabyte > volumes of data between research organisations. It's about developing > the next generation of network apps that will rely on this > capacity of > transit. > > As for 15 c/MB charges at Victoria, we face similar charges > at Waikato. > It's one of the reasons we (as a network research group) want this > network - not because we care overly about paying to read > Slashdot every > morning, but because 15 or 10 even 1 c/MB is far too much > when you want > to send 600 GB of network traces to Auckland. And it'll take > too long > across a 10Mbit TC ethernet connection. You know, talking about what specific users plan to do with a research network might actually be operational content, and so on topic for this list. - Donald Neal Donald Neal |World Domination is Technical Specialist |proceeding according to Operations Engineering |plan. - Andrew Tridgell Integration & Services Division +----------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

2 1

Sprintlink- Planned Outage Notification
by Jonathan Brewer 25 Sep '04

25 Sep '04

Folks, This came from one of our providers, and I hadn't seen mention of it on the list. Not that 5min is any big deal, but it's nice to know why the pager is going off in the middle of the night. Cheers, JB Dear Valued Customer, Sprintlink, our upstream provider has notified us of an upcoming outage caused by Telecom NZ Ltd performing scheduled maintenance work. Details are as follows: Start date: 3 Oct 04, Sunday Time: 00:01 hrs End date:3 Oct 04, Sunday Time: 01:01 hrs Duration: One 5 minute outage during this window. Reason: Maintenance work by TNZ

1 0

APNIC records to be marked as 'private' for end user delegations
by Mark Foster 23 Sep '04

23 Sep '04

http://www.apnic.net/docs/policy/proposals/prop-007-v001.html http://www.apnic.net/info/faq/privacy-faq.htm As at 30 September client-side delegation information will be hidden from whois - the only info provided will be the ISP involved. Suprised there hasnt been any discussion of this on here so thought id pass it through. (original information sourced via NANOG, where theyre now busy 'discussing' the merits of making life easier for spammers, etc.) Cheers Mark. [posts are imho, as usual]

1 0

new BIND releases today
by Joe Abley 23 Sep '04

23 Sep '04

Fresh out of the oven: BIND 9.3.0 BIND 9.2.4 BIND 8.4.5 For more information, see: http://www.isc.org/sw/bind/ http://www.isc.org/sw/bind/bind9.3.php Joe

5 7

International routing issues yesterday
by Tom Hibbert 23 Sep '04

23 Sep '04

Hi guys, We were stung by a routing issue yesterday affecting us and many of our customers unable to reach most international hosts. Our clients are with lots of different ISPs, and so far we have had confirmation from Orcon (thanks Craig) that there was an issue with the Global Gateway. I'd appreciate if someone from VISP or Iconz could confirm that they were affected too. I know getting an official report from Telecom or GG will be next to impossible, but it would be great if someone from there could tell me which endpoint was affected. Thanks in advance :) Tom Hibbert Technical Specialist Phone: +64-9-306-0230 Technical Helpdesk: +64-9-306-0234 Mobile: +64-274-307-784 Email: tom(a)nsp.co.nz Website: http://www.nsp.co.nz The information in this email and any attachments is confidential. This information may be subject to legal, professional, or other privilege. It must not be disclosed to any person without our authority. If you are not the intended recipient you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. Please return this message to the sender immediately and delete any and all copies from your system.

1 0

TelstraClear WIX/APE de-peering and national/international cost split
by Bruce Fitzsimons 22 Sep '04

22 Sep '04

Hello list. As a TC Cable customer I'm curious about what the impact of the TC de-peering is going to be on my monthly bill. They've previously announced (and I believe its still on their FAQsite) that they may revisit the current 1:10 cost differential between international and national traffic at some time in the future. I'd hazard a guess that the de-peering may provide some impetus for this, since national traffic sources who don't pay to peer with them may cost them more money. It'd be nice of course if that meant they reconsidered their peering policy, but I won't hold my breath. Anyone heard anything? Have I got the peering cost equation the wrong way around? /Bruce

1 0

nznog research group for NGI?
by Lin Nah 22 Sep '04

22 Sep '04

Looks like the NGI proposal will shut out private or commercial users unless they comply with the Network use policy. All points to setting up a nznog related research group in order to be able to play in it. Unfortunately nothing states the fee required to be a Partner. Anyway they are looking for feedback by 1 Oct "Private Sector shut out of Advanced Network" http://computerworld.co.nz/news.nsf/UNID/35095BD5DF6B4AABCC256F160019E134 http://www.morst.govt.nz/?CHANNEL=IT+INFRASTRUCTURE&PAGE=IT+Infrastructure all a big yawn? lin

8 10

RE: [nznog] nznog research group for NGI?
by Craig Humphrey 21 Sep '04

21 Sep '04

Hi Daniel, This isn't a dig at you... > -----Original Message----- > From: Daniel Lawson [mailto:daniel(a)wand.net.nz] > Sent: Wednesday, September 22, 2004 5:10 PM > To: Simon Lyall; nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] nznog research group for NGI? [snip snip] > I2 won't give us free or cheap gigabit access at home. It will give > universities, other research organisations and similarly minded > businesses a high speed collaborative platform. That's what > it's there for. So an "under subscription" scheme rather than the commercial "over subscription" scheme... Ahhh... That's right, it's better and faster, because almost no one is using it! If bandwidth and technology is cheap enough that the Government can set up something like this and presumably have it economically viable (while excluding fee paying commercial customers), then why can't our existing infrastructure be upgraded to similar or even better capabilities since there would be lots of $$ involved? Maybe I'm just naive... And have over simplified things. Just my 2c. Later'ish Craig

1 0

RE: [nznog] nznog research group for NGI?
by Craig Humphrey 21 Sep '04

21 Sep '04

To quote from Page 28 of the Advanced Network Architecture document: http://www.morst.govt.nz/uploadedfiles/Documents/Current%20work/An%20Adv anced%20Network%20Architecture%20for%20New%20Zealand%20V1.11.pdf "...Beyond the current use of the Internet for email, web-browsing and web-oriented applications, some of the current R+E+I use is to support applications that require peer-to-peer connection between institutions, both nationally and overseas, simply because there is no other economic alternative. For this last important group of applications the overall Internet performance is particularly bad - latency, jitter, low bandwidth and packet loss are aggravated by the volume-oriented cost structures. ..." Is it just me, or is that a nice little dig at the current Internet situation and it's duopoly on International bandwidth (OK, so the likes of IHUG and others have their "own" International links, but they probably pale in comparison to the big two.) Oh and I see that it's primarily IPv4 based, with IPv6 being offered as a service over the top. So much for next generation... Shouldn't this be IPv6 based from the start, with perhaps IPv4 gateways at the fringe? Maybe I just need to read more... But it's home time... Later'ish Craig

1 0

RE: [nznog] nznog research group for NGI?
by Craig Humphrey 21 Sep '04

21 Sep '04

Sheesh... Heaven forbid that someone should set up a network that might compete with Telco's.... Don't you think that if someone can do it better/cheaper, then that's a Good Thing(tm) for competition in NZ. I know the network is supposed to be for "research", but then you could argue that the original NZ backbone (linking the Universities, etc) was too and look where it is now... Then again, maybe you don't want to look... :) Just my 2c. Later'ish Craig > -----Original Message----- > From: Lin Nah [mailto:lin(a)darkmere.gen.nz] > Sent: Wednesday, September 22, 2004 4:35 PM > To: nznog(a)list.waikato.ac.nz > Subject: [nznog] nznog research group for NGI? > > Looks like the NGI proposal will shut out private or commercial users > unless they comply with the Network use policy. > > All points to setting up a nznog related research group in order to > be able to play in it. Unfortunately nothing states the fee required > to be a Partner. > > Anyway they are looking for feedback by 1 Oct > > "Private Sector shut out of Advanced Network" > http://computerworld.co.nz/news.nsf/UNID/35095BD5DF6B4AABCC256 > F160019E134 > > http://www.morst.govt.nz/?CHANNEL=IT+INFRASTRUCTURE&PAGE=IT+In > frastructure > > all a big yawn? > > lin > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog >

3 2

NZ Network Providers List?
by Evan Taylor 21 Sep '04

21 Sep '04

Hello from Australia, This is my first post to this list, just subscribed - looks interesting! Figured this was the most obvious place to start asking questions ... The organisation I work for has just made some aquisitions in NZ. We have taken over (or about to) an existing network running on the Telecom PON service. I was wondering - is there a global register of network providers in NZ? Currently we are sticking with Telecom as its already implemented, but I would like to research further out and see what other options there are. We have a guide for AUS, http://www.whirlpool.net.au/ Though not completely concise its an excellent start. I'm finding already the Telecom PON service - even the upgraded POM - quite restrictive. I cannot SNMP query any routers (we do all our own stats) nor, can I manage these myself (we also managed all our own gear). DSL in NZ seems quite interesting - up to 8Mbit/s according to the Xtra website? I take it this is not gaureenteed and on distance basis as well. I notice that you utilise full GDMT here - not GDMT.Lite as we do. Without moving off the Telstra DSLAMs I am lucky if I can get 1.5Mbit/s downstream and 256k up. Very interested to know more about providers, carriers, etc. over there in NZ - hopefully might be able to head over in the near future too! Cheers, Ev-

4 5

Telecoms "deadline"
by Richard Patterson 21 Sep '04

21 Sep '04

I was told yesterday by a Telecom employee that the 250,000 goal for Broadband residential users was an ultimatum from the comcom to Telecom saying "reach this otherwise we will unbundle the local loop" Are any ISP's thinking of boycotting UBS or iUBS for the greater good so to speak? or is everyone just going to jump on the bandwagon for slightly faster intarwebnet? -Richard

1 0

OT, Archiving Email
by Gavin Palmer 20 Sep '04

20 Sep '04

Hiya All, Please forgive the OT post. Can anyone shed some light on how long the law requires us to archive/retain email for legal purposes, and is this covered in the new amendment act? Please reply off list if this is too OT. Thanx Gav

1 0

OT: Motorola S1936 (voice/data) interface wanted
by Michael Hallager 19 Sep '04

19 Sep '04

Hi all. Anyone got a Motorola S1936 interface unit? This connects a Motorola carphone to a (RJ11?) standard telecommunications device (phone, fax, dialup modem etc). // Michael Hallager Director || Head geek || Making IT work. URL: http://www.networkstuff.co.nz networkStuff, NZ's leading online supplier of high quality new and used networking equipment. Phone: (09) 839-1000 (DDI) 0800 638-788 (Freecall) Fax: (09) 837-8100 0800 329-788 (Freecall) Mobile: 029 638-7883

1 0

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

19 Sep '04

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 APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Mon, 20 Sep 2004 15:18:43 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0409201518200.5722(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS7657 descr: Route set advertised to AS9560 by ihug - AS7657 members: 203.109.128.0/17^17-24, 203.173.128.0/17^17-24, 203.118.128.0/18^18-24, 203.96.192.0/19^19-24, 210.55.248.0/21^21-24, 202.49.240.0/22^22-24, 202.50.188.0/22^22-24, 202.21.136.0/23^23-24, 202.36.94.0/23^23-24, 202.49.46.0/23^23-24, 202.49.88.0/23^23-24, 202.49.148.0/23^23-24, 202.49.176.0/23^23-24, 202.49.180.0/23^23-24, 192.107.113.0/24, 202.21.130.0/24, 202.36.44.0/24, 202.49.33.0/24, 202.49.48.0/24, 202.49.63.0/24, 202.49.178.0/24, 202.49.186.0/24, 202.50.84.0/24, 202.50.103.0/24, 202.50.255.0/24, 210.55.110.0/24, 210.55.184.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)wix.net.nz notify: noc(a)ihug.co.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: asjl(a)wix.net.nz 20031210 changed: rpsl-admin(a)ape.net.nz 20040813 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS7657 descr: Route set advertised to AS9560 by ihug - AS7657 members: 203.109.128.0/17^17-24, 203.173.128.0/17^17-24, 203.118.128.0/18^18-24, 203.96.192.0/19^19-24, 210.55.248.0/21^21-24, 202.49.240.0/22^22-24, 202.50.188.0/22^22-24, 202.21.136.0/23^23-24, 202.36.94.0/23^23-24, 202.36.230.0/23^23-24, 202.49.46.0/23^23-24, 202.49.88.0/23^23-24, 202.49.148.0/23^23-24, 202.49.176.0/23^23-24, 202.49.180.0/23^23-24, 192.107.113.0/24, 202.21.130.0/24, 202.36.44.0/24, 202.49.33.0/24, 202.49.48.0/24, 202.49.63.0/24, 202.49.178.0/24, 202.49.186.0/24, 202.50.84.0/24, 202.50.103.0/24, 202.50.255.0/24, 210.55.110.0/24, 210.55.184.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)wix.net.nz notify: noc(a)ihug.co.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: asjl(a)wix.net.nz 20031210 changed: rpsl-admin(a)ape.net.nz 20040813 changed: rpsl-admin(a)ape.net.nz 20040920 source: NZRR

1 0

domestic vs. international
by Joe Abley 16 Sep '04

16 Sep '04

Would any access providers who measure such things care to share the ratio of domestic:international traffic, inbound to and outbound from their networks? Back when I was crashing routers in AS 4768 the feeling was that about 20% of traffic stayed local, within New Zealand. That was pre-Southern Cross, though, and it's perfectly possible that the ratio was inflated due to unsatisfied demand. The prices for transit in other countries are much, much cheaper now, and the cost of reaching those countries directly (if you buy your own transmission capacity there) has also gone down substantially, so maybe that would also act to make the ratio lower. On the other hand, as people become more used to doing things over the Internet, you'd expect local content to grow. On yet another hand (four, now?) since so many people are still inexplicably cursed with dialup, maybe that growth would be lower than in other, more enlightened markets. Seems like an interesting question, anyway. I guess this would be easiest to measure at an ISP that used separate domestic and international uplinks (like Telecom used to provision, and may still do for all I know, and like TCL have started to do). If anybody would like to share some numbers, feel free to mail me directly and I can summarise back to the list. Joe

1 0

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

15 Sep '04

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 APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX 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: Thu, 16 Sep 2004 18:07:06 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0409161806400.14082(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: Route set for AS4770 members: 138.235.0.0/16^16-24, 192.107.113.0/24, 192.173.16.0/21^21-24, 202.6.84.0/24, 202.12.70.0/24, 202.12.248.0/21^21-24, 202.14.100.0/24, 202.21.130.0/24, 202.21.136.0/23^23-24, 202.36.32.0/24, 202.36.36.0/22^22-24, 202.36.44.0/23^23-24, 202.36.76.0/23^23-24, 202.36.155.0/24, 202.36.157.0/24, 202.37.76.0/24, 202.37.85.0/24, 202.37.136.0/24, 202.37.140.0/22^22-24, 202.37.144.0/21^21-24, 202.37.163.0/24, 202.37.197.0/24, 202.37.200.0/22^22-24, 202.37.224.0/21^21-24, 202.37.232.0/24, 202.37.252.0/23^23-24, 202.49.62.0/24, 202.49.89.0/24, 202.49.249.0/24, 202.50.87.0/24, 202.50.246.0/24, 202.55.96.0/20^20-24, 202.74.224.0/21^21-24, 203.9.179.0/24, 203.9.180.0/24, 210.48.0.0/17^17-24, 210.54.136.0/22^22-24, 210.54.140.0/24, 210.54.160.0/19^19-24, 210.55.24.0/22^22-24, 210.55.182.0/23^23-24, 210.55.253.0/24, 210.56.32.0/20^20-24, 210.185.0.0/18^18-24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)ape.net.nz 20030428 changed: rpsl-admin(a)wix.net.nz 20040629 changed: rpsl-admin(a)wix.net.nz 20040831 changed: rpsl-admin(a)wix.net.nz 20040909 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: Route set for AS4770 members: 138.235.0.0/16, 192.107.113.0/24, 192.173.16.0/21, 199.212.90.0/23, 199.212.92.0/23, 202.6.84.0/24, 202.12.70.0/24, 202.12.248.0/21, 202.14.100.0/24, 202.21.130.0/24, 202.21.136.0/23, 202.36.155.0/24, 202.36.157.0/24, 202.36.32.0/24, 202.36.36.0/22, 202.36.44.0/24, 202.36.45.0/24, 202.36.76.0/23, 202.37.136.0/24, 202.37.140.0/22, 202.37.144.0/21, 202.37.163.0/24, 202.37.197.0/24, 202.37.200.0/22, 202.37.224.0/21, 202.37.232.0/24, 202.37.252.0/23, 202.37.76.0/24, 202.37.85.0/24, 202.49.62.0/24, 202.49.89.0/24, 202.49.249.0/24, 202.50.87.0/24, 202.50.246.0/24, 202.55.96.0/20, 202.74.224.0/21, 203.9.179.0/24, 203.9.180.0/24, 205.233.128.0/21, 205.233.136.0/23, 205.233.243.0/24, 210.185.0.0/18, 210.48.0.0/17, 210.54.136.0/22, 210.54.140.0/24, 210.54.160.0/19, 210.55.182.0/23, 210.55.24.0/22, 210.55.253.0/24, 210.56.32.0/20 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz notify: john.johnston(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: asjl(a)wix.net.nz 20030407 changed: rpsl-admin(a)wix.net.nz 20040629 changed: rpsl-admin(a)wix.net.nz 20040831 source: NZRR

1 0

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

15 Sep '04

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 APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Thu, 16 Sep 2004 18:05:55 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0409161802410.14082(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: Route set for AS4770 members: 138.235.0.0/16^16-24, 192.107.113.0/24, 192.173.16.0/21^21-24, 202.6.84.0/24, 202.12.70.0/24, 202.12.248.0/21^21-24, 202.14.100.0/24, 202.21.130.0/24, 202.21.136.0/23^23-24, 202.36.32.0/24, 202.36.36.0/22^22-24, 202.36.44.0/23^23-24, 202.36.76.0/23^23-24, 202.36.155.0/24, 202.36.157.0/24, 202.37.76.0/24, 202.37.85.0/24, 202.37.136.0/24, 202.37.140.0/22^22-24, 202.37.144.0/21^21-24, 202.37.163.0/24, 202.37.197.0/24, 202.37.200.0/22^22-24, 202.37.224.0/21^21-24, 202.37.232.0/24, 202.37.252.0/23^23-24, 202.49.62.0/24, 202.49.89.0/24, 202.49.249.0/24, 202.50.87.0/24, 202.50.246.0/24, 202.55.96.0/20^20-24, 202.74.224.0/21^21-24, 203.9.179.0/24, 203.9.180.0/24, 210.48.0.0/17^17-24, 210.54.136.0/22^22-24, 210.54.140.0/24, 210.54.160.0/19^19-24, 210.55.24.0/22^22-24, 210.55.182.0/23^23-24, 210.55.253.0/24, 210.56.32.0/20^20-24, 210.185.0.0/18^18-24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: asjl(a)wix.net.nz 20030407 changed: rpsl-admin(a)wix.net.nz 20040629 changed: rpsl-admin(a)wix.net.nz 20040831 changed: rpsl-admin(a)wix.net.nz 20040909 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: Route set for AS4770 members: 138.235.0.0/16, 192.107.113.0/24, 192.173.16.0/21, 199.212.90.0/23, 199.212.92.0/23, 202.6.84.0/24, 202.12.70.0/24, 202.12.248.0/21, 202.14.100.0/24, 202.21.130.0/24, 202.21.136.0/23, 202.36.155.0/24, 202.36.157.0/24, 202.36.32.0/24, 202.36.36.0/22, 202.36.44.0/24, 202.36.45.0/24, 202.36.76.0/23, 202.37.136.0/24, 202.37.140.0/22, 202.37.144.0/21, 202.37.163.0/24, 202.37.197.0/24, 202.37.200.0/22, 202.37.224.0/21, 202.37.232.0/24, 202.37.252.0/23, 202.37.76.0/24, 202.37.85.0/24, 202.49.62.0/24, 202.49.89.0/24, 202.49.249.0/24, 202.50.87.0/24, 202.50.246.0/24, 202.55.96.0/20, 202.74.224.0/21, 203.9.179.0/24, 203.9.180.0/24, 205.233.128.0/21, 205.233.136.0/23, 205.233.243.0/24, 210.185.0.0/18, 210.48.0.0/17, 210.54.136.0/22, 210.54.140.0/24, 210.54.160.0/19, 210.55.182.0/23, 210.55.24.0/22, 210.55.253.0/24, 210.56.32.0/20 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz notify: john.johnston(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: asjl(a)wix.net.nz 20030407 changed: rpsl-admin(a)wix.net.nz 20040629 changed: rpsl-admin(a)wix.net.nz 20040831 source: NZRR

1 0

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

15 Sep '04

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 APE and/or WIX route servers 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, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Thu, 16 Sep 2004 13:51:53 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0409161349450.12852(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23754 descr: Route set for Citylink to WIX members: 203.118.144.0/24, 198.48.0.0/22^22-24, 202.8.44.0/22^22-24, 203.97.231.224/28, 210.48.103.0/28, 210.48.103.144/28, 210.48.103.136/29, 203.79.85.80/29, 203.109.195.72/29, 202.7.4.32/28 admin-c: RPA1-NZRR tech-c: RPA1-NZRR mnt-by: MAINT-NZRR-NZ notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz changed: rpsl-admin(a)wix.net.nz 20040112 changed: rpsl-admin(a)wix.net.nz 20040303 changed: rpsl-admin(a)wix.net.nz 20040322 changed: rpsl-admin(a)wix.net.nz 20040407 changed: rpsl-admin(a)wix.net.nz 20040525 changed: rpsl-admin(a)wix.net.nz 20040617 changed: rpsl-admin(a)wix.net.nz 20040622 changed: rpsl-admin(a)wix.net.nz 20040629 changed: rpsl-admin(a)wix.net.nz 20040813 changed: rpsl-admin(a)wix.net.nz 20040816 changed: rpsl-admin(a)wix.net.nz 20040909 changed: rpsl-admin(a)wix.net.nz 20040913 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23754 descr: Route set for Citylink to WIX members: 203.118.144.0/24, 198.48.0.0/22^22-24, 202.8.44.0/22^22-24, 203.97.231.224/28, 210.48.103.0/29, 210.48.103.112/29, 203.79.85.80/29, 203.109.195.72/29, 202.7.4.32/28 admin-c: RPA1-NZRR tech-c: RPA1-NZRR mnt-by: MAINT-NZRR-NZ notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz changed: rpsl-admin(a)wix.net.nz 20040112 changed: rpsl-admin(a)wix.net.nz 20040303 changed: rpsl-admin(a)wix.net.nz 20040322 changed: rpsl-admin(a)wix.net.nz 20040407 changed: rpsl-admin(a)wix.net.nz 20040525 changed: rpsl-admin(a)wix.net.nz 20040617 changed: rpsl-admin(a)wix.net.nz 20040622 changed: rpsl-admin(a)wix.net.nz 20040629 changed: rpsl-admin(a)wix.net.nz 20040813 changed: rpsl-admin(a)wix.net.nz 20040816 changed: rpsl-admin(a)wix.net.nz 20040909 changed: rpsl-admin(a)wix.net.nz 20040913 changed: rpsl-admin(a)wix.net.nz 20040916 source: NZRR

1 0

RE: [nznog] PPPOE Performance testing question
by Beatty Lane-Davis 14 Sep '04

14 Sep '04

Hi Neil, > PPPOE Access Concentrator that can easily keep up with > 100Mbit of PPPOE throughput at large sizes, and preferably > all sizes. Any and all brands or thoughts considered. Best bet is an ERX, for so many reasons. You could probably get away with a 7200 with an NPE-400 as a bare minimum, but you'd be happier with a NPE-G1 and almost certainly happiest with the ERX. > In addition, who would be the best people to validate a bit > of equipment for this requirement (assuming we don't end up > buying calibrated and certified test gear). Validate? People? Certification of the smartbits\ixia or of the router you'll be using? I don't recall ever having our test beds validated at the vendor I used to work for, course we never sold any routers either, so that's neither here nor there... ;-) Cheers, b

2 1

PPPOE Performance testing question
by neil gardner 14 Sep '04

14 Sep '04

Sorry if this is offtopic but I think it's close enough :-) We'll be needing to do some performance testing of a product shortly and while we have most of the bits we need (Ixias, smartbits etc) I was wondering if someone could point me to a PPPOE Access Concentrator that can easily keep up with 100Mbit of PPPOE throughput at large sizes, and preferably all sizes. Any and all brands or thoughts considered. In addition, who would be the best people to validate a bit of equipment for this requirement (assuming we don't end up buying calibrated and certified test gear). Cheers - Neil G NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0