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 still do not know the answer to this question
as by the time Cisco replied to me with a canned answer access to
Cisco's website from that IP address was working again.
Chris Burton
Network Engineer
Walt Disney Internet Group - Network Services
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above. If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this
e-mail in error, please contact Walt Disney Internet Group at
206-664-4000.
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