North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Website contact for www.cisco.com

  • From: Michael . Dillon
  • Date: Tue Sep 28 05:54:01 2004

>    All very true; but I prefer take away from everything
> complicated and make it simple (This is my opinion, YMMV).  Since
> nothing in my environment has changed, no broken equipment or software
> issue, and all the routes were correct (including CEF/dCEF) and I was
> able to access Cisco's site from several other IP address from my
> network as well as outside networks I made a logical assumption (or at
> least I think it was logical) that it was "possible" that Cisco blocking
> this one particular /32. 

I think that you made one wrong assumption while troubleshooting
that led you down the wrong path. We often assume that if we
cannot make a TCP connection, then there is some kind of
routing or network problem. However, when websites are
involved, especially large websites with load balancing
and other stuff, you can get problems at higher layers
that only appear to be network problems.

Once you determined that it was only a single /32 affected,
I think you should have eliminated network causes as the
problem. dCEF issues would have affected more than a 
single /32 in your subnet. And problems that affect only
one single IP address are more likely to be found in the
TCP stack or higher layers.

Here are a couple of possible reasons why Cisco's website
would "block" you even though nobody at Cisco configured
router ACLs or firewalls to do any blocking. Many web server
farms enforce a kind of automatic protection against web
crawlers that blocks an IP address if it accesses the website
too many times over too brief an interval. Maybe this happened
to that /32 (leaning on the Ctrl-R key) or maybe their mechanism 
made a mistake. The damping mechanism kicked in and blocked
your /32 for a while.

The second possibility is that if their webserver
was not properly closing open sockets from your /32, it may
have assumed that your /32 was opening too many simultaneous
sessions. When the sockets finally disappeared on their side
you were able to connect again. It's common for large websites
to limit any IP address to only two simultaneous connections.
Also, in our company's network management systems we are 
currently trying trying to solve a problem on SUN servers
where sockets are being held open on the server end and
blocking clients because the application limits the number
of simultaneous connections.

Neither of these things are easy to diagnose and generally
the network/routing people don't understand enough technical
details of server farms and aren't responsible for managing
server farms. Sometimes your troubleshooting guides just
have to note that you have identified the problem as being
in someone else's domain and leave it at that.

--Michael Dillon