Although I’m calling it the software strategy, it really targets the development of two specific standards: software image and configuration template. Choosing the correct software will be a critical factor in the success of a deployment. All the design and best practice efforts will amount to nothing if a critical defect is encountered in software. Software defects have created their fair share of network outages but what’s most frustrating is that many of these outages are caused by well-known defects that could have easily been avoided with a little research!
Software Risk Analysis
It has been my experience that often customers will deploy a hardware platform with the software that came installed from the factory. As you can imagine, this leads to a very diverse deployment of software. In this instance, diversity is not good as it creates a scenario where you cannot manage the risk and it is left to chance. Standardization of your software releases will put you in control of the risk and allow you to properly research software prior to deployment.
The decision tree on selecting software is pretty straight forward. The design will determine the hardware and the hardware and feature requirements will define the software releases that can support the deployment. Well, that certainly sounds easy but you’re not done yet. There will undoubtedly be multiple releases of code available for download, so which is the correct release to choose? Shouldn’t we just choose the latest release? The answer to this has to be adjusted to fit the specific circumstances. Let’s say there are numerous releases available and the latest release was posted just a week ago. With all software, you have to understand that there is a chance that changes made could have introduced what the industry calls a “regression” bug as part of the changes in that release. Often times these can go undetected by the testing of the release and tend to be found in the field. This makes the “age” of the software rather important from a risk perspective. The 1st thing you would want to understand is what bugs does the most recent release resolve and whether these fixes would impact your deployment. If it resolves no bugs relevant to your deployment, then you can lower your risk by deploying an earlier release with much wider distribution. Of course, if it does resolve a bug that would impact your deployment, then we will need to attempt to mitigate this risk in our own testing and piloting process (I will discuss change management strategy in my next post).
So what can be used to research? The Bug Toolkit, available on Cisco.com provides the ability to launch a target query to identify known defects for the platform and software in question. The tool will return the details of the bug along with workarounds (where available) and list the status (New, Open, Resolved …). If a defect is resolved, then you can refer to the releases that it has been resolved in and move to a new release which does not have the defect. If it is open and could impact the deployment, then you would need to seek technical assistance from TAC or your Network Optimization Service Engineer. This research should also be supplemented by the individual release notes for a given platform or software release.
Security Vulnerabilities
If the software was researched as outlined above, we will already be aware of software-based advisories, responses and notices that have been publicly released. In this instance, you would just need to monitor the release of these to ensure that there is nothing new that could impact your deployment. See publicly released Security Advisories, Responses and Notices.
Configuration Best Practices
Now you develop the final configuration that will be submitted for testing or validation. There are many published best practice guides and documents on Cisco.com. The Design Zone provides some great content and searching Cisco.com for “Catalyst 6500 Best Practices” will return a link to Best Practice Recommendations for the Catalyst 6500 Series Switch. Other sources of best practice configuration would our Cisco Press books. Leveraging Baseline Templates can allow for the creation of custom templates to create customer best practices and monitor compliance.
Researching software requires knowledge and access to the latest information possible. The Network Optimization Service (NOS) provides a full software strategy for your deployed devices, researches software and tracks compliance as a core part of this service. The NOS engineer is able to look at the complete pool of defects including those that have not yet been fully documented for external consumption. Most importantly, the NOS engineer is able to arm your engineers with the knowledge, specific to your business, needed to be successful.
Check out my next post where I’ll cover the final strategies- change management and network management.
CONNECT WITH US