Importance of Network Diagrams

dontstop

Howdy all,

This is aimed more at the CCNA/CCNP folks out there. My question is: How much do you rely on Network Diagrams? Once designs get complex (I guess simple networks also can be the case) how much faith do you put in the logical on paper diagram vs. what you can physically see in the rack? I've always tried to understand the Network in my head, Once they get complex it all starts to break down. So do you normally find you forget how it's physically connected and just believe the diagram (always checking physical for obvious reasons)

I've seen a lot of younger network admins take pride in knowing the network via Physical understanding but is this something that pails in comparison to the logical design (what is represented in a diagram)

Thanks,
ds

networker050184

Depends on how up to date the diagrams are kept. Some departments keep them updated constantly, some it's hard to find anything that is years old.

Either way the diagrams are just a guideline. I always double check in the equipment before making any actual configuration changes.

dontstop

So would you say it's a mix between understanding diagrams and checking configurations/port settings vs. Knowing how it's all wired up?

networker050184

I don't ever physically go to any gear, its all too far away so I have no way to see how things are wired up. If it was a smaller network where you can physically go check then that is obviously the most accurate way to see how things are physically connected. You can be 99% certain by checking the config, CDP etc though.

Knowing the logical design is just as important as well. Knowing how it's connected isn't going to really help you all that much with your STP topology and things like that.

alanaround

I will use network diagrams (where available) as a starting point to get a general lay of the land. Once i've got an idea of how it's physically connected i'll hop on a device and take it from there, make my own notes.

I could troubleshoot and fix most issues by connecting to the devices and no documentation vs just looking at a document and not knowing passwords to key devices.. but colourful pictures and diagrams do help and it keeps the management happy.

nerdydad

NEVER trust the diagrams, sure, look at it to get a general idea, but always do discovery! LFMF

Sett

When the network becomes fairly complex, simple drawing of the physical setup won't help much. A well written design document is what you'd need. However many engineers don't bother writing these.

f0rgiv3n

I think network diagrams are extremely important. They are so very useful if anyone comes in from behind you and they need to understand what's going on in a pinch. Another example is if you have many different sites/networks and can't have it memorized what happens when you get called at 3AM about one of those sites? Are you going to quickly go "Oh, this is that site they have a b and c". The truth is maybe, but not always. If you have network diagrams to refer to it helps with immediate reaction. When I worked for a MSP, I created diagrams for every client and it helped me and many others troubleshoot any problems that decided to show up.

The other area I use them in is to explain new designs/implementations to others. They can be either network-inclined or not but the diagram is designed depending on their technical understanding.

We network engineers might know our network but not everyone else will. It's better to have a documented, easy-to-understand view instead of it being "tribal knowledge" only. The network isn't magic, just like virtualization isn't magic, people who don't understand how it works just see it as a big blob of magical power. By creating a visual of the network, it brings it to life and helps people understand what is going on in the background.

By helping others see what's going on in the background this will help lower the number of "blaming the network" tickets just because they ran out of options. Sure, it won't get rid of it; but it will hopefully stop some physical layer problem tickets from being escalated up to the engineering level .

/end passionate soap box speech

tpatt100

I annoy our guys here to make sure network diagrams are kept up to date and they do it. I have to refer to them for audits when I have to explain something

f0rgiv3n

Two thumbs up and kudos to you for being the proponent for documentation that is useful

RobertKaucher

I just want to comment that developers should see these diagrams as well. If all a dev ever does is imagine the network as a cloud, they will design systems poorly at best. This is why DevOps is so important. Being involved with the design of the systems that are being built can also influence how Network Engineers design the physical network. This is a highly important conversation that devs and the network team need to have on a regular basis.

A DevOps primer for network engineers

Mrock4

Diagrams are extremely relevant in complex networks. In my position, I do a lot of new design/installs, and I cannot hand over a network with no form of documentation...especially when some of the people who will be maintaining the network i designed are often not very experienced- so it's even more important the diagrams are filled with relevant, accurate information. As an added note, without accurate diagrams, you're at the mercy of your current engineers and their historical knowledge. What if John, the lead engineer who knows all about your network- walks out one day, gets sick, or takes a new job? You now are up the creek. With good diagrams, a good engineer will be able to fill the gap..or should be able to.

Little story about diagrams: One network I was working on had 4x Nexus 7K's, 8x Nexus 5K's, and about 30'ish 4510R's at the access layer. One day, I got a call that the entire network was down and they needed help. I took a look, and realized pretty early on there was some sort of routing issue. My problem? They had NO diagram (I didn't install this network!)..and I had people breathing down my neck to fix their network. I ended up fixing the issue (it was a fiber-gone-bad, but not bad enough to bring down the port-channel..causing severe degradation to only select traffic, since the port-channel hashes were load-balancing based on source/dest IP)..They implemented UDLD after this). The catch? I was so irritated at having NO reference documentation, that I diagrammed their entire core (literally 50+ redundant links) after the fact, and provided them with the diagram later.

DevilWAH

I have seen diagrams that or over the top as well though. Or at least there was no granularity, every little bit of info was on a single huge VISO digram, and it there where no layers to remove to make viewing easy. Zoomed out it was just a mass of lines and blocks. Impossible to make sence of as you could not get an over view of the logical structure.

Many networks are module and in my view detailed diagrams should be matched to logical sections, with higher level simple overviews showing how it all links together.

I agree with Sett, Digrams are just one part of documenting a network, they are not always the correct way to recorded the set up. Bad diagrams are no better than no diagrams.

Mrock4

Absolutely, I'd still prefer a bad diagram over none. When I show up to a customer site, I'm expected to already know their network- not spend a day playing around on it to find out how things are setup. Of course, there's an assumption there that we've been provided with diagrams by our customers..and generally that is part of the agreement in our contracts.

kj0

A couple of weeks ago I create a drawing of our Center of Network stack. It is 5 HP 5820 SFP switches, and I made it that each fiber run from the fobots were in alphabetical order for each building. We link aggregate most of the switches so that A block is into 1/0/1 and 2/0/1 then B block 1/0/3 and 2/0/3 etc. Each port is colour coded to the type of connection. So teal for OM-3, Yellow for OS-1, Bright green for 10gb om-3. etc...


IT isn't one that will be needing updating that often, but we do have another network diagram for all our edge switches and router. It's all viewable on an intranet page. it also uses SNMP to tell if a switch is down or not.

WE also have visio drawings of our Center of Network room, all 6 racks and all their servers and gear. It too won't need updating for a while, but since myself and another person have been here. Keeping a clear doco on all changes to the network is key, and something we both strive to keep up to date.

RobertKaucher

kj0 wrote: »

WE also have visio drawings of our Center of Network room, all 6 racks and all their servers and gear. It too won't need updating for a while, but since myself and another person have been here. Keeping a clear doco on all changes to the network is key, and something we both strive to keep up to date.

I just want to say that this is commendable and this should be something driven from the top. You really know when the company has seen the value from this documentation when keeping it up-to-date is being driven from the top down, though. That's when the bosses have seen that having up-to-date documentation can improve the performance of multiple departments.

kj0

When I setup any clients with new computers, or networks I also keep as much documentation as i can in regards to their setup of servers and roles, IPs, and software. That way when I get a phone call i can help them over the phone a lot easier. Or if I go to a site, I know exactly the set up and can sit down straight away.

CodeBlox

Network diagrams helped me troubleshoot a routing issue here at my current gig.

Mike-Mike

I use Network Diagrams almost daily at my job

undomiel

I create network diagrams that are promptly ignored by everyone, unfortunately. So I end up fielding calls where I keep having to tell them to check the documentation. One of these days I'm hoping it will sink in.

Roguetadhg

I like documentation. Documentation is my friend. I won't remember what X goes to down the road, or what un-listed links go where.

Docuementation? I love it. Breath it. Makes my job easier. Need Pictures? Bam. Need layout of the network? Like awesome. With one thing to note: Make sure the docs are up to date. Nothing like cursing at yourself for not documenting something important. I've had that happen where my docs were outdated. That was a lesson learnt.

wes allen

How are you all managing your diagrams / documents? Last place I worked, I set up a sharepoint site for everything. Was very helpful for the next guy for sure.

Mike-Mike

We use a sharepoint site

Corza

Very important! Nothing worse than having to try and figure out what another network admin was thinking and having to draw your own up anyway! Always nice to have a starting point.

CodeBlox

wes allen wrote: »

How are you all managing your diagrams / documents? Last place I worked, I set up a sharepoint site for everything. Was very helpful for the next guy for sure.

Heh, people do not believe in breathing documents... Most times people end up with their own copies of documentation that they update and never share. Two people never have the same piece of documentation. We do have Sharepoint set up too.

WiseWun

Network diagrams are crucial when your working for/with ISPS and dealing with hundred thousands of customers. I pull up dozens of diagrams each day for each customer site, also device configs/CDP helps a lot.

DevilWAH

My way of documenting has always been. If I came in fresh and sat down at the computer, how long would it take me to understand what was going on?

No bit of information should be more than 3 or 4 clicks away, and every thing should come back to a single portal/document from which you can drill down in to. The last thing some one who does not know the systems wants is to be looking through 2 share point sites and 5 network drives!

Starting every thing from a single documents makes tracking your documentation much easier to, as you find the top document has the generic over views and you drill down in to the detail as you need it.

dontstop

I've always found it difficult to comprehend a network once it came to physically cabling it up when labbing. I think because I lacked diagrams I found it hard to visualise the connections. So I really struggled when all the equipment was stacked up and didn't represent a logical layout. After reading this thread I think I'll be making sure to put a little more effort into logical diagrams before labbing and then using that as a guide for my physical equipment.