• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 870
  • Last Modified:

What we see on a web site is different than what others see.

So I think what we have is a router problem.  There is a public site that access's our databases from our public web page, when they make the request the request comes to our site severs and then they gets redirected to the data base that resides in another state.

Problem is they get a blank page, I thought it was something on our end before the redirect. so I remoted to my home computer and tried the same database and get it just fine there, we also get the database just fine in the office.  

For whatever reason that was in my head (from the office) I went to "their" site and received a page that has not been in use for years, none of the links on that page work and when i Google the site all the links listed by Google are not working.  So again I tried the site and the Google page from my remoted computer and all the links worked just fine.

The closest thing I can find that matches this problem is here   http://en.kioskea.net/forum/affich-92145-one-certain-site-will-not-load-help  .    It sounds almost identical except we do see a page in the office just a really old page

should we be checking stuff on our side and if so what, im not a networking guru and just starting out with CCNA-ICND.  I tend to think this is on "their" side.
0
Drakcon
Asked:
Drakcon
  • 3
3 Solutions
 
AmickCommented:
Some sites use local server caching to minimize WAN traffic.  This was much more common 15-20 years ago when we were using ISDN for access, but I suppose some might still do it.  If this is the case, the server admin needs to check the amount of time configured until a cached object is considered stale, or just clear the cache and everything should return to normal. Another possibility is that the remote browser cache is set to never check for newer versions of a page. Since you mentioned that this is a site-wide phenomenon the only way that would occur is if all the browsers were set not to check for newer versions and this is kind of unlikely, but worth checking nonetheless.
0
 
rfc1180Commented:
Some of the items I would check:

Check DNS, ensure that the FQDN matches the IP address

Using old local A records
Could be possible that have added a A record some time ago and is still connecting to the old site.
Check the HOSTS file too, they could have an old record that they used for testing.

There could be an old static NAT mapping if there is a site to site VPN
The code could have a redirect to an old site based on source IP.
Internal Proxy server that is not updating the cache (Using old records).

Billy
0
 
DrakconAuthor Commented:
one of the first things I did on our side was to check and clear out caches, most were already set to clear cached information and cookies at the time of closing there browsers, but none the less i checked the caching folders just the same....... all clear.   While I was at it I took a look (as Billy suggested) at everyone's HOSTS file in our office on the off chance, but they were all devoid of anything other than the REM comments.  Our server, other than local profile caching and rather large event logging files was devoid of anything else notable to this event.

I did take a look at the DNS for the site that made the inquiry about our database as that was one of  the first things that came to my mind before I remoted.  There DNS records all looked as I would expect, no VPN is in place and I remoted to work just now and check for any Proxy, happily we have none...........  

I have been in this position 2 weeks now, in the course of that time we have traversed to the public site in question several times and never saw what we were seeing now, someone had told me they went to the site yesterday without issue also,  only thing I know that has happened in the 24 hours prior was they rolled out there new website design :/

I will forward this on to their site IT guy and see if he responds, but thanks for the suggestions!
0
 
DrakconAuthor Commented:
well above information did not help public site, I suggested they start checking there MAC tables and see if we were in there and being restricted and/or if there user was somehow getting in the ban list.  MAC address filtering  was on to several VLAN interfaces.  Public site has since turned off the MAC address access control lists fixed some VLAN access maps, we now see there site but still unknown if user can access our database as there away for a month.

We are assuming this issue is closed, so this question can be closed also.
0
 
DrakconAuthor Commented:
well above information did not help public site, I suggested they start checking there MAC tables and see if we were in there and being restricted and/or if there user was somehow getting in the ban list.  MAC address filtering  was on to several VLAN interfaces.  Public site has since turned off the MAC address access control lists fixed some VLAN access maps, we now see there site but still unknown if user can access our database as there away for a month.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now