----- Original Message -----
From: "Steve Phillips" <steve@focb.iconz.co.nz>
> After two to three months of constant problems with the DSL sites we ended
> up ripping the entire lot out and replacing them with Dialup ISDN circuits
> due to the dropouts. Faults were logged with these circuits and telecom
did
> find some problems with the DSL lines in various locations, but after
these
> were fixed the "micro outages" still persisted seemingly at random and
> after telecom playing the old jedi mind trick of "there is no problem..."
> and wanting us to *prove* that there was a fault we simply gave up.
>
> Now we refuse to call DSL a "business quality" connection and recommend
> that customers use something more reliable if they wish to do anything
past
> simple web access and e-mail.
Your choice. All of us telcos have more expensive services we are happy to
sell you. Personally, I prefer not to get emotionally biased against
technologies one way or another, and prefer to recommend solutions to
customers that meet their business needs in the most cost effective fashion.
> This was all put together with cisco 827's and 1600/2600 routers.
>
> I guess it was all in our imagination.
I doubt it. You had a problem alright. But there definitely has been a
breakdown in communication between yourselves and the individuals in Telecom
you dealt with. From what I have seen Wayne and his team take customer
service really seriously and are happy to work with customers to solve their
problems.
It helps to remember we are just people, though, and sometimes don't have
all the answers. You might be calling the big black evil empire but at the
other end of the line is a person who has a different perspective than you
do.
> >The problem does not seriously affect our other ADSL service,
IP.Networking,
> >because that provides businesses with a non-Internet, private IP network
> >with full routing and therefore does not use NAT in the modem.
>
> We were not useing NAT in the modem's either, we used the 827's to
> establish a tunnel to a 2600 and simply tunneled private IP's thru this,
> any NAT on this network was done by a firewall in the main site in
auckland.
What does the 827 do to any tunnels it has established when the interface
associated with the DSL link goes down and back up again? Does it tear them
down and refuse to set them up again? I have never tried using one like
this, but I would have thought it would be possible for it to be configured
to auto-reconnect in some way. Because you are tunnelling private IPs this
should be reasonably transparent to users other than a brief period of no
traffic.
> Mabee it didn't affect your service because it was all internal to telecom
> ? so possibly the problem is with the gateways between telecom and the
> ISP's ? after all, this would also cause small "micro outages" as well ?
> one thing I did find to be interesting was that my *routes* would vanish -
> yet the modem itself wouldn't reset - however, most of this was
experienced
> from work or when i was at a remote location and couldn't check to see if
> the modem was retraining - another interesting thing to note was that no
> authentication requests would ever appear in our radius server logfiles -
> mind you, i only ever checked this a few dozen times, and only for a
couple
> of specific customers (in this case a mixture of Nokia 1122 and Cisco
gear)
> so mabee sometimes the modem would re-authenticate the PPP layer.
>
> Possibly there are a couple of problems, one with the modems actually
> resetting (line noise caused by neighbors taking up ARC Welding ?) and
> route dropouts (caused by something on the telecom internal network
talking
> through the CAR ?)
Definitely this sounds like quite a different issue. If a modem drops out
you will see a radius authentication come through to you when it logs in
again, every time.
Where were the routes disappearing? In the Cisco 827, in the 2700, or in
your main router that connects to the jetstream network? Which routes were
you losing, the routing to and from the Telecom network or the routes to the
private network that you were carrying through the tunnel? Were you able to
ping either tunnel endpoint from the other?
The routing inside the Telecom network is extremely simple. We are not aware
of any of the routes associated with the contents of your tunnels, we only
know about the public Internet space that you are tunneling across. We do
not advertise any routes down to the DSL modem itself. We have a default
route to the ISP from the network, and we only advertise up the pool of
addresses that are associated with the DSL modems themselves.
If you are losing routes associated with your private addresses, then the
issue is almost certainly related to what is happening at your tunnel
endpoints and unlikely to be related to any routing information in the
Telecom network.
If you lose routing connectivity to the modem, then you will lose it to a
large number of customers at once. This is definitely something that we
would want to work with you to resolve.
> Mabee we should try and separate these out - people log times and dates
and
> ask their ISP's to see if authentication requests were sent through the
> ISP's Authentication servers ? - I realise this is a pain for ISP's to
have
> to monitor and for home users to setup to log - but it could persuade
> telecom that the problem is real - isn't related to "line noise" and
asking
> them to "Defrag your hard drive and scan for virii then call me back" wont
> make it go away
Oh, the line problem is much easier to identify than that. Look in the modem
log files for messages about the DSL interface (or ATM cell lock) going down
then back up again 30 seconds later.
>
> I have also noticed here that when we have a "mico outage" i traceroute to
> DSL IP's starting with 210.48.81.1 (our static range and my home IP) and
> count upwards (210.48.81.2.. etc etc) and usually get up to around 10 or
so
> before the routes start sending the packets back thru the CAR to ipnet -
> funny how my home wiring and line noise is affecting the first 10 or so
> static ADSL customers at exactly the same time...hmm
No this isn't a line problem. Sounds like something to do with how your
static pool is configured. Where are you pinging from? Where do the
misplaced packets go off course?
> except when these outages cause interactive sessions to vanish and in so
> doing (be it bad database design or whatnot) cause an outage in say - a
> database server, which then needs to be rebuilt after hours and locks up
> records..
>
> oh, that's right, this setup isn't common - therefore we will go back to
> the jedi mind tricks and see if we can persuade people to use the internet
> for what it was designed for.. browsing websites for pr0n ! how DARE they
> try to use a DSL connection for anything semi-serious.
Don't be so sensitive ;-)
> only if it means someone at telecom will pull finger and start treating
> this as a real problem. Upgrading your CAR's from 4500's may be a start as
> well.
Um, why?
Cheers,
Daniel.
This message is part of the NZ ADSL mailing list.
see http://unixathome.org/adsl/ for archives, FAQ,
and various documents.
To unsubscribe: send mail to majordomo@unixathome.org
with "unsubscribe adsl" in the body of the message
Received on Thu Mar 1 23:50:37 2001