- NZNOG - lists.nznog.org

My Bad
by Te Aroha 12 Jun '01

12 Jun '01

OK ppl's My Bad I submitted to this list instead of majordomo...Cheers to Brendan Willis, Mark Little, Gavin Quayle and crew for sorting me out...I guess supervising you guys taught me nothing. :) Te Aroha Maxnet Support Team tearoha(a)maxnet.co.nz t(a)maxnet.co.nz

1 0

subscribe NZOG
by Te Aroha 12 Jun '01

12 Jun '01

Hi there Can you please subscribe me to this mailing list. Cheers Te Aroha Maxnet Support Team Customer Services Supervisor support(a)maxnet.co.nz Ph: 0508 MAXNET Ph: (09) 300-7555 Tech Support Ph: (09) 300-7222 Office

1 0

Problem at Clear???
by Craig Whitmore 12 Jun '01

12 Jun '01

Anyone notice that Clear are unreachable from the Internet?? (Overseas/Orcon/Win Internet/etc) Thanks Craig Whitmore I Talk for Myself

5 7

RE: Lots of broken mail at Xtra
by Olof Olsson 11 Jun '01

11 Jun '01

> From: Joe Abley [mailto:jabley(a)automagic.org] > Sent: Tuesday, June 12, 2001 6:59 AM > > ETRN is actually optional with mailbagging, too. Connection attempts > will begin shortly after the mailbagging user connects, and > will repeat > at regular intervals if there is mail to deliver. > > The following script may be useful: > > for n in ${things_involving_mail} > do > olof ${n} > done > Thanks for blowing my cover Joe! :-) Basically, what we do for CLEAR Net Mail is: 1) Add X-Envelope-To: headers to all inbound messages. This allows for POP3 retrieval of messages for one or more domains/users etc, without having lost the envelope recipients. (Many POP3 <=> SMTP gateways have the capabilities of performing deliveries on these kind of custom headers.) Is POP3 the right mechanism for this? Maybe not, but a lot of our customers want to do just this. And of course, the customer is always right. :-) But a nicer way is mailbagging... For mailbagging: 2a) For mailbagging customers we delivery messages into a separate mailbagging store. This store is designed so that it can efficiently queue large number of messages for each customer. It also (of course) preserves envelope information. 2b) Customers configure a "mailbagging pick-up user-id" via our self-provisioning interface. 2c) When a customers logs on using his pick-up user-id, we kick off outbound SMTP delivery. Once all the mail has been delivered, we check for new incoming mail every 60 seconds, and deliver appropriately. (For as long as the user stays logged on.) Some notes: *** We can do this for both static _and_ dynamic IP assignments. (However, we only offer customers dynamic IP addresses. Static addresses for dial-up customers are bad, for many reasons.) *** Handling dynamic IP addresses (obviously) requires us to keep track, in real-time, of who is assigned what IP address. We do this via a real-time database. Delivery via SMTP is triggered from this database when a user-id record is added that is tagged as a "mailbagging pick-up user-id". *** There are some racing conditions which makes it hard to safely use a standard MTA to implement mailbagging with dynamic IP addresses. Hence, we use a custom MTA. *** We ignore ETRNs. --Olof --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

RE: Lots of broken mail at Xtra
by Ben Martel 11 Jun '01

11 Jun '01

Don, > If you really must use POP to retrieve multiple users' mail, use > multiple mailboxes and query 'em all. Better still, use a real > transport protocol. SMTP with ETRN or dial-up triggering > strikes me as a > *much* better (if not perfect) solution. <infomercial>Take a look @ CLEARs mailbagging product. It even does it on dialup connect or dial-up triggering as you suggested :)</infomercial> ~benm --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 2

FW: Rootserver Change Request
by Peter Mott 06 Jun '01

06 Jun '01

Anybody got anything to say about this? Peter Mott Chief Enthusiast 2day.com -/- > ***************************************************************** > This message is being sent to 70 ISP's in New Zealand > It's a request for your company to change it's Root Server setup. > ***************************************************************** > > > To whom it may concern, > > > The Wapterix Internet Group is in the process of setting up it's online > presence. > > We are looking to offer a number of online services including hosting, > domain registration and web design to name a view. One area we > will not be > entering into is that of an ISP. We feel that there is already a good > selection and number of ISP's operating in New Zealand and for us to enter > into this sort of service would dilute our energies from the provision of > services that will be profitable for us. > > The reason for our contacting you is that we have a number of domains > relevant to our business operation that have been registered > under the ".z" > domain extension. As this extension is an alternative extension, and not > recognised by the A-Root Server, we are writing to ask that you > adjust your > name servers and resolvers to allow New Zealand internet users access to > this extension. > > The extension is controlled by ADNS.net through their site, www.adns.net, > where you will be able to find information on how, as an ISP, you > can change > your servers so that domains under this extension are visible to the > internet users of New Zealand. > > ADNS use the ORSC Root Server (www.open-rsc.org) rather than the A Root > Server given that they are an alternative extension. This Root > Server has a > large number of internet users accessing it, and offers the added > advantage > that users, while being able to access alternative extensions > covered by the > ORSC Root Server, they can also access all generic extensions - > .com, .net, > .org, .co.nz - and so on. > > We have chosen to operate domains under the ".z" extension in > support of our > belief that the internet should be not be controlled by one > governing body, > and that individuals should be free to choose any extension that > suits their > operation and/or operate their own extensions, provided those > extensions do > not legally interfere with the operation of extensions operated by other > individuals or organisations. We hope you accept our view and > will support > us in our operation by changing your servers accordingly allowing us to > operate our domains, and New Zealand internet users the ability to access > our domains. > > Should you have any querries please do not hesitate to contact me. I will > be more than willing to answer any questions you may have. > > > Yours > > Trevarr McCarthy > President > The Wapterix Internet Group --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

7 7

VOIP, the next big test.
by Roger De Salis 05 Jun '01

05 Jun '01

This is sufficiently thought provoking and on-topic that I thought it worthy of posting. RDS. The article disses Cisco fairly thoroughly (there are also some compliments as well). I've added some comments at the bottom. Feel free to discard my comments as appropriate. -----Original Message----- From: Peter Ecclesine [mailto:petere(a)aimnet.com] Sent: Monday, 4 June 2001 9:59 PM To: wireless Subject: Comments on Australia's VOIP nets From: Frank A. Coluccio Thursday, May 31, 2001 12:35 PM Glenn Turner, who apparently operates the Australian Academic and Research Network has some very interesting IMO things to say about running voice over the Internet. This is from the ongoing discussion on NANOG that questions: QOS or More Bandwidth? Enjoy, FAC ================snip begins: <so and so> wrote: > > > Whenever I did the cost of deploying and managing fancy QoS > > and compared it with the cost of getting and managing more > > capacity, it was always MUCH MUCH cheaper to get and manage > > more capacity than to mess with more QoS. > > We did one VoIP network deployment, and I tried each of the > different QoS services in IOS at that time (about 18 months ago) > both in the lab and in the field, and more bandwidth was the > answer then. Interesting. We have a national VoIP network which handles long-distance calls for the Australian universities. It's not a trial, it's a real VoIP rollout that interconnects the PBXs of the universities. We think that's about 300,000 handsets. More bandwidth doesn't cut it, as the voice calls then fail during DDOS attacks upon the network infrastructure. It's not too hard to fill even a 2.5Gbps link when new web servers come with gigabit interfaces and when GbE campus backbones are being rolled out. If these DDOS attacks use protocols like UDP DNS then traffic shaping the protocol is problematic and the source IP subnet from where the attack is launched needs to be filtered instead. Just finding and filtering a DDOS source can easily take more than five minutes, which pushes the availability to less than 99.999% and leads to legal issues with telecommunications regulators about access to emergency services. We found the Cisco low latency queuing to be adequate. It still has a fair amount of jitter, but not enough to matter for VoIP calls with a diameter of 4,000Km. We do have issues with Cisco's 7500: dCEF is still problematic, but needed for the LLQ feature. The QoS features are too linked to the hardware (you can't configure a service-policy that is enacted on the VIP or main CPU, depending upon the hardware). Despite QoS being most needed on cheap E1/T1 links, they expect you to upgrade to a many thousand dollar VIP4 to support QoS. We police access to QoS by source IP address, mapping non-conforming traffic to DSCP=0. As this requires an access list executed for each packet, the number of VoIP-speaking connecting sites to 50 or so, and requires H.323/SIP proxies at the edge of the sites. We don't use IntServ. When a link is down RSVP takes so long to find an alternative path that the telephone user hangs up. So what we are really waiting for is the implementation of the combined IntServ/DiffServ model so that hosts on member networks can do local authentication and bandwidth reservation and we can police the amount of QoS traffic presented at each edge interface. "Local authentication and bandwidth reservation" also hides a host of issues that are yet to be fully addressed. Most universities don't even *have* an authentication source that covers everyone that can use IP telephony. In practice, even with our deliberately simplistic implementation this whole area is a IOS version nightmare. There's no excuse for a monolithic statically-linked executable in this day and age. Hopefully Juniper's success with monolithic kernel and user-space programs will lead to Cisco looking to leapfrog the competition and adopt the on-the-fly upgradable software modules as described in Active Bridging (1997). Having dissed Cisco, I should point out that their H.323/ISDN gateway software that runs on their RAS boxes (5300, etc) was the most solid of all the manufacturers we tested and Cisco was the vendor most willing to fix the differing interpretations of ISDN we enountered when we connected the North American-developed RAS to our European-developed PABXs (Ericsson MD110, Alcatel, etc). ------------------------- As far as the "engineering staff costs" argument goes, we have found that they the real engineering time goes into hardening the existing infrastructure. When carrying voice every engineering shortcut you have taken comes back to haunt you -- clocking problems, a low percentage of CRCs, ATM links with no OAM, synchronous links with carrier nailed high. Very little of the costs were due to the configuration of the routers. Most of the cost was incurred at the edge of the network, where there is a greater variety of devices, less correct engineering, and worse configuration control. > The trans-Pacific problem is being solved. Give it another > 6-18 months and fibre between US/CA and ANZ or JP or SG should > drop significantly in price. Although the price will drop, it will never drop to the levels of trans-Atlantic prices. Even then, countries like Fiji which have landing points would find it hard to raise the millions required to buy an STM-1 from that landing point. You can make a case that North America is unique. It doesn't have 2,000Km expanses with no population centers. It isn't split off from the remainder of the world by mountain ranges so high that to do an hour's lifting can take a week. It doesn't have a population so huge that training people to lay fiber is in itself a massive undertaking. In these cases, no amount of money will buy you more bandwidth tomorrow and the engineering costs of QoS and TE are immediately worthwhile. VoIP and QoS let you use all of the long-haul optical capacity for IP, whereas the slower growth of the Internet in North America allowed the running parallel Internet and PSTN networks. -- end snip -- 'Time doesn't fool around.' 'without prejudice' U.C.C. 1-207 ======= End of Article ============================================= Comments by Rog. Please discard if you think not appropriate to this list. Cisco 7500, this was a pretty cool box 5 years ago. You all bought lots of them. We acknowledge it is now struggling to keep up, due to all the bandwidth. We'll trade it at favourable rates to help. Current thinking within Cisco is.... 7500 is a 5Gbps box. (really 4 x 1.25Gbps box). 6509/7600OSR is a 256Gbps box. Sufficient horsepower for long and complex ACL lists to counter DDOS attacks (but how do you find and load the source of the attack into the ACL swiftly?) 16 port GE cards means price of GE is slightly below US$1K/port. (7600-OSR appears to me to be 6509 with Optical Service Modules, STM-4, STM-16, GigE blades????? No we don't know why they did this either?) Fiji. The cost of an STM-1 card is about 5-10K. Double it for reliable service. So the millions referred to is really about how the Southern Cross consortium recover their investment dosh. Doing a sweet-heart deal for Fiji, and setting a price that Fiji can afford, sets a very unwelcome precedent for negotiations with other countries. So effectively Fiji misses out, and the country most in need of low-cost communications cannot have it. This is of interest to me as the same economic situation occurs in rural NZ. If rural NZ had widely available, fast communications infrastructure (10mpbs customer access minimum), then the choice of where to run a new-economy business would be much wider. The alternative is building more roads in Auckland. London built the M25 as a possible solution, but it simply created more traffic. Yeah, you have to have both, but comms networks are cheaper to build than road networks. R -- \_ Roger De Salis Cisco Systems NZ Ltd </' +64 25 481 452 L8, ASB Tower, 2 Hunter St /) +64 4 496 9003 Wellington, New Zealand (/ roger(a)desalis.gen.nz rdesalis(a)cisco.com ` 4/4/01. Mike Volpi, Cisco's chief strategy officer, announces four key markets: VOIP, wireless LANs, content networking, streaming media. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 2

Number of AS's and Networks in NZ?
by Craig Whitmore 04 Jun '01

04 Jun '01

Has anyone a list of AS's in New Zealand I should see and the number of Networks associated with each AS? I want to make sure I am going Nationally for every place that is in New Zealand Thanks Craig Whitmore

9 14

Paradise Not Announcing Routes to Telecom?
by Craig Whitmore 04 Jun '01

04 Jun '01

I don't think paradise is announcing all their ranges to Global-gateway/telecom/netgate ... All I can see coming from Paradise's AS via Global-Gateway's AS is.. 202.0.32.0/21 202.0.40.0 202.49.136.0 202.49.137.0 202.50.109.0 203.96.144.0/20 Which means going to a few of there sites takes the long way around This is from 210.55.71.10 (Netgate DSL Ports) [root(a)lennon /root]# traceroute 203.79.66.5 traceroute to 203.79.66.5 (203.79.66.5), 30 hops max, 38 byte packets 1 210-55-71-254.adsl.netgate.net.nz (210.55.71.254) 46.917 ms 45.328 ms 47.723 ms 2 gateway.adsl.netgate.net.nz (192.168.253.1) 42.951 ms 45.873 ms 46.387 ms 3 202.37.247.253 (202.37.247.253) 247.152 ms 293.514 ms 228.592 ms 4 p1-1.akbr2.global-gateway.net.nz (202.50.116.161) 129.325 ms 170.006 ms 162.937 ms 5 202.50.116.170 (202.50.116.170) 168.543 ms 176.873 ms 181.526 ms 6 a4-1-0-3.sybr1.netgate.net.nz (202.50.116.82) 195.767 ms 191.548 ms 195.817 ms 7 connect.sybr1.netgate.net.nz (202.50.116.115) 200.465 ms 216.558 ms 229.336 ms 8 atm0-1-0-27.bdr1.syd.connect.com.au (210.8.219.237) 236.039 ms 233.281 ms 169.433 ms 9 Fddi1-0-0.pad13.Sydney.telstra.net (139.130.32.5) 179.480 ms 184.586 ms 197.406 ms 10 GigabitEthernet4-0.pad-core3.Sydney.telstra.net (139.130.249.240) 197.091 ms 222.966 ms 226.596 ms 11 Pos6-0-0.nzsx-core1.Auckland.net.reach.com (203.50.126.50) 251.709 ms 244.772 ms 259.497 ms 12 FE4-1-0.b2.sxb.akl.tsnz.net (203.98.4.2) 237.052 ms 247.860 ms 192.220 ms 13 bertha.lqy.tsnz.net (203.98.21.29) 219.672 ms 203.286 ms 217.687 ms 14 fe0-0-0.kelly.paradise.net.nz (203.96.152.1) 221.610 ms 243.152 ms 240.241 ms 15 ipnet.ipnet2.paradise.net.nz (203.96.155.157) 259.118 ms 244.233 ms 225.757 ms 16 * * * 17 203-79-66-5.adsl-wns.paradise.net.nz (203.79.66.5) 219.332 ms 220.679 ms 234.058 ms Paradises announced ranges works well ... traceroute to 202.49.136.1 (202.49.136.1), 30 hops max, 38 byte packets 1 210-55-71-254.adsl.netgate.net.nz (210.55.71.254) 48.527 ms 45.405 ms 49.883 ms 2 gateway.adsl.netgate.net.nz (192.168.253.1) 45.382 ms 45.137 ms 47.048 ms 3 a3-0-1.tkcr1.netgate.net.nz (202.50.245.162) 44.982 ms 47.008 ms 45.924 ms 4 paradise.akcr1.netgate.net.nz (202.37.246.74) 57.388 ms 56.106 ms 57.412 ms 5 fe7-0-1.bertha.paradise.net.nz (203.96.152.254) 55.865 ms 55.924 ms 58.631 ms 6 203-96-144-21.cable.paradise.net.nz (203.96.144.21) 67.965 ms * 66.898 ms Thanks Craig Whitmore --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

4 4

The New Zealand Network Operators' Group
by Donald Neal 03 Jun '01

03 Jun '01

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. At present it consists of the subscribers to this mailing list, which anyone is free to join. This list has around 230 subscribers, growing by a handful each month. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by an employee of Telecom NZ Ltd. Neither of these organisations (nor the administrator) is responsible for its content. NZNOG Mailing List Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 4. Postings to multiple mailing lists are discouraged. 5. Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 6. Blatant product or service marketing is unacceptable. 7. Postings of a political, philosophical or legal nature are discouraged. 8. Postings to the list should be in ASCII or MIME encoded as text/plain. Attachments should not be sent to the list. To present a document, a suitable URL may be referred to. For documents of general interest, the use of proprietary file formats is discouraged. 9. Breaches of list etiquette should be dealt with privately with the offending list user, and should not result in complaints being sent to the list. Mailing List Archives A full archive is available at http://list.waikato.ac.nz/archives/nznog/ To search the archive, see http://list.waikato.ac.nz/archives/search.html (and remember to select nznog). Subscribing to the List To subscribe to the NZNOG list, send email to majordomo(a)list.waikato.ac.nz, where the body of the message reads subscribe nznog There are at present no restrictions on who may subscribe to the list, or even on who may post to the list. Digest Mailing List If you don't wish to receive postings as they are sent, you can instead subscribe to the nznog-digest mailiing list, on which all postings are sent out in a single "digest" every couple of days. Other Activities NZNOG does not at present have other regular activities than this mailing list. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0