..I'm starting to wonder if it would be a good idea to have a group of say, 5-10 people who were entitled to say when an email is, or isn't off-topic, and everyone else's thoughts to stay private (yes, moderators, if you please). I find this list very informative, and a great way of keeping "In the know" about the industry. But like everyone else, i get extremely tired of my mailbox filling with off-topic, personal-opinion.. ..emails. This annoyance is greatly increased when an off-topic email is followed by several other off-topic, or irrelevant reply's. (I remember my NZNOG folder growing to ~160 unread messages, over about 2 weeks, about 3 months ago.) 15 on-topic emails broaden my knowledge, and are greatly appreciated. 15 off-topic emails.. I don't much care for, and tend to make me take a lot less notice when NZNOG mail arrives. It seems that everyone here is either a network admin (hence "NZ Network Operators Group") or someone like myself wanting to reach that level. I would assume that the average IQ on this list is around 140, therefore, one person's opinion is 90% irrelevant to the rest of the list, assuming that they have the sense to fully analyse a situation before jumping to a narrow-minded conclusion. It would be appreciated if the more.. "shoot now, ask questions later" posters could keep in mind just how many people this list reaches, and how many hours of time you are wasting with your off topic opinion's. (If someone could give us a full count of subscribers, I'm sure it would open a few lazy eyes.) Adam: In this instance, you were a little out of line. 95% of the people on this list have a strong commitment to a network company, and therefore, are not in a position to take up your offer. I suggest the NZ Herald for more appropriate applicants. (or sales(a)ISP of you are looking to wholesale) Michael: Your post contained nothing but personal opinion an experience. It contained absolutely nothing Network oriented, and therefore, was a waste of hundreds of people's time. Surely everyone reading this list is intelligent enough to know that door-to-door sales isn't the best career decision for them at this point. (People not in this category, please see http://www.nzherald.co.nz/classifieds/search.cfm?pillar=1&subpillar=28 ) In summary, I'd like to think that from now on, people could think for a minute.. "Does anyone really care what i think?!". If you're not helping to increase the knowledge of the group, please post off list. Keeping within these guidelines will make NZNOG a much more approachable, helpful, no bull list, where you can be assured that every email will be worth the read, and most queries will be answered in a timely matter. Regards Jeremy B

Business Internet Solutions (connected.net.nz) - no longer in business - was trying this back in the mid nineties when I had a brief stint working for them. It was a very bad deal.

Every business would love to have their whole sales force on a commission basis. Unfortunitely, exclusing Real Estate and some car yards (And even segments of those industries are moving away from commissions) it is a bad deal and the sales staff just end up broke and effectively funding their 'employer'.

DREAMnet does seem to be rather apt name.

...

Currently Dream Net Internet www.dreamnet.co.nz are in need of several sales people to work on a commission basis.

This can be part or full time.

You would sign up customers to Dream Net and earn a commission for doing so. Also we will soon have wireless access available. When this is operating you will be encouraged to contact businesses and the rural community to sell this product.

As well as internet access we also supply webdesign and hosting services, which are also available to you to sell.

Anyone interested please reply to sales(a)dreamnet.co.nz

Regards Adam Fenech Director Dream Net Internet Services LTD www.dreamnet.co.nz

-- // Michael Hallager Director || Head geek || Making IT work.

URL: http://www.networkstuff.co.nz networkStuff, NZ's leading online supplier of high quality new and used networking equipment.

Phone: (09) 839-1000 (DDI) 0800 638-788 (Freecall) Fax: (09) 837-8100 0800 329-788 (Freecall) Mobile: 029 638-7883

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Hi Folks, I've recently come up against the issue of some ISP routers in New Zealand which block ICMP. This creates an issue for some of our clients, who we deliver service to via GRE tunnels over a multi-hop wireless network. The issue is defined in RFC 2923, quoted below. My question for the list is, what are the known PMTUD "black holes" in New Zealand? Is there anyone out there unwilling to allow ICMP into their network? How do we make sure Path MTU Discovery works to all endpoints within NZ? Thanks, and regards, Jonathan Brewer Araneo Wireless Solutions

From RFC 2923:

"A host performs Path MTU Discovery by sending out as large a packet as possible, with the Don't Fragment (DF) bit set in the IP header. If the packet is too large for a router to forward on to a particular link, the router must send an ICMP Destination Unreachable -- Fragmentation Needed message to the source address. The host then adjusts the packet size based on the ICMP message. As was pointed out in [RFC1435], routers don't always do this correctly -- many routers fail to send the ICMP messages, for a variety of reasons ranging from kernel bugs to configuration problems. Firewalls are often misconfigured to suppress all ICMP messages. IPsec [RFC2401] and IP-in-IP [RFC2003] tunnels shouldn't cause these sorts of problems, if the implementations follow the advice in the appropriate documents. PMTUD, as documented in [RFC1191], fails when the appropriate ICMP messages are not received by the originating host. The upper-layer protocol continues to try to send large packets and, without the ICMP messages, never discovers that it needs to reduce the size of those packets. Its packets are disappearing into a PMTUD black hole."

I've recently come up against the issue of some ISP routers in New Zealand which block ICMP. This creates an issue for some of our clients, who we deliver service to via GRE tunnels over a multi-hop wireless network.

this is largely an off-topic response, but while on the topic of PMTUD i'd like to point at a tool useful to debug forward path PMTUD issues, like tracepath does for example. Note that Jonathan's problem is a reverse path issue. http://www.wand.net.nz/scamper/ given an IP address, scamper will do a traceroute towards it to establish the forward path and an address at the end of the network that will terminate probes. then it will try ICMP based PMTUD starting with the interface's MTU size. If it does not get a response, it tries smaller packet sizes until it has inferred the largest packet that will get some response from the path. Then it does a TTL limited search to infer the hop[s] possibly responsible for not sending an ICMP Fragmentation Required message. It marks the mtu annotations for the hop[s] with an asterisk. For example, here's a sanitised example: traceroute from 199.109.33.1 to XXX 1 199.109.33.254 0.744 ms [mtu: 4470] 2 XXX 14.041 ms [mtu: 4470] 3 XXX 26.454 ms [mtu: 4470] 4 XXX 22.627 ms [mtu: 4470] 5 XXX 35.079 ms [mtu: 4470] 6 XXX 38.690 ms [mtu: 4470] 7 XXX 47.683 ms [mtu: 4470] 8 XXX 59.337 ms [mtu: 4470] 9 XXX 63.797 ms [mtu: 4470] 10 XXX 61.082 ms [*mtu: 1514] 11 XXX 60.909 ms [mtu: 1500] 12 XXX 61.541 ms [mtu: 1500] Note that the path between hop 9 and 10 probably has a L2 disagreement on the media's MTU size as the hop will happily generate other ICMP types. ./scamper -4mi <IP addresses> is the basic usage of scamper for this purpose.

My question for the list is, what are the known PMTUD "black holes" in New Zealand?

at one point this was the case with at least one large internet banking site, where they filtered out [at a minimum] inbound ICMP unreach. i have no idea if this is still the case. ICMP6's packet-too-big message is a completely different ICMP type, presumably to try and prevent that message being turned off through naive filtering of ICMP6 unreach.

Is there anyone out there unwilling to allow ICMP into their network? How do we make sure Path MTU Discovery works to all endpoints within NZ?

there is some effort to make PMTUD work the other way around. the idea is that a host will start of sending small size packets and work their way up through larger packet sizes until a frame is dropped. http://www.psc.edu/~mathis/draft/draft-ietf-pmtud-method-XX.txt