Conference gyro::internet_toolss

Sandra,

Right now, there is no way to change this behavior.
Have you reported this to your ISP?  If you're 
constantly getting dropped, it may be that they
don't have a very good path between your dial-in
server and the Digital Internet gateway thru
which you're tunneling.

It looks like you're using the MCS tunnel
service in CXO (not the CCS service).  You may
want to contact local support to see if they
have any other suggestions.

    
    I have contacted local support, and you are right, this is not
    a super good path.  Its about 13 hops, thru bbnplanet primarily.
    
    The thing is, a good path is a day-by-day thing. I have 
    checked with many many  providers and this ISP has (a) the best ISDN rate
    (b) shortest hops; (c) cheap static IP and (d) greatest reliability
    of all the ISP's I have checked in Dallas.  All around, this is
    really the best choice.  
    
    The support group for the CSC knows that this problem could
    be alleviated drastically if we could just stop the pinging
    or at least make it longer or less often.  
    
    I can deal with slow, its the timeout tunnel down that is causing
    me grief.  What other's are doing is using alternate tunnels
    ALF or RAS I believe when CSC tunnel has problems.  
    
    I realize that there is not a "Feature" or menu that allows this
    to be changed.  I was looking for the "registry hack".  
    
    
    Sandra

    I have a similar problem, although it is occasional. However, I use a
    cable modem which provides a 1.5Mbps downlink and 300Kbps uplink. The
    backbone provider is BBN Planet, my tunnel server is DAS.
    
    Last Tuesday and Wednesday during the aftermath of the snow storm, the
    tunnel stayed up for hours. I did see some reconnects in the log. 
    
    Sunday evening, the tunnel would not stay up for more than a few
    minutes at a time. The, for some reason, would not even accept my
    password. 

    Are you sure you are having Ping Failure problems and not TCP/IP hang
    ups.
    
    The client will report the following error when it has Ping Failures.
    
     "Tunnel seems to have lost connection to server"
    
    If you get any other error, that means that TCP/IP reported a problem
    to us and we are dropping the connection.   Now the 1.0  and 1.1
    clients are a little hyper sensitive to network problems.  We have
    fixed this problem in the v2.0 Beta release.  We can make a change to
    the registry to allow you to customize the ping failure, but the server
    and the client will need to agree on this value.
    
    What is the error you are getting?  What version of the software are
    you running?
    
    
    Dan

Dan, I've already drafted both of these folks as official beta sites :-).

j.

    I have loaded the Tunnel97 Beta. I ran it last night with no connection
    anomalies. The older version would silently reconnect. Last night the
    connection was established with no problems. I may try to leave it up
    all day tomorrow. Since they are shutting most of this facility down
    this weekend, I am not sure if I can use the weekend.
     

I am also seeing VERY frequent disconnects using the
Alta-Vista Tunnel version 1.1 (SSB) under Windows-NT
version 4.0 w/service-pack 2 installed.  

I live in Gainesville, Florida, the home of the 
University of Florida (gotta love them Gators!), and 
use an ISDN line to connect via GTE Internet Solutions 
(ISP), and tunnel into any of three different tunnel 
gateways depending upon which one is currently "closest"
as the bytes go.

(And since I use the same "TOOLS" cluster, I know 
how much of a pain in the A__ it can be when TOOLS 
completely loses a call as a result of a tunnel drop.)   

I see two types of tunnel failures:

(1) Spontaneous "Tunnel connection failed" sometimes
preceeded by a "pause" in the data flow, but at least
as often without any "pause", sometimes right in the 
middle of a screen paint where data had been flowing
well right up to the instant of the drop... 

(2) Excessively long "Rekeying" sequences, where the
tunnel reports: 
	"Rekeying...", 
then
	"Connected, now authorizing.." 

and takes so long to complete the authorization, 
while apparently blocking any data SENDS, that the 
VTSTAR sessions declare a disconnect before the tunnel 
finishes its authorization sequence.  Frequently the 
TUNNEL stays UP through one of these but causes all 
of the VTSTAR (telnet) sessions to disconnect.  

These get MORE and MORE frequent the later in the 
afternoon it gets when the traffic gets heavier, 
usually after noon, EVERY "Rekey" nails me... 
so I have taken to keeping the tunnel window up and 
looking how long it is to the next "Rekey..." before 
I start anything I don't want to lose... one can
sometimes survive the "Rekey" if all of the sessions
are IDLE, (not SENDing anything to the tunnel because
you stopped typing well before the "Rekey"), but
not always.

Re: .2 - CSC32::MEREOS:>
>    I have contacted local support, and you are right, this is not
>    a super good path.  Its about 13 hops, thru bbnplanet primarily.
>    
>    The thing is, a good path is a day-by-day thing. I have 
>    checked with many many  providers and this ISP has (a) the best ISDN 
rate
>    (b) shortest hops; (c) cheap static IP and (d) greatest reliability
>    of all the ISP's I have checked in Dallas.  All around, this is
>    really the best choice.  

I guess I am a bit further "south" than you are... <grin>, 
get a load of these traceroute results (which are among the
best I've seen in weeks, usually they are MUCH worse than
this when the "surf is up" and the Internet starts loosing
packets along most of the routes from here.  Unfortunatly,
GTE Internet Solutions, (who are actually reselling UUNET 
lines in Gainesville because this is BELLSOUTH territory), 
is the ONLY 'ISDN' capable ISP in town as yet at anything 
like a reasonable price for telecommuting.

EXAMPLE 1: (Closest tunnel gate, but throughput sometimes
worse than going via the CXO gate.)
Windows-NT 4.0, svcpk 2, using 128KB ISDN link into GTE Internet
Solutions Gainesville, Florida (ISP) dialin port, tunneling to
CCS' ALF tunnel gateway on tunnel2.
----------------------------------------------------------------
C:\>tracert -w 5000 tunnel2.alf-x.dec.com

Tracing route to tunnel2.alf-x.dec.com [207.120.185.4]
over a maximum of 30 hops:

  1    70 ms    60 ms    60 ms  Max7.Orlando.FL.MS.UU.NET [207.76.15.12]
  2    50 ms    60 ms    60 ms  Ar1.Orlando.FL.MS.UU.NET [207.76.15.3]
  3     *       80 ms    60 ms  Fddi0-0.GW1.ORL1.Alter.Net [137.39.40.99]
  4   260 ms   151 ms   180 ms  130.Hssi3-0.CR1.ATL1.Alter.Net 
[137.39.59.230]
  5   110 ms    91 ms   540 ms  109.Hssi5-0.CR1.TCO1.Alter.Net 
[137.39.69.69]
  6   110 ms   121 ms   210 ms  411.atm10-0.br1.tco1.alter.net 
[137.39.13.13]
  7   230 ms    91 ms   120 ms  maeeast-2.bbnplanet.net [192.41.177.2]
  8   160 ms   120 ms   120 ms  4.0.1.93
  9   110 ms   120 ms   301 ms  4.0.1.89
 10  3355 ms     *        *     collegepk-br1.bbnplanet.net [4.0.1.226]
 11     *      171 ms   150 ms  collegepk-br2.bbnplanet.net [128.167.253.7]
 12   161 ms   150 ms   120 ms  atlanta2-br2.bbnplanet.net [4.0.1.46]
 13   200 ms   150 ms   150 ms  atlanta2-cr1.bbnplanet.net [192.221.25.226]
 14   170 ms   151 ms   150 ms  dec3.bbnplanet.net [192.221.101.246]
 15   141 ms   150 ms   150 ms  207.120.185.4

Trace complete.


EXAMPLE 2: (I use this one in the MORNINGS, but after 2pm...ugh)
Windows-NT 4.0, svcpk 2, using 128KB ISDN link into GTE Internet
Solutions Gainesville, Florida (ISP) dialin port, tunneling to
MCS' CXO tunnel gateway on relay2.
---------------------------------------------------------------
C:\>tracert -w 5000 relay2.service.digital.com

Tracing route to relay2.service.digital.com [192.208.35.19]
over a maximum of 30 hops:

  1    70 ms    91 ms    60 ms  Max7.Orlando.FL.MS.UU.NET [207.76.15.12]
  2    50 ms   121 ms    90 ms  Ar1.Orlando.FL.MS.UU.NET [207.76.15.3]
  3    50 ms    60 ms    60 ms  Fddi0-0.GW1.ORL1.Alter.Net [137.39.40.99]
  4   411 ms   210 ms   300 ms  130.Hssi3-0.CR1.ATL1.Alter.Net 
[137.39.59.230]
  5   231 ms   170 ms   150 ms  109.Hssi6-0.CR1.CHI1.Alter.Net 
[137.39.30.177]
  6   350 ms   451 ms   541 ms  411.atm11-0.br1.chi1.alter.net 
[137.39.13.101]
  7   110 ms    90 ms   120 ms  core3-hssi3-0.WillowSprings.mci.net 
[206.157.77.81]
  8   140 ms   120 ms   120 ms  core1.Denver.mci.net [204.70.4.157]
  9   140 ms   120 ms   211 ms  border2-fddi-0.Denver.mci.net [204.70.3.114]
 10   141 ms   120 ms   120 ms  ncar.Denver.mci.net [204.70.29.6]
 11   140 ms   120 ms   150 ms  205.169.250.9
 12   141 ms   270 ms   150 ms  204.131.250.42
 13   170 ms   120 ms   151 ms  csnden7001.csn.net [205.169.130.250]
 14   140 ms   271 ms   150 ms  204.133.223.249
 15   200 ms   121 ms   150 ms  204.133.223.242
 16     *      150 ms   151 ms  relay2.service.digital.com [192.208.35.19]

Trace complete.


EXAMPLE 3: (I almost never use this one as its rarely THIS good.)
Windows-NT 4.0, svcpk 2, using 128KB ISDN link into GTE Internet
Solutions Gainesville, Florida (ISP) dialin port, tunneling to
CCS' DAS tunnel gateway on tunnel1.
-----------------------------------------------------------------
C:\>tracert -w 5000 tunnel1.das-x.dec.com

Tracing route to tunnel1.das-x.dec.com [192.208.46.248]
over a maximum of 30 hops:

  1    50 ms    60 ms    60 ms  Max7.Orlando.FL.MS.UU.NET [207.76.15.12]
  2    50 ms    60 ms    60 ms  Ar1.Orlando.FL.MS.UU.NET [207.76.15.3]
  3    80 ms    61 ms    60 ms  Fddi0-0.GW1.ORL1.Alter.Net [137.39.40.99]
  4    80 ms    90 ms    91 ms  130.Hssi3-0.CR1.ATL1.Alter.Net 
[137.39.59.230]
  5   260 ms   151 ms    90 ms  109.Hssi5-0.CR1.TCO1.Alter.Net 
[137.39.69.69]
  6   140 ms    91 ms    90 ms  411.atm10-0.br1.tco1.alter.net 
[137.39.13.13]
  7   110 ms   121 ms    90 ms  maeeast-2.bbnplanet.net [192.41.177.2]
  8   231 ms    90 ms   110 ms  4.0.1.93
  9   731 ms   571 ms   541 ms  4.0.1.89
 10     *        *      101 ms  washdc1-br2.bbnplanet.net [4.0.1.174]
 11   120 ms   150 ms   151 ms  nyc1-br1.bbnplanet.net [4.0.2.34]
 12   170 ms   151 ms   150 ms  nyc1-br2.bbnplanet.net [4.0.1.178]
 13   141 ms   120 ms   150 ms  cambridge1-br1.bbnplanet.net [4.0.1.122]
 14   231 ms   120 ms   150 ms  cambridge1-br2.bbnplanet.net 
[199.94.205.102]
 15   171 ms   150 ms   120 ms  cambridge2-br2.bbnplanet.net [4.0.2.26]
 16   530 ms   181 ms   120 ms  cambridge2-cr3.bbnplanet.net [199.92.129.3]
 17   141 ms   180 ms   841 ms  dec.bbnplanet.net [131.192.95.2]
 18   441 ms   120 ms   151 ms  tunnel1.das-x.dec.com [192.208.46.248]

Trace complete.


Common factor in all of the above TRACEROUTE's:  All 
of them pass through UU.NET into ALTER.NET, then into 
BBNPLANET.NET, and it seems that most of the lost packets
and timeouts are either in ALTER.NET, BBNPLANET.NET or 
somewhere in between.   I *REALLY* wish that someone 
else had a good ISDN 'POP' in Gainesville, but to date,
GTE (UU.NET really) is the only one in town.  I get
great throughput to lots of non-DEC websites, but its
an awful long trek to CXO from here no matter how I go.

How's this compare to your 13-hopper?

� Common factor in all of the above TRACEROUTE's:  All 
� of them pass through UU.NET into ALTER.NET, then into 
� BBNPLANET.NET, and it seems that most of the lost packets
� and timeouts are either in ALTER.NET, BBNPLANET.NET or 
� somewhere in between.   I *REALLY* wish that someone 
� else had a good ISDN 'POP' in Gainesville, but to date,
� GTE (UU.NET really) is the only one in town.  I get
� great throughput to lots of non-DEC websites, but its
� an awful long trek to CXO from here no matter how I go.

uu.net IS alter.net.  Unfortunately, most times they meet bbnplanet at
mae-east, one of the most congested spots on the internet these days.
I'm afraid that you've pinpointed your problems.  You've got horrible
end-to-end connectivity to Digital's firewalls.  Maybe you can convince
a local IS group to put a firewall up and connect it to uunet so you'll
have better connectivity.  Might be easier than pushing on GTE, although
listening to them talk they paint a picture of a network which is much
better connected to the internet than you're showing.

I don't think the new version of the tunnel will help you here.  What
you can do is tune the operating system to be a bit more tolerant with
IP traffic.  You can set the two registry settings below to help out
with that.  You're welcome to beta test the new code as well.  Just send
me mail and I'll send you a pointer.  But I doubt it will make much
difference.

j.

Note: These are for Windows NT only.  For Windows 95, they seem to work,
but the values are strings, not dwords.

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpMaxDataRetransmissions"=dword:0000000a
"TcpMaxConnectAttempts"=dword:00000005

    I have also been getting the "drop" problem on an intermittent basis.
    How does one get a copy of the Tunnel97 Beta?
    
    Thanks,
    

    � I have also been getting the "drop" problem on an intermittent basis.
    � How does one get a copy of the Tunnel97 Beta?
    
It's still in beta.  It should be submitted on 4/21 and you should be able
to buy a copy shortly after that.

j.

    I too am lucky enough to have cable-modem access to the internet. I
    have the 10mbps LANcity variety, 100 feet of coax to the street, and
    then FIBER from there all the way to the Internet MA-West connector.
    
    I get about 3.0-4.0M BITS/Sec when accessing a typical, non firewalled,
    non-tunnel server (e.g. www.Intel.com). I have been running the
    Alta Vista Tunnel 95 for months and have had very few operational
    problems, a few cosmetic anoyances, but in general very reliable
    connection. It does however produce a fairly BIG performance
    bottleneck.
    
    After running some ad-hoc performance testing, I found when using
    either CXO or DAS tunnel servers, in the middle of the business day,
    or in the middle of the night, I get from 75K to 400K BITS/SEC.
    
    So it appears the Firewall/AV Tunnel approach incurs a significant
    performance degrade. I'm not sure where the problem lives, but since
    I've tried both servers, and done it at 3AM, It must be a
    characteristic of OUR EASYNET design, not due to bursty loading or
    other variables.
    
    Mark

>    After running some ad-hoc performance testing, I found when using
>    either CXO or DAS tunnel servers, in the middle of the business day,
>    or in the middle of the night, I get from 75K to 400K BITS/SEC.

	That's not surprising given what the tunnel has to do to encrypt
  the packets and then redirect the packet to the tunnel server.  I understand
  that they are going to be changing things in the next release which
  will speed things up quite a bit by doing compression before encryption.
  Encrypted packets don't compress well due to the "random" nature of the
  resultant bits.

		Danny

It's more likely the firewall relay than the tunnel server.  I'd suggest
mentioning it to the folks who run the firewall.  I know a few of the
firewalls are running the intelligent relay in debug mode, which forces
every packet to be logged.  In addition to making huge daemon.log files,
it does wonders for throttling back your throughput.  CRL has a generic
relay - give that one a shot and see if your performance improves.  Other
people with cable modems report performance better than at the office ;-).

j.

while you may have good connectivity to www.intel.com,
the path to the Digital tunnel relays may also 
contribute to the poor performance you're seeing.

you may also want to check the performance to the
tunnel servers. Try ping/tracert to tunnel1.das-x.dec.com
(the DAS relay) &/or tunnel3.cxo-x.dec.com (CXO relay).
You can also try ping/tracert to the servers inside
Digital to see how well they're connected to the the
tunnel entry points.