There're alot of other reasons why the tunnel dies than just what I said... but yeah. It's all usually based around odd ppp sessions dying. Infact, goto http://www.scannerx.com/ - win2k/win98/winME machine running raspppoe/enternet, with no firewall - do the free trial, should kill the tunnel. XP seems to lose the ppp session, but very rarely does it get a dead tunnel. What increases frequency of dead tunnels.... - Borderline attenuation problems (usually with downstream), this also accounts for customers going in and out of sync alot and that causing ppp sessions to die, this repeatedly disconnected thing sees a higher frequency of the tunnel dying. - Exchange capacity issues....been a while since ive seen such a problem, since 'unlimited' went away :) - cmux problems, don't know the cause, NASC will sometimes initiate the software being reloaded onto the cmux, sometimes the cmux port is swapped for customers that get alot of tunnel problems. But pretty much telstra have stopped blaming alcatel for the tunnel problems, it is still under 'investigation' by Nortel and Telstra technicians, blah blah blah. - as i was saying with udp based things, saturating upstream with these type of things, when your machine is trying to send out to many packets, that really increases the likely hood the ppp session will die and the tunnel too. for example, 512/128 customer, running a quake3 server ( I don't know why, but they do) - 4 other people connect in with rates of 5000+ - bam. - IPSN upgrades/faults - generally some maintainence telstra have done to the IPSNs has killed tunnels, they don't have an easy way of doing bulk resets, apart from reloading the entire IPSN. And these days telstra are very unlikely to do an IPSN reload for a small amount of customers, there was a time when there were 500customers with tunnel problems in WA, they didn't wish to do a full reset to fix it for all of these customers, so singular cases had to be dealt with by the NASC. - re: the tunnel rebuilds being done - NASC have tools to test data flow down 8/35. they send something like 100,000 cells and see how many they get back. - If an IPSN upgrade is due to go through, this will stop any tunnels being reset/rebuilt/modified. They have something like an embargo, something along the lines of the nortel guys take an image of the server to work on for a new update, so unless it was a severe fault, the modify would wait until after IPSN update (this can cause the week long delay type stuff) - Tunnel reset does not generate a new pvc id, a tunnel rebuild does. So the reset is more like a refresh. - PPPoE clients, seems to happen with all pppoe clients, however, in regards to things like broadcast protocols saturating your bandwidth, we tend to see OSs with better tcp stacks handle things better. Linux/rp-pppoe tends to get alot less of these types of issues, where as win98/ME are culprits. Probably the send-q handling, I dunno really. - seems to happen less with pppoa based devices/software, but it still happens under same circumstances as above. Dunno if much of that would apply to pacific, do you guys send your tunnel problems to NASC like us? Personally I've had 3 tunnel rebuilds on 2 different ADSL connections since I got adsl sept-00. At bigpond, we're trying to change our trouble-shooting away from software reinstalls and more to like modem led trouble shooting. For example timeout on a win98 machine. ----------------------------------------------------------- - Check line sync. Check link integrity on NIC and modem. pwr cycle modem if all ok. - Applying 10.0.0.1/255.0.0.0 to NIC TCP, to see if can ping modem ok (good nic test i guess, also gets a computer reboot in there, customer is more happy to reboot if windows asks, not you :). - Check dev manager, make sure pppoe adaptor has no exclamations on it. - During connection attempt and profile creation, if LAN and TX are flashing, but no RX activity at all during that. > then escalate for tunnel reset/rebuild/test. ----------------------------------------------------------- Why create new profile? with enternet, it's a good check if they have 2 NICs to make sure both drivers are ok. Also we're not always told of IPSN changes, Telstra will be splitting up the IPSNs more as the userbase gets larger, since they only allow customers to see the one IPSN, sometimes they do the change and since the profile is pointing back to the old service, needs to be refreshed or re-created. We also want to be able to get a tunnel reset/rebuild/test for routers not supplied by telstra or linux/bsd/etc, by doing the pwr cycle of modem and check LAN/TX/RX leds. Guess we'll have to wait and see if telstra will let us do that. sigh. The fact that it takes minutes to do tunnel testing and reset or rebuild... in reality we should be doing it at the helpdesk level, we have seen 0 improvement over the almost 2years in regards to the frequency of tunnel collaspes. But still they refuse to give us the tools. If I was an ADSL reseller, I would force Telstra to give me the tools to do tunnel testing and to do modifies, since it's a fault of their network. To be able to test the tunnel would be neat, you could do it without forcing the customer to trouble shoot at all, then say with certainty, that the ADSL service is ok. Last little interesting note: Tunnel testing is done before any service calls are booked for bigpond now. To sort of weed out anything that shouldn't be a service call and also to make sure that the service has the best chance of actually being able to be fixed by field tech. hope this incoherent dribble has helped : > -dan