Monday, December 6, 2010

Design: does it really matter for a network engineer?

A couple of days ago,
I was using a demo account on Safari Books, released to my university library.

It's nice and interesting to go through the whole Cisco Press catalog and look at titles and arguments that aren't strictly on my CCIE R&S track. There is always something that opens new ideas on my mind, something interesting and useful to read.

I started reading a couple of pages of the "NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures" book, just to have an eye on the cli commands, then I've seen a bit of "TcL Scripting for Cisco IOS".

Then I landed on "Top-Down Network Design, Third Edition", a book by Priscilla Oppenheimer.
Well, that book looks like non strictly technical, I guess there are no cli commands on it, but it has captured my attention on the interesting topics.

"Design: Logical and Physical architectures" for example (This is one of my favorite arguments, I almost ALWAYS like to chat about it)

It's difficult and require a lot of experience to develop a proper design for a network, even the smallest one, when starts growing, often design issues and mistakes will emerge.

Usually I found very prepared engineers that haven't already assimilated the difference between Logical and Physical, and I do most of times this example:

Given this physical topology:


How to realize this logical topology?


I'm shure all of you can configure this in a couple of minutes. (or maybe you will respond like "you have to recable it" or "it's impossible" [that happened!] )

But how to know when a physical topology, in other words "the way how we connect devices" will be scalable and support future changes and requirements?

Well, that book refers to a lifecycle called PDIOO (Plan Design Implement Operate Optimize)
Here the page, courtesy of Google Books:


All the phases are detailed enough to keep me thinking...
Too often I see these steps squeezed in a sort of lifecycle like this:

-Analyze Requirements becomes a Single Requirement: finish quickly and do the stuff working
-Develop Logical and Physical Design becomes Just Connect in a couple of free ports, who cares about design?
-Test, Optimize and Document Design becomes: skip it, must be done for yesterday :-)
-Implement and Test Network becomes: haven't it done yet?
-Monitor and Optimize Network Performances becomes: ping and keep it up as long as possible

The last phase is called "Retire" (see the next page on Google Books frame..).
Well, the retire phase did me thinking and thinking... a well designed network, has a plan to retire equipments, has an idea of when a solution or an implementation will become obsolete.
Hopefully has a "retirement plan", something like a part of the solution specifically studied for the retire phase.

That's amazing!

Try to explain it to the engineer that produly states "my old XY switch is switching frames since 10 years, why I have to change it? Only because it's 10 Rack U for 24 ports?" :-)

moral: You can be a good network engineer, but you MUST work with a good architect with a lot of experience to realize clean, working and scalable networks, otherwise you can do your job using your own criteria, keep networks working as best, but you will pay it in terms of scalability during the years.

(me for example... I'm still asking myself why I did "no switchport" instead of a trunk on switch XYZ years ago... now adding a new vlan will be easy...)

Marco

No comments: