Network World
Tuesday, December 2, 2008
DNSstuff.com
Get information about your IP
IP Information
50+ On-demand DNS and network tools

Jeff Doyle on IP Routing

Cisco Subnet

Navigation

Designing Your Network in the 21st Century

You need to make a business trip from San Francisco to Singapore. At the airport, you find out that you are going to be traveling on the inaugural flight of the brand new BoBus A888.

“Cool,” you think as you board the latest in aviation technology. You gaze in admiration at the gleaming exterior and spotless interior.

Settling into your seat, you strike up a conversation with the guy next to you; sticking to standard business traveler chitchat, you ask what he does for a living.

“Why, I’m a principal architect for BoBus. In fact I led the team that designed this very aircraft,” he tells you.

“Cool!” you reply. “The CAD and simulation software you use for a project like this must be amazing.” 

“Oh, those things are way too expensive,” he says. “Don’t use ‘em.”

Your left eyebrow goes up half an inch.

“How can you design something as complex as this airplane without computer models?” you ask.

“Why, I’ve been designing planes for decades.” He taps his temple. “A few good rules of thumb are all it takes.”

“Rules of thumb?” you ask, beginning to look around at the interior, seeing it in a quickly changing light.

“Sure!” he says. “After all, aircraft design is really more art than science.”

You wave a shaky hand at the flight attendant. “M’am, I need to get off.”

That story is absurd, because vast computational resources go into the design of any modern commercial aircraft – sending hundreds of souls across thousands of miles of ocean in anything that has been put together based on some “rules of thumb” is inconceivable.

And yet most data networks are designed and built in exactly this way. You might say that I’m making a bad comparison: A poorly designed network doesn’t put lives in danger. But in fact networks used in healthcare, law enforcement and emergency response, air traffic control, and perhaps dozens of other fields can indeed put lives at risk if they fail. At the very least, thousands upon thousands of businesses are dependent on the reliability of their networks.

I wrote in the previous two posts about the importance of offline modeling for reducing the risk of network changes and for network survivability analysis. Both of those applications concern networks that are already built; modeling is equally important for building the network correctly in the first place. While the benefit of both change modeling and survivability modeling is OPEX reduction – including the monetary benefits of risk reduction – the benefits of design modeling are the reduction of both CAPEX and OPEX – again including risk reduction.

Change and survivability modeling involve modeling your existing network, adding known link loads and application flows, and then imposing changes or failures to see how the loads and flows react. In design modeling you start with the applications you need to support, determine the flows those applications will create, and then model the network that best serves those flows. Survivability analysis then becomes a part of the design process as you refine your modeled design to be as robust as possible within your budget constraints.

Capital expenditures are reduced because you remove the guesswork from your design. You know what your requirements are – both immediately and throughout the expected lifetime of the network equipment – before you even begin negotiations with your vendors. You sharply reduce both the expense of buying more costly equipment than you need and the expense of buying equipment that cannot keep up with projected network growth and must be replaced earlier than intended.

Operational expenses are reduced because you fully understand the network you are building and do not make it more complex than it needs to be. You also understand the failure characteristics of the network, allowing you to either set SLAs that can be supported by the network or design the network to support predetermined SLAs.

Yes, modeling is expensive if you are looking just at the cost of the applications or the cost of outsourcing the modeling. But within the context of what modeling saves you, it pays for itself many times over.

There are still plenty of people around who will tell you that network design is more art than science; don’t listen to them, because they’re justifying their need to make educated guesses in the design project. Most complex systems these days – not just airplanes – are designed with the assistance of computer models. Your network should be designed the same way.

 

Yes and more

Useful answer?
0

I definitely agree. Modeling any complex system should always be done. And even a small network can be complex for reasons of, as you say, change and survivability. I would add performance / capacity to that also. Now, one gripe I have is the definition of network. I'm old school, a network is anything between end points, user to application/database, system to system, application to application, etc. It makes it even more interesting and more complex but also, if you can model that, avoids a lot of problems later on. It used to be more common, I did that for large Tandem networks where servers / services were part of model. Tedious and hard work but at end not so expensive in scope of total cost and we got some very good results even modeling future growth and changes. Very good article, thank you.

How to model

Useful answer?
0

I'm sold; I'm ready to go model my network and see what I can do to break the model.
But how? What software packages might I find to help model flows, etc?

Modelling Software

Useful answer?
0

Opnet (http://www.opnet.com/) would probably be the best place to start the search. Yes it could be considered expensive, but when you take into account the depth of the suite...

If only the funding matched the rhetoric....

Useful answer?
0

While I agree with your intent, our IT leaders do not fund the development, design and testing to same level.

The design and testing of a plane is allocated budgets in the order of billions of dollars, with s suitable amount of time to execute.

My business leaders dont, won't and cannot envisage that sort of commitment.

lineecho

If your only tool is a hammer, every problem looks like a nail - Abraham Maslow

Excellent topic. I used to

Useful answer?
0

Excellent topic. I used to develop modeling tools for design of large scale networks at a carrier. All the points Jeff made about opex and capex were so obvious that it supported a core team of couple dozen people who worked exclusively on developing new modeling techniques and algorithms.

There are two types modeling techniques. The most widely used is simulation made popular by fantastic tools like Opnet. Simulation is great for measuring performance of a network, e.g. delay, jitter, packet loss etc. by simulating an actual network.

The other technique is 'combinatorial optimization' (I know it is a mouthful). Well known routing algorithms for shortest path like Dijkstra, min-max flow and minimum spanning tree are example of combinatorial optimization. I have not seen any good modeling tools in the market that model and solve network design using optimization techniques.

Having seen the strengths of simulation and optimization techniques up close I think lack of optimization tools is a big void.

Re: Excellent Topic

Useful answer?
0

Hi Farrukh,

There are a couple of new players that are focused on route analytics that are worth having a look at. One is iptivia (www.iptivia.com) and the other is Aria (www.aria-networks.com).  

--Jeff 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

About Jeff Doyle

Jeff Doyle is president of Jeff Doyle and Associates, an IP network consultancy. Jeff is the author of Routing TCP/IP, Volumes I (read an excerpt) and II and of OSPF and IS-IS: Choosing an IGP for Large-Scale Networks. He is a frequent speaker on IPv6, MPLS, and large-scale routing.

Contact him.

RSS feed XML feed

Jeff Doyle archive.

Cisco Subnet

RSS feed Cisco news RSS feed

The opinions expressed in this Weblog are those of the writer and may not represent the opinions of Network World.

Advertisement: