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