Hi and welcome to Cyberia. My name's Anthony and I'm your local subject matter expert for Network Plus And today we're gonna be talking about different types of network management documentation. So when it comes to our networks, one of the biggest favors that we can do for not only ourselves but for also those who later inherit our networks is documentation
Now with documentation.
It's one of those things that not many people like to do it, but it is extremely important to maintaining the maintaining the integrity and maintaining a good management stance on our network. So when we're talking about our documentation, what types of documentation do we want to perform for our network? While one of the first
types of documentation we want to perform is our wiring scheme
now our wiring scheme is essentially the wiring in the information about our wiring infrastructure. What type of pin standards do we use our all of our straight cables et tu et orbi to be what type of cables do use in our ceiling or in our in our walls.
What type of cat cable do we used to? We used co axial cable. Are we using any fiber cable on backbones.
We need some cable maps and diagrams. Where did the cables actually run? Are there any spice points? Are there any repeaters, eyes there, anything that we need to be aware of any patch panels or any additional wiring closets? So our wiring scheme is essentially going to be the skeleton of our network,
not only physical diagrams of our network of our the wiring of our network,
but also information that will need to know if we ever need to expand our networks, such as our pin outs and what category of cable were using so that we know what type of throughput that we can expect. So we have our wiring scheme that we need toe put down in our documentation.
We also need thio do cable management. Now. Our cable management also goes ties in a bit with our documentation and network management. But our cable management is Maura about our cable neatness and the cable physical management of our cabling. Not only does this make this visual make our cabling visually appealing,
but it also helps us with cable identification.
If we have written down on our wiring schemes that okay the cables that plug the cable that's plugged into Port One is the cable that goes to a router. The cables two through five are this section of computers. Cables six through 10 are this section of computers,
and then someone goes into our network cause it and they open it up and expect to see our patch panel with everything nice and neat.
And it's just a jumble of wires. They're gonna have a much harder time even using our wiring scheme in order to identify cabling. Because everything. So everything's all jumbled up. So we want to keep visually appealing. We want to make it easy for cable identification, and this also improves cooling and safety.
If we have just big bundles and jumbles of wires that are stuck behind our devices that are stuck with our our switches and our routers, then we're gonna have a little bit more of an issue with cooling because it was gonna be harder for air to circulate. We also have safety issues because people can trip. People cannot be looking and inadvertently
trip over cables or pull a cable out because they weren't expected. They were not expecting it to be laying on the floor there,
so we need to be aware of that when we are doing cable management. However, especially with data cables, we need to be aware not to bundle them too tightly. Ever. Many people have seen pictures of data centers where the date or the cabling is
perfect eyes the perfect length and his bundle bundle just writing stretched across the ceilings and down the walls. And
you're like, Oh, that's that's amazing. That's great cable management. Now, when you're trying to replicate that, however, don't take all your cables and take zip ties and then pull those suckers as tight as you can and get those cables and really tight bundles. Number one you might cause breaks or shorts within the cable's number. Two Too many cables, bundled really tightly together
that are running parallel to each other, can cause electromagnetic interference.
The all the electricity and all the, uh, the electromagnetic interference that is being radiated off those cables is just
making it even more so with so many in a really tight bundle. So as nice as it may look and as easy as it may be, you need to be aware that we don't want to take cabling like that and just put it in these very big, really tight bundles because we may have issues with cable breakage or electromagnetic interference later on down the line or even immediately.
So do be aware of that.
Our next type of documentation is going to be our actual network maps. Now we're making our network maps we need to do both. Physical and logical layouts are physical layout is going to be just what it sounds like, a blueprint of wherever, whatever our location is
with our wiring scheme, as well as the different devices and where they're located physically, so that we can find them if we need to later.
But and then we also have our logical layout, which is going to be how our data flows. We may have a We may have a network which looks like a start apology because all of our devices are physically in our physical layout connected toe one single device.
But it may actually logically be a ring topology because that central device that's that is connecting to
passes around a token ring in order for the different devices to communicate. So we need to put both our physical in our logical layouts with our network maps. We want to include things like our I P addresses of our different devices we want include the divide, all of the different devices themselves.
We want to include any V lands or any sub nets that we have on our network and identify those in which devices are on those.
I want to include our topology tight when we're doing our logical lay out whether we're doing a rink apology or bust apology in which devices air, which we want to do our port maps we wanna include. If we have switches that airport managed and certain ports are meant for certain V lands and are connected to certain devices, we want to note that down
in our network maps. So for ever changing any ports were moving any devices to a different villian,
we know which ports we need to move them to without having to connect to the device. So
the better our documentation is, the easier it is on us. And the and the less work that we have to do in order to find something out if we just inherit if we just pass on a network to somebody because we move on somewhere else and leave them absolutely no documentation.
They're not gonna have a very fun time starting at your Demark point and tracing all the wires and running all the configurations to find out how your network ticks.
The best thing to do is to be able to hand them a binder or hand them Oh, are linked them to a network linked into a ah file or folder on your network and say, Here's our network documentation. It has the wiring schemes that has the network layout. It has the physical and logical topology. It has all of the device configurations and the poor configurations.
That's a much nicer thing to do than just handing somebody a building and saying
with in conjunction with our wiring scheme, we want also have our network maps. Ah, lot of times these 2 may be on the same type of documentations may be on the same busy oh, documents that we set up in order to make sure that they're very clearly clearly displayed.
If we need to do one big overview for our entire our entire building
so that we can our entire office space so that we can give the person who's reading it a good overview and a good idea of what's going on and how data gets from our public Internet to our private side. Then we can do that. But we also want to make sure that we include more detailed maps of individual network segments.
So we'll be able to say, OK, so these devices connecting to these ports and this device is configured with this I p address
and we'll have a more detailed idea of what's going on
and the next we have some miscellaneous documentation.
This is just gonna be a bunch of different types of documentation, different types of information we want to include in our network documentation. We wanna have our network topology. We'll have a wiring schemes. We wanna have information about device configurations such as their V lands and the device. Loggins. We wanna have
user names and passwords somewhere so we don't have to reset devices back to defaults
and redo all their settings just to get the log in user name and password in the log in i p address of that device. We wanna have our different port layouts and what different ports correspond to which computers we wanna have. If we're a systems administrator, if we're just doing the network side, this really doesn't concern us as much.
We wanna have the different server roles we wanna have
are different firewall rules in our different contact information, all included in this network documentation. So if we need to hand this over, we need to turn this over to somebody. We will have all of this information in one centralized place. Now the larger organization gets, or the more enterprise and organization gets,
the more all of this documentation is broken up and given to different groups,
the firewall rules are given to the security team. The device, the device configuration in the port layouts and the and the device. Loggins for the different switches and routers is given to the networking team. The server rolls and the and the servant roles are given to the systems administration team.
Networked apology and the wiring schemes are given to the actual people
who come in and wire our building. So each of these different each of this different network documentation is broken up and given to and specialize in two different groups. But despite who it goes to, it needs, It still needs to get done somehow. And there needs to be someone in charge of making sure that all that gets done
and is able to be in a location, that
it can be accessed by the people who need to know that information.
So take nothing for granted. Just because it seemed logical or seemed obvious to you when you implement it, it doesn't mean it's going to be logical. Are obvious to the next person. Doesn't mean it's gonna be logical are obvious to you in a month. So you need to make sure that you don't take for granted. That something is
is obvious or something just makes sense just by looking at it like, Oh, you can
you can you can look at that that patch panel with that with that switch underneath of it and determine that are drops. Go to the patch panel in the patch panel connects to the switch, which connects to the Internet, which goes to over to the router, which connects to the other router, which connects to the point of demarcation, which goes out to our Internet, then somebody who comes in after you may say What?
Why do we have three routers here? Why is why are these three routers connected to this switch, which are connected to this switch which is connected to this other router? Why don't we just do this like this? Well, they may start doing it like that and then say, Oh, now I understand after they've spent two weeks trying to redo the network.
So make sure that things aren't just taken for granted that you document everything that it is documented clearly. And you put in the reasons why you did something. And if you tried a different network topology or you tried something that didn't work, You may want to include things such as this.
Hey, handles traffic better than this type than this layout that we tried earlier.
You may want to include revisions, or you may want to update your network, but also keep the previous version saved, just in case we need to go back in. Review older versions of the network. We can't.
So keep that information handy. Keep it well documented, and it will make it a lot easier for network management, not just for you, but for the people who inherit your network after you.