Alright, so welcome back.
We're looking at a couple of the questions that are coming in.
I see specifically questions revolving around storms.
Our next, our next module will be on storms.
But one of the key things to remember about storms is
it's generally something broken on your network,
and that is creating additional traffic to be sent out.
And this could be, this could happen for many reasons.
And now simplistically, we talked about, let's say, hardware failure where
you have, let's say, a malfunctioning NIC card,
and it's the very, most basic example.
But it might just keep spilling out bad information and by doing that
it's creating a lot of traffic on the network
and it's making your devices work overtime.
So, for every piece of data that a device like a switch or a router takes,
it's going to take it, strip it, read inside of it,
rebuild it and send it out again and
it's not just doing that, it's doing a lot of other functions.
So, if you like, look at your, show your processes
on your system like your CPU, your buffers,
and you're seeing a lot of tiny packets, or you're seeing a lot of activity,
you're seeing issues with STP as an example,
you could have a broadcast issue.
You can look at the interfaces and example if you look at the show interface
and you see a high amount of incrementing broadcast or multicast traffic.
There's a lot of ways to see storm-like activity on your network.
But just remember, it may not always be a storm.
You may have a lot of multicast enabled devices
or you may have a misconfigured, or I should say,
you should have, you may have a
improperly configured or non-optimally configured
multicast routing system where you're doing like PIM and it's just sending out all
interfaces where it may only need to go one way.
You may have a situation where it's really an issue
where somebody plugged something into the network
and we'll look at this in the next module.
But somebody plugged something into the network, created a loop,
because maybe you didn't have STP configured correctly or somebody hubbed in.
Or you had STP disabled which I've seen a few times
where the wrong thing plugged into the network
can create a gigantic storm, and take out your network.
So, that's pretty much the segway into moving into our next module
which is on broadcast storms.
So, what exactly is a broadcast storm?
So, broadcast storms are excessive requests and responses to these requests
that create a gigantic or unwieldly amount of traffic on your network.
Many times caused by loops, we'll talk about that briefly but
it could be caused by many other things.
It's not necessarily something that is just caused by a loop in your network.
As we have mentioned earlier, it could be caused by a, a misconfiguration.
It could be caused by something that is configured correctly but not optimally.
It could be caused by something that's damaged.
So essentially, a broadcast storm is a ton of traffic
that's sent to and from and is causing likely your network to deteriorate,
and or completely, beyond usable.
So, let's take a quick look at
an actual broadcast storm and we'll talk about this for a moment.
Alright so here, we see specifically, a storm.
And the way that we see that is we can see basically broadcast of all apps going out
to many different hosts, and it just keeps asking all over and all over and
over and over again.
This is in fact, a storm. This is one of those captures where
it's very quick and easy to see as soon as you open it up
that you do have some type of storm-related activity.
You didn't really need to dig too deeply into it.
This is a pre-capture filter so we only captured ARP on this one.
But if you had to sort, obviously you would just filter for ARP.
And then once you did, you'd be able to take a look and drill down into the this.
But again, as you can see very clearly
there's just constant broadcast sending out data on your network.
So, now that you understand a simple view of a broadcast storm,
again, it's important to understand that this could completely
paralyze that segment or your network in general.
It could do a lot of damage that you may not be aware of.
And it can cause excessive I/O on your systems where
it's trying to process all that information
and it may not be able to do so and it may completely overwhelm the system.
So again, what is a loop?
If you have a loop in your network, this can be caused by
Spanning Tree Protocol, STP misconfiguration.
Maybe something got connected in and it wasn't expected.
We talked about this when we're talking about hubbing in to do analysis.
If you do not have port security set up,
and someone's able to connect a hub to your network,
and possibly create a loop that will or could possibly potentially take down the network.
Because what starts happening is a flood of information comes out,
it doesn't know how to appropriately balance or shut off one link and it just sends it,
floods it and then the receiving devices, their input/output or their I/O of the device
is completely taken up and, and it stops the device from doing other things.
So as an example, with a Cisco router,
if it's constantly, you know, processing things and is starting to take up all the CPU,
it goes into basically life, life support mode, you know, just start dropping services.
So, you may have problems trying to log into the devices.
This is very common, and very frustrating for those who are trying
to quickly get into a device to try to see what's going on on the network.
Another reason why Wireshark is a great tool -
you may not be able to get into your router to be able to isolate what the problem is.
There may be locking up.
You may see routing completely dropped off or be very unstable as well.
During this time, if it's constantly trying to weed out
and figure out what's going on here
and when you're using, let's say, as an example,
VSS pair, or you're using some other type of port control,
between devices, that may also impair the entire core or distribution of your network.
So, very important to remember, it's very, very important that when you look at a design
that you look at everything in a way where it's very clear to you
that you don't want, if you're going to have resiliency,
you're going to have redundant connections, you don't want to disable STP.
If you think that you're not going to use, let's say, port security as an example,
and someone's able to quickly hub in, create a loop.
and completely take down your entire network.
So broadcast storms are commonly caused and created this way.
And we've seen this many times in the past.
A couple of pointers - that we already mentioned this to you.
Make sure that if you're going to disable STP for whatever reason,
you've taken into consideration that these redundant links,
if something is set incorrectly, or something does happen on your network,
it could create a loop and it could completely overwhelm your network
and take it down.
So does Wireshark allow you to do as mentioned before -
sometimes during a broadcast storm
very difficult to get into the device to
to identify what the problem is.
It's probably contending with the, the storm itself.
You may not be able to get in very easily
to quickly identify if you have a storm.
You may be able to start setting up Wireshark, capturing the data as we looked at before
and start to figure out which MAC address might be correlated to creating the storm
as we saw it in the capture.
You can see that it is the same exact port everytime here.
So that's what, that's where you're starting to see,
ok well, I know exactly where it's sourcing from. I know that the destination is all f's.
It's a broadcast and it's sending it out everywhere.
But I'm starting to see where it's originating from.
So that's essentially what we're looking for,
figure out where it's originating from and to kill it so that it could stop generating the traffic
and we can move on to a stable and resilient network.
and continue productivity but again,
trying to find this problem within, within the switch, within the router,
within the devices is sometimes difficult.
Very easy to set up Wireshark, quickly capture this data,
find out the source issue and isolate it.
Isolate it to the segment where it's coming from
and hopefully to either shut off the port, unplug the cable or turn off the machine
or device and stop the storm activity from occuring.
As we've mentioned earlier, once you've captured this data
you can run a filter, a simple ARP filter.
There are other options once you start building out your filter
and you can look in and refine this data.
But by quickly running an ARP filter,
you can see if it's an ARP storm and
you'll again see, denoted by all f's in hex
and you could see that it's broadcast based.