In our last tip we focused on the importance of simplifying routers and switch configurations and standardizing...
the key areas within your network in the hopes of facilitating various operational tasks. The other advantage of this practice is the ability to upgrade and advance your network in an efficient and intelligent way. This tip will focus on the importance of prioritizing your requirements, understanding budget constraints and planning the upgrade to ensure a predictable implementation.
Look at the Bigger Picture
As software features mature, as vulnerabilities increase, and as IT budgets continue to integrate the wave of new technologies it becomes increasingly important to plan and prioritize network changes and upgrades over an extended period of time. The majority of large scale changes inevitably cost money. It is important even as an engineer to be "budget aware" throughout the course of a fiscal year. With long-term planning and intelligent technology choices there will be less chance that the IT department will hear the dreaded "sounds great but it's not within our budget" statement from the finance department or CIO. "Rome wasn't built in a day" and neither was a network with a 10G MPLS enabled backbone across 200 sites delivering VoIP, IP/VTC and Multicast.
Not all required upgrades involve large amounts of cash to implement. The most common upgrades fall under the service contracts you pay for yearly and include critical updates and software downloads. Don't take the vendor's word when it comes to any type of "code" upgrades. Vendors test and validate new code with a common subset of customers' hardware and technology features, but you should always test upgrades on your network's hardware and features.
Calculating the Outcomes
The decision has been made to upgrade the network. The money has been allocated and the vendors, smelling the new money have their account reps on the scene to write that purchase order faster that you can dictate. Despite a recent "plug and pray" mentality, networks don't design and upgrade themselves.
Lay it All Out There
Once the equipment decisions have been made, hopefully based upon requirements and capabilities and not politics, the next step is to lay out the L2/L3 design so you can get the entire picture. Some people will tell you that it's better to design in more manageable sections of the network. This will work only if there is a clear L2/L3 demarcation or hierarchy within your design. In other words don't do this unless all of these particular "sections" of the network are exclusive of one another. A prime example of a hierarchical design is Cisco's three tiered model (Core, Distribution, Access).
Some key focus points when viewing the network in its entirety: Failure scenarios, convergence, routing demarcation points and L2/L3 interaction. Remember to keep it simple and standard across the board. If you're using STP from Edge to Distribution, blanket the priorities across each devices and force traffic to take the path you have chosen. Know where convergence is going to be an issue. If you're using authentication with OSPF over a broadcast media, know that a failure can cause adjacencies to bounce because of timing irregularities between DR elections and authentication validation.
We would all like to have the picture book design with the redundant everything and the money to make it all possible – but that wouldn't be reality. I'm not saying any of this is easy to put into practice, but it is essential in ensuring success of the transition. A lot of companies out there have test labs, where theory becomes reality and good practice makes perfect, then of course there are those who don't have those testing labs and a knowledgeable engineer with a white board and Visio are as good as it gets. Knowing why is just as important, if not more so, than knowing how. Hopefully you have a better understanding how budgets affect networks and how design affects the future. Next weeks tip will focus on the difference between Juniper and Cisco OSPF implementation.
Doug Downer (CCIE #9848) is a Sr. Consultant with Callisma, INC, a wholly owned subsidiary of SBC Communications. Doug has over 7 years in the industry and currently provides high level business and technology consulting for various federal clients in the Washington D.C. area. He can be reached at email@example.com.