- NZNOG - lists.nznog.org

Re: Fw: [nznog] Rescue from alligators in the swamp
by Ewen McNeill 28 Nov '04

28 Nov '04

In message <Pine.LNX.4.56.0411281830110.22205(a)green.darkmere.gen.nz>, Simon Lyall writes: >Currently I can get a domain for less than $US 20 per year and that will >get injected in the "DNS routing table" of every provider in the world. >I fail to see why a block of IP addresses should cost more. (a) scarcity: the number of possible IP addresses (4 billion) is rather less than the number of possible domain names (37 ** 63 per name segment) (b) impact on other people's systems: a DNS delegation just sits quitely on a couple of DNS servers in a corner, minding its own business, until someone happens to ask about it; a prefix advertised into the global routing table ends up occupying space in every router in the world with a "full table" and being shuttled around between them fairly often. More DNS delegations means bigger hardware at Verisign (or whoever); more prefixes (eventually) means bigger hardware for all routers that make up the Internet. 2 ** 24 (all possible /24s advertised) is a big number, even at only 64 bytes per routing entry (2 ** 30 bytes of memory). (c) volume: a block of IP addresses consists of multiple addresses; at the US$1250/year mark, that's over 1000 usable addresses. If you were to get 1000 $20 domain names, it'd cost more than US$1250/year :-) (d) scale: the many millions of .com domain names pay for the registry; the few thousand APNIC members need to pay for APNIC to run With all that said, I do sympathise with those with smaller-than-/22 requirements for whom portability and/or the ability to multihome would be useful. And if there's some appropriate way that smaller applications can be fitted within APNIC's requirements it'd be worth considering. However my recollection of what the University of Waikato was doing was that it was largely making allocations along the lines of the proposed "national internet registry" -- at least from the point of view of those receiving the allocations -- and 10 years later, it didn't turn out quite as smoothly as one might have hoped. So if it is done some thought will need to be given as to how one will ensure the "portable" assignments will remain "portable" for an extended period of time. Ewen

3 4

Rescue from alligators in the swamp
by FX Networks 28 Nov '04

28 Nov '04

Given today's discussion about address space etc, FX Networks is prepared to allocate equivalent address space to any ISP that is affected by this policy. reply to this address offlist if you wish to stop using old swamp space.

12 16

Fw: [nznog] Rescue from alligators in the swamp
by Keith Davidson 28 Nov '04

28 Nov '04

I agree in principle with Joe, APNIC are pretty easy to deal with, and for any reasonable robuts requirer of numbers, the costs are hardly prohibitive at US$2,000 one-off, plus US$1,250 per annum. But I guess the argument is that some people have a class C or 2 that they pay nothing for currently and would like to continue to pay nothing. As I said in my previous email, InternetNZ would be happy to step up to the plate if there really is a need - but I doubt we'd be in the business of supplying free number blocks. Keith Davidson Joe Abley stated: > As far as I can see, it's APNIC's job, and they're doing it pretty well > already. > > There seem to be a lot of people assuming that APNIC are hard to deal with > (or that the policies are unreasonable) without ever having tried to deal > with them, or to find out what the policies actually are. > > The economics are pretty simple for ISPs and largish multi-homed > companies: you can pay the cost of renumbering every time you change > provider, or you can pay the membership fees at APNIC and obtain > provider-independent resources. Choose the option that suits your budget. > > Regardless of how much someone might think that every two-person company > deserves provider-independent address space, the unfortunate reality is > that this doesn't scale (and the problem is the routing system, not > address space scarcity). > > > Joe

6 6

Notification of NZRR Database changes
by NZRR Database Notifications 28 Nov '04

28 Nov '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the 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: Notification of NZRR Database changes (fwd) - Date: Mon, 29 Nov 2004 09:57:27 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0411290955550.12055(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW DELETED: route-set: AS9560:RS-ROUTES:AS5767 descr: Route set advertised to AS9560 by Xxx Ltd - AS5767 members: 222.43.45.0/22^22-27 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)lpnz.org mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041129 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 28 Nov '04

28 Nov '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the 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:AS5767 descr: Route set advertised to AS9560 by Xxx Ltd - AS5767 members: 222.43.45.0/22^22-27 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)lpnz.org mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041129 source: NZRR

1 0

Re: SPF and mail forwarding (was Re: [nznog] Sendmail Question)
by Ewen McNeill 27 Nov '04

27 Nov '04

In message <8AC558B6BC09CD42BCAF3C667E2A88CC0FC838(a)red.IFM.local>, Philip D'Ath writes: >Ewen McNeill writes: >>It would be very helpful if operators that provide a mail forwarding >>service (eg, just about every ISP that provides mail services) were to >>do the forwarding in a SPF-compatible manner. > >Wouldn't it be easier to just get those people using SPF that forward >through an ISP to include their ISPs server in the permitted list (which >is what we do)? Alas, this doesn't solve the problem except if you do what I resorted to doing -- for now anyway -- and say "the mail could come from any mail server I guess" ("?all" at the end of the SPF record). Why? To take an actual recent example, I host the Wellylug mailing list and website. The Wellylug website has a feature whereby users can subscribe to "meeting reminders", sent out by email shortly before the monthly meetings. usera(a)ispa was one address so subscribed. Unfortunately usera(a)ispa actually forwards mail to userb(a)ispb, without rewriting the envelope from address -- unknown to anyone else until the mail bounced because the SPF check failed (due to the message now coming from a mail server which wasn't in the SPF list for the domain in the envelope from). Given N subscribers to such a list, at M ISPs, the list of "mail servers the mail might come from" soon grows without bound, especially if one considers that the mail may be forwarded more than once (and yes, I encounter multiple forwards fairly often). As I said, this "what happens to forwarded mail" issue is the single biggest (and most contraversal) problem with SPF. And given that more sites are doing SPF checks it would be very helpful if more ISPs that provide mail forwarding services to their customers did so in a SPF-compatible way. Ewen PS: You might argue that users subscribing to such services should subscribe their final destination address, rather than one that forwards on to another account. However even ignoring the reasons why one might wish to subscribe an address the forwards somewhere else, the chances of all users acquiring such clue to do so seems... low.

2 1

SPF and mail forwarding (was Re: [nznog] Sendmail Question)
by Ewen McNeill 27 Nov '04

27 Nov '04

In message <001801c4d402$0e7ad2d0$0100000a(a)lennons>, "Lennon - Orcon" writes: >We have SPF and SRS implemented on our email servers and yes it does work. Unfortunately there are also a considerable number of systems (including in New Zealand) which forward mail without rewriting the envelope from address, which is required by SPF. This means that when the mail is forwarded it suddenly appears to be coming from a mail server that isn't authorised to send messages for that domain, which results in it being rejected and bounced back to the originator. I've had to relax the SPF statements for some of the domains that I manage in order to compensate for this problem (changing from "-all" to "?all" -- ie, "won't come from anywhere else" to "umm, I guess you might see it from some others too"). It would be very helpful if operators that provide a mail forwarding service (eg, just about every ISP that provides mail services) were to do the forwarding in a SPF-compatible manner. Something like procmail's approach (forward message on with envelope from of the account triggering the forward) is sufficient -- you don't have to do SPF's convoluted envelope from rewriting if you don't want to. I suspect this issue (mail forwarding) will continue to be the biggest obstacle to widespread SPF adoption for quite some time. Ewen

3 2

RE: SPF and mail forwarding (was Re: [nznog] Sendmail Question)
by Philip D'Ath 26 Nov '04

26 Nov '04

Wouldn't it be easier to just get those people using SPF that forward through an ISP to include their ISPs server in the permitted list (which is what we do)? In which case, it is more an issue of educating people who use SPF to include all servers, rather than getting every provider to change their email system. -----Original Message----- ... Unfortunately there are also a considerable number of systems (including in New Zealand) which forward mail without rewriting the envelope from address, which is required by SPF. This means that when the mail is forwarded it suddenly appears to be coming from a mail server that isn't authorised to send messages for that domain, which results in it being rejected and bounced back to the originator. I've had to relax the SPF statements for some of the domains that I manage in order to compensate for this problem (changing from "-all" to "?all" -- ie, "won't come from anywhere else" to "umm, I guess you might see it from some others too"). It would be very helpful if operators that provide a mail forwarding service (eg, just about every ISP that provides mail services) were to do the forwarding in a SPF-compatible manner. Something like procmail's approach (forward message on with envelope from of the account triggering the forward) is sufficient -- you don't have to do SPF's convoluted envelope from rewriting if you don't want to. ...

1 0

Sendmail Question
by Dan Clark 26 Nov '04

26 Nov '04

Hi Guys, Just wondering if anyone has seen the ability to configure sendmail to match from address to the msg id field (after the @) or weather or not it should do this by default. eg: Nov 26 10:55:24 mail sm-mta[15318]: iAPLtBa7015318: from=<forest.stein_rk(a)fyna.com.au>, size=982, class=0, nrcpts=1, msgid=<53fc01c4d339$34ac1af3$45006654(a)africon.co.za>, proto=SMTP, daemon=MTA, relay=[65.126.46.48] I would imagine a hell of alot of SPAM would be returned if our mail server was matching @fyna.com.au with the @africon.co.za and finding that they dont match? I hope I'm on the right track here. Regards Dan Clark

4 3

RE: [nznog] [Inetnum object]
by Donald Neal 25 Nov '04

25 Nov '04

> David Robb wrote: > > >I just got this from APNIC. Anyone else get one? > > > >My initial reaction is "say WHAT!?" > > > >Are Telecom trying to assert authority over IP space which > I'd like to see > >a whole lot of justification as to why it's "theirs". > > One simple answer is that it long has been, and before that was held by The University of Waikato. That Telecom hold a lot of New Zealand's address space isn't a new issue. (See, for instance, the archive for this list for June 1998.) - Donald Neal Donald Neal |Presbyopia - inability to see what Technical Specialist | bishops are for. Operations Engineering | Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

9 8

[Inetnum object]
by David Robb 25 Nov '04

25 Nov '04

I just got this from APNIC. Anyone else get one? My initial reaction is "say WHAT!?" Are Telecom trying to assert authority over IP space which I'd like to see a whole lot of justification as to why it's "theirs". ---------- Forwarded message ---------- Hello, It has been brought to our attention that your organisation's maintainer is currently protecting the following resources: inetnum: 202.49.252.0 - 202.49.255.255 <stuff skipped> However NZTelecom has full authority over the following blocks: 202.27.0.0/16 202.36.0.0/16 202.37.0.0/16 202.49.0.0/16 202.50.0.0/16 Therefore as these assignments are from NZTelcom's blocks in one week's time the maintainer protecting these assignments will be changed to the maintainer of NZTelecom. Please approach NZTelecom for further updates required for these assignments. If you have any question regarding this matter please do not hesistate to contact the APNIC helpdesk at: <helpdesk(a)apnic.net> To discuss this matter further in person a staff member of APNIC will be attending NZNOG5 in Hamilton 2 - 4 February 2005. Regards, APNIC Secretariat

4 3

RE: [nznog] Sendmail Question
by Regan Murphy 25 Nov '04

25 Nov '04

You would probably lose a lot of mail that way. E.g. From: NZRR Database Notifications <rpsl-admin(a)nzix.net> Precedence: bulk Message-Id: <E1CXQJJ-0007Ps-00(a)zoff.wix.net.nz> From: Sun Microsystems <sun-events(a)see.sun.com> Message-id: <0I7P002S8ZMRCO(a)olm-ms2.sun.com> Message-ID: <880B6B3B42770C4E92F35D85732893A0EB910C(a)aklemail01.salesforce.co.nz> From: Fly Buys Service Centre <contactus(a)mailus.co.nz> A lot of mailservers are on subdomains masquerading as the root domain. Also some organisations send mail for different domains (legit ones) from the same mailserver. -- Regan -----Original Message----- From: Dan Clark [mailto:dan(a)scarfies.net] Sent: Friday, 26 November 2004 11:17 a.m. To: 'nznog' Subject: [nznog] Sendmail Question Hi Guys, Just wondering if anyone has seen the ability to configure sendmail to match from address to the msg id field (after the @) or weather or not it should do this by default. eg: Nov 26 10:55:24 mail sm-mta[15318]: iAPLtBa7015318: from=<forest.stein_rk(a)fyna.com.au>, size=982, class=0, nrcpts=1, msgid=<53fc01c4d339$34ac1af3$45006654(a)africon.co.za>, proto=SMTP, daemon=MTA, relay=[65.126.46.48] I would imagine a hell of alot of SPAM would be returned if our mail server was matching @fyna.com.au with the @africon.co.za and finding that they dont match? I hope I'm on the right track here. Regards Dan Clark _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 25 Nov '04

25 Nov '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the 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, 26 Nov 2004 10:24:47 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0411261013430.9968(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: initially peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR REPLACED BY: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: PNIX peering at '218.100.21.10' descr: see Citylink RT job #1487 descr: APE peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 import: from AS9281 accept ANY AND NOT fltr-bogons export: to AS9281 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 25 Nov '04

25 Nov '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the 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: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: initially peering at '218.100.21.10' descr: see Citylink RT job #1487 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9281 accept ANY AND NOT fltr-bogons export: to AS9281 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041111 source: NZRR REPLACED BY: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: initially peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR --- PREVIOUS OBJECT: route: 203.114.128.0/19 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041111 source: NZRR REPLACED BY: route: 203.114.128.0/19 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR --- PREVIOUS OBJECT: route: 203.96.157.0/24 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041111 source: NZRR REPLACED BY: route: 203.96.157.0/24 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR --- PREVIOUS OBJECT: route: 203.79.88.0/23 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041111 source: NZRR REPLACED BY: route: 203.79.88.0/23 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS17705 descr: Route set advertised to AS9560 by Inspire Net - AS17705 members: 203.114.128.0/19^19-24, 203.96.157.0/24, 203.79.88.0/23^23-24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR

1 0

Re: [nznog] to xtra.co.nz sysadmins
by admin 24 Nov '04

24 Nov '04

thanks to everyone who replied. I was told by my ISP to change the ppp MTU from the default of 1514 to 250 a week ago because I was having problems connecting to another machine so I changed it to 512 just now and that enables me to view those sites again and access the other machine. regards to all tom PS I wasn't pointing the finger, I assumed knossos was correct but you're right about not troubleshooting properly, I only looked up the ns for yellowpages, not telecom. my bad :((

5 5

Re: [nznog] to xtra.co.nz sysadmins
by Ewen McNeill 24 Nov '04

24 Nov '04

In message <5FC2EE64-3EA0-11D9-A37D-000D93B24C7A(a)isc.org>, Joe Abley writes: >On 24 Nov 2004, at 22:11, admin wrote: >> no, orcon told me to use 250 and it seems 1514 is the default in linux. > >The MTU usually depends on the frame size that can be accommodated by >an interface. There is no useful "default" MTU. I seem to remember >hearing from someone that Linux includes the encapsulating frame >headers in its calculations when it interprets an MTU, which would make >1514 make sense for Ethernet. Kind of. That's the first I've heard of that. All the Linux boxes that I administer have a MTU of 1500 (by default, anyway) on their Ethernet interfaces.[0] To the best of my knowledge the MTU figure given to Linux network tools is the same as the MTU figure given to any other OS (ie excluding link layer framing overhead). Some googling turns up several references to "mtu 1514", from various equipment (eg, Cisco loopbacks with a MTU of 1514's, tunnels on various things, PPP interfaces, etc), but it's not clear what made someone consider it a "default".[1][2] There are also various reports of 1514 octet MTUs on ADSL connections (presumably on the interface facing the DSLAM), with various suggestions to change them to other things, including some elaborate "optimisations" based PPPoA or PPPoE overhead and ATM cell tax. 14 octets extra doesn't seem to match PPPoE or PPPoA overhead though. >However, in general, if you reduce your MTU below 1500 bytes you can >expect all the inexpertly-firewalled, pMTUd-enabled servers of the >world to stop sending you packets, sooner or later. Ah, the joys of "I don't know what ICMP is, it sounds dangerous, we'd better block it" firewall administration. Ewen [0] The default MTU on some of the other interface types is different, but a lot of them seem to default to 1500 for Ethernet compatiblity. [1] There are a bunch of people "learnedly" pronoucing that the maximum Ethernet MTU is 1514 but they appear to be deluded; about the only thing which makes some sense is that capturing packets off an Ethernet network with link headers will give you 1514 octet frames (since you don't capture the CRC at the end of the frame), which seems to confuse some people. [2] PPP on a Linux system I tried defaults to 1500 octets, presumably to deal with packets-of-ethernet without fragmentation; but it appears there may be some Linux distributions which ship with PPP defaulting MTU to something else.

2 1

Unable to reach anything but orcon servers on bitstream
by Jonathan Brewer 24 Nov '04

24 Nov '04

Hi Folks, Following email came to the WellyLUG list and I though the situation might be of interest to the NOG community. Given that Telecom is *the* provider of DSL, and bitstream is *the* unbundled option, issues in switching over customers should be paid close attention to! The customer affected now believes the issue to be related to a profile not being set to the right authentication server. Is anyone else out there successfully using unbundled DSL? How can we find out how many Bitstream customers there are? Cheers, Jon -----Original Message----- From: wellylug-admin(a)lists.wellylug.org.nz [mailto:wellylug-admin(a)lists.wellylug.org.nz] On Behalf Of Simon . Sent: Thursday, 25 November 2004 9:35 a.m. To: wellylug(a)lists.wellylug.org.nz Subject: [wellylug] (OT) Unable to reach anything but orcon servers on bitstream My apologies for the non-linux nature of this post. I think I'm hooked up with Bitstream at home now... I'm not 100% sure, and if you've been waiting for over a month like I have, you'd be sceptical too. My internet connection was severed at about 15:30 on Tuesday, and my ADSL router would only synchronise, but was unable to send ATM packets. This changed when I came home last night, and now I'm able to send ATM packets, yet I'm not able to access anything but orcon servers. Below is an email I've sent to orcon, but their helpdesk is insanely understaffed at the moment. The email has been edited to protect the innocent. If anyone can let me know what the problem might be? I have a feeling my account isnt set up properly on the gateway server, and wont let me access anything further. If I try a traceroute to google, it gets as far as the gateway, and then no further. Cheers, Simon Antliff ---------- Forwarded message ---------- Date: Wed, 24 Nov 2004 18:58:31 +1300 (NZDT) From: Simon Antliff <REMOVED> To: support(a)orcon.net.nz Subject: Unable to reach anything other than DNS/mail server Hello, I rang the Helpdesk yesterday, and left a message regarding my ADSL connection not being able to send anything over ATM. I havent heard back about this. Well, this afternoon I find that I am now able to properly connect my ADSL router to the ISP and my routers diagnostic tests all come back as a pass. I assume that I have been moved to Bitstream, since I now connect at a lower rate than before (320 now, versus 2000 yesterday). However, I cannot access anything outside of Orcon, such as google.com. Pinging google reveals that it is unreachable. So is anything else, other than 219.88.240-246.XXX and I can also ping 210.55.12.1 and 210.55.12.2 which I'm using as DNS servers. The gateway that I'm using (was assigned by DHCP) is 219.88.242.171 I am able to use email, since smtp.orcon.net.nz is 219.88.242.10. If I try to ping www.orcon.net.nz I get the following: >From www.orcon.net.nz (219.88.241.90) icmp_seq=1 Dest Unreachable, Bad Code: 10 Here is a tcptraceroute log for www.orcon.net.nz: Tracing the path to www.orcon.net.nz (219.88.241.90) on TCP port 80, 30 hops max 1 192.168.0.1 (192.168.0.1) 72.818 ms 71.805 ms 71.999 ms 2 219.88.242.171 (219.88.242.171) 72.126 ms 71.482 ms 72.079 ms 3 fe-colocation-core.nct.orcon.net.nz (219.88.242.244) 71.774 ms 71.445 ms 69.920 ms 4 www.orcon.net.nz (219.88.241.90) [open] 73.935 ms 73.450 ms 75.942 ms Please let me know if you need any more information. --- contact info snipped --- Cheers, Simon. ---- End of message --- _________________________________________________________________ Need more speed? Get Xtra JetStream @ http://xtra.co.nz/jetstream -- Wellington Linux Users Group Mailing List: wellylug(a)lists.wellylug.org.nz To Leave: http://lists.wellylug.org.nz/mailman/listinfo/wellylug

2 1

to xtra.co.nz sysadmins
by admin 24 Nov '04

24 Nov '04

Hi, Posting here because xtra staff say they have no systems admins :)) I can't access these sites or send mail to telecom.co.nz, whitepages.co.nz or yellowpages.co.nz. all 3 names have similar problems http://www.knossos.net.nz/checkdomain.cgi?domain=telecom.co.nz&submit=Query telecom.co.nz Name servers The following name servers for telecom.co.nz were found in the delegation from co.nz: * ish4.telecom.co.nz, IP address 146.171.13.195 * ish5.telecom.co.nz, invalid host name Authority (SOA) data * Primary name server: ish4.telecom.co.nz, IP address 146.171.13.195 * Contact email address: root(a)ish4.telecom.co.nz * Serial number: 2004112402 (24 Nov 2004) * Secondaries query every 3 hours; retry every 1 hour; expire after 7 days. * Time to live for negative responses: 30 minutes * Time to live of SOA record: 30 minutes Other services No services appear to be assigned to this domain. Additional information indicates an error that can potentially cause access to services to fail. indicates an error that while technically violating standards is unlikely to cause actual problems. No address record for the nameserver ish5.telecom.co.nz could be found. This could be due to the nameserver being removed from service, or bad configuration on another server. If nameserver has been removed from service, it should also be removed from the list of authoritative name servers at the registry for co.nz. The name server ish4.telecom.co.nz is an alias (or CNAME) for smtp1.telecom.co.nz. Name server names are not permitted to be aliases for other names. Remove the CNAME record and replace it with an A (address) record pointing to the IP address of the name server. Alternatively, amend the list of NS records to include smtp1.telecom.co.nz instead of ish4.telecom.co.nz. If the latter course of action is taken, don't forget to update the registry database for co.nz to reflect the change. The list of name servers returned by the nameserver ish4.telecom.co.nz at IP address 146.171.13.195 does not match those listed in the delegation for the domain in the registry for co.nz. (This list is displayed under the ``Name servers'' section above.) Please check the registry data and ensure that it matches the data in the local name servers. The list obtained from ish4.telecom.co.nz is as follows: The name server ish5.telecom.co.nz at IP address did not return SOA data. Please check that this is the correct IP address for the server, and if not, check that the registry for co.nz has the correct data. Only one functioning name server was found. Having only one name server means that any failure of that server will cause names within the domain to become unresolvable. Furthermore, most registries require that a domain have two or more actual functioning name servers. A reverse map (PTR) record for one of the IP addresses referred to could not be found. A PTR record along the lines of the following should be included in the appropriate reverse map domains: 195.13.171.146.in-addr.arpa. IN PTR ish4.telecom.co.nz. DNS delegation checking script copyright © Don Stokes 1999-2004. No liability will be accepted for the accuracy or (mis)use of information presented by this facility. Please read the FAQ for more information.

2 1

FW: [sig-policy] APNIC EC endorses policy decisions from APNIC18
by Nurani Nimpuno 22 Nov '04

22 Nov '04

Hi, I thought I'd forward this, as some of the policies below may be relevant to the NZ community. Kind regards, Nurani Nimpuno ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nurani Nimpuno <nurani(a)apnic.net> Asia Pacific Network Information Centre (APNIC) http://www.apnic.net PO Box 2131 Milton Tel: +61-7-3858-3100 Brisbane, QLD 4064, Australia Fax: +61-7-3858-3199 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: sig-policy-bounces(a)lists.apnic.net [mailto:sig-policy-bounces(a)lists.apnic.net] On Behalf Of APNIC Secretariat Sent: 22 November 2004 16:49 To: apnic-announce(a)lists.apnic.net; sig-nir(a)lists.apnic.net; sig-policy(a)lists.apnic.net Subject: [sig-policy] APNIC EC endorses policy decisions from APNIC18 [Apologies for duplicates] Dear Colleagues, The consensus policy decisions from the 18th APNIC Open Policy Meeting were endorsed by the Executive Council (EC) on November 19th at their regular monthly teleconference. The proposals endorsed by the EC are listed below: [prop-005-v004] - Internet Assigned Numbers Authority (IANA) policy for allocation of IPv6 blocks to Regional Internet Registries [prop-021-v001] - Expansion of the initial allocation space for existing IPv6 address space holders [prop-022-v001] - A proposal to abolish redundant charges in IPv6 allocations [prop-025-v001] - Proposal for an IPv6 IRR service at APNIC Details of each policy proposal, presentations, and minutes of the SIG and Member Meeting discussions are available on the policy proposal index page at: http://www.apnic.net/docs/policy/proposals This is the final stage in the policy development process before implementation. These policies were created in accordance with the policy development process for the Asia Pacific region. More details on this process can be found at the URL below: http://www.apnic.net/docs/policy/dev/ Regards ______________________________________________________________________ APNIC Secretariat <secretariat(a)apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 --------------------------------------------------------------------- * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy

1 0

OT - Unix Support Team Leader Position
by Edward Yardley 21 Nov '04

21 Nov '04

Hi All, If anyone is interested in a Unix Support Team Leader Position in Wellington ($ open). Please give me a call on one of the numbers below. Must have experience managing a team and have been a Unix admin/engineer. (04) 499-1276 or 021-509-890 Cheers Edward. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

1 0

Palmerston North Internet Exchange
by Andy Linton 18 Nov '04

18 Nov '04

Hopefully we got the sniggering about the PNIX out of the way the other day so I'm pleased to announce the opening of a new Internet exchange in Palmerston North. For more details see http://pnix.nzix.net/ We're also working on other exchanges in other centres and are happy to work with anyone wishing to establish open neutral peering points. As always we encourage widespread peering as a strategy to increase robustness and performance.

1 0

Orcon Internet Prefix List Updaet (2004-11-18)
by Craig Whitmore 18 Nov '04

18 Nov '04

Hi For all those peering with Orcon Internet (AS17746) nationally, please update your prefix lists with the following networks (also in attached file). Added: ip prefix-list orcon-national permit 203.86.192.0/20 Regards, Craig Whitmore Orcon Internet Network Operations

2 1

NZNOG 05 - Lightning Talks
by Simon Lyall 16 Nov '04

16 Nov '04

As part of the process of finalising the NZNOG 05 schedule it's been suggested that perhaps we have a session of lightning talks (it's been mentioned before but this is a semi-official call). Lightning talks are talks/presentations that last no more than 5 minutes. Several of them are usually run one after the other so that multiple speakers and topics can be covered in a short time. Here is a good page on the subject with links so where these have been held before and there are more links at the bottom of this email: http://www.justanotherperlhacker.org/lightning/ Possible topics might be (see also the pages linked in this email): - How to use RPSL with NZIX Route Registry. - Advice for finding IT jobs in NZ. - I'm involved in the X project, here is why it is cool. - I want to do cool project X. Does anyone want to help? - A quick way to clone Linux Servers - Interesting stats from the netflow across my APE link. - Building and maintaining a large and popular file archive while avoiding the lawyers. - Successful Project: I did project X. It was a success. Here's how you could benefit. - Failed Project: I did project X. It was a failure, and here's why. - Heresy: People always say X, but they're wrong. Here's why. - You All Suck: Here's what is wrong with the our community. - View from the Far Side, experiences as an IT journalist. - Call to Action: Let's all do more of X / less of X. - Wouldn't it be cool if X? - IF each ISP were an animal which animal would it be. - Someone needs to do X. - Maintaining router configs using awk - Wish List - How to get and keep portable IP addresses cheap. - Why X was a mistake. - Why X looks like a mistake, but isn't. - What it's like to do X. - Where I think the New Zealand Internet is going. - Here's a useful technique that worked. - Experiences with Juniper vs Cisco. - Here's a technique I thought would be useful but didn't work. - Why you shouldn't ever run qmail. What I would like to do at this point is gauge the interest people have in having and giving these talks at nznog05. Please email me if: - If you are interested in giving one (suggest possible topics). - You would like to suggest a topic that someone else could give a talk on ( Feel free to suggest the person) - You think it's a good/bad idea. - Any other questions or comments. I'll go over the emails (and subsequent followups) in the next few days and give a summary. If we get the numbers then I'll probably do one myself ( either on a topic I choose or something others suggest). Assuming we get at least half a dozen people prepared to give talks then I'll see if I can get us a place in the schedule. This is a good opportunity to get your pet topic out there or perhaps to get some experience with presenting without having to go to a full hour long talk. Some links. Advice on giving Lightning Talks: http://www.perl.com/pub/a/2004/07/30/lightningtalk.html A couple more links: http://www.metaart.org/maca/perl/lightning/lightning_what.html http://perl.plover.com/lt/lightning-talks.html http://www.metaart.org/maca/perl/lightning/lightning_what.html -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

NZNOG 2005 Progress Report - 16 November
by Donald Neal 15 Nov '04

15 Nov '04

NZNOG People, We've received a surprising number of late offers to present, some of which we're still working through. That has drawbacks for the organisers, but it's been good to have a high level of interest from presenters, from which a strong technical programme seems to be growing. We're adding the names of presenters as they're confirmed to the conference web site at http://www.nznog.org/ . Expect to see rapid change to that site over coming weeks. In particular, we expect to be opening registration early in December. So you'll have plenty of opportunity to talk to your manager _before Christmas_. - Donald Neal Donald Neal |Presbyopia - inability to see what Technical Specialist | bishops are for. Operations Engineering | Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

1 0

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

15 Nov '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the 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: Tue, 16 Nov 2004 14:50:39 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0411161449550.28886(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64558 descr: Route set for AS64558 members: 203.167.235.0/24, 218.101.2.0/23^23-24, 218.101.4.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: dion.hallam(a)xtreme.net.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20031030 changed: rpsl-admin(a)nzix.net 20040217 changed: rpsl-admin(a)nzix.net 20040930 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64558 descr: advertised to AS9439 by Xtreme Networks - AS64558 members: 218.101.8.0/24^24-29, 203.167.235.0/24^24-29, 218.101.2.0/23^23-29, 218.101.4.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: dion.hallam(a)xtreme.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR --- OBJECT BELOW CREATED: route: 218.101.8.0/24 descr: Route for Xtreme Networks - AS64558 origin: AS64558 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dion.hallam(a)xtreme.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR --- OBJECT BELOW CREATED: route: 218.101.2.0/23 descr: Route for Xtreme Networks - AS64558 origin: AS64558 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dion.hallam(a)xtreme.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR --- OBJECT BELOW CREATED: route: 218.101.4.0/24 descr: Route for Xtreme Networks - AS64558 origin: AS64558 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dion.hallam(a)xtreme.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR

1 0