- NZNOG - lists.nznog.org

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '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, 28 Oct 2004 14:01:56 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281401420.5844(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW DELETED: route: 210.48.101.64/27 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '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, 28 Oct 2004 13:59:44 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281356090.5844(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW DELETED: route: 202.53.189.128/29 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR --- OBJECT BELOW DELETED: route: 202.174.161.0/24 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR --- OBJECT BELOW DELETED: route: 210.48.109.224/27 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR

1 0

RE: [nznog] ADSL @ Home
by Geraint Jones 27 Oct '04

27 Oct '04

/me brushes the sand off his ears ;-P Geraint Jones Systems Administrator French Maid Foods Limited www.french-maid.net Tel: +64 (0)4 568 2687 Fax: +64 (0)4 568 2345 Mob: +64 (0)21 739 240 -----Original Message----- From: Drew Broadley [mailto:drew(a)corrupt.co.nz] Sent: Thursday, October 28, 2004 1:24 PM To: Geraint Jones Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] ADSL @ Home Geraint Jones wrote: > I got a charming email from extra informing me that their flat rate > customers charged @ 69.95 will be going from 256kbit to 2mbit in the > next month, the first I heard of it was the email. Was anyone aware this > was going to happen and it was just me having my head in the sand or is > this as unexpected as I find it. Is this really on-topic ? Answer: yes, your head is in the sand, http://www.telecom-media.co.nz/releases_detail.asp?id=3096 :) - Drew This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '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: [CityLink #1422] Changes to AS64598 (fwd) - Date: Thu, 28 Oct 2004 12:28:34 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281227470.5286(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64598 descr: Route set advertised to AS9439 by Araneo - AS64598 members: 202.53.189.128/29, 202.174.161.0/24^24-29, 210.48.109.224/27^27-29, 210.48.101.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64598 descr: advertised to AS9439 by Araneo - AS64598 members: 210.48.109.104/29, 210.48.109.112/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 210.48.109.104/29 descr: Route for Araneo - AS64598 origin: AS64598 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Oct '04

27 Oct '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: [CityLink #1421] Changes to AS64597 (fwd) - Date: Thu, 28 Oct 2004 12:27:23 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0410281226020.5286(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64597 descr: Route set advertised to AS9439 by Araneo at RNZ - AS64597 members: 210.48.109.224/27 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: jon.brewer(a)att.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040801 changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64597 descr: advertised to AS9439 by Araneo - AS64597 members: 202.53.189.128/29, 210.48.101.64/27^27-29, 210.48.109.224/27^27-29, 202.174.161.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: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 202.53.189.128/29 descr: Route for Araneo - AS64597 origin: AS64597 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 210.48.101.64/27 descr: Route for Araneo - AS64597 origin: AS64597 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 210.48.109.224/27 descr: Route for Araneo - AS64597 origin: AS64597 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR --- OBJECT BELOW CREATED: route: 202.174.161.0/24 descr: Route for Araneo - AS64597 origin: AS64597 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jon.brewer(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041028 source: NZRR

1 0

Re: [nznog] ADSL Rate Limiting on the line.
by neil gardner 23 Oct '04

23 Oct '04

Well, I've never met Bruce, and I do read Aardvark most days, but I think it would be good to get someone that really _knows_ what the impact of reducing the line speed on latency will be. We have a few dslams here for testing but they're been used for real work right now. Anyone _know_ what the effect will be? Cheers - Neil G >>> Richard Nelson <richardn(a)cs.waikato.ac.nz> 22/10/2004 12:44:56 p.m. >>> Maybe you misread it, there is a 'but' in the sentance: "This will likely increase latency for all but those on the full-speed JetStream plans ..." Richard. Craig Spiers wrote: > Hi guys, > > > > Reading todays article on http://www.aardvark.co.nz/ he raves on about > 'increased latency' > > > > Would I be right in saying the latency would only increase on lower speed > jetstream plans - as it takes longer for the packets to pass over a smaller > pipe. > > > > Why is he talking about it increasing latency on full rate jetstream plans? > > > > Cheers > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog 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.

4 4

Weekend reading on Exchanges
by Andy Linton 21 Oct '04

21 Oct '04

Here's a paper on IXes you might like to read: Prescriptive Policy Guide for Developing Nations Wishing to Encourage the Formation of a Domestic Internet Industry http://www.pch.net/resources/papers/policy-guide/policy-guide.html

1 0

FW: Westpac: SERVICE MESSAGE
by Barry Murphy 21 Oct '04

21 Oct '04

Just received: Return-Path: <www(a)forcartex.com.tw> Delivered-To: unix.co.nz-barry(a)unix.co.nz Received: (qmail 57023 invoked from network); 22 Oct 2004 00:25:24 -0000 Received: from www(a)forcartex.com.tw by firewall.unix.co.nz by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4396. Clear:RC:0(219.88.242.3):. Processed in 0.334605 secs); 22 Oct 2004 00:25:24 -0000 X-Qmail-Scanner-Mail-From: www(a)forcartex.com.tw via firewall.unix.co.nz X-Qmail-Scanner: 1.22 (Clear:RC:0(219.88.242.3):. Processed in 0.334605 secs) Received: from unknown (HELO dbmail-mx3.orcon.net.nz) (219.88.242.3) by smtp.unix.co.nz with SMTP; 22 Oct 2004 00:25:24 -0000 Received: from mail.unix.co.nz (firewall.unix.co.nz [219.88.241.242]) by dbmail-mx3.orcon.net.nz (8.13.1/8.13.1/Debian-14) with SMTP id i9M0PONQ030574 for <blacklabel(a)orcon.net.nz>; Fri, 22 Oct 2004 13:25:25 +1300 Received: (qmail 57013 invoked by uid 89); 22 Oct 2004 00:25:23 -0000 Delivered-To: barry(a)southafrica.co.nz Received: (qmail 57007 invoked from network); 22 Oct 2004 00:25:22 -0000 Received: from www(a)forcartex.com.tw by firewall.unix.co.nz by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4396. Clear:RC:0(211.22.18.59):. Processed in 0.985909 secs); 22 Oct 2004 00:25:22 -0000 X-Qmail-Scanner-Mail-From: www(a)forcartex.com.tw via firewall.unix.co.nz X-Qmail-Scanner: 1.22 (Clear:RC:0(211.22.18.59):. Processed in 0.985909 secs) Received: from unknown (HELO mail.forcartex.com.tw) (211.22.18.59) by smtp.unix.co.nz with SMTP; 22 Oct 2004 00:25:21 -0000 Received: from localhost (localhost.forcartex.com.tw [127.0.0.1]) by mail.forcartex.com.tw (Postfix) with ESMTP id B207F12BC24 for <barry(a)southafrica.co.nz>; Fri, 22 Oct 2004 08:25:18 +0800 (CST) Received: from mail.forcartex.com.tw ([127.0.0.1]) by localhost (www.forcartex.com.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10715-03 for <barry(a)southafrica.co.nz>; Fri, 22 Oct 2004 08:25:18 +0800 (CST) Received: by mail.forcartex.com.tw (Postfix, from userid 80) id 4D67012BCA8; Fri, 22 Oct 2004 08:24:21 +0800 (CST) To: barry(a)southafrica.co.nz Subject: Westpac: SERVICE MESSAGE MIME-Version: 1.0 Content-type: text/html; charset=iso-8859-1 From: Westpac New Zealand <service(a)westpac.co.nz> Reply-To: service(a)westpac.co.nz X-Mailer: PHP/4.3.8 Message-Id: <20041022002421.4D67012BCA8(a)mail.forcartex.com.tw> Date: Fri, 22 Oct 2004 08:24:21 +0800 (CST) X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on dbmail-mx3 X-Virus-Scanned: by amavisd-new at forcartex.com.tw X-Amavis-Alert: BAD HEADER Improper use of control character (char 0D hex) in message header 'MIME-Version': MIME-Version: 1.0\r\n Received-SPF: none (dbmail-mx3.orcon.net.nz: 219.88.241.242 is neither permitted nor denied by domain of forcartex.com.tw) receiver=dbmail-mx3.orcon.net.nz; client-ip=219.88.241.242; helo=mail.unix.co.nz; envelope-from=www(a)forcartex.com.tw; x-software=spfmilter 0.93 http://www.acme.com/software/spfmilter/; X-Virus-Status: Clean X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on firewall.unix.co.nz X-Spam-Level: X-Spam-Status: No, hits=0.9 required=5.0 tests=BAYES_50,HTML_MESSAGE, HTML_TITLE_UNTITLED,MIME_HTML_ONLY autolearn=no version=2.64 _____ From: Westpac New Zealand [mailto:service(a)westpac.co.nz] Sent: Friday, 22 October 2004 1:24 p.m. To: barry(a)southafrica.co.nz Subject: Westpac: SERVICE MESSAGE <http://www.westpac.co.nz/w_nz.gif> Dear Westpac customer, Recently there has been a large number of identity theft attempts targeting Westpac customers. In order to safeguard your account, we require that you confirm your banking details. This process is mandatory, and if not completed within the nearest time your account may be subject to temporary suspension. To securely confirm your Westpac account details, please fill in the form that will follow after signing in at: http://www.westpac.co.nz/personal/Checking/OnlineBanking/Internet_Banking/in dex.cfm <http://www.saracie.org/secure/online/adtrack/IOLB/newSession/nz.htm> Thank you for your prompt attention to this matter and for using Westpac! Westpac Banking Corporation ABN 33 007 457 141, incorporated in Australia (New Zealand division). CopyrightC1999-2004 Westpac Banking Corporation

3 2

ADSL Rate Limiting on the line.
by Craig Spiers 21 Oct '04

21 Oct '04

Hi guys, Reading todays article on http://www.aardvark.co.nz/ he raves on about 'increased latency' Would I be right in saying the latency would only increase on lower speed jetstream plans - as it takes longer for the packets to pass over a smaller pipe. Why is he talking about it increasing latency on full rate jetstream plans? Cheers

2 2

Unsubscription from NZNOG
by Donald Neal 21 Oct '04

21 Oct '04

After repeatedly making postings to this list which were not compatible with the list's acseptable use policy, Michael Hallager has been unsubscribed from the NZNOG list. I have received a number of complaints about his behaviour. My thanks to those subscribers for not sending their complaints to the list. - Donald Neal NZNOG Mailing List Administrator Donald Neal |Presbyopia - inability to see what Technical Specialist | bishops are for. Operations Engineering | Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

1 0

Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by neil gardner 20 Oct '04

20 Oct '04

>>> Stephen Ridley <stephen.ridley(a)k.co.nz> 21/10/2004 11:00:01 a.m. >>> >And the latency is somewhat better than what we used to get from the jetstream >link: >traceroute to xtra.co.nz (202.27.184.102), 30 hops max, 38 byte packets > 1 a.a.a.a (a.a.a.a) 0.926 ms 0.864 ms 0.922 ms > 2 b.b.b.b (b.b.b.b) 8.465 ms 8.123 ms 12.425 ms > 3 cs2-e4-7-acld.auckland.clix.net.nz (203.97.9.98) 8.771 ms 9.305 ms 9.286 ms > 4 g1-0-927.u11.tspn.telstraclear.net (218.101.61.6) 11.422 ms 10.660 ms 10.282 ms > 5 xtra.ape.net.nz (192.203.154.60) 14.338 ms 10.610 ms 10.278 ms > 6 v512.XTRAK2-B1.xtra.co.nz (202.27.176.226) 11.048 ms 10.160 ms 10.023 ms We don't need no Interleaving We don't need no surf control No dark deals screwing VOIP Telcos, leave them bits alone Hey, Telcos! Leave them bits alone! All in all it's just another service to fall All in all, you're just a consumer that's going to get screwed by corporate greed and can't do a damn thing about it at all! (Apologies to Pink Floyd and for the number of syllables in the last line :-) 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.

5 4

RE: [nznog] FYI: Telecom changes the ADSL playing field again...
by Steve Schmidt 20 Oct '04

20 Oct '04

The question will be "Free" for how much longer? I have heard rumors that Citylink may have some new tricks up their sleeve (free to comment, open for blasting) to try and maintain free peering exchanges but it will ultimately come down to all the "other" isp's ensuring that they continue to peer at the exchanges. (note: MCI/Voyager just completing their own peering hub and peering arrangements are now being "reviewed") TCNZ are reviewing. TCL have already made their intentions clear. (pardon the pun :-) -----Original Message----- From: Richard Patterson [mailto:richard(a)helix.net.nz] Sent: Thursday, 21 October 2004 10:28 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] FYI: Telecom changes the ADSL playing field again... J S Russell wrote: > >Doesn't this kinda defeat the whole point of having a seperate realm for >JSG, then? That full-speed business was the only thing that made it >interesting. If your connectivity to it is the same as your connectivity >to any other normally-peered (Hi TelstraClear!) New Zealand game server, >why bother maintaining it as a seperate realm you need to re-login to >access? It was worth the bother to re-login when it got you decent speeds, >but without them it's just a pain in the ass. You may as well just lift >the access lists and put allow access to these machines from the general >internet. Or is that what's happening anyway? I remember hearing something >recently about JSG going away. > > > > > Well it won't count to your usage cap. Your 10Gb Usage cap. Including NATIONAL Traffic National traffic thats delivered over the public peering exchanges. Thats ~free anyway. </rant> _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it.

9 19

RE: [nznog] FYI: Telecom changes the ADSL playing field again...
by Donald Neal 20 Oct '04

20 Oct '04

Subscribers to this list should by now be well aware that the Acceptable Use Policy begins "The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate." This does include, for example, discussion of the way QoS features are used in carrier-class networks. But ADSL-related threads on this list have a record of quickly becoming irrelevant to the list's purpose. Let's try and keep this on topic, please. - Donald Neal NZNOG list administrator Donald Neal |Presbyopia - inability to see what Technical Specialist | bishops are for. Operations Engineering | Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

1 0

FYI: Telecom changes the ADSL playing field again...
by Craig Humphrey 20 Oct '04

20 Oct '04

This just came up in the NZ ADSL list: http://www.telecom.co.nz/content/0,3900,204368-201502,00.html Many of you (who work for ISPs) are probably already aware of this, but here's a quick summary: 1. Telecom moving the rate-limiting to the DSLAM and implementing new backend QoS. 2. Telecom apparently (pointed out by an NZ ADSL user) introducing a further 30ms of latency to ADSL connections (presumably due to new QoS). 3. JetStream Games realm and Remote.Office connections will now be limited to connection plan speed (due to the limiting being done at the DSLAM). Yes, this will impact the usage of the jetstreamgames.co.nz and ftp.paradise.net.nz(?) game/linux/bsd mirrors. Note: this is just a mixture of my interpretation and info garnered from NZ ADSL. I/we could be completely wrong :) Later'ish Craig

9 8

Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by neil gardner 20 Oct '04

20 Oct '04

>>> Barry Murphy <barry(a)unix.co.nz> 21/10/2004 10:23:04 a.m. >>> >Telstra Clear already do this with their tempest service, if you purchase a >256k connection, check your router status and you'll see you are connected at >288k. They at least give 32k leaway. Not really - that 288k is 288k of ATM bandwidth... It translates (as best I can figure) to 31.32Kb/sec or 250.56kbits of real world transfer... So you're actually getting more than 256kbits of raw traffic, it's the TCP overheads that bring the number below 256. Cheers - Neil G (Reference : http://www.broadbandreports.com/information/kb/maximum+DSL+speeds/ATM) quoted below maximum DSL speeds Maximum DSL speed is a function of distance, the gauge (thinness) of the phone wire used in your locale, and the DSL technology employed. The fastest DSL now commonly available is ADSL, and it offers maximum download speeds of up to 7.1mbps and around 1.1m upload. Most residential ADSL is limited to 90-680k for download, depending on the Telco. SDSL currently has a max of 1.5mbps, but that is both up and down (symmetric). Other common rates are (in k bits per second) 640k/90k, 1600k/90k, 680k/680k for ADSL. Rule of thumb for converting speeds to something easier to understand: take the k bps, and divide by 10. This is the maximum transfer K per second you are ever likely to see in a browser download window. More accurately, divide by 8 and take off 13%, which is overhead from tcp/ip and, more importantly, ATM overhead. (DSL lines use ATM as an underlying data-transport protocol). Modems range from 2-5k a second, DSL lines from 10-500k a second, office computer interconnections are usually either (best case) 800k a second (10mbit) or 8000k a second (100mbit switched). NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by Michael Hallager 20 Oct '04

20 Oct '04

> This makes a lot of sense, though, technically. Why connect the user at > 8Mbits/sec down and churn out a boatload of RF bollocks from the copper, > when they're only buying a 256Kbits/sec "broadband" connection? May as > well make it 256Kbits/sec right at the start. This will probably enhance > overall network stability somewhat. It does lead automatically to point 3, > however... Good point. Here I have to use two micro filters in series to have a useable phone. (On the ADSL line). Anyone else have this experience? Michael Hallager

1 0

RE: [nznog] FYI: Telecom changes the ADSL playing field again...
by Regan Murphy 20 Oct '04

20 Oct '04

>From: Juha Saarinen [mailto:juha(a)saarinen.org] >Sent: Thursday, 21 October 2004 9:39 a.m. > >What's so badly b0rk3d about DSLAM rate-limiting >and the new QoS implementation that causes latency >to jump like that? Anyone know? "QoS also provides mechanisms for the network to control the delay characteristics (both latency and jitter) of high-priority traffic. Together, prioritization and delay control enable the transmission of real-time voice and video streams." The key word there is "control" (not "reduce" or "limit"). Maybe the latency is applied by design rather than being a fault of the DSLAMs. -- Regan

1 0

Re: Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by Jonny Martin 20 Oct '04

20 Oct '04

> What's so badly b0rk3d about DSLAM rate-limiting and the new QoS > implementation that causes latency to jump like that? Anyone know? If they're dropping the DSL line rate down to plan speed then your bits will take longer to wander to the exchange. It makes quite a significant difference when moving from 8 odd Mbit/s down to 256kbit/s downstream. Can't really take jibes at Telecom for this. If they are taking this approach, then the slower line rates will also mean less RF inteference in the cable binders, which means more robust [albeit slow and piddly] DSL connections. This is how most, if not all, providers work in Australia. Cheers, Jonny.

1 0

RE: Voyager changing AS number
by Booker, Chris 19 Oct '04

19 Oct '04

Hi, Notification that AS4740 Voyager will change to AS703 (MCI Asia Pac) on Thursday 21/10/2004 at 05.30. I am writing to you as the contact point for peering between your AS and our legacy AS 4740 (Voyager) at the Auckland Peering Exchange. If you are not the best contact for peering in your organisation I would appreciate it if you could pass this e-mail on to the right person. MCI acquired Voyager some time ago and we have recently built a new hub in Auckland. We are migrating our peering links to the new site. As part of the move we would like to change the AS on our side to AS703. Our routing policy with respect to your AS will remain the same - we will treat you as a national peer. We will advertise our New Zealand prefixes to you and we will advertise your prefixes to our New Zealand customers. Our peering committee is currently reviewing our peering arrangements in New Zealand and you may hear from a member of our engineering team in the future with regards to that review. Our proposed date time for migration is this Thursday at 0500 New Zealand time. The only change required at your end should be for you to change the remote AS from 4740 to 703. Our IP address will remain the same. I'd appreciate it if you could contact me to let me know if this works for you. Thanks for your time. Regards Christopher Booker Implementation Engineering MCI Australia Email <mailto:chris.booker(a)au.mci.com> chris.booker(a)au.mci.com Tel: + 61 2 9434 5967 Fax: + 61 2 9434 5970

1 0

Invitation to Cisco ISP Update Seminar
by Arron Scott 19 Oct '04

19 Oct '04

Hi all I have asked the List owner for his opinion on whether this may be construed as sales content, so I hope this does not find dis-favour with anyone. Cisco has our primary ISP Consulting Engineer for Australia/New Zealand in Auckland next week, and would be please to invite any ISP staff to attend the following Product Update and Technology Seminar. Attendance is at no cost, and morning tea is included. Please RSVP to browns(a)cisco.com if you would like to attend. ISP's Technology Update Dear All Cisco systems is pleased to invite you a ISP Technology Update Date: Wednesday 27th October Time: 9am to 12.00 Location: Level 16, ASB Building , 135 Albert Street, Auckland During this update we will cover; . IOS software enhancements . 7301 and 7206 NPE-G1. . 10K with PRE-2. . BRAS and LNS Platform update . New RADIUS functionality . Policy management and integration . SSG enhancements . Netflow developments . Core routing update . CRS-1 and IOS-XR . 12000 update RSVP: browns(a)cisco.com We look forward to your participation Arron Scott (CCIE #4099) Phone: +64(9)3551951 Systems Engineer Mobile: +64(21)883163 Cisco Systems New Zealand Ltd. Fax: +64(9)3584442 Level 25, 135 Albert St, Auckland eMail: ascott(a)cisco.com

1 0

SPF Records
by Craig Whitmore 18 Oct '04

18 Oct '04

Hi folks. We have noticed a number of domains in NZ have entered in their NS's domain.co.nz IN TXT "v=spf1 mx -all" This means domain.co.nz will never attempt to send emails at all. (but valid emails are trying to be sent). I've talked to a couple of domain holders who had this and they've fixed them but most said it was done ages ago and they where playing and never expected it to catch on (but it has a lot looking at the number) We (Orcon) have started to use SPF (for testing inbound email) and found it helps with identifying spam. _ALOT_ of people have published valid SPF records. Thanks Craig Whitmore Orcon Internet

11 14

Re: [nznog] SPF Records
by Ewen McNeill 18 Oct '04

18 Oct '04

In message <200410190425.i9J4PvGX007457(a)mailserv.waikato.ac.nz>, "Barry Murphy" writes: >I've wanted to setup SPF in the past but have always wondered what happens >when you have a roaming user sending via paradise for example. The best solution for roaming users is (SASL authenticated) relaying via a central mail server that is listed with SPF. Most commonly used mail clients (and some mail servers) will do SASL authentication these days, and many MTAs can be configured to do SALS authenticated mail relaying. Pushing mail through a central mail server like this is also useful if you are doing other processing on that mail server (eg, statistics, storing copies of messages, etc). >Would one need to know every internet facing ip for all ISP's mailservers? SPF also allows for "include" options, so that you can include (by reference) the SPF records published by the ISPs that are being used. You could, eg, "include" the SPF records of all ISPs used by roaming users. It'd be looser than ideal, but still much better than nothing. If that still isn't sufficient (eg, you have roaming users doing direct-to-remote-server SMTP), you could perhaps list all those ISP dialup subnets (in CIDR fashion). Again this is not ideal, but narrowing it down to a few /22s or even /20s compared with "the whole internet" is still an improvement. With some combination of these it should be possible to list a "much better than nothing" SPF record and then focus on tidying things up so it can be tighter (perhaps eventually down to just "v=spf1 mx -all"). More details at the SPF wizard: http://spf.pobox.com/wizard.html?mydomain=example.com Ewen

1 0

RE: [nznog] Mailwasher and its Forged Bounces
by neil gardner 18 Oct '04

18 Oct '04

Longtime listener, first time poster (on this topic anyway) _IF_ it's possible to reliably (and easily) identify the MailWasher bounces, why not just use that to identify customers using it, and block them from your mail server for a while (Hell, even disable their account perhaps) BUT, and this is the important bit, Send an email to the MW developers telling them that as an ISP you are blocking customers that use their software in this way. Suggest that users of their software will find their Intarwebthingy disabled. Sure the developers may not like taking out neat features, but they probably won't like fielding calls from users who get their net killed because of their product either. 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.

3 2

Mailwasher and its Forged Bounces
by Lennon - Orcon 18 Oct '04

18 Oct '04

I've been looking lately and a "large" number of double bounces to postermaster are caused by people who use "MailWashers" to Bounce Spam. I rmember the days when I could read every message to postmaster(a)isp.co.nz They are quite easy to spot as they all have the format of: mail.local: unknown name: username 550 username(a)domain.co.nz ... User unknown Coming from MAILER-DAEMON(a)domain.co.nz (usually the ISP's one) (and forging the email (which I presume is against all ISP's T&C) In mailwashers FAQ it says: ------- Do the spammers know I am bouncing email? No, spammers do not know you are bouncing messages. Bounced messages look just like a returned mail message you would receive if you sent an email to an incorrect address. --------- If I can tell if someone if using mailwasher.. why cannot the spammers? Even so I would think 99.9% of all emails bounced via this program don't get back to the spammers anyway (they don't use proper from addresses or use someone else's domain to send from (anyone in NZ using/looking at using SPF? to stop this type of thing) What I am trying to say (if not very well). What do people think of this feature of mailwasher. I've emailed the writer a few times for comments over the last few years and heard nothing from him. Have ISP's complained to uses using it? stopped people using it? or what? Thanks Craig Whitmore

12 19

Ihug Prefix list update
by Sainesh Singh 17 Oct '04

17 Oct '04

Please update domestic filters for Ihug. APE details: AS7657 192.203.154.36 192.203.154.37 Updated list can be found at: http://www.ihug.net/ihug-prefix-list and is included below. Cheers, Sainesh Singh Ihug Engineering ip prefix-list ihug-networks permit ip prefix-list ihug-networks description ihug peering prefix-list contact: noc(a)ihug.co.nz : Updated 2004-10-18 ip prefix-list ihug-networks permit 192.107.113.0/24 ip prefix-list ihug-networks permit 202.21.130.0/24 ip prefix-list ihug-networks permit 202.21.136.0/23 le 24 ip prefix-list ihug-networks permit 202.36.44.0/24 ip prefix-list ihug-networks permit 202.36.94.0/23 le 24 ip prefix-list ihug-networks permit 202.36.230.0/24 ip prefix-list ihug-networks permit 202.36.231.0/24 ip prefix-list ihug-networks permit 202.37.182.0/24 ip prefix-list ihug-networks permit 202.49.33.0/24 ip prefix-list ihug-networks permit 202.49.46.0/23 le 24 ip prefix-list ihug-networks permit 202.49.63.0/24 ip prefix-list ihug-networks permit 202.49.148.0/23 le 24 ip prefix-list ihug-networks permit 202.49.176.0/23 le 24 ip prefix-list ihug-networks permit 202.49.178.0/24 ip prefix-list ihug-networks permit 202.49.180.0/23 le 24 ip prefix-list ihug-networks permit 202.49.186.0/24 ip prefix-list ihug-networks permit 202.49.249.0/24 ip prefix-list ihug-networks permit 202.50.84.0/24 ip prefix-list ihug-networks permit 202.50.103.0/24 ip prefix-list ihug-networks permit 202.50.188.0/22 le 24 ip prefix-list ihug-networks permit 202.50.255.0/24 ip prefix-list ihug-networks permit 203.96.192.0/19 le 24 ip prefix-list ihug-networks permit 203.109.128.0/17 le 24 ip prefix-list ihug-networks permit 203.109.130.0/24 ip prefix-list ihug-networks permit 203.109.132.0/22 ip prefix-list ihug-networks permit 203.109.133.0/24 ip prefix-list ihug-networks permit 203.109.134.0/24 ip prefix-list ihug-networks permit 203.109.135.0/24 ip prefix-list ihug-networks permit 203.109.144.0/20 ip prefix-list ihug-networks permit 203.109.157.0/24 ip prefix-list ihug-networks permit 203.109.192.0/21 ip prefix-list ihug-networks permit 203.109.198.0/24 ip prefix-list ihug-networks permit 203.109.199.0/24 ip prefix-list ihug-networks permit 203.109.230.0/24 ip prefix-list ihug-networks permit 203.118.128.0/18 le 24 ip prefix-list ihug-networks permit 203.118.144.0/20 ip prefix-list ihug-networks permit 203.118.160.0/20 ip prefix-list ihug-networks permit 203.118.164.0/22 ip prefix-list ihug-networks permit 203.118.168.0/21 ip prefix-list ihug-networks permit 203.173.128.0/17 le 24 ip prefix-list ihug-networks permit 203.173.170.0/23 ip prefix-list ihug-networks permit 203.173.192.0/19 ip prefix-list ihug-networks permit 203.173.224.0/20 ip prefix-list ihug-networks permit 203.173.240.0/21 ip prefix-list ihug-networks permit 210.55.110.0/24 ip prefix-list ihug-networks permit 210.55.184.0/24 ip prefix-list ihug-networks permit 210.55.202.0/23 le 24 ip prefix-list ihug-networks permit 210.55.248.0/21 le 24

1 0