July 2006 - NZNOG - lists.nznog.org

121.72.0.0/15 - outdated bogon lists
by David Robb 20 Jul '06

20 Jul '06

TelstraClear has recently been allocated 121.72.0.0/15 by APNIC. I'm aware that this range used to be covered by some bogon filters, so can I ask that people please check their bogon lists are up to date, or better yet make use of the BGP fed bogon list from the nice folks at cymru. Thanks, David

4 3

UCE from Catmail Auckland.
by Mark Karena 19 Jul '06

19 Jul '06

F.Y.I Thanks, -------------------------------------------- Mark Karena Administrator ENLIGHTEN HOSTING +64 7 853 6060 http://www.enlightenhosting.com <http://www.enlightenhosting.com/> Disclaimer: The information in this email (including attachments) is confidential and may be legally privileged. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email and destroy the message. If you are not the intended recipient, any use, disclosure, copying or distribution is prohibited and may be unlawful. _____ Received: from fep05.xtra.co.nz by mail.enlightenhosting.com (mail.enlightenhosting.com v5.5) with SMTP id HRQ38575 for <admin(a)enlightenhosting.com>; Thu, 20 Jul 2006 15:10:52 +1200 Received: from catserver ([219.89.206.1]) by fep05.xtra.co.nz with ESMTP id <20060720031047.FNTQ19334.fep05.xtra.co.nz(a)catserver> for <admin(a)enlightenhosting.com>; Thu, 20 Jul 2006 15:10:47 +1200 Reply-To: <brendon(a)catmail.co.nz> From: "CATMail - Brendon Udy" <brendon(a)catmail.co.nz> To: <admin(a)enlightenhosting.com> Subject: CATMail - Email Initiatives for Advertisers Date: Thu, 20 Jul 2006 15:11:31 +1200 Organization: CATMail Ltd Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAADOM8t4+jDZJsX/MLB34QHEBAJwBFoy83khLhWqks3sVUMkAAAAB KRAAABAAAAB9b7c91cI0T7OB31wgaXYAAQAAAAA=(a)catmail.co.nz> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0042_01C6AC0E.C8683530" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 thread-index: AcarqjLIVWeCIiH/R4O9//2WiwOyyg== Disposition-Notification-To: "CATMail - Brendon Udy" <brendon(a)catmail.co.nz> From: CATMail - Brendon Udy [mailto:brendon(a)catmail.co.nz] Sent: Thursday, 20 July 2006 3:12 p.m. To: admin(a)enlightenhosting.com Subject: CATMail - Email Initiatives for Advertisers Over 90% of business communication has become email and where is it all? Generally sitting in a variety of in-box's around the office which typically creates an information management system that has a lot of holes and doesn't allow for email supervision and overview. If this sounds at all familiar please take the time to read about CATMail. Established in Auckland, CATMail specialise in providing email solutions for advertisers nationwide. We see advertising as the key to any successful business and have put ourselves in a position to help the advertising industry help themselves. What does CATMail do? * It stores emails to job or customer files * It interfaces with Microsoft OUTLOOK * It shares emails across a network by job and date range * It creates email schedules by job and date range * It allows you to find any email in seconds * It automatically creates address books for each job or customer * The share file resides on the shared drive, so backups are simpler * It stores email in a readable format outside of Outlook * Email content and properties are not editable giving integrity to the content * It gives your staff tools to do their job more efficiently Why do I need CATMail? If your company is customer or job focused and use email as a traceable means of communication, it will open up new opportunities to improve team efficiency and management of email archives. Is it difficult to use CATMail? Its interface was designed to follow common Windows navigation habits, allowing a natural feel when using it. The simplistic design limits tasks to a matter of clicks. How Does CATMail Work? CATMail seamlessly integrates into Microsoft OUTLOOK. From a supplementary button embedded into the dashboard of OUTLOOK, individual users are offered a pull-down menu of active company jobs or customer files. Users simply select the relative job or customer file, click to confirm, and the email and its attachment are sent off for indexing and storage into the company's job directory and the CATMail database system. You now have the company email system working in the company's interest. All business emails (and their valuable email addresses) are now embedded into the CATMail database and can be accessed by all authorised staff. Please visit www.catmail.co.nz <http://www.catmail.co.nz/> to find out more information or ring (09) 574-5735 to organise a demo.

2 1

smartmailpro.co.nz
by Russell Fulton 17 Jul '06

17 Jul '06

Any know anything about this crowd? Their name has come up in connection with a spamming incident that we got involved with. >From the web site they could be a legit 'bulk mailer' (if that isn't an oxymoron) or bunch of ratbag spammers. I'd like to have some more information before we decide what to do next. Russell.

5 5

Re: [nznog] APE Route reflector stability
by Gordon Smith 17 Jul '06

17 Jul '06

I believe that Juniper users would be more likely to detect this issue first, since the default arp cache timeout on a Juniper is 20 minutes, as opposed to 240 minutes (4 hours) on a Cisco

1 0

Re: [nznog] APE Route reflector stability
by Thomas Salmen 16 Jul '06

16 Jul '06

> > Hi Thomas > > On Mon, Jul 17, 2006 at 06:26:25PM +1200, Thomas Salmen said: > > > As far as I know, proxy-arp is disabled under junos by default. Our > > peering at APE is done with M-series kit, and we didn't notice any > > issues. > > I wasn't suggesting that the Junipers were proxy-arping, rather that > when the Juniper gets two replies to an ARP broadcast it previously sent > (one from the legit MAC, and one from the proxy-arping MAC), it seems to > be a bit of a lottery which one the Juniper uses. I see; I didn't read your initial message properly - sorry for the mistake. If I recall correctly, some earlier versions of BSD would run into problems if a host received more than one response to an ARP who-has that it had issued. I know that FreeBSD at least was at some point vulnerable to ARP cache poisoning as well; this was a few years ago now. The fix for this particular problem utilized unicast ARP. There is possibly some link here; Junos is based on BSD. I can't find any further reference to this anywhere though. There are possibly some BSD-specific ways of tuning the ARP implementation on the Junipers, but if so it'd no doubt require low-level fiddling. All I can say is that we didn't notice any problems at the time; so I'm not going to play with my production routers too much :) If I do find out any more information I'll let you know; I'm quite interested in finding out myself, now. Cheers, Thomas

1 0

Re: [nznog] APE Route reflector stability
by Thomas Salmen 16 Jul '06

16 Jul '06

As far as I know, proxy-arp is disabled under junos by default. Our peering at APE is done with M-series kit, and we didn't notice any issues. http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-networ k-interfaces/html/interfaces-ethernet-config40.html This is for 7.5 code, which is fairly newish - it's possible there are issues when using older versions. On the E-series it's enabled by default: http://www.juniper.net/techpubs/software/erx/junose72/swcmdref-a-m/html/ i-commands204.html Cheers, Thomas > > Hi all. > > On Fri, Jul 14, 2006 at 07:56:44AM +1200, Gordon Smith said: > > > Would someone like to comment on what's happening with the APE route > > reflectors? The flap statistics I'm seeing are impressive - those > > servers got wings now? :-) > > This turned out to be caused by another ISP lighting up a new router and > > a) getting the netmask wrong > b) forgetting to disable proxy-arp > > So, those setting up new routers, especially Cisco kit that defaults to > turning proxy-arp on, "no ip proxy-arp" is your friend. > > An interesting observation is that of the ~40 active peers, only two > seemed to be adversely affected by the proxy-arp, and they're both > Juniper boxes. I'm wondering if Junipers may have a more trusting > approach to handling ARP replies than other kit. > > So, if anybody has bright ideas on ways that the ARP handling of > Junipers can be made a little more cynical (ie, something more like the > Linux handling where it does unicast ARP until the other end stops > responding, and then goes back to broadcast ARP, but something less > restrictive than static ARP entries), I'm all ears. > > Cheers > Si > >

2 1

APE Route reflector stability
by Gordon Smith 16 Jul '06

16 Jul '06

Would someone like to comment on what's happening with the APE route reflectors? The flap statistics I'm seeing are impressive - those servers got wings now? :-) Cheers, Gordon

2 2

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

13 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:AS24347 descr: Route set advertised to AS9439 by Intergen - AS24347 members: 202.126.80.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: dwayne.bace(a)intergen.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS24347 descr: advertised to AS9439 by Intergen Limited - AS24347 members: 202.46.160.0/20^20-29, 202.126.80.0/21^21-29, 202.49.144.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: dwayne.bace(a)intergen.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060714 source: NZRR

1 0

Re: [nznog] Procedure for handling a new spammer
by Scott Weeks 12 Jul '06

12 Jul '06

----- Original Message Follows ----- From: Justin Cook <skull(a)skull.co.nz> > I don't really think they were doing superlarge volume at > this point, just your usual commercial spammer who > desperately wants to appear legitimate. One piece of UCE is one too many. It's like someone throwing wet bull crap at you. One is too many. period. scott

6 5

Spectrum Allocations for Broadband Wireless Access
by Jonathan Brewer 11 Jul '06

11 Jul '06

Hi Folks, Last week our friends at the Ministry of Economic Development released a discussion paper on spectrum for broadband wireless. http://www.rsm.govt.nz/spp/bwa/discussion/index.html We'd like to see as many comments on this paper submitted to the MED as there are members of the ISP community. Our primary agenda is getting "mandatory deployment of services" attached to any future management rights and area licenses, so we don't see large players buying up huge blocks of spectrum and sitting on them. This has damaged the environment in New Zealand in the past, and needs to be stopped. "Managed Park" and "Light Licensing" are new ideas (to New Zealand) in the paper also very worthy of our consideration. Responses to this paper are due 4th August 2006, so please have a look now. If there is interest from the community, we would be willing to host a discussion in Wellington on these issues on Thursday, 27th July. Regards, Jonathan Brewer ------------------------- Araneo Limited 230 Left Bank 116 Cuba Street Wellington 6011 Ph: 04 978 7350 Fx: 04 978 7355 http://www.araneo.net.nz/ -------------------------

2 1