- NZNOG - lists.nznog.org

Multicast in NZ FAQ
by Lennon - Orcon 30 Jan '05

30 Jan '05

Hi Folks.. I have updated a little my "Multicast in NZ" FAQ (http://www.mbone.net.nz) My Wish (Yes I'm dreaming) is get all networks multicast enabled so as people can start to broadcast the content on the net in NZ and if a customer asks, "can I do it" you say "Yes I can". With UBS and Wireless it is possible to get the content out there ,and in the future, if higher speed connections are available which are multicast enabled, Video and other content can get to the customers with people want to see. Yes I know there is no content yet (maybe the big hurdle in people wanting to set it up on their network), but maybe ISP's/Other network providers will want to start to release some content (Radio Stations/Television Stations/Other Content providers) If anyone want to give any suggestions or help, please let me know.. I need some examples of how other people (if anyone else) is setting up their equipment (Like Cisco L2TP termination for UBS etc) which can be put out to other people interested. Thanks Craig

1 0

RE: [nznog] backscatter attack
by Regan Murphy 28 Jan '05

28 Jan '05

"James Riden" writes: >It's best to do SMTP rejects for unknown users; this will >help cut the load on your servers if the forged From addresses >don't exist at your domain. This is relatively straightforward >for most MTAs - I believe postfix can do LDAP queries >against AD, or can talk to a postgresql database. Since >most of the forged addresses will be nonexistent, this should >help quite a bit. >(Bonus - it will also stop you generating this kind of traffic >for other sites in the future.) My mail domain is relatively small - about 40 real users - but I still drop about 1500 mail connections a day for email sent to invalid users. About 200 of these were typically virus initiated (and therefore had attachments) and almost all the rest were spam. My MTA is Mailmarshal and it can easily be configured to do this. You can set up LDAP or Active Directory connectors to hook into your directory servers which makes managing the lookup lists simple. And before I hear cries of "argh, not mailmarshal again..." Its configured so that is does *not* send outbound notifications for viruses etc. -- Regan

2 1

PGP Key Signing at NZNOG 2005
by Joe Abley 28 Jan '05

28 Jan '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We're going to engage in a frenzy of PGP keysigning at the NZNOG meeting in Hamilton. People who know what PGP stands for should read on. People who don't know what PGP is are more than welcome to ask me off-list, or alternatively ask Google (who at least knows people who know). Here's what we will attempt to do for the meeting next week: 1. As soon as you can, generate an ASCII-armoured copy of your public key and paste it into the convenient form here: http://www.biglumber.com/x/web?keyring=5468 Consult your PGP software's documentation to find out how to generate an ASCII-armoured copy of your public key. With GnuPG you use "gpg -a - --export <your-key-id>". You're looking for a block of ASCII text which begins with the line "-----BEGIN PGP PUBLIC KEY BLOCK-----". 2. Before you set off to the NZNOG meeting, remember two things: 2.1. BRING PHOTO ID. Key signing is a process of representing trust, and if you are interested in getting signatures on your key (and you're reading, so presumably you are) you should be ready to provide proof of your identity to other people. Drivers licences, passports, things of that nature. BRING PHOTO ID. 2.2. BRING A TRUSTED COPY OF YOUR PGP KEY FINGERPRINT. This could be achieved by bringing a laptop with a trusted copy of your public key on it, or alternatively you could generate the fingerprint of your public key, write it down and bring the bit of paper with you. BRING A TRUSTED COPY OF YOUR PGP KEY FINGERPRINT. The precise procedure we use at the key signing party will depend on how many keys are uploaded in the next week; if there's a small handful we can read signatures aloud -- if there are more, we can try Len Sassaman's efficient key signing method (<http://sion.quickie.net/keysigning.txt>). I'll send more words on this closer to the time. Thanks! Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFB+bVj/f+PWOTbRPIRAi5jAJ93/s+kA1HJnO82JxCqwhAj2mniPQCcC72i uxmFZl1QTdi4ZMk5AXa5u5k= =6Rnh -----END PGP SIGNATURE-----

2 2

Telecom
by Garrett Stoupe 27 Jan '05

27 Jan '05

Is it possible anyone from telecom to contact me off list in regards towards the proxy servers that Telecom uses Garrett Stoupe Network And Database Administrator Cabbage Tree Press garretts(a)te.co.nz www.te.co.nz www.jobzone.co.nz www.nzcarbuys.co.nz

3 2

IANA IPv4 allocations and bogon update: 124/8, 125/8 and 126/8
by Rob Thomas 27 Jan '05

27 Jan '05

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

1 0

Nznog travel
by Scott Walsh 27 Jan '05

27 Jan '05

Hi All, I've driving down to Hamilton for nznog early Wednesday morning (leaving by 6:30) and returning Friday pretty much right the conference close. If anyone would like a ride, get in touch. Thanks Scott Walsh Service Implementation Specialist Integrated Technology Services (ITS) - Passionate about Winning IBM New Zealand Limited

2 1

Nznog dinners
by Lin Nah 26 Jan '05

26 Jan '05

Hi All I am organising the dinners on Wednesday 2 February and Friday 4 February. It won't be anything as organised as the Thursday dinner! It is definitely NOT part of the conference and so a. You have to pay for your own meal, and, b. attendance isn't limited to ppl attending the meet Please read the page about the dinners and if you wish to attend, give me an indicative reply Page on dinners: http://www.nznog.org/curry_about.php Look forward to seeing you there. regards lin Auckland Thursday Night Curry http://auckland.thursdaynightcurry.com

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 26 Jan '05

26 Jan '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS9503 descr: Route set advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-27, 161.29.0.0/16^16-27, 161.65.0.0/16^16-27, 192.88.85.0/24^24-27, 192.133.31.0/24^24-27, 202.36.226.0/24^24-27, 202.37.86.0/23^23-27, 202.49.80.0/23^23-27, 202.50.52.0/22^22-27, 202.50.196.0/22^22-27, 202.50.200.0/21^21-27, 202.50.208.0/20^20-27 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050127 source: NZRR

1 0

Slightly OT: Petition to ban someone from the 'net
by Matthew Poole 25 Jan '05

25 Jan '05

Now, I'll preface this by saying that I'm almost certain it's bovine excrement. But once you involve politicians, anything's possible. A friend of a friend (yeah, one of those stories) has raised with him the suggestion that NZ has some system to petition to have someone permanently banned from the Internet. This notional petition only requires 50 signatures. Can anyone confirm such a beast? I imagine there will be peals of laughter accompanying the reading of this e-mail, and I'll be stunned if someone says it does actually exist, but there's no harm in asking the group of people most likely to know. -- Matthew Poole "Don't use force. Get a bigger hammer."

7 7

Two low-severity BIND security advisories (BIND 8, BIND 9)
by Joe Abley 25 Jan '05

25 Jan '05

Advisories for BIND 9 and BIND 8 follow. Note that BIND 9 is only vulnerable if the DNSSEC validator is turned on (it's off by default). Begin forwarded message: > From: Mark Andrews <Mark_Andrews(a)isc.org> > Date: 26 January 2005 17:55:48 GMT+13:00 > To: bind-announce(a)isc.org > Subject: Internet Systems Consortium Security Advisory: BIND: Self > Check Failing > > > Internet Systems Consortium Security Advisory. > BIND: Self Check Failing > 18 November 2004 > > Versions affected: > BIND 9.3.0 > Severity: LOW > Exploitable: Remotely > Type: denial of service > Description: > > An incorrect assumption in the validator (authvalidated) > can result in a REQUIRE (internal consistancy) test failing > and named exiting. > > Workaround: > > Turn off dnssec validation (off by default) at > the options/view level. > > dnssec-enable no; > > Fix: > > Upgrade to BIND 9.3.1 > http://www.isc.org/sw/bind/ > > See also: > http://www.kb.cert.org/vuls/id/938617 Begin forwarded message: > From: Mark Andrews <Mark_Andrews(a)isc.org> > Date: 26 January 2005 17:54:31 GMT+13:00 > To: bind-announce(a)isc.org > Subject: Internet Systems Consortium Security Advisory: BIND: Buffer > Overrun (q_usedns). > > > Internet Systems Consortium Security Advisory. > BIND: Buffer Overrun (q_usedns). > 17 November 2004 > > Versions affected: > BIND 8.4.4 and 8.4.5 > Severity: LOW > Exploitable: Remotely > Type: denial of service > Description: > > It is possible to overrun the q_usedns array which > is used to track nameservers / addresses that have > been queried. > > Workaround: > > Disable recursion and glue fetching. > > Fix: > > Upgrade to BIND 8.4.6 > http://www.isc.org/sw/bind/ > > See also: > http://www.kb.cert.org/vuls/id/327633

2 1

RE: [nznog] Slightly OT: Petition to ban someone from the 'net
by Donald Neal 25 Jan '05

25 Jan '05

> -----Original Message----- > From: Antonio Broughton [mailto:anacarda(a)flerwin.net] > Sent: Wednesday, 26 January 2005 10:58 a.m. > To: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Slightly OT: Petition to ban someone > from the 'net > > Matthew Poole wrote: > > That's exactly what I thought. Not to mention that you could get 50 > > signatures simply by standing on the corner of Queen St and > Wellesly St at > > lunchtime. > > This person is apparently adamant (aren't they all?) that > such a thing > > exists. To the point that she's out seeking further details. > > > > ahhh there we go then... a female... 'nuff said... :) I think we can leave that thread there. - Donald Neal NZNOG Liat Administrator/Muggins Donald Neal |A prophecy is a guess that comes Technical Specialist |true. If it doesn't come true, it's NGN Operations |a metaphor. - G'Kar, Babylon 5 Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

2 1

How to stop spam
by Juha Saarinen 25 Jan '05

25 Jan '05

http://www.circleid.com/article/917_0_1_0_C/ Some interesting discussion there. -- Juha

2 1

HEADS UP - Upcomming Webcasting Activity
by Richard Naylor 24 Jan '05

24 Jan '05

Next week is the 2005 Premiere Yearling Sale and the event will be webcast live. The dates are Monday 31 Jan through to Friday 4 Feb inclusive. 1000Hrs to 1700Hrs There will be test streams running on Sunday 30 Jan at various times (ie when we get it going). The event web site is www.nzb.co.nz, with the streams originating from R2.co.nz - There will be 5 bit rates (streams) so that users get a choice of stream quality, affordability, etc. The webcast will include the Select Yearling Sale (ie cheaper horses), which is the thursday and friday. At this stage, the Festival Yearling Sale (ie even cheaper horses), on Sunday and Monday 6, 7 February, is *NOT* being webcast. These events are not huge in terms of viewer numbers, but with large sums of money involved ISP Help Desks may receive a few calls from "excited" clients, needing to watch in a hurry etc. (About $60M changes hands during the event - must put my hand out....) The event web page at R2 is http://www.r2.co.nz/20050131 details of the streams etc will be available on that page. The Premiere Sale (first 3 days) is also broadcast on Trackside TV, and SkyTV. Thanks you for your assistance; I hope there aren't too many calls for you. Richard

1 0

Philip Hazel public presentation
by Craig Box 24 Jan '05

24 Jan '05

Hi everyone, As Philip Hazel is in town for the NZNOG conference, the Waikato Linux Users Group have arranged for him to present a public meeting the night before his tutorial (1st February). The talk is entitled "Exim and PCRE: How free software hijacked my life" [1]. Philip will present a non-technical talk on the history of the Exim and PCRE software projects, how they got started, where they are now, and where they are currently going. We thank the NZNOG conference for sponsoring Philip to NZ, but attendance at NZNOG isn't required for attending this talk, so I figured some people here might be interested or know people who are (especially if they were going to a different tutorial). The meeting will start at 7:30pm, in the LitB[2] building at Waikato University. All are welcome, although non members are encouraged to make a gold coin donation. Tea/coffee/biscuits/juice will be provided after the meeting. Hamilton is only a short amble from Auckland and is lovely this time of year. For those unfamiliar with the WLUG, especially people involved in Linux support or administration, you might like to check our wiki out at http://www.wlug.org.nz/. Regards, Craig Box Waikato Linux Users Group Secretary [1] For more information on Philip and the meeting, see http://www.wlug.org.nz/MeetingTopics.2005-02-01 [2] For a map, see http://www.wlug.org.nz/LitB

1 0

Virus Filtering by ISPs vs the need to receive security/abuse traffic
by Mark Foster 21 Jan '05

21 Jan '05

This is one that i've come across from time to time and often pondered myself - Obviously virus traffic can fluctuate up and down and become an annoyingly high percentage of an ISPs total mail load. Thus AV filtering which drops these messages is beneficial and can be provided as a benefit to customers, etc... So what happens to role accounts like, heaven forbid, abuse@ ? And for that matter, if the messages are dropped, is there any logged trace of the fact the message was sent in the first place? The reason I ask is that i've seen at least one ISP to whom i've reported viral infections to recently actually reject the report, because of the 'illegal file attatchment' (where the criteria used was the file extension... not even viral code within the attatchment)... So I had to manually copy/paste headers only to get my point across. The argument can be made that headers are all thats required, and that the actual payload isnt needed - but what if theres occaision where you want said payload? (To provide actual evidence of the infection, to identify what variant of the virus is infected, to help build filters ...?) Do ISPs out there regularly exclude their security team or at least build in means for one-off exceptions on an as-required basis? Do ISPs that drop viral (or suspected viral) traffic do anything to report said infection, or do they just drop the virus and pretend it never happened? (Doesn't actually fix the problem, does it...) Appreciate your thoughts. Mark.

4 5

I guess somebody needs a Beer.
by Simon Lyall 20 Jan '05

20 Jan '05

Sounds like a few people out there had a rough few days. I found this linked at the top of the paradise homepage. http://www2.paradise.net.nz/security_update/news.html Security Update Security issue - email and web hosting A small number of Paradise.net customers may have have experienced email delays and web-hosting problems on Thursday January 20th and Friday January 21st. Early Thursday morning some Paradise email was delayed. Our security people detected a security threat and disconnected a server to preserve the integrity of Paradise.net. This server will be reconnected shortly and backlogged email should be delivered this afternoon (Friday January 21). As part of our security precautions we also disconnected hardware which hosts Paradise web pages. We have been working round the clock to ensure the hardware can be reconnected with no risk to Paradise.net or Paradise users. We expect to restore web pages this evening. We know that an external party has attempted to interfere with Paradise.net. This attempt was picked up and immediate steps were taken to avoid any further impact on Paradise.net customers. Please accept our apologies for any inconvenience these very necessary steps have caused. Our approach, as always, is to take firm steps to preserve the security of Paradise.net and protect our customers. the team at Paradise.net -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

2 1

Mystery compound in beer fights cancer
by Andy Linton 20 Jan '05

20 Jan '05

Seems that research into this topic is warranted at NZNOG. http://www.newscientist.com/article.ns?id=dn6895

6 7

Notification of NZRR Database changes
by NZRR Database Notifications 20 Jan '05

20 Jan '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Fri, 21 Jan 2005 13:15:27 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0501211313160.7621(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW DELETED: route-set: AS9439:RS-ROUTES:AS23959 descr: Route set advertised to WIX by Catalyst-IT - AS23959 members: 202.49.159.0/24^24-29, 202.46.190.0/24^24-29, 202.20.6.0/24^24-29, 203.167.212.32/29, 203.167.247.160/29, 202.7.4.64/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: andrew(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040120 changed: rpsl-admin(a)nzix.net 20040628 source: NZRR

1 0

RE: [nznog] National BGP routing
by Gordon Smith 19 Jan '05

19 Jan '05

> Why are inconsistent AS-paths bad? Operationally, I mean. (I > hadn't had any operational mishaps in all my years at UUNET > because of inconsistent AS-paths, so I'm wondering if > something else causes an issue now?) > > Technically there is nothing wrong with them. As you > observed, it's simply an organisation multihoming using a > private ASN - hopefully their upstreams are stripping out the > private ASN before they propogate the originated prefixes > further. (Mind you, I find it rare for two ISPs to agree > which private ASN to use for a mutual customer to multihome - > often so much easier to obtain a real one.) > > And yes, people can quite easily use public ASNs. It's simply > a case of an APNIC member obtaining an ASN so their customer > can multihome. And that can't be too hard, right? > > philip > -- > Hi Philip, You're quite right. Technically, you can still be pass traffic to the client's endpoint, although the path selected may not be optimal. What can cause issues is if you then start creating routing policies on your route reflectors based on AS-path, especially if you don't have a direct peer with both of the providers that are carrying that customer's traffic. With multiple peering points, you can end up backhauling the traffic over your own links because the routing decisions passed via your IGP are no longer necessarily optimal e.g. I may wish to pass a 10Mbit stream from a Wellington customer to somewhere else in Wellington, via another provider, but the route reflectors see that destination as having a shorter AS path via Auckland. We don't have a destination AS that a metric can be applied to. We can of course apply different costs to the WAN links (and should have done), but the fine-grained control of traffic isn't achievable because the router can't be given much to go on. Policy routing and tagging is an option, but relies on the destination site, who is not necessarily a customer of ours, informing us of changes in their topology so our rules can be updated. APNIC have always been very good when it comes to getting ASN's; I've always found the justification of additional address space to be an ordeal though :-) In my opinion, it would be far more preferable if APNIC allocated an ASN when a customer was given an independent address assignment. After all, the reason that most want independantly allocated space is to multihome... Cheers, Gordon

3 2

National BGP routing
by Gordon Smith 18 Jan '05

18 Jan '05

I'm sure I can't be the only one that notices the BGP inconsistancies in their route tables.... Seeing the latest NZRR update prompted me to check the BGP tables again... We do not and will not accept route advertisements containing private AS numbers from our peers. The reason we don't is the same reason we don't route RFC1918 space externally... If a customer has their own address space and wants to multi-home, they should also have their own AS. Advertising up private AS numbers that should really remain within the network isn't a solution. Inconsistant AS-paths are bad enough, without creating additional problems... At least we're only seeing 5 class C's being advertised at the APE with inconsistant AS-paths at the moment. Perhaps BGP routing could be a topic for discussion at NZNOG 2005? Cheers, Gordon

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 18 Jan '05

18 Jan '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Wed, 19 Jan 2005 13:40:23 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0501191339480.4620(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS24226 descr: Route set advertised to AS9439 by Catalyst IT - AS24226 members: 202.46.190.0/24^24-29, 202.49.159.0/24^24-29, 202.20.6.0/24^24-29, 202.36.119.0/24^24-29, 210.48.47.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS24226 descr: advertised to AS9439 by Catalyst IT - AS24226 members: 202.20.6.0/24^24-29, 202.36.119.0/24^24-29, 202.46.190.0/24^24-29, 202.49.159.0/24^24-29, 202.78.240.0/21^21-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR --- PREVIOUS OBJECT: route: 202.20.6.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route: 202.20.6.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR --- PREVIOUS OBJECT: route: 202.36.119.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route: 202.36.119.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR --- PREVIOUS OBJECT: route: 202.46.190.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route: 202.46.190.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR --- PREVIOUS OBJECT: route: 202.49.159.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.zanetti(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041027 source: NZRR REPLACED BY: route: 202.49.159.0/24 descr: Route for Catalyst IT - AS24226 origin: AS24226 notify: rpsl-admin(a)nzix.net notify: netadmin(a)catalyst.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050119 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 18 Jan '05

18 Jan '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: rt(a)citylink.co.nz - Subject: [CityLink #1656] New Object for inclusion into the NZRR Route Registry (fwd) - Date: Wed, 19 Jan 2005 12:25:41 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0501191224520.4620(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: 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.101.112/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 20041209 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.101.112/28^28-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 20041209 source: NZRR

1 0

Xtra in the SpamHaus SBL
by Peter Macaulay 17 Jan '05

17 Jan '05

I don't know if anyone from Xtra reads this list - trying to get through to anyone who has even an iota of understanding about this type of thing by phone appears to be almost impossible. Xtra has managed to get itself into the SBL realtime blocklist - http://www.spamhaus.org/sbl/sbl.lasso?query=SBL22816 It appears that someone objected to some promotional material sent out by the "House of Travel" travel agent group and has ended up blocking them; this means that one of Xtra's MX (mail exchanger) servers is now blocked by anyone who uses the SBL as a spam filter. If anyone knows anyone at Xtra who can do something about this, could you pass this message on? It's probably inconveniencing a reasonably large number of people. The NZNOG list would be a good place to post this too, I suppose, but I'm not a subscriber. Cheers! -- David -- ------------------ David Harris -+- Pegasus Mail ---------------------- Box 5451, Dunedin, New Zealand | e-mail: David.Harris(a)pmail.gen.nz Phone: +64 3 453-6880 | Fax: +64 3 453-6612 Phrase found in a Soviet Russian-English language guide: "Flying in the TU-114 I felt myself excellently." _______________________________________________ members-discuss mailing list members-discuss(a)internetnz.net.nz http://listserver.internetnz.net.nz/mailman/listinfo/members-discuss -- *Peter Macaulay* /Executive Director/ *InternetNZ */Direct +64 4 495 2113 Skype petermacaulay Mobile +64 21 488 485 /

6 5

(OT) Getting to NZNOG '05
by Jeremy Naylor 16 Jan '05

16 Jan '05

Hey guys, For people who want to know about how to get to the NZNOG '05 conference, you might want to catch the Overlander train that Tranz Scenic run. There's 2 every day (1 from Wellington - Auckland & 1 from Auckland - Wellington). You can get more info about these trains if you want to on Tranz Scenic's web site, at: http://www.tranzscenic.co.nz/services/overlander.aspx Hope this helps. Thanks, -- Jeremy Naylor p: +64 21 374 689 e: jeremy.naylor(a)r2.co.nz w: http://www.r2.co.nz/~jeremy w: http://e-living.wellington.net.nz -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004

3 2

RE: [nznog] Alternative DSL?
by Philip D'Ath 16 Jan '05

16 Jan '05

VDSL switches are a good middle ground between Ethernet switches and DSLAMs ... _____ From: Richards, David [mailto:David.Richards(a)ccc.govt.nz] Sent: Monday, 17 January 2005 5:34 p.m. To: jon.brewer(a)araneo.net.nz Cc: nznog Subject: RE: [nznog] Alternative DSL? Any reason why you aren't thinking Ethernet? - Provided the distances are shot. An Ethernet switch is a lot cheaper than a DSLAM. -- David Richards, Senior Network Engineer IT Services Unit - 'Enabling people through technology' Christchurch City Council, New Zealand Phone: +64 3 941 8689 | Fax: +64 3 941 8989 | Mobile: +64 27 242 7689 email: David.Richards(a)ccc.govt.nz

1 0