Drawing out your topology before labbing?
dontstop
Member Posts: 579 ■■■■□□□□□□
in CCNA & CCENT
Before you ever connect a single cable in a physical lab do you generally diagram/plan out your networks on paper first or at least document/write down the configuration points/addressing?
I assume if you try keep it all in your head things can get pretty messy, fairly quickly?
I assume if you try keep it all in your head things can get pretty messy, fairly quickly?
Comments
-
OctalDump Member Posts: 1,722In a lab situation, I always work from a diagram. It might not be as detailed as "this port on this switch to this port on that switch" but it would at least be "this switch to this switch to this router" or whatever. But once connected, you will usually be configuring on a port basis, so you'd just pencil in those as you go ie SW1 Gi0/2 to SW2 Gi0/2 (that's another trick, to use similar port numbers on both sides to make it easier to remember how things are connected).2017 Goals - Something Cisco, Something Linux, Agile PM
-
dontstop Member Posts: 579 ■■■■□□□□□□Yeah that sounds a very reasonable approach, I've burnt myself a few times trying to keep everything in my head. When you finally start labbing you begin to forget how the logical layout looks and it all fall apart. I'll make sure in the future when labbing I'm atleast sketching out my topology first.
-
wseyller Member Posts: 44 ■■■□□□□□□□You should also do it in the real world. It is ***** when you take over a network and it was never documented. No labels on wall plates. No labeling on patch panels, etc. Even if label I believe in diagrams. You can take a diagram and you have 90% of what you need to troubleshoot a network issue.
-
OctalDump Member Posts: 1,722You should also do it in the real world. It is ***** when you take over a network and it was never documented. No labels on wall plates. No labeling on patch panels, etc. Even if label I believe in diagrams. You can take a diagram and you have 90% of what you need to troubleshoot a network issue.
What's even more fun is when they do label things, but the numbers on the patch don't correspond to the numbers on the data points. Or the "management IP" label on the gear is from 6 network redesigns ago, when the switch was at another site.2017 Goals - Something Cisco, Something Linux, Agile PM -
stunnedsoup Member Posts: 120What's even more fun is when they do label things, but the numbers on the patch don't correspond to the numbers on the data points. Or the "management IP" label on the gear is from 6 network redesigns ago, when the switch was at another site.
Our building's network closet makes me nauseous. It's spaghetti city in there. Cables upon cables that are different colors. Everything is labeled...labeled w/ these. When you walk in you see dozens of those tags laying on the floor w/ random numbers on them (14, 52, 55, 101, etc) from where they broke off from the cabling. I'm in consulting so I'm not the network admin for the building. But I want to re-cable and label everything when I'm not swamped. Then do a full topo so the IT dept doesn't take hours to sort through the spaghetti to see what's connected to what, where all the network drops are, etc. Bon appetit!Cisco: CCENT COLOR=#ff0000]✔[/COLOR CCNA COLOR=#ff0000]✔[/COLOR || MCSE: 70-410 COLOR=#ff0000]✔[/COLOR 70-411 [ ] 74-409 COLOR=#ff0000]✔[/COLOR 70-534 [ ] || VMWare: VCP [ ] -
OctalDump Member Posts: 1,722I think the expression is "it's a process, not a product". So you sketch out your plan, do the work, update the documents, do changes, update the documents and so on. Communicating what changes have been made is part of managing the change, and unmanaged change is chaos.2017 Goals - Something Cisco, Something Linux, Agile PM
-
dontstop Member Posts: 579 ■■■■□□□□□□Thanks for the feedback guys, I'm definitely more happy now that I'm drawing out my logical networks before racking up kit.