- NZNOG - lists.nznog.org

Launch of REANNZ/KAREN
by Richard Naylor 30 Aug '06

30 Aug '06

Today at 6pm (I think) they're launching KAREN (Kiwi Academic Research and Education Network). Theres a webcast at <http://www.r2.co.nz/20060831/>http://www.r2.co.nz/20060831/ and includes (hopefully) a webcast of the Access grid in session.

1 0

dodgywhitemaori wants to share sites with you...
by dodgywhitemaori＠gmail.com 27 Aug '06

27 Aug '06

dodgywhitemaori (dodgywhitemaori(a)gmail.com) has invited you to StumbleUpon! You can see my other favorites here: http://dodgywhitemaori.stumbleupon.com Thanks, dodgywhitemaori --- StumbleUpon lets you discover great sites with a single click. Give it a try at: http://www.stumbleupon.com/join.php?friend=1265183&emailcode=4tywd1y5drcjtl…

2 1

OT: Network Engineer position available at Orcon
by Thomas Salmen 24 Aug '06

24 Aug '06

Everyone else seems to be doing it today, so I'll throw mine in the mix: http://www.orcon.net.nz/jobs__orcon/job_vacancy/network_engineer/ Anyone with questions, etc - feel free to get in touch. Cheers, -- Thomas Salmen Network Operations Orcon Internet

1 0

NZNOG Conference 2007
by Donald Neal 24 Aug '06

24 Aug '06

During and after this year's successful conference, a number of suggestions were made to organisers about the way in which the next NZNOG conference could be organised. After consideration of a number of generous offers to host the conference, the organising committee have opted to retain a stand-alone conference structure, but once again to try a new venue. Next year's New Zealand Network Operators' Group Conference is scheduled to run from 31 January to 2 February 2007 in Palmerston North. Our hosts are Inspire.net (http://www.inspire.net.nz/) . This will be the first time the conference has been in Palmerston North, and the first time we've been hosted by an ISP. The venue is to be at Massey University's campus. A Call for Presenters should be issued later this month. Please form an orderly queue ... - Donald Neal Donald Neal |"I can marry anyone I please! The Support Engineer |trouble is, I don't please NGN Operations |anybody." - Waldorf T. Flywheel 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.

6 8

OT: Senior Network Engineer position open at Citylink
by Simon Blake 24 Aug '06

24 Aug '06

http://citylink.co.nz/jobs/ Subject pretty much says it all. If you've any questions, feel free to contact me. Cheers Si

1 0

Grid job
by Clark Mills 24 Aug '06

24 Aug '06

Hi all. Our uni is looking for someone, it seems bleeding edge and may very well include a free beer [approval token paid ;) ]. ============================================================================= http://www.vacancies.auckland.ac.nz/positiondetail.asp?p=4465 Research IT Specialist (G609-06J) Enterprise Architecture Group, ITSS This position will be required to implement, manage and develop Research IT infrastructure in support of the BestGrid program (www.bestgrid.org) Location: Auckland Term of Contract: Fixed Term of 9 Months Closing Date: 31 August 2006 Position Overview: Graduate or postgraduate computer science or equivalent in engineering sought for Research IT specialist position in support of NZ wide research program involving high speed networks, grid computing, data grid, shared scientific databases and access grids. (www.bestgrid.org) Job Description =============== Purpose Statement: To establish and manage research IT facilities for BestGrid Responsible To: Enterprise Architecture Manager, BestGrid Director Key Accountability Areas: Delivery of Research IT infrastructure and programming for the BestGrid project. Person Specification ==================== Qualifications: Applicants should have a graduate degree involving computer science or higher. Experience: Experience in computational science beneficial. Must have strong IT skills in systems and application configuration and programming. A knowledge of GRID computing toolkits and middleware, e.g. Globus GRIDkit is desireable but not essential. Attributes and Skills: Innovative, hands on with strong communication skills, specifically Wiki and Blogs. Willingness to learn and understand discipline-specific research requirements and assist with the development of purpose built tools to enable research usage adanced GRID technologies.

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 23 Aug '06

23 Aug '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by LinuxNet - AS18119 members: 202.46.160.0/20^20-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.37.136.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.0/24^24-29, 202.7.4.80/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: soa(a)linuxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050513 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by Advanced Computer Solutions - AS18119 members: 202.46.160.0/20^20-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.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: lincoln(a)acsdata.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060824 source: NZRR

1 0

Beer - and other things.....
by Richard Naylor 21 Aug '06

21 Aug '06

EU ORDERS DEUTSCHE TELEKOM TO SHARE NETWORK The European Commission (EC) supported German regulators who ordered Deutsche Telekom AG to open its high-speed Internet networks to competitors. As a result of the order, the company must permit competitors to buy access on its broadband network to offer their own services to end users. German regulators will have advance approval of the price charged. Past refusals to grant access forced the company's business rivals to build their own networks, effectively preventing them from operating outside cities and causing higher Internet prices in rural areas, according to the EC. Wall Street Journal, 21 August 2006 http://online.wsj.com/article/SB115616823663141011.html

1 0

Attn: abuse @ xtra
by John ＠ netTRUST 21 Aug '06

21 Aug '06

emails to abuse @ xtra.co.nz are being bounced with the following message- ---------------------------------------------------------------- This is a system generated message. Please DO NOT REPLY. Your message was not delivered for the following reason: The user(s) account is temporarily over quota. <cts6(a)team.xtra.co.nz> For more information on why this message wasn't delivered, and an explanati on of other common mail delivery errors, visit our Web site at: http://xtra.co.nz/maildelivery Kind regards. The Xtra Messaging Team

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 14 Aug '06

14 Aug '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS9245 as-name: NZRR-AS9245 descr: Compass Communications descr: APE peering at '192.203.154.110' descr: see Citylink RT job #6667 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS9245 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dquigan(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060810 source: NZRR REPLACED BY: aut-num: AS9245 as-name: NZRR-AS9245 descr: Compass Communications descr: APE peering at '192.203.154.110' descr: see Citylink RT job #6667 descr: WIX peering at '202.7.0.179' descr: see Citylink RT job #6708 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS9245 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS9245 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dquigan(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060815 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS9245 descr: Route set advertised to AS9439 by Compass Communications Limited - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 202.36.121.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.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: dquigan(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060815 source: NZRR

1 0

NZNOG 07 - Sysadmin stream on the Wednesday
by Simon Lyall 10 Aug '06

10 Aug '06

Just a quick heads up but it is likely that myself and a few others will be organising a Systems Administrators stream on the Wednesday of NZNOG 07 in January next year. The stream will be a operationally orientated event for those NZNOG people who work with servers and server-based services especially in an Internet context (web facing rather than say desktop management). The Call for Papers will probably look something like this: http://sysadmin.miniconf.org/cfp.html which is from an event held in January as part of linux.conf.au . Please send me some email if you are interested in participating and/or presenting or otherwise have some feedback. Now is also a good time to start considering if you or someone you know might have a suitable presentation. Official announcements and CFPs will be made when details are finalized. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 09 Aug '06

09 Aug '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: aut-num: AS9245 as-name: NZRR-AS9245 descr: Compass Communications descr: APE peering at '192.203.154.110' descr: see Citylink RT job #6667 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS9245 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dquigan(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060810 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS9245 descr: Route set advertised to AS9560 by Compass Communications - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 202.36.121.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.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: dquigan(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060810 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 09 Aug '06

09 Aug '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: aut-num: AS23995 as-name: NZRR-AS23995 descr: VoiceValley descr: APE peering at '192.203.154.27' descr: see Citylink RT job #6665 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS23995 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: kamy(a)voicevalley.com.au mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060810 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS23995 descr: Route set advertised to AS9560 by VoiceValley - AS23995 members: 202.182.96.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: kamy(a)voicevalley.com.au mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060810 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 09 Aug '06

09 Aug '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Broadcast Communications Ltd - AS24324 members: 124.157.64.0/19^19-29, 202.49.128.0/21^21-29, 202.27.83.0/24^24-29, 202.36.75.0/24^24-29, 202.36.154.0/24^24-29, 202.37.168.0/24^24-29, 202.49.183.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: smc(a)bclnz.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060712 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Broadcast Communications Ltd - AS24324 members: 124.157.64.0/19^19-29, 202.49.128.0/21^21-29, 218.185.224.0/21^21-29, 202.27.83.0/24^24-29, 202.36.75.0/24^24-29, 202.36.154.0/24^24-29, 202.37.168.0/24^24-29, 202.49.183.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: smc(a)bclnz.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060810 source: NZRR

1 0

ispmap.co.nz update
by Barry Murphy 08 Aug '06

08 Aug '06

Hey guys, I'm in the process of redesigning ispmap.co.nz because the layout & functionality is pretty out of date as the site still gets close to 1000 unique hits a day. Before the overhaul is done, I'd like to get the database up to date, so if you work for; or are connected to one of the ISP's listed, please advise me of any out of date international circuits. If your ISP is not listed, please send me details. Cheers Barry Murphy

1 0

Problem with xtra webmail caching sessions
by Ian Batterbee 06 Aug '06

06 Aug '06

We (AUT) have been seeing a lot of problems with users accessing xtra webmail through our http caches since last week. Basically, the sessions appear to be getting mixed up, and users are jumping between sessions apparently randomly each time they click on something within the webmail application. For example, from one of our users: "when I opened my inbox all my mail was there, however when I went to compose a message it threw me into another users account - ([deleted](a)xtra.co.nz) I then tried to navigate to the mailbox page to see if it was still my mail and it logged me into yet another account ([deleted](a)xtra.co.nz and then [deleted](a)xtra.co.nz)" We've been in contact with xtra about this and they initially said they haven't been able to reproduce the fault. Also, those users who have contacted xtra directly have been told that their account has been disabled (how thoughtful) Does anyone on the list have any further information about this problem ?

1 0

Re: [nznog] Domain Registration scam
by Scott Weeks 06 Aug '06

06 Aug '06

----- Original Message Follows ----- From: "Craig Whitmore" <lennon(a)orcon.net.nz> To: "Jeremy Strachan" <JeremyS(a)cclnz.co.nz>, "NZNOG" <nznog(a)list.waikato.ac.nz> > > I see this scam is back again, obviously using out of > http://www.nzdomainregistration.com/ hosted at nac.net > with no website . Did anyone send email to abuse(a)nac.net? scott

2 1

Domain Registration scam
by Jeremy Strachan 06 Aug '06

06 Aug '06

I see this scam is back again, obviously using out of date Domain registration information, and mass mail drops. I've probably received 20 letters today to register domains we don't have. Presumably it's the same culprit as the previous two occasions.

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 06 Aug '06

06 Aug '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS10022 descr: advertised to AS9560 by Datacom - AS10022 members: 202.175.128.0/21^21-29, 202.14.20.0/22^22-29, 202.14.82.0/23^23-29, 202.36.198.0/23^23-29, 192.203.216.0/24^24-29, 202.14.84.0/24^24-29, 202.27.76.0/24^24-29, 202.27.140.0/24^24-29, 202.27.143.0/24^24-29, 202.27.250.0/24^24-29, 202.36.233.0/24^24-29, 210.55.5.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: idc(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060602 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS10022 descr: advertised to AS9560 by Datacom Systems Auckland - AS10022 members: 202.36.8.0/21^21-29, 202.175.128.0/21^21-29, 202.14.20.0/22^22-29, 202.14.82.0/23^23-29, 202.36.198.0/23^23-29, 192.203.216.0/24^24-29, 202.14.84.0/24^24-29, 202.27.76.0/24^24-29, 202.27.140.0/24^24-29, 202.27.143.0/24^24-29, 202.27.250.0/24^24-29, 202.36.233.0/24^24-29, 210.55.5.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: idc(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060807 source: NZRR

1 0

Yet another trademe scam...
by Mark Foster 05 Aug '06

05 Aug '06

http://www.blakjak.net/node/548 Rather cleverly created, doesn't look forged unless you're fairly onto it. ISPs may like to null-route the IP the HREF points at. Trademe - you probably also need to know. Regards Mark.

3 2

Weird DNS Problems
by Jithen Singh 04 Aug '06

04 Aug '06

Hey Guys, Was wondering if anyone could help out with this. Just two days ago we started to experience DNS problems resolving international addresses. The DNS servers are configured with no forwarders and go directly out. We can resolve NZ addresses but nothing else. Norhing's changed on the DNS severs and the problem just started happening. Link is going out on Citylink through to ICONZ. Any ideas? or help? Cheers J > intergen.co.nz Server: ns1.eaglegis.co.nz Address: 210.48.106.196 Name: intergen.co.nz Address: 202.49.144.165 > google.com Server: ns1.eaglegis.co.nz Address: 210.48.106.196 DNS request timed out. timeout was 2 seconds. *** Request to ns1.eaglegis.co.nz timed-out > nzpost.co.nz Server: ns1.eaglegis.co.nz Address: 210.48.106.196 Name: nzpost.co.nz Address: 202.12.249.9

3 3

Screening 2.4Ghz AP's?
by Simon Blake 02 Aug '06

02 Aug '06

While we're on the subject of subfunctional wireless links, does anybody know of a simple way of reducing the RF output from a functioning AP? Basically, I'd like to find a way to mute an AP while it's being setup, so that it doesn't affect other users of production AP's near by (in the same SSID). I'm thinking putting it in a box surrounded with a bunch of (non frozen) plastic freezer packs might be the go, but I'd be interested to know if anybody has any other cunning ideas. We could disable the RF or remove aerials, but that adds extra steps - I'm looking for something that could sit on a desk that the AP could be dropped in while somebody is working on the console. Cheers Si

8 8

Notification of NZRR Database changes
by NZRR Database Notifications 02 Aug '06

02 Aug '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes. filter: {1.0.0.0/8^+, 2.0.0.0/8^+, 5.0.0.0/8^+, 7.0.0.0/8^+, 23.0.0.0/8^+, 27.0.0.0/8^+, 31.0.0.0/8^+, 36.0.0.0/8^+, 37.0.0.0/8^+, 39.0.0.0/8^+, 42.0.0.0/8^+, 49.0.0.0/8^+, 50.0.0.0/8^+, 77.0.0.0/8^+, 78.0.0.0/8^+, 79.0.0.0/8^+, 92.0.0.0/8^+, 93.0.0.0/8^+, 94.0.0.0/8^+, 95.0.0.0/8^+, 96.0.0.0/8^+, 97.0.0.0/8^+, 98.0.0.0/8^+, 99.0.0.0/8^+, 100.0.0.0/8^+, 101.0.0.0/8^+, 102.0.0.0/8^+, 103.0.0.0/8^+, 104.0.0.0/8^+, 105.0.0.0/8^+, 106.0.0.0/8^+, 107.0.0.0/8^+, 108.0.0.0/8^+, 109.0.0.0/8^+, 110.0.0.0/8^+, 111.0.0.0/8^+, 112.0.0.0/8^+, 113.0.0.0/8^+, 114.0.0.0/8^+, 115.0.0.0/8^+, 116.0.0.0/8^+, 117.0.0.0/8^+, 118.0.0.0/8^+, 119.0.0.0/8^+, 120.0.0.0/8^+, 173.0.0.0/8^+, 174.0.0.0/8^+, 175.0.0.0/8^+, 176.0.0.0/8^+, 177.0.0.0/8^+, 178.0.0.0/8^+, 179.0.0.0/8^+, 180.0.0.0/8^+, 181.0.0.0/8^+, 182.0.0.0/8^+, 183.0.0.0/8^+, 184.0.0.0/8^+, 185.0.0.0/8^+, 186.0.0.0/8^+, 187.0.0.0/8^+, 197.0.0.0/8^+, 223.0.0.0/8^+} remarks: For the complete set of bogons, please see: fltr-martians - special use and reserved prefixes. fltr-bogons - fltr-unallocated + fltr-martian. http://www.cymru.com/Documents/bogon-list.html admin-c: RTH32-ARIN tech-c: RTH32-ARIN notify: radb(a)cymru.com notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-BOGON-FILTERS changed: rpsl-admin(a)nzix.net 20040819 changed: rpsl-admin(a)nzix.net 20060113 source: NZRR REPLACED BY: filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes filter: { 1.0.0.0/8^+, 2.0.0.0/8^+, 5.0.0.0/8^+, 7.0.0.0/8^+, 23.0.0.0/8^+, 27.0.0.0/8^+, 31.0.0.0/8^+, 36.0.0.0/8^+, 37.0.0.0/8^+, 39.0.0.0/8^+, 42.0.0.0/8^+, 49.0.0.0/8^+, 50.0.0.0/8^+, 77.0.0.0/8^+, 78.0.0.0/8^+, 79.0.0.0/8^+, 92.0.0.0/8^+, 93.0.0.0/8^+, 94.0.0.0/8^+, 95.0.0.0/8^+, 96.0.0.0/8^+, 97.0.0.0/8^+, 98.0.0.0/8^+, 99.0.0.0/8^+, 100.0.0.0/8^+, 101.0.0.0/8^+, 102.0.0.0/8^+, 103.0.0.0/8^+, 104.0.0.0/8^+, 105.0.0.0/8^+, 106.0.0.0/8^+, 107.0.0.0/8^+, 108.0.0.0/8^+, 109.0.0.0/8^+, 110.0.0.0/8^+, 111.0.0.0/8^+, 112.0.0.0/8^+, 113.0.0.0/8^+, 114.0.0.0/8^+, 115.0.0.0/8^+, 116.0.0.0/8^+, 117.0.0.0/8^+, 118.0.0.0/8^+, 119.0.0.0/8^+, 120.0.0.0/8^+, 173.0.0.0/8^+, 174.0.0.0/8^+, 175.0.0.0/8^+, 176.0.0.0/8^+, 177.0.0.0/8^+, 178.0.0.0/8^+, 179.0.0.0/8^+, 180.0.0.0/8^+, 181.0.0.0/8^+, 182.0.0.0/8^+, 183.0.0.0/8^+, 184.0.0.0/8^+, 185.0.0.0/8^+, 186.0.0.0/8^+, 187.0.0.0/8^+, 197.0.0.0/8^+, 223.0.0.0/8^+ } remarks: For the complete set of bogons, please see: fltr-martians - special use and reserved prefixes fltr-bogons - fltr-unallocated + fltr-martian http://www.cymru.com/Documents/bogon-list.html admin-c: RTH32-ARIN tech-c: RTH32-ARIN notify: radb(a)cymru.com notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-BOGON-FILTERS changed: rpsl-admin(a)nzix.net 20040819 changed: rpsl-admin(a)nzix.net 20060113 changed: rpsl-admin(a)nzix.net 20060803 source: NZRR

1 0

Fwd: [Apnic-announce] APNIC debogon project
by Nurani Nimpuno 02 Aug '06

02 Aug '06

Fyi. APNIC is now allocating from the address ranges below. Cheers, Nurani --------------------------------------------------------------------- Nurani Nimpuno email: nurani(a)apnic.net Outreach coordinator, APNIC sip: nurani(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 --------------------------------------------------------------------- Welcome to APNIC 22! Kaohsiung, Taiwan, 4-8 September 2006 http://www.apnic.net/meetings --------------------------------------------------------------------- Begin forwarded message: > From: John Tran <john(a)apnic.net> > Date: 3 August 2006 10:32:10 AM > To: apnic-announce(a)apnic.net > Cc: apops(a)apops.net, pacnog(a)pacnog.org, sanog(a)sanog.org > Subject: [Apnic-announce] APNIC debogon project > Reply-To: apnic-talk(a)apnic.net > > > Dear colleagues > > In January 2006, APNIC received the following IPv4 address ranges > from IANA: > > - 121/8 > - 122/8 > - 123/8 > > APNIC has started making allocations from these address ranges. > > To ensure these ranges are not being accidentally filtered, > selected prefixes from each /8 have been announced using AS12654. > > A reachability test can be done on each test prefix. A list of > "pingable" hosts and a daily visibility report for each prefix is > available here: > > http://www.ris.ripe.net/debogon/debogon.html > > If you need further assistance or have any concerns, please feel > free to contact us at <helpdesk(a)apnic.net>. > > Regards > ______________________________________________________________________ > __ > Son Tran email: > helpdesk(a)apnic.net > Resource Services Manager, APNIC sip: > helpdesk(a)voip.apnic.net > http://www.apnic.net/helpdesk phone: +61 7 3858 > 3188 > fax: +61 7 3858 > 3199 > ______________________________________________________________________ > __ > Welcome to APNIC 22! > Kaohsiung, Taiwan, 4-8 September 2006 http://www.apnic.net/meetings > _____________________________________________________________________ > > _______________________________________________ > Apnic-announce mailing list > Apnic-announce(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-announce

1 0

Re: [nznog] Wireless link adversly affected by the sun?
by Michael Davies 02 Aug '06

02 Aug '06

Wow thanks for all the responses. In reply to Neil Fenemor: I can definitely see how thermal things like that and the way heat moves could effect things, the building we link to isn't too far away but the route as the crow flies is directly over the city and therefore a lot of asphalt and whatnot so I can see how that would cause problems. I imagine there's not a lot a lot that can be done to prevent/circumvent that other than changing to a different connection method. Irt Mark Foster & others regarding heat: This definitely sounds like something I'll have to look at further, I know the trango unit does have some kind of internal thermometer (probably for this very reason) so I'll look into a way of graphing the output from that. What kind of temperatures would be classed as too high? 40-50deg? Irt Dave, I'll reply off list. Cheers all, Michael Btw hopefully the weather keeps up, would be nice to see a warm end to winter :) ________________________________________ From: Ben Deller - Airnet NZ [mailto:ben(a)team.airnet.net.nz] Sent: Tuesday, 1 August 2006 4:22 p.m. To: Michael Davies Subject: RE: [nznog] Wireless link adversly affected by the sun? Hi Michael Perhaps try being more specific in isolating the problem. Is it latency and jitter in the wireless link or past the link out on another network (the internet)? Try the smokeping test to your ISP's network not the internet. Also have you checked you signal and noise levels on the wireless link? (Or asked your ISP to check this) It could be wireless interference from another network. Or it could just be too hot. Ben ________________________________________ From: Michael Davies [mailto:michael(a)hereisasite.co.nz] Sent: Tuesday, 1 August 2006 3:48 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Wireless link adversly affected by the sun? Hi there, As the subject suggests, I've been noticing an interesting problem with our internet. We're lucky enough to be on the receiving end of a wireless net connection running through Trango broadband hardware, fairly conventional wireless tech. However I've noticed through monitoring the connection with smokeping to various places around the country that the connection quality seems to decrease dramatically through the middle of the day, but not every day. At first I thought that this was simply related to congestion somewhere, but from following the weather a bit I've started noticing that it gets worse on the nice sunny days. For example: Today, a balmy 17 degrees in Dunedin and beautifully sunny all day. Packet loss and jitter begins to increase at about 9am and peaks about 1pm with 60% loss, then at 2pm as if flicking a switch it returns to nearly 0% loss. From looking at the graphs over time, this does happen quite often but not every day and the loss today is definitely the worst I've seen it (but also the warmest/sunniest day we've had in Dunedin for quite a while). Has anyone seen or heard of this happening before? Would there be any way to prevent this - supposing that the sun is the culprit - short of installing a Mr. Burns type sun shield? Regards, Michael

3 3

Wireless link adversly affected by the sun?
by Michael Davies 01 Aug '06

01 Aug '06

Hi there, As the subject suggests, I've been noticing an interesting problem with our internet. We're lucky enough to be on the receiving end of a wireless net connection running through Trango broadband hardware, fairly conventional wireless tech. However I've noticed through monitoring the connection with smokeping to various places around the country that the connection quality seems to decrease dramatically through the middle of the day, but not every day. At first I thought that this was simply related to congestion somewhere, but from following the weather a bit I've started noticing that it gets worse on the nice sunny days. For example: Today, a balmy 17 degrees in Dunedin and beautifully sunny all day. Packet loss and jitter begins to increase at about 9am and peaks about 1pm with 60% loss, then at 2pm as if flicking a switch it returns to nearly 0% loss. From looking at the graphs over time, this does happen quite often but not every day and the loss today is definitely the worst I've seen it (but also the warmest/sunniest day we've had in Dunedin for quite a while). Has anyone seen or heard of this happening before? Would there be any way to prevent this - supposing that the sun is the culprit - short of installing a Mr. Burns type sun shield? Regards, Michael

16 15

Re: [nznog] Screening 2.4Ghz AP's?
by Gordon Smith 01 Aug '06

01 Aug '06

A small Faraday cage? > -----Original Message----- > From: Simon Blake [mailto:simon(a)citylink.co.nz] > Sent: Wednesday, 2 August 2006 2:11 p.m. > To: nznog(a)list.waikato.ac.nz > Subject: [nznog] Screening 2.4Ghz AP's? > > While we're on the subject of subfunctional wireless links, > does anybody know of a simple way of reducing the RF output > from a functioning AP? > > Basically, I'd like to find a way to mute an AP while it's > being setup, so that it doesn't affect other users of > production AP's near by (in the same SSID). I'm thinking > putting it in a box surrounded with a bunch of (non frozen) > plastic freezer packs might be the go, but I'd be interested > to know if anybody has any other cunning ideas. > > We could disable the RF or remove aerials, but that adds > extra steps - I'm looking for something that could sit on a > desk that the AP could be dropped in while somebody is > working on the console. > > Cheers > Si > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog >

2 1

Re: [nznog] Wireless link adversly affected by the sun?
by Stewart Fleming 01 Aug '06

01 Aug '06

Depending on exact location in Dunedin, this is most likely to be interference related. Which way is the antenna pointing? :) We have a bunch of Trango gear up as well and don't notice any characteristic like the one posted. Surveying from one particular location indicated -30dBm spikes on 3 channels (both polarizations) and one of our units managed to associate with an old AP (hey, free Internet!), so there is a lot of potential for interference. There is an AP condition with old firmware where the heater doesn't kick in properly and causes packet loss on the Ethernet interface (that's upstream from you). A mismatch in speed/duplex settings on your end can cause this too, but that's unlikely to be time-dependent. Some of the newer Trango SUs have firmware issues which can cause similar to what you are seeing. If you can monitor RSSI on the SU you will get a clearer picture of what is going on. It's possible that it is overloading on the AP or congestion upstream :-) We cleared up a similar packet loss issue by adding a 88cm dish for a 3km link.

1 0

Ihug UBS vs Telecom Fault Query
by Jon Dean 01 Aug '06

01 Aug '06

Apologies first, since I know this isn't a helpdesk forum. A plea for help from Ihug and Telecom and the list. Two Ihug bitstream customers, on the same exchange in Invercargill both suffered internet failure at the same on Monday. Discussions with the ISP have resulted in a claim that Telecom have sent an e-mail to the Network team saying their was a fault and it is being worked on (but this doesn't appear on the status/faults page). Discussions with Faults at Telecom say there are no faults in Invercargill. My question to the list and to Ihug/Telecom... Is there a standard mechanism for logging faults, and delivering the report to wholesale ISPs? Can there be DSL/DSLAM faults so minor (as a proportion of customers) that it doesn't get flagged by the various systems? Is it possible that the way UBS is organised that customers on different ISPs but the same exchange won't have problems? (i've got some reports of problems with Xtra and Southnet on the same exchange in the same timeframe). My difficulty is trying to understand who/what/where the problem is and therefore who to target to get it fixed. Responses on or off-list are much appreciated. Kind Regards, -- Jon Dean Wormhole Technology Limited http://www.wormhole.co.nz P.O. Box 7063, Dunedin, New Zealand; Freephone: (0800)219-676; Mobile: (021)414-070;

1 0

Re: [nznog] Wireless link adversly affected by the sun?
by Michael Davies 31 Jul '06

31 Jul '06

Hmm yes I think we will definitely be getting in touch with the ISP, I thought/knew that some degree of loss is acceptable with wireless but was unaware that Trangos have this polling system you speak of. I'm not entirely sure how the AP is shared, I presume at worst there are a few other users on it but no huge amount, as far as I'm aware it's not just set for us. Normally there's no loss, and between 3pm and now the graph is a nice flat green line showing no loss, so whatever was causing the problem had stopped by then. I've managed to wrangle up a temperature graph thing from the handy inbuilt thermometer in the SU on our roof, but I've a suspicion that it doesn't actually work as the only value that's come off it so far tonight is 21 deg and considering that it's close to 6 degrees outside now I somehow doubt that. Hopefully it'll show some reading tomorrow... Unfortunately there's no measure of the RSSI unless the SU is switched into a different mode, meaning that it doesn't actually provide internet. If I catch the problem happening tomorrow or whenever I'll be sure to flick it across and see what's happening though. I'd heard about differing elevations making problems for wireless links before, but this was referring to a more extreme variation in height like sending wireless up a mountain. If there is variation in height it'd only be marginal and not be enough to make a difference, then again I don't really know what I'm talking about so I'll bring this up with the ISP too. In reply to Tim Price: I know what you mean about increased traffic causing problems, loading up the link causes increased jitter but doesn't seem to effect loss (unless the link is entirely saturated). Certainly at the time of the problem today there was almost zero traffic going across. Fortunately trango sits a bit further away from the 2.4 guys at the spectrum table, up in the 5.8 region like the 50km links you mention so I guess that pretty much counts out weather effecting things, unless it was a specific problem with our model which seems unlikely. Anyways, thanks for all the responses and info, it does narrow the mystery slightly. I'll get in touch with the ISP and see what they have to say and if they come up with anything really interesting/groundbreaking I'll dig the thread back up. Best Regards, Michael ________________________________________ From: jediblair(a)gmail.com [mailto:jediblair(a)gmail.com] On Behalf Of Blair Harrison Sent: Tuesday, 1 August 2006 8:50 p.m. To: Michael Davies Subject: Re: [nznog] Wireless link adversly affected by the sun? Hiya, You should definitely get your ISP to look at the link - sounds like they need to do some tweaking, a trango graph shouldn't look anything like what you've posted - should be a nice 10-20ms line with NO packet loss - is it a point-to-point dedicated link just for you, or is the AP shared by a few others? either way the polling system used by the Trango network should ensure no packet loss.. The only time I've seen Trango links have drop out issues in the sun, is when the radios reach the high 30s and 40 degrees, after about 40 degrees things just start to go haywire.. if the radios are in direct sunlight all day then they might be heating up a bit much - if you can start graphing the rssi and heat as Jonathan suggested then that would help a lot in determining issues.. Cheers, Blair On 8/1/06, Michael Davies <michael(a)hereisasite.co.nz> wrote: Hi there, As the subject suggests, I've been noticing an interesting problem with our internet. We're lucky enough to be on the receiving end of a wireless net connection running through Trango broadband hardware, fairly conventional wireless tech. However I've noticed through monitoring the connection with smokeping to various places around the country that the connection quality seems to decrease dramatically through the middle of the day, but not every day. At first I thought that this was simply related to congestion somewhere, but from following the weather a bit I've started noticing that it gets worse on the nice sunny days. For example: Today, a balmy 17 degrees in Dunedin and beautifully sunny all day. Packet loss and jitter begins to increase at about 9am and peaks about 1pm with 60% loss, then at 2pm as if flicking a switch it returns to nearly 0% loss. From looking at the graphs over time, this does happen quite often but not every day and the loss today is definitely the worst I've seen it (but also the warmest/sunniest day we've had in Dunedin for quite a while). Has anyone seen or heard of this happening before? Would there be any way to prevent this supposing that the sun is the culprit short of installing a Mr. Burns type sun shield? Regards, Michael _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Trojan "MS Windows TCP/IP Patch" spam run
by matthew＠auscert.org.au 31 Jul '06

31 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings all, We've had a few reports of a spam run for a fake MS Windows TCP/IP Patch (as below) that leads to a trojan site. Anyone else seeing much of this? Any feedback appreciated. - -- Matthew McGlashan -- Coordination Centre Team Leader | Hotline: +61 7 3365 4417 Australian Computer Emergency Response Team | Direct: +61 7 3365 7924 (AusCERT) | Fax: +61 7 3365 7031 The University of Queensland | WWW: www.auscert.org.au Qld 4072 Australia | Email: auscert(a)auscert.org.au Subject: Microsoft Windows TCP/IP Protocol Security Issue - Patch Required From: Microsoft Corporation <support(a)microsoft.com> Date: 31 Jul 2006 19:31:57 +0200 To: auscert(a)auscert.org.au Dear Customer, Our anti-virus labs have detected a new 0-day vulnerability in the Microsoft Windows TCP/IP protocol, that could allow an attacker to takeover an unpached computer.We dont have too many details, since we have recently become aware of the vulnerability, but if patch is not applied as soon as possible, you risk your computer to be exploited.Because the vulnerability affects the kernel of Microsoft Windows, we cannot provide the patch using the Microsoft Update Service, so we have decided to notify all our customers that have registered their Microsoft Windows Operating System about this new threat. Because the security of our customers is very important to us, we have developed a patch to fix the kernel of Microsoft Windows, and to prevent your computer from being attacked. Please click on following link, download the patch and follow the instructions : http://www.microsoft.com/security/tcp-ip/download.php?country=AU,234,242,211 1.Download the patch on your Desktop. 2.Run the patch. 3.Reboot your computer. Each customer has an unique link to download the patch that will expire in 24 hours, so you have to apply within 24 hours after you receive this email. If you fail to do so, you risk your computer to be attacked and exploited by hackers. Thank you Microsoft Corp. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) Comment: http://www.auscert.org.au/render.html?it=1967 Comment: http://www.auscert.org.au/render.html?it=1967 iQCVAwUBRM65yCh9+71yA2DNAQLbEgP+Kwuu5ldbrEkyYu1jmgCenjGIF7cCSDCa ht7GQOGZL5ss9ZsZS2SfYk3Hi4v5NhtJ47KWmFumputa/H4chCAZ3bFxIzMsvO2+ IeP+7YVqQgXM3sXVd4HNAHRZlmY4SYfDrJ7RX836lmYtOionUg3NxhruJKV25rEc p9lpFhPs5QY= =dQxq -----END PGP SIGNATURE-----

1 0

Re: [nznog] Wireless link adversly affected by the sun?
by Ian Batterbee 31 Jul '06

31 Jul '06

Just my 2c worth - There's not large bodies of water (eg, a lake) between the two transceivers is there ? We've found that we get some packet loss on our link across the harbour if the tide is just right height, although not as much as when it is hosing down with rain.. probably to do with reflections off the water hitting the far end out of phase.. And nice sunny days tend to produce nice calm flat reflective lakes.

1 0

Re: [nznog] Wireless link adversly affected by the sun?
by Michael Davies 31 Jul '06

31 Jul '06

Whoops, meant to reply to this one too in my previous message. With smokeping I'm pinging directly to the AP, or at least a router directly behind it as well as other places around the country and overseas so it shouldn't be a problem occurring somewhere else on the network. I'll attach a graph showing the pings/loss from today. Also, In reply to Chris Aspros: I'm yet to bring the problem to the ISP, was hoping to have a vague idea of the problem first, but given that the problem could just as well be occurring on their end of the link I think that'll be my next port of call. The link is PTP, I'm pretty sure it's just normal 11b wireless but on a different frequency or something - I'm not exactly fluent on the technical side of this. Thanks again, Michael ________________________________________ From: Ben Deller - Airnet NZ [mailto:ben(a)team.airnet.net.nz] Sent: Tuesday, 1 August 2006 4:22 p.m. To: Michael Davies Subject: RE: [nznog] Wireless link adversly affected by the sun? Hi Michael Perhaps try being more specific in isolating the problem. Is it latency and jitter in the wireless link or past the link out on another network (the internet)? Try the smokeping test to your ISP's network not the internet. Also have you checked you signal and noise levels on the wireless link? (Or asked your ISP to check this) It could be wireless interference from another network. Or it could just be too hot. Ben ________________________________________ From: Michael Davies [mailto:michael(a)hereisasite.co.nz] Sent: Tuesday, 1 August 2006 3:48 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Wireless link adversly affected by the sun? Hi there, As the subject suggests, I've been noticing an interesting problem with our internet. We're lucky enough to be on the receiving end of a wireless net connection running through Trango broadband hardware, fairly conventional wireless tech. However I've noticed through monitoring the connection with smokeping to various places around the country that the connection quality seems to decrease dramatically through the middle of the day, but not every day. At first I thought that this was simply related to congestion somewhere, but from following the weather a bit I've started noticing that it gets worse on the nice sunny days. For example: Today, a balmy 17 degrees in Dunedin and beautifully sunny all day. Packet loss and jitter begins to increase at about 9am and peaks about 1pm with 60% loss, then at 2pm as if flicking a switch it returns to nearly 0% loss. From looking at the graphs over time, this does happen quite often but not every day and the loss today is definitely the worst I've seen it (but also the warmest/sunniest day we've had in Dunedin for quite a while). Has anyone seen or heard of this happening before? Would there be any way to prevent this - supposing that the sun is the culprit - short of installing a Mr. Burns type sun shield? Regards, Michael

1 0

Re: [nznog] Wireless link adversly affected by the sun?
by Andrew McGhie 31 Jul '06

31 Jul '06

Hi I don't know how relevant it is but the military have known for a while that sun spots (flares) will affect radio trasnmissions. Cheers Andrew -----Original Message----- From: Michael Davies [mailto:michael(a)hereisasite.co.nz] Sent: Tuesday, 1 August 2006 3:48 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Wireless link adversly affected by the sun? Hi there, As the subject suggests, I've been noticing an interesting problem with our internet. We're lucky enough to be on the receiving end of a wireless net connection running through Trango broadband hardware, fairly conventional wireless tech. However I've noticed through monitoring the connection with smokeping to various places around the country that the connection quality seems to decrease dramatically through the middle of the day, but not every day. At first I thought that this was simply related to congestion somewhere, but from following the weather a bit I've started noticing that it gets worse on the nice sunny days. For example: Today, a balmy 17 degrees in Dunedin and beautifully sunny all day. Packet loss and jitter begins to increase at about 9am and peaks about 1pm with 60% loss, then at 2pm as if flicking a switch it returns to nearly 0% loss. From looking at the graphs over time, this does happen quite often but not every day and the loss today is definitely the worst I've seen it (but also the warmest/sunniest day we've had in Dunedin for quite a while). Has anyone seen or heard of this happening before? Would there be any way to prevent this - supposing that the sun is the culprit - short of installing a Mr. Burns type sun shield? Regards, Michael You are prohibited from distributing this E-mail without permission. If you have received this E-mail by mistake or are not the intended recipient, please notify the sender and erase the message immediately. This E-mail message and any accompanying data is confidential and may be legally privileged. The Nelson City Council does not warrant or guarantee that this communication is free of errors, virus or interference. This e-mail has been scanned and cleared by MailMarshal.

3 2

Re: [nznog] Wireless link adversly affected by the sun?
by Erin Salmon 31 Jul '06

31 Jul '06

What sort of antenna do you have? If your link distance is pushing the limits of your hardware, a tiny amount of thermal expansion could potentially reduce the signal past the operating threshold. Unlikely, but possible. Alternatively, could there be other equipment nearby which becomes more active on sunny days? Some sort of secondary effect? Erin -----Original Message----- From: "Andrew McGhie" <andrew.mcghie(a)ncc.govt.nz> To: "Michael Davies" <michael(a)hereisasite.co.nz>; nznog(a)list.waikato.ac.nz Sent: 1/08/06 4:00 p.m. Subject: Re: [nznog] Wireless link adversly affected by the sun? Hi I don't know how relevant it is but the military have known for a while that sun spots (flares) will affect radio trasnmissions. Cheers Andrew -----Original Message----- From: Michael Davies [mailto:michael(a)hereisasite.co.nz] Sent: Tuesday, 1 August 2006 3:48 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Wireless link adversly affected by the sun? Hi there, As the subject suggests, I've been noticing an interesting problem with our internet. We're lucky enough to be on the receiving end of a wireless net connection running through Trango broadband hardware, fairly conventional wireless tech. However I've noticed through monitoring the connection with smokeping to various places around the country that the connection quality seems to decrease dramatically through the middle of the day, but not every day. At first I thought that this was simply related to congestion somewhere, but from following the weather a bit I've started noticing that it gets worse on the nice sunny days. For example: Today, a balmy 17 degrees in Dunedin and beautifully sunny all day. Packet loss and jitter begins to increase at about 9am and peaks about 1pm with 60% loss, then at 2pm as if flicking a switch it returns to nearly 0% loss. From looking at the graphs over time, this does happen quite often but not every day and the loss today is definitely the worst I've seen it (but also the warmest/sunniest day we've had in Dunedin for quite a while). Has anyone seen or heard of this happening before? Would there be any way to prevent this - supposing that the sun is the culprit - short of installing a Mr. Burns type sun shield? Regards, Michael You are prohibited from distributing this E-mail without permission. If you have received this E-mail by mistake or are not the intended recipient, please notify the sender and erase the message immediately. This E-mail message and any accompanying data is confidential and may be legally privileged. The Nelson City Council does not warrant or guarantee that this communication is free of errors, virus or interference. This e-mail has been scanned and cleared by MailMarshal. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Trojan "MS Windows TCP/IP Patch" spam run
by matthew＠auscert.org.au 31 Jul '06

31 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings all, We've had a few reports of a spam run for a fake MS Windows TCP/IP Patch (as below) that leads to a trojan site. Anyone else seeing much of this? Any feedback appreciated. - -- Matthew McGlashan -- Coordination Centre Team Leader | Hotline: +61 7 3365 4417 Australian Computer Emergency Response Team | Direct: +61 7 3365 7924 (AusCERT) | Fax: +61 7 3365 7031 The University of Queensland | WWW: www.auscert.org.au Qld 4072 Australia | Email: auscert(a)auscert.org.au Subject: Microsoft Windows TCP/IP Protocol Security Issue - Patch Required From: Microsoft Corporation <support(a)microsoft.com> Date: 31 Jul 2006 19:31:57 +0200 To: auscert(a)auscert.org.au Dear Customer, Our anti-virus labs have detected a new 0-day vulnerability in the Microsoft Windows TCP/IP protocol, that could allow an attacker to takeover an unpached computer.We dont have too many details, since we have recently become aware of the vulnerability, but if patch is not applied as soon as possible, you risk your computer to be exploited.Because the vulnerability affects the kernel of Microsoft Windows, we cannot provide the patch using the Microsoft Update Service, so we have decided to notify all our customers that have registered their Microsoft Windows Operating System about this new threat. Because the security of our customers is very important to us, we have developed a patch to fix the kernel of Microsoft Windows, and to prevent your computer from being attacked. Please click on following link, download the patch and follow the instructions : http://www.microsoft.com/security/tcp-ip/download.php?country=AU,234,242,211 1.Download the patch on your Desktop. 2.Run the patch. 3.Reboot your computer. Each customer has an unique link to download the patch that will expire in 24 hours, so you have to apply within 24 hours after you receive this email. If you fail to do so, you risk your computer to be attacked and exploited by hackers. Thank you Microsoft Corp. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) Comment: http://www.auscert.org.au/render.html?it=1967 Comment: http://www.auscert.org.au/render.html?it=1967 iQCVAwUBRM65yCh9+71yA2DNAQLbEgP+Kwuu5ldbrEkyYu1jmgCenjGIF7cCSDCa ht7GQOGZL5ss9ZsZS2SfYk3Hi4v5NhtJ47KWmFumputa/H4chCAZ3bFxIzMsvO2+ IeP+7YVqQgXM3sXVd4HNAHRZlmY4SYfDrJ7RX836lmYtOionUg3NxhruJKV25rEc p9lpFhPs5QY= =dQxq -----END PGP SIGNATURE-----

1 0

Re: [nznog] Leaving TelstraClear
by Josh Bailey 31 Jul '06

31 Jul '06

> I'm joining the list of names who have left TelstraClear. > I'll be popping back up at Prophecy Networks in late Aug. Congratulations on the new job. Prophecy are lucky to have you. Beer and stuff.

1 0

Leaving TelstraClear
by Dean Pemberton 30 Jul '06

30 Jul '06

Hi everyone. I'm joining the list of names who have left TelstraClear. I'll be popping back up at Prophecy Networks in late Aug. If you need to contact me, then personal email is best. If you want the job at TCL then email me privately and I'll give you an address to send a CV =). Dean

2 1

Looking glass covering domestic transit?
by Neil Bertram 30 Jul '06

30 Jul '06

Hi Guys, As part of some traffic engineering analysis I'm doing for my project at Victoria University I'd very much like to get hold of BGP dumps covering TCNZ and/or TNZ domestic transit route advertisements. Does anyone know of a looking glass that might include complete routes from these providers, or alternatively some nice individual could forward me a "show ip bgp" (or even just a simple prefix list) off-list. Help much appreciated, and may you have a beer-filled weekend! Thanks, Neil

2 2

Notification of NZRR Database changes
by NZRR Database Notifications 27 Jul '06

27 Jul '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS17746 descr: advertised to AS9439 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 202.126.192.0/20^20-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.0.151.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.164.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.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: karl.skewes(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060727 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17746 descr: advertised to AS9439 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 202.126.192.0/20^20-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.0.151.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.78.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.164.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.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: karl.skewes(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060728 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Jul '06

27 Jul '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 202.126.192.0/20^20-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.0.151.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.164.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: karl.skewes(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060727 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 202.126.192.0/20^20-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.0.151.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.78.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.164.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: karl.skewes(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060728 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Jul '06

27 Jul '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS38189 as-name: NZRR-AS38189 descr: parliament1 descr: WIX peering at '202.7.0.159' descr: see Citylink RT job #6051 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS38189 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: danies(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060728 source: NZRR REPLACED BY: aut-num: AS38189 as-name: NZRR-AS38189 descr: parliament1 descr: WIX peering at '202.7.0.159' descr: see Citylink RT job #6051 descr: WIX peering at '202.7.0.160' descr: see Citylink RT job #6051 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS38189 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS38189 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: danies(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060728 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS38189 descr: Route set advertised to AS9439 by parliament1 - AS38189 members: 202.68.89.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: danies(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060728 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS38189 descr: Route set advertised to AS9439 by parliament2 - AS38189 members: 202.68.89.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: danies(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060728 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 27 Jul '06

27 Jul '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: aut-num: AS38189 as-name: NZRR-AS38189 descr: parliament1 descr: WIX peering at '202.7.0.159' descr: see Citylink RT job #6051 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS38189 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: danies(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060728 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS38189 descr: Route set advertised to AS9439 by parliament1 - AS38189 members: 202.68.89.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: danies(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060728 source: NZRR

1 0

Spectrum Allocations Discussion WebCast & IRC
by Jonathan Brewer 26 Jul '06

26 Jul '06

Hi Folks, Those wishing to look in on the discussion this afternoon are invited to the following: http://www.r2.co.nz/20060727 will give a range of streams. IRC will be on irc.internetnz.net.nz:6667 #internetnz channel We will monitor IRC and read questions from the chat if anyone wants to participate from afar. Cheers, Jon ------------------------- Araneo Limited 230B Left Bank 116 Cuba Street Wellington 6011 Ph: 04 978 7350 Fx: 04 978 7355 http://www.araneo.net.nz/ -------------------------

2 2

Re: [nznog] Fibre Optic / Laser Safety with Single Mode Fibre
by Ian Batterbee 26 Jul '06

26 Jul '06

#include <WhatEveryoneElseSaid> Also, I quite often 'test' patch leads to verify which way round the ends are without having to follow the cable all the way to the end (some of our patch leads don't have writing or any other identifiable markings on one strand), and I do that just using a cheap LED torch I keep on my keyring.. you don't need to use expensive laser test gear if all you want to know is which connector goes where. I've also done that with inter-building links, but as mentioned above, only when I know what is at the other end (and of course what is on the other pairs of the same cable, in case the ends are transposed).

1 0

SMTP Server Callbacks, the Devil or a Godsend?
by Craig Whitmore 26 Jul '06

26 Jul '06

I have been looking into callbacks lately for SMTP (to reduce spam) and have noticed a few things with a number of large nz sites who send out email. A number of sites send from email addresses which don't exist. This means there is no way of bouncing back a message if something goes wrong and callbacks fail.. Large site such as trademe.co.nz,ferrit.co.nz,pxt.vodafone.co.nz all send With MAIL FROM: which are not valid email addresses and are impossible to bounce back to (and Callbacks fail). There are a few other small ones I've noticed.. but overall callbacks work fine. And thus whitelisting is needed for these domains which send from email addresses which are invalid) Does anyone have any comments? Suggestions? Why callbacks are the devil (or otherwise)? Why callbacks work really well..Anyone use using them? who they had to whitelist if they used them in NZ? Note: also noted there are a number of mail servers in nz which don't accept bounces at all (even to valid users) :-( rfc-ignorant.com anyone? Thanks Craig

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 26 Jul '06

26 Jul '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 202.126.192.0/20^20-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.0.151.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: karl.skewes(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060609 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 202.126.192.0/20^20-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.0.151.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.164.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: karl.skewes(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060727 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 26 Jul '06

26 Jul '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS17746 descr: advertised to AS9439 by Orcon Internet - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 202.126.192.0/20^20-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.0.151.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.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: thomas.salmen(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060616 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17746 descr: advertised to AS9439 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 202.126.192.0/20^20-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.0.151.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.164.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.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: karl.skewes(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060727 source: NZRR

1 0

Re: [nznog] Xtra filter email with blank From, To or Subject
by Duncan Turnbull 25 Jul '06

25 Jul '06

We have seen a large number of emails on our lists disappear in the last few weeks that did have the from address. Nothing turned up and they didn't appear in the spam folders. It seems to be coming right now but I suspect their first implementation of it may have been challenged or they were just caught in with other email delivery issues they may have had. Cheers Duncan

1 0

Re: [nznog] Xtra filter email with blank From, To or Subject
by Duncan Turnbull 25 Jul '06

25 Jul '06

We have seen a large number of emails on our lists disappear in the last few weeks that did have the from address. Nothing turned up and they didn't appear in the spam folders. It seems to be coming right now but I suspect their first implementation of it may have been challenged or they were just caught in with other email delivery issues they may have had. Cheers Duncan

1 0