Conference gyro::internet_toolss

    You mean Easynet->proxy->Easynet, right, not Easynet->proxy->RealWorld?
    
    -Tom

	It would be nice if the offending user got sent to a web
	page that told them to fix their proxies properly.

	Other than that, go for it.

							mike

>        It would be nice if the offending user got sent to a web
>        page that told them to fix their proxies properly.

	Users of the IBG Software Distribution Server get such a warning if
  they go through either CRL or PA in getting to the Server.

		Danny

>    You mean Easynet->proxy->Easynet, right, not Easynet->proxy->RealWorld?

	It's more likely the latter than the former.  The labs have been
  supporting the corporation in gaining Web access for so long that most people
  have forgotten that the goal of the Labs is to conduct research rather than
  act instead of the Corporate networks group.  Now that DAS has picked up most
  of the East Coast traffic, there's no need for the Labs to continue to support
  the rest of the corporation in this way.

		Danny

Yes!  Make everyone go through their local proxies so those of us that follow
the rules aren't cheated by those who go directly to the CRL or PA proxies.

Although I often change from the MRO proxy to the PA proxy when the response
time becomes unbearable.  Perhaps restricting access will solve this problem.

Paul

tecotoo.mro.dec.com::mayerDanny Mayer (@teco.mro.dec.com.enet.xyz.com) wrote:
: Title: Easynet access to CRAnet proxies
: Reply Title: (none)

: >    You mean Easynet->proxy->Easynet, right, not Easynet->proxy->RealWorld?

: It's more likely the latter than the former.  The labs have been
: supporting the corporation in gaining Web access for so long that most people
: have forgotten that the goal of the Labs is to conduct research rather than
: act instead of the Corporate networks group.  Now that DAS has picked up most
: of the East Coast traffic, there's no need for the Labs to continue to support
: the rest of the corporation in this way.

Correct. Easynet will no longer be able to access the "real world"
through PA or CRL web proxies.

Note that this does not affect other services like FTP relay, telnet
relay, CompuServe/AOL/newsgroup relays, mail, news, etc. Only web
proxy service will be screened out; browsers won't be able to use PA
or CRL for ftp: URLs, but FTP clients will still be able to use
ftp-gw.{pa,crl}.dec.com.

This policy will most likely be implemented in the screening routers
between CRAnet and Easynet, rather than at the proxies themselves. If
this is the case, TCP connections to proxy host port 8080 will fail
with a "host unreachable" message.

Stephen
--
- -----
Stephen Stuart				stuart@pa.dec.com
Network Systems Laboratory
Digital Equipment Corporation
[posted by Notes-News gateway]

Maybe its the time difference on the left coast or maybe its the fact that
Stephen Stuart works really wierd hours when doing net repairs, perhaps because
he realizes that people work around the clock, but I've had to switch to pa.dec
more than once to get access to the world.  It was really annoying since it
was only midnight or 1 am.

    The proxy servers at DAS, CXO and ALF do restart at midnight local
    time.   This interruption should only last for a minute or two.
    
    If you continue to have problems using the IMC gateways, please let me
    know.
    
    John

    Are DAS, CXO, and ALF now all completely unrestricted?

    I work 100% of the time on customer site, dialled in through RAS. I
    work in three different countries (UK, Ireland and Belgium), and
    currently use PA as my proxy for web access. If I understand this
    string correctly, that will be turned off ere long. Where am I supposed
    to route through now?
    
    Cheers, Laurie.

Laurie i expect you missed the announcement that you are supposed to use www-proxy.<sitecode>.dec.com !!!

The proxy servers at DAS, ALF and CXO are unrestricted.  But you should be 
pointing your proxy at www-proxy.<sitecode>.dec.com.

John

    > this, it would happen early next week, and be announced here.
    
    Also announce in HUMANE::DIGITAL.
    
    Not everyone who uses the web proxies is a regular reader of this
    conference.  Also, the message should state where to point your web
    browser to, (as others in this string have noted).

re: .11

>Laurie i expect you missed the announcement that you are supposed 
>to use www-proxy.<sitecode>.dec.com !!!

I certainly never heard any official announcements, although others
I know apparently did.  Maybe mine was sent via Exchange. :-)

That said, I'm getting *much* better performance with www-proxy.cop.dec.com
than I was previously with www-proxy.pa.dec.com.  

-Hal

> But you should be 
> pointing your proxy at www-proxy.<sitecode>.dec.com.

That doesn't help much if the site merely chains to [pa|crl].

So if [pa|crl] are going off the air, where do we chain our proxy servers to? 
Remember that for some of us, DAS, CXO, and ALF are half a world away.

PJDM

    If you are in the US, the www-proxy.<sitecode>.dec.com should be
    pointing to the CCS/IMC gateway, not PA or CRL.  This was done by
    corp telecom months ago.   If the site isn't managed by a CCS networks
    group, then it could be pointing to anywhere.
    
    If you need to, point to the site that is closest to you, using
    www-proxy.das.dec.com, www-proxy.alf.dec.com, or www-proxy.cxo.dec.com.
    
    John
    

    Yep, I saw no such announcement. However, as I have no fixed "site",
    and I know some are restricted to employees based at said site, I
    expected, and had, difficulty changing. In the end HHL worked for me.
    
    Cheers, Laurie.

	Using DAS proxy server almost always fails and generates an 
	error message if this is the first entry of a site's URL it has seen.  
	Simply hitting RELOAD will usually be successful unless there is a 
	legitemate typo in my OPEN statement.  Even bookmarked locations 
	generate this error if they are old.  I usually use Netscape 3.01 
	as a browser.  Switching to CRL or PA reduces those errors to almost 
	nil.  

	I remember seeing a 'feature' discussed a ways back in here that was 
	fixed on PA and CRL servers, but cannot locate it now.  Would
        someone have the problem/solution discussion entry reference?

	I would like to submit the DAS site proxy server is generating 
	noise and wasting bandwidth for Digital with these frequent rejection 
	errors.  I am not inclined to use my site proxy forwarder to DAS if 
	this feature persists.  I wastes my time and effort as well.  
	Does someone have the proper error reporting contact?  Should the
        complaint be logged with CCS in at CALLUS::ESHELP or where?  

	Thanks

	Dave

re: .6
>So if [pa|crl] are going off the air, where do we chain 
>our proxy servers to? Remember that for some of us, DAS, 
>CXO, and ALF are half a world away.

just doing some DNS lookups, there are entries for
www-proxy.sno.dec.com and www-proxy.zpo.dec.com.  The
first may be restricted, but the second is at a 
CCS run Internet gateway, so I'd expect it is open to
AP sites.  Peter, you're in a better position than
I to follow up with the folks in SNO to confirm the
status. If I can find any official info about proxies
in AP, I'll post here.

I agree with .18, though it seems worse to me.  www-proxy.zko.dec.com is
frequently unbearable slow, or completely fails to find a site, while pa is fast
and reliable.  I knew I was "supposed to" switch to zko, and I did, but then I
discovered that even my occasional access to the web was near nil, so I switched
back to pa.

Burns

re:.20

	Hear, hear.. The ZKO proxy is very slow. PA is usually twice
	as fast and 100% more reliable.

						mike

The LKG proxy is also slow and undependable.  Tried it
for 2 days and set the pointer back to PA.

-John

    There's a good reason why ZKO and LKG are both slow.
    
    It's the same server (proxy1.ecom.dec.com).
    
    The www-proxy.site.dec.com stuff a bunch of aliases so that they can
    rearrange things without too much grief.
    
    Steveg
    
    > www-proxy.zko.dec.com
    Server:  sage.hpn.lkg.dec.com
    Address:  16.22.0.1
    
    Non-authoritative answer:
    Name:    proxy1.ecom.dec.com
    Addresses:  207.120.185.2, 192.208.46.249
    Aliases:  www-proxy.zko.dec.com
    
    > www-proxy.lkg.dec.com
    Server:  sage.hpn.lkg.dec.com
    Address:  16.22.0.1
    
    Non-authoritative answer:
    Name:    proxy1.ecom.dec.com
    Addresses:  207.120.185.2, 192.208.46.249
    Aliases:  www-proxy.lkg.dec.com
    
    

> re: .6
>>So if [pa|crl] are going off the air, where do we chain 
>>our proxy servers to? Remember that for some of us, DAS, 
>>CXO, and ALF are half a world away.
> 
> just doing some DNS lookups, there are entries for
> www-proxy.sno.dec.com and www-proxy.zpo.dec.com.  The
> first may be restricted, but the second is at a 
> CCS run Internet gateway, so I'd expect it is open to
> AP sites.  Peter, you're in a better position than
> I to follow up with the folks in SNO to confirm the
> status. If I can find any official info about proxies
> in AP, I'll post here.

	You can find a list of all available Proxy Servers at URL:

http://ibgzko.zko.dec.com/cgi-bin/Proxies

	It was set up expressly for the purpose of helping people find nearby
  Proxy servers.

		Danny

I too have found that the DAS proxy denies knowledge of valid hosts, whereas
PA works fine.  This is extremely aggravating.  Who is responsible for
investigating such problems?

					Steve

> I too have found that the DAS proxy denies knowledge of valid hosts, whereas
> PA works fine.  This is extremely aggravating.  Who is responsible for
> investigating such problems?
> 
>                                        Steve

	John Brunelle.

		Danny

	1. Hitting the RELOAD key is annoying, but it wastes time and 
		bandwidth.  It also increases the load at DAS.

	2. Has John Brunelle been made aware of this string?  

	3. What was the patch/fix applied to PA and CRL to correct this 
		problem?  I know I saw it in here a while ago.

	Dave

	I logged CCS call REF:0745542 on the DAS proxy issue .18-.23

	Dave

Re .19:

Just doing DNS lookups isn't necessarily enough. www-proxy.sno.dec.com chains to 
[pa|crl], so that's no good.

According to the page mentioned by Danny, www-proxy.zpo.dec.com doesn't even 
exist.

PJDM

    Re .29:
    
    www-proxy.sno.dec.com has been upgraded in the last few weeks.
    It is now a stand-alone proxy server linked to Telstra's Big Pond.
    The old proxy server used to chain to one of the US proxies.
    
    Mark Fowler

    Folks,
    
    Thanks for the logged called... If it didn't get logged, I may have not
    read this until later in the week.
    
    You all have noted problems with proxy1.ecom.dec.com, which is located
    in DAS.  But no one has given an example of a URL that didn't work.  As
    of now, the CCS/IMC Gateway proxies are not restricted and you
    shouldn't be experiencing any connection problems.
    
    As for the noted performance problems from ZKO and LKG, we are aware of
    the issue.  This problem is being addressed with increased bandwidth
    between the sites and DAS.  It's expected to improve before the end of
    the month.
    
    Please provide examples, and I will look into the problems and report
    back here.
    
    John
                                          

The trouble is that a URL might fail one day and work the next.  Yesterday,
I couldn't get to www.logitech.com from DAS, but today I can.  Similarly,
I was unable for several days to see files at ads.csi.emcweb.com through
DAS, but I can today.

				Steve

One other tidbit I've noticed is that a DNS lookup for proxy1.ecom.dec.com
reveals two IP addresses.  One is the one in DAS, and the other is the
proxy2 address in ALF.  This might account for some of the unpredictability,
as the two proxies get used at random.

Sam

Yesterday www.amazon.com would not work via www-proxy.zko.dec.com.  Today it is
ok.  www.netscape.com failed a couple days ago as well.

Burns

Well, obviously this hasn't happened yet; we're still debating the
relative merit of having the research data (around two million hits
per day in Palo Alto) versus freeing up the bandwidth to the rest of
the corporation. It is unlikely that we will implement anything this
week or next. Stay tuned.

Stephen
--
- -----
Stephen Stuart				stuart@pa.dec.com
Network Systems Laboratory
Digital Equipment Corporation
[posted by Notes-News gateway]

This is shortly after midnight...

www-proxy.zko.dec.com translates to two systems, one in das and the other in alf

From zko to das, it appears that there is a T1 link: 
interfaces.ifTable.ifEntry.ifSpeed.5 = Wrong Type (should be Gauge): 1536000

From zko to das and to pa, it appears to be an inverse mux of two T1s:
interfaces.ifTable.ifEntry.ifSpeed.5 = Wrong Type (should be Gauge): 3333333

However, the attached very small and therefore unreliable traceroute sample
suggests that the route to das is faster than to alf or pa, but pa seems to be
almost as fast as alf.

I suspect that netscape will translate the proxy address once per session,
so you might get das one day and alf the next if you used www-proxy.zko.

I would have to talk to someone about the specific link speeds between each of
the sites before I would believe the interface settings, especially since my
group installed its own T1 link between NIO and ZKO because the fastest link
from nio to zko was 500k and that was with something like 8 hops and CCS was
being told to cut their comm costs in half because we had half the number of
people.  We actually wanted to put in T3 but ZKO objected that we would have
more bandwidth between nio and zko than existed into our engineering partners,
unix and vms, (more than 4 times as much) even tho zko has a backbone built
around 3 GIGAswitch/FDDIs.  As far as I know, the situation in zko has not
improved significantly because of the proposed densification.  It might well
be that the problems in zko are due to the poor connectivity inside zko.

What I find interesting is that we had virtually no problem justifying doubling
the amount that we spent on network as a group from a financial standpoint.
The opportunity cost in terms of lost time because the network was so slow
and unreliable was higher than the approximately $5k per month for the T3.
What killed that upgrade was fact that engineering groups in zko didn't order
FDDI adapters on every server they bought and then required the facility network
people to connect them up to the building FDDI network.

I believe that we have a number of customers with more GIGAswitch/FDDIs
installed than we do, and they have fewer people to support.  And they pay
at least twice as much as the IEG price, and IEG is making a nice profit.

P$ traceroute www-proxy.zko.dec.com
traceroute to proxy1.ecom.dec.com (207.120.185.2), 30 hops max, 40 byte packets
 1  stertr (16.135.32.10)  7 ms  7 ms  7 ms
 2  nions3 (16.135.16.254)  4 ms  6 ms  4 ms
 3  16.252.31.1 (16.252.31.1)  41 ms  9 ms  36 ms
 4  bbzkd1.zko.dec.com (16.33.16.151)  20 ms  15 ms  14 ms
 5  alf-zkd1-pp.bb.dec.com (16.55.115.2)  79 ms  110 ms  55 ms
 6  fw6.alf.dec.com (16.72.16.250)  50 ms !H  50 ms !H  75 ms !H
P$ traceroute www-proxy.zko.dec.com
traceroute to proxy1.ecom.dec.com (192.208.46.249), 30 hops max, 40 byte packets
 1  stertr (16.135.32.10)  7 ms  7 ms  6 ms
 2  nions3 (16.135.16.254)  4 ms  4 ms  4 ms
 3  16.252.31.1 (16.252.31.1)  11 ms  13 ms  8 ms
 4  bbzkd2.zko.dec.com (16.33.16.152)  13 ms  20 ms  13 ms
 5  das-zk2-pp.bb.dec.com (16.55.100.2)  16 ms  28 ms  17 ms
 6  fw3.imc.das.dec.com (16.136.240.51)  12 ms !H  52 ms !H  12 ms !H
P$ traceroute www-proxy.zko.dec.com
traceroute to proxy1.ecom.dec.com (207.120.185.2), 30 hops max, 40 byte packets
 1  stertr (16.135.32.10)  7 ms  9 ms  7 ms
 2  nions3 (16.135.16.254)  4 ms  4 ms  4 ms
 3  16.252.31.1 (16.252.31.1)  8 ms  8 ms  9 ms
 4  bbzkd1.zko.dec.com (16.33.16.151)  23 ms  17 ms  15 ms
 5  alf-zkd1-pp.bb.dec.com (16.55.115.2)  53 ms  54 ms  72 ms
 6  fw6.alf.dec.com (16.72.16.250)  77 ms !H  92 ms !H  90 ms !H
P$ traceroute www-proxy.pa.dec.com
traceroute to www-relay.pa-x.dec.com (204.123.2.44), 30 hops max, 40 byte packet
s
 1  stertr (16.135.32.10)  9 ms  6 ms  7 ms
 2  nions3 (16.135.16.254)  4 ms  4 ms  4 ms
 3  16.252.31.1 (16.252.31.1)  8 ms  8 ms  9 ms
 4  bbzkd2.zko.dec.com (16.33.16.152)  34 ms  24 ms  13 ms
 5  wrlnhd-zkd2-pp.bb.dec.com (16.56.32.1)  101 ms  101 ms  102 ms
 6  easy-pa-gw2.pa.dec.com (16.1.224.101)  90 ms  98 ms  96 ms
 7  cerberus1.pa.dec.com (16.1.240.243)  87 ms !H  96 ms !H  103 ms !H

    Folks,
    
    UPDATE.... the problem with resolving hostnames has been correct.  The
    problem was a NAMESERVER that wasn't functioning correctly.
    
    As for the link between the DAS-IMC and ZKO, it is true it's a T1 only. 
    But we are in the process of improving the bandwidth of that circuit
    among other things.
    
    During the week of 5/19, we will cutting over to a IS-IS routing
    protocol, which will allow us to load balance between our two 3mb circuits. 
    Today, this doesn't happen and most of the traffic is coming down one
    circuit.
    
    So stay tune, and things will be getting better.
    
    John

>Well, obviously this hasn't happened yet; we're still debating the
>relative merit of having the research data (around two million hits
>per day in Palo Alto) versus freeing up the bandwidth to the rest of
>the corporation. It is unlikely that we will implement anything this
>week or next. Stay tuned.
>
>Stephen
    
    Are you still permitting proxy requests for internal pages? If so, you
    could free up some of your resources by denying them. I don't think
    you'd find any argument about that.
    
    -Tom

RE: .37

	I logged a call on a nameserver a few weeks ago. It was
	taking FOREVER to resolve names. Of course, when Mollie got
	to look at it, it was running fine. Oh well.

	Thanks for the update on what's happening John.

							mike

>    www-proxy.sno.dec.com has been upgraded in the last few weeks.
>    It is now a stand-alone proxy server linked to Telstra's Big Pond.
>    The old proxy server used to chain to one of the US proxies.
>    

	The Proxies Web page at URL:

http://ibgzko.zko.dec.com/cgi-bin/Proxies

  has not been updated to reflect that.  You should consider doing this.  I
  could do this myself, but I don't have the necessary details.  You can
  contact me directly if you have problems doing this.

		Danny

>>Well, obviously this hasn't happened yet; we're still debating the
>>relative merit of having the research data (around two million hits
>>per day in Palo Alto) versus freeing up the bandwidth to the rest of
>>the corporation. It is unlikely that we will implement anything this
>>week or next. Stay tuned.
>>
>>Stephen
>    
>    Are you still permitting proxy requests for internal pages? If so, you
>    could free up some of your resources by denying them. I don't think
>    you'd find any argument about that.

	I have considered denying access to the IBG software distribution
  server for people coming in via the PA and CRL sites.  I haven't done
  so yet, I just issue a warning about it.  It would be easy for me to
  turn on.

		Danny

Tom Smith MRO1-3/D12 dtn 297-4751 (smith@cfsctc.enet.dec.com) wrote:
: Title: Easynet access to CRAnet proxies
: Reply Title: (none)

:     Are you still permitting proxy requests for internal pages? If so, you
:     could free up some of your resources by denying them. I don't think
:     you'd find any argument about that.

We haven't for a while; I think CRL only turned it off just recently
(or maybe not).

Stephen
--
- -----
Stephen Stuart				stuart@pa.dec.com
Network Systems Laboratory
Digital Equipment Corporation
[posted by Notes-News gateway]

	Now www-proxy.lkg.dec.com points me off to ALF where that is failing 
	in a similar manner to how DAS was.  I get 'The requested item could 
	not be loaded by the proxy.' which I immediately hit reload which 
	usually loads the page.  The server's name is www-relay.alf-x.dec.com 
	which I assume is in ALF?

	Who is the contact to notify there?

	Dave

    RE: .43

    Hi Dave,

    Please log a call to the CCS HelpDesk at 800-332-2468, and ask for the 
    call to go to the "Internet Management Center" (the folks that support
    the tool you are trying to use).

    Ihthy,

	Ron

    The network improvements that I indicated would be done this month
    have been completed.
    
    I am interested in hearing about any network problems or
    improvements to the CCS/IMC proxy servers.
    
    John
    

    
    for a couple of days, i have been getting proxy hangs using
    www-proxy.zko which i understand maps to www-proxy.das  ..
    today i switched to www-proxy.pa and the pages i had been
    trying to reach come up fine.
    
    i sure hope the people who run PA and CRL don't take away their
    proxy access until there other proxies have established a track
    record of being functional.
    
    Paul Clark
    

    Paul,
    
    Thanks for the information.  There appears to be a problem with the ZKO
    to IMC circuit, which is being researched by the AMNOC (Corp Telecomm). 
    I will forward your issue, and update you later this week.
    
    BTW.. the www-proxy.zko maps to Dascomb and Alpharetta servers.
    
    John