9 hours 49 minutes
here we go with a brand new module and our network plus course, we're going to begin with network operations. These are the day to day things that need to be in place so we can control our operations and make sure things go smoothly.
In this chapter, we're going to talk. First of all, about having network documentation specifically diagrams, processes and procedures so that anyone coming to the network can understand how the network is configured.
More importantly, in the event of some disaster where we would need to rebuild the network, we need documentation to refer to.
After that, we'll look at some basic generic policies and best practices that should be in place in the workforce to promote security and good network function.
Scanning, monitoring and patching, being aware of what's happening at the network at all times and making sure we're getting the best out of our performance and security.
Then we'll talk about fault management
with fault management. We're looking at needing redundancy of devices in case one device fails. We want to be able to continue our operations
that needs to be comprehensive. So if it's data or file redundancy, if it's hard drivers, servers or links. We want comprehensive fault managements that we cannot withstand downtimes
finally, disaster recovery and business continuity,
something I like to call what happens when bad things happen to good network admins With the disaster, we have some sort of high level incident that impacts our business.
How do we recover from that disaster?
How do we continue our business after the disaster?
This is what we have coming up for us in Module five.
Let's go ahead and jump right into the network diagrams and documentations.
It's good to know the standards based documentation.
These are universal, well accepted as illustrations.
When you're documenting a router, you can see the cylinder with the errors and switch. There's going to be the most common, but you also have a multi layer switch, P I X firewall and firewall and router capability.
You see the bricks on that? I'm not saying you have to memorize all of these, but I would certainly be familiar with the main ones. Routers switch, multi layer switch, firewall, router.
We also want to take a look at logical versus physical diagrams we're talking about. Logical diagrams are really considering how the networks are conceptually grouped together at a high level.
We're not showing all the details over on the right. You can see we have that physical diagram where we get very specific.
The PC goes to the face plate, goes to the patch panel, goes to the switch and goes to the firewalls.
This is really much more of an accurate physical diagram. Whereas looking on the left, we have much more of a general conceptual diagram that sort of describes connectivity without all the details.
They're both helpful because one will give us a big picture overview. That's a logical diagram, whereas I can really use the physical diagram in a disaster to rebuild my network
rack. Our rack system or our server racks are how we're holding our network equipment within these racks.
Usually a lot of the components of the racks look alike. It's not necessarily obvious the different types of switches or routers. We've got our r a I D sets, so we want our racks labeled with what we know. So what each component and elements is
change management documentation gotta have it
change management documentation and a change management process as a whole is going to help make sure that my network stays stable.
As a general rule, I'm going to implement the signs for my server and my workstations.
Whatever those systems are will each have a separate baseline, one set of baseline configuration or one baseline configuration for my end users, one baseline configuration for my domain controllers and one for my Web servers.
I'm going to take time configuring those images to make sure they're secure,
and they have all the elements they need. I want to make sure any changes go to the baseline, go through an authorized procedure and that we don't make changes to those baseline configurations on the fly.
Having a good change management process is going to require that I'll ideally have a change control board.
I can submit change request to the Change Control Board. They can evaluate the change, come back with a yes or no, and then we test the change in a lab environment before rolling it up.
Even for changes that don't get approved, we still need to document to keep track
change. Control is really important because I don't want to allow variation from my baseline unless there's a legitimate reason that's approved to do so.
Wiring import location. I love the good wiring. Bad wiring.
You can just tell the difference between the two.
Making sure that our cables are neat, labeled when possible is important.
It's very difficult to trace a cable to its location. When you have something like what you see on the right at the top,
we've got to consider the wiring for our aliens, W. A. N s and our home networks.
Again, the challenge comes as setting things up correctly from the start.
Then it's easy to build on to this.
If you're going to take over a wiring closet that looks like the top right, you've got a lot of work ahead of you.
Network configurations are equally important to monitor
not just how the devices are physically laid out or wired and connected, but also any sort of virtual connections as well.
We want to monitor the performance, and we want to have information that's stored on the baseline performance of these systems.
What's normal network utilization
on our servers? What's the normal process or utilization? How much paging do we have? Those sorts are hardware performance based issues because we're going to measure. When we go to monitor, we want to monitor for the baseline.
If we're pretty close to the baseline, you can assume things are going on as normal,
and we see that were drastically different from baseline performance. That may be an indicator that we have a problem
labelling an inventory management knowing or your stuff is and how it's configured, which goes back to change. Configuration management
configuration management usually has to do with changing settings on your device.
Change. Management has to do with the devices themselves. Different organizations will use those terms a bit differently.
Once again, it comes down to having a set configuration of my network and to control any modification to that.
Part of. This is going to be an asset management keeping track of what servers are. Laptops come and go and how that happened.
I have to be able to manage my inventory because I don't want to look around and be missing 15 laptops.
Standard operating procedures provide us with the steps of how to carry out the various work of the network. Like I t I l I T. Information library
procedures are really designed to provide step by step instructions to perform some sort of activity.
Here's some tumbling from I t I L
I T I l stands for I t Infrastructure Library.
One of the things I find is that what I'm trying to bring in new documentation to an organization, it's that it's best not to create these things from scratch,
having templates that go through incident response or change requests, and so on. Make things easier. And this is just an example of some templates. There are lots more on the Web,
just a quick review of the first section. We talked about the importance of diagrams, whether they're logical or physical diagrams of your network, diagrams of borax wiring that is properly labeled and documented, and having good change control and configuration management in place to make sure that those configurations we've documented don't change.
The idea here is to have a stable network. We have policies and procedures in place, and we document them if we don't know which policies are documentation. We have many organizations provide templates such as the one that we looked at with I t. I L