T.R | Title | User | Personal Name | Date | Lines |
---|
4645.1 | | CFSCTC::SMITH | Tom Smith MRO1-3/D12 dtn 297-4751 | Thu May 01 1997 20:50 | 3 |
| You mean Easynet->proxy->Easynet, right, not Easynet->proxy->RealWorld?
-Tom
|
4645.2 | | axel.zko.dec.com::FOLEY | http://axel.zko.dec.com | Thu May 01 1997 20:52 | 7 |
|
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
|
4645.3 | | teco.mro.dec.com::tecotoo.mro.dec.com::mayer | Danny Mayer | Thu May 01 1997 21:07 | 7 |
| > 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
|
4645.4 | | teco.mro.dec.com::tecotoo.mro.dec.com::mayer | Danny Mayer | Thu May 01 1997 21:16 | 10 |
| > 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
|
4645.5 | No driving in the breakdown lane! | FUNYET::ANDERSON | OpenVMS pays the bills | Thu May 01 1997 21:35 | 7 |
| 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
|
4645.6 | Re: Easynet access to CRAnet proxies | QUABBI::"stuart@nsl-too.pa.dec.com" | Stephen Stuart | Thu May 01 1997 23:33 | 34 |
| 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]
|
4645.7 | Is DAS more reliable these days? | TWICK::PETTENGILL | mulp | Fri May 02 1997 02:36 | 5 |
| 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.
|
4645.8 | Should be reliable | 192.208.48.2::BRUNELLE | | Fri May 02 1997 04:01 | 7 |
| 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
|
4645.9 | | CFSCTC::SMITH | Tom Smith MRO1-3/D12 dtn 297-4751 | Fri May 02 1997 05:18 | 1 |
| Are DAS, CXO, and ALF now all completely unrestricted?
|
4645.10 | | VAXCAT::LAURIE | Desktop Consultant, Project Enterprise | Fri May 02 1997 11:44 | 7 |
| 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.
|
4645.11 | Announcements who makes them! | geraldo.reo.dec.com::ConnollyG | One of those awfully nice AlphaStudio People | Fri May 02 1997 12:32 | 1 |
| Laurie i expect you missed the announcement that you are supposed to use www-proxy.<sitecode>.dec.com !!!
|
4645.12 | Yes, UNRESTRICTED | dasdhcp-136-160-96.das.dec.com::brunelle | | Fri May 02 1997 13:37 | 5 |
| The proxy servers at DAS, ALF and CXO are unrestricted. But you should be
pointing your proxy at www-proxy.<sitecode>.dec.com.
John
|
4645.13 | HUMANE::DIGITAL would give greater coverage. | BASEX::EISENBRAUN | John Eisenbraun | Fri May 02 1997 17:59 | 7 |
| > 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).
|
4645.14 | | NEWVAX::LAURENT | Hal Laurent @ COP | Fri May 02 1997 19:14 | 12 |
| 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
|
4645.15 | | BIGUN::nessus.cao.dec.com::Mayne | A wretched hive of scum and villainy | Sun May 04 1997 22:26 | 9 |
| > 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
|
4645.16 | Try this | smoken.imc.das.dec.com::BRUNELLE | | Mon May 05 1997 00:36 | 10 |
| 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
|
4645.17 | | VAXCAT::LAURIE | Desktop Consultant, Project Enterprise | Mon May 05 1997 13:00 | 5 |
| 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.
|
4645.18 | DAS fails to find new URL sites | NETCAD::ATKINSON | Dave Atkinson | Mon May 05 1997 13:48 | 23 |
|
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
|
4645.19 | there are some proxies in AP | PARZVL::ogodhcp-125-112-135.ogo.dec.com::kennedy | nuncam non paratus | Mon May 05 1997 14:30 | 13 |
| 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.
|
4645.20 | | SKYLAB::FISHER | Gravity: Not just a good idea. It's the law! | Mon May 05 1997 16:37 | 7 |
| 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
|
4645.21 | | axel.zko.dec.com::FOLEY | http://axel.zko.dec.com | Mon May 05 1997 17:52 | 6 |
| re:.20
Hear, hear.. The ZKO proxy is very slow. PA is usually twice
as fast and 100% more reliable.
mike
|
4645.22 | similar things in LKG | NETCAD::BARENYS | John Barenys | Mon May 05 1997 21:01 | 5 |
|
The LKG proxy is also slow and undependable. Tried it
for 2 days and set the pointer back to PA.
-John
|
4645.23 | | NPSS::GLASER | Steve Glaser DTN 226-7212 LKG1-2/W6 (G17) | Mon May 05 1997 22:19 | 28 |
| 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
|
4645.24 | | teco.mro.dec.com::tecotoo.mro.dec.com::mayer | Danny Mayer | Tue May 06 1997 14:11 | 22 |
| > 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
|
4645.25 | | QUARK::LIONEL | Free advice is worth every cent | Tue May 06 1997 15:27 | 5 |
| 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
|
4645.26 | | teco.mro.dec.com::tecotoo.mro.dec.com::mayer | Danny Mayer | Tue May 06 1997 15:40 | 9 |
| > 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
|
4645.27 | repeat questions | NETCAD::ATKINSON | Dave Atkinson | Tue May 06 1997 17:41 | 10 |
|
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
|
4645.28 | CCS call logged... | NETCAD::ATKINSON | Dave Atkinson | Tue May 06 1997 18:00 | 4 |
|
I logged CCS call REF:0745542 on the DAS proxy issue .18-.23
Dave
|
4645.29 | | BIGUN::nessus.cao.dec.com::Mayne | A wretched hive of scum and villainy | Tue May 06 1997 21:44 | 9 |
| 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
|
4645.30 | New proxy at SNO | SNOFS1::FOWLERMARK | Mark Fowler | Tue May 06 1997 22:58 | 7 |
| 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
|
4645.31 | Problem reported, examples needed | smoken.imc.das.dec.com::BRUNELLE | | Wed May 07 1997 01:00 | 20 |
| 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
|
4645.32 | | QUARK::LIONEL | Free advice is worth every cent | Wed May 07 1997 17:11 | 6 |
| 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
|
4645.33 | | PASTA::HO | Like money in the bank | Wed May 07 1997 17:37 | 6 |
| 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
|
4645.34 | | SKYLAB::FISHER | Gravity: Not just a good idea. It's the law! | Wed May 07 1997 17:55 | 4 |
| 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
|
4645.35 | Re: Easynet access to CRAnet proxies | QUABBI::"stuart@nsl-too.pa.dec.com" | Stephen Stuart | Thu May 08 1997 01:33 | 13 |
| 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]
|
4645.36 | Interesting data on the paths from zko to www-proxy.zko and .pa | TWICK::PETTENGILL | mulp | Thu May 08 1997 05:08 | 75 |
| 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
|
4645.37 | UPDATE | smoken.imc.das.dec.com::BRUNELLE | | Thu May 08 1997 10:21 | 17 |
| 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
|
4645.38 | | CFSCTC::SMITH | Tom Smith MRO1-3/D12 dtn 297-4751 | Thu May 08 1997 13:15 | 13 |
| >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
|
4645.39 | | axel.zko.dec.com::FOLEY | http://axel.zko.dec.com | Thu May 08 1997 14:51 | 9 |
| 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
|
4645.40 | | teco.mro.dec.com::tecotoo.mro.dec.com::mayer | Danny Mayer | Thu May 08 1997 14:59 | 14 |
| > 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
|
4645.41 | | teco.mro.dec.com::tecotoo.mro.dec.com::mayer | Danny Mayer | Thu May 08 1997 15:02 | 18 |
| >>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
|
4645.42 | Re: Easynet access to CRAnet proxies | QUABBI::"stuart@nsl-too.pa.dec.com" | Stephen Stuart | Thu May 08 1997 17:13 | 18 |
| 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]
|
4645.43 | ALF relay acting up | NETCAD::ATKINSON | Dave Atkinson | Wed May 14 1997 18:04 | 10 |
|
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
|
4645.44 | Log a call to CCS ... | YASHAR::RONNIEB | Debt Free! Thank You, Jesus! | Thu May 15 1997 13:51 | 11 |
| 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
|
4645.45 | Network reconfiguration completed | smoken.imc.das.dec.com::BRUNELLE | | Wed May 28 1997 01:51 | 8 |
| 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
|
4645.46 | for a couple of days now, ZKO proxy is useless | STAR::PCLARK | | Mon Jun 02 1997 16:18 | 12 |
|
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
|
4645.47 | ZKO circuit is being look at. | smoken.imc.das.dec.com::BRUNELLE | | Wed Jun 04 1997 02:32 | 10 |
| 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
|