Contrary to my numerous requests over the years an organization continues to redeploy EOS hardware into production.
In the latest case, an organization has chosen to take a good number of old 2900/3500XL switches to be put back into service. Production or non-production (yet still connected to the production network), I consider this to be highly undesirable. The 3500XL EN line was announced for EOS in July 2002, nearly eight years ago. It went EOS in July 2007, two and a half years ago. There have been no software updates for nearly 3 years now. http://www.cisco.com/en/US/products/hw/switches/ps637/prod_eol_notice09186a008032d190.html
However, I am not able to find the clear cut "Best Practice" which says definitively that this is highly undesirable or clearly not recommended. I know it seems like a no-brainer for an enterprise that invests into Cisco hardware for its data transport infrastructure.Some may assume an organization like such should have already arrived at such an opinion independently without significant debate or resistance, but that is not the case here.
Google search results only find product EOS announcements, not general instructions of "best practices" for a large infrastructure. If NIST 800-100, 800-53 address this explicitly, I’m missing it.The best I can derive is 800-53’s SI-2 and SI-5.SI-2 may apply as there is no flaw remediation since July 2007 and Cisco potentially not even acknowledge a flaw as the product is now EOSupport.
So, I am asking security-minded peer professionals to let me know where I may find documented proof that an organization would not redeploy into production old EOS hardware. This proof/recommendation does NOT have to come from Cisco. It may be a technology foundation/edu/organization/governing body. I am sure some here have already encountered this (years ago) and may recall a good document/bulletin from a technology foundation/edu/organization/governing body, like Sans, NIST, etc that addresses this.
Please post any URL here.
If anyone knows of a well moderated security policy forum (not a technical how-to forum) where topics like this are addressed, I would greatly appreciate those recommendations as well.
If I am wrong and I should be thankful for the redeployment of XLs into production, please also say so here.
Please do not talk about the economy as these decisions are made by an organization with deep pockets which does not hesitate to spend $2-5K per user on replacement desktop hardware, and not just for CAD using engineer types, but even for the common Word/Excel/Outlook user types.
Re: Re-Deployment of EOS Pulls - "Best Practices?"
I had the same amusing experience with a large government organization with a CIO who has no idea about the importance of a good network. My recommendation to upgrade the 3500XLs with 2950 as the cheapest alternative was shot down by the network architect told the client "Leo doesn't know what he's talking about".
My shinning moment came when the client started refreshing their PCs (>3,500). As per my recommendation report, the PCs' Intel NIC didn't like the 3500XL. The client reluctantly agreed (kicking and screaming) to upgrade the switches. He who laughs last, laughs best. Due to the inaction of my recommendation, the client had to spend more than DOUBLE, because they were no longer able to purchase the 2950 due to End-of-Sale, and had to purchase the more expensive 3750.
There are a significant number of CIO who's pressured to cut cost and maximize profits. I am a firm believer of the adage "You can design a network with the following options: cheap, fast and correctly. Choose TWO." Don't risk your job over it. Your shinning moment will come when you support a network that couldn't keep up with the latest technologies and security threats. And when expert opinion is results come back, you will pull out all of the correspondence by your company over your head like a "get-out-of-trouble" card, then you should be fine.
In my situtation, I had a Cisco Senior SE vouch my findings. And this was one of my two "get-out-of-trouble" card which help saved our company million of dollars in financial penalties.
If your organization has deep pockets but decides to skimp on good network infrastructure, then top management probably came from the same tree as the CIO. In my humble opinion, there's very limited you can do or convince someone his pet theory is wrong until you show them where it's falling apart and WHEN it's falling apart.
Don't you worry. You are not alone. Nearly 20% (or more) post here at NetPro are due to design and architectural validations by posters who has serious misgiving or doubts about the tasks they are forced to implement.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :