Hi and welcome to cyber dot i t. My name's Anthony and I'm your local subject matter expert for Network Plus And today we're gonna be talking about using appropriate software tools to troubleshoot connectivity.
So now that we've talked about some of the hardware tools that we use in order to diagnose our network connectivity, let's talk about some of the software tools. Now, sometimes some of the software tools ca NBI, even Maur, if not just as if not more informative than using the hardware tools itself
and one of our most powerful software tools is going to be a pro to our protocol analyzer.
Now we've talked about protocol analyzers a little bit in our previous module, but let's get into them a little bit more
now. Now, at this point, we're talking about the actual protocol analyzer software that we have installed on our device Now. Typically, this could just be a protocol analyzer, a packet capture software on aid on a computer that's just plugged into our network,
typically plugged into a mirror or span port, and this will allow us to capture all of the data that's going on, say, on our on our switch. We set up a span port on our switch and direct all mirrors of all of the data that's going on everywhere else to that span port. Then we're going to see everything.
So we plug in our computer, we start up wire shark, We start up Microsoft, the Microsoft Protocol analyzer, and we start capturing packets. Now, if to the untrained eye, this may just look like tons of lines of data, Uh, some I P addresses thrown in there, some protocols Shoni showing up.
And if we don't have a baseline established for what our normal network traffic looks like,
then really all we're doing is just capturing a bunch of big data. We're not getting anything out of it, but then we start taking a closer look at it.
We were noticing that none of our computers are getting an I p. Address. So we throw up our protocol analyzer and we see that we have all of these be HCP discover messages. But nothing is coming back. Well, that means that somewhere along the line, our d. C. P server isn't issuing back
responses. Maybe it's out of addresses. Maybe it's turned off.
Maybe the service has turned off. For whatever reason, these devices are sending out B A. C P Discover messages, and they're getting on the network. But they're not getting a response back. Maybe we noticed there is a lot of network slowness no one can get on the network. No one can get out to the Internet. We pull up our protocol analyzer and we just see that there's broadcast floods. There's a broadcast flood going on.
There's Aton of broadcast traffic, and it's just
inundating our network and we can't get any traffic through. Well, maybe our spanning tree protocol has failed. Maybe there is a device that's miss configured on our network. Something going on.
We can see. We can open up our protocol analyzer and we can see that someone is doing is performing a Thanh of our requests. They're doing a ton of ping requests or they're just scanning ports. Well, there may be someone malicious out there trying to scan our computers to see if they can try and break into any of them. If there's
see if there's any vulnerabilities or any open ports that they can try to take advantage off,
protocol analyzers are very, very useful and they can do a lot for us and they can give us a lot of insight into our network. But one of the best ways in order. One of the best things that we can do when we first set up our protocol analyzers in order to help us is to create a baseline.
Ah, baseline is essentially a capture for a certain period of time, of our network traffic under normal operating conditions. This allows us to take that capture and then compare it later to another capture. When we're noticing that something's not quite right in order to see if we can identify, you know
which of these things is not like the other. We take our captures and then say OK, I have a lot more of this
where I have a lot less of this in this capture than in this capture. It's normal, and baseline is normal, standard operating operating functionality that we could compare. We can compare odd traffic against to find what's not right.
There may be a certain network where we just have a lot of broadcast requests. For some reason, that may be normal. We may have a network that we have a lot of AARP requests that may just be normal. We may have a device on our network that we have configured to go out and scan ports occasionally, or we may have, say, a server, which has which has a
certain software on it that goes out and scans for new hosts.
Okay, that does a scan. Occasionally, may we have something like Spice Works or we have, ah, Symantec anti anti malware on our network that scans for hosts that it hasn't seen before to see if there's anything on our network, and so the port scanning on occasion, maybe regular. But we won't know that unless we have a baseline that we can compare against.
So when we're setting this up
under normal operating procedures, create a baseline. Take a look, see if there's anything that's odd. If not, save that on your say that on the network somewhere. Say that on your device, and then when odd things happen, you can throw your protocol analyzer and then compare the odd traffic against the normal traffic.
Next we have our throughput. Testers now are throughput. Testers are going to simulate network traffic So
I say we set up. We made some changes to our network. We configure some switches a little bit differently. We configured are the routers a little bit differently, and it's
9 p.m. On Sunday night, and we came in to do all this configuration. But we don't want to go into production Monday morning and everything falls to pieces. We want to be able to simulate some network traffic, and we want to be able to make sure that connections can get from point A to Point B
without having to have 50 people come in and try doing work.
So with that, we can use some of our three put testers. Now we can use our throughput testers just to test from one point to another. Or we can use our throughput testers in order to simulate a stress tester. Now, when we stress test, our network were essentially trying to push our network to the limits without crashing it.
We're taking it. We're taking several divide. A couple devices
were just having them continuously, push out requests and push out requests and try to push out traffic and try to download traffic from other hosts. and by doing that were essentially simulating a working production environment at top performance in order to see what made go first.
Now way. Obviously don't want to do this while we're in production. We don't want to take,
uh, Monday, Monday morning at 10 a.m. and start stress testing our environment because then if something goes down than everybody else on our network will also be down when they're trying to work. But choose a time when where are if we aren't a 24 hour, 24 7 shop, choose a time when most people are gone.
maybe in taking a day from the weak and not coming in, but then coming in on the weekend and stress testing your environment or doing so remotely even, perhaps, and being able to use thes throughput testers using the software throughput testers to test our environment and especially have to again, especially after we make changes
and see if there's any particular bottlenecks that we need to take a look at,
or any place that our traffic really slows down and is unable to get through as well. Next, we have our connective ity software now are connective ity software is going to provide us with either continuous or a periodic testing to see if we have a certain device is online. If we can connect to a certain device. This may allow, especially system administrators,
to make sure that all of their devices all of their servers that they need, that people need to access
our online without them continuously having to check every single server every two minutes. So these this software can be configured on a server. Or maybe if we have a website that we have stood up, we can sign up for an online service
where a offsite location tries to continually send a request to our website to see if they can get it could initiate a
initiate a small packet connection. Maybe it does so once every five minutes are once every two minutes, depending on how often we want to make sure it checks.
And this simply just verifies that our systems are online. It may send http request, or it may just send a standard I see and peeping request just to see if it can check and see if our computers online or check and see if a certain servers online, and then we can configure certain warnings to send alerts if our devices down.
Think of our if we have a certain file server on our network
that we need to know that we set up software and we want to make sure that it can let us know when it goes down. Well, if someone if a mouse chews through the power court of that server and the server goes out immediately, If we don't have a battery backup on that server or the mouse chewed through the power cord inside the server somehow
that server can't send us an alert that says it went down because it's off a computer that's off. Can't really do anything for us. So we need to have other software configured that's trying to connect to that server that says, Hey, wait a second. I'm not getting an ICMP echo request back. I'm not getting a response back.
So what I'm gonna do is okay. I didn't get
I'm gonna send a packet of four. I'm gonna send four icmp echo requests. One no response to no response. Three. No response for no response. Okay, that triggers my flag.
So now I'm going to send an alert via the email address that I have configured. And I'm gonna send an alert to the system administrator to make let him know that the system is down. So depending on how often are how often we have our system trying to connect to that device, maybe we have it set for two minutes or five minutes.
our period, our periodic time of how long we have wait, waiting between when we try to ping the device, that's that's how long were down. So at the most. So we're down for five minutes the most or two minutes of the most. Before we know that we're down rather than having to wait for someone to call us and say,
Hey, I can't access my file on the file server, something going on
and then we try to access and we say, Oh, it's down.
So rather than spend, rather than being down for an hour, an hour and 1/2 we know hopefully before anyone else, and we're able to go and start working on it and trying to fix it immediately. So connective ity connectivity software again can be internal, so we can set it up on a local device that tries to paying local servers.
Or, if we want to make sure that people on the Internet can constantly connect to our devices,
that we may outsource or may sign up for a Web based service that will try to connect in to, say, our Web server and make sure that it can connect to our our internal devices or otherwise sickness and alert if it cannot.