In this video, we're going to discuss collisions
and broadcast storms, how to identify 'em
and how to overcome them.
First collisions.
A collision occurs on your network when something happens
to the data as it's sent through the physical network medium
and it's prevented from reaching its final destination.
Now, most of the time a collision occurs when two hosts
on the network are transmitting at the same time,
and therefore their signals get combined
on the network medium and become unreadable.
Now, a collision can occur in both wired
and wireless networks.
If you think back to earlier lessons on ethernet,
you learned how CSMA/CD work
or on wireless networks, how we use CSMA/CA.
You remember that collisions are possible
on both of these type of networks,
and we have to figure out a way to get through them.
Now, to prevent collisions,
you need to architect your networks
with smaller collision domains
because this decreases the chance of a collision happening.
A collision domain is a network segment
connected by a shared medium or through repeaters
or simultaneous data transmissions
can collide with one another.
Now, if we connect all of our devices to a hub,
all of those devices are going to share
a single collision domain.
Similarly, if we're all connected
to the same wireless access point,
we're all going to be treated as being a part
of the same collision domain.
To break apart those collision domains
into smaller collision domains,
we need to use any Layer 2 device,
like a switch or a bridge.
Now, when we replace a hub with a switch,
each switch port becomes its own collision domain,
and this completely prevents all the collisions
from occurring on that switch port between the switch
and that client device
if you're connecting it directly to it.
So how can you detect collisions and why are they so bad?
Well, the first indication
that you might have excessive collisions
is when your network performance starts to go bad.
After all, anytime you have collisions
on an ethernet-based network,
the devices are going to pick a random back off timer,
and then they're going to retransmit.
So if you have a collision,
it now requires two additional transmissions
to get that data sent back out from the sources
to those destinations.
If you have a lot of collisions,
this causes an exponential decline
in the performance of your network's throughput.
Another way you can more accurately determine if collisions
are occurring on your network
is to run the show interface command on your network device,
and then look at the statistics
for the different switch ports.
Let's take a look at a few examples here.
First, let's look at this example
where we can see the collision counter is increasing.
We expect to see zero collisions,
but as the collisions begin to occur,
the interface statistics are going to start climbing upwards.
If you're using hubs in your network,
you're going to have some collisions occur, and that's fine.
This only becomes a problem
when you start to have too many collisions
and your network performance starts to deteriorate.
That said, if you're running a switch based network
and you really should be, then you shouldn't have
collisions occurring, and this would be an indication
that something is not working the way you designed it.
Next, we could also see the deferred counter increasing.
Now the deferred counter is going to count the number of times
the interface has tried to send a frame,
but they found the carrier busy at the first attempt.
This is called carrier sensing.
Again, if you're running a switch,
you should not see a deferred counter rising
because nobody should be waiting to transmit.
Now, if you're using a hub-based network,
this is going to be a normal part of your network operations
and it shouldn't be a concern.
Next, we have late collisions.
Now, this occurs when a collision is detected
after 5.12 microsecond, which is the amount of time it takes
for the 512th bit of a frame to be sent.
This is displayed under the late collision counter
in the interface statistics.
A late collision by itself indicates a problem
but not the root cause.
Instead, the cause is usually an incorrect cable being used,
a bad network interface card
or the use of too many hubs on the network.
Finally, we have excess collisions.
Basically, there is a limit to the number
of times a device can back off from transmitting
and wait when it experiences collision to retransmit again.
When the collision occurs,
it's going to choose a back off timer,
and then it tries retransmitting again.
If it detects another collision,
it picks a new back off timer and tries again.
It'll keep doing this for up to 16 times,
but on the 16th time, it's going to give up
and simply just drop that frame.
In this case, it's marked by the interface statistic
as an excessive collision.
Now, if you want to display the exact number
of excessive collisions, you can enter the command
show controller ethernet on your network platform,
and the excessive collision counters will be displayed.
If you're experiencing excessive collisions,
this is going to indicate a problem in the network.
Usually, this is caused
by devices using full duplex communication
over a shared ethernet segment, like a hub
or you have a broken network interface card,
or you simply have too many clients connected
to the same collision domain.
To overcome an excessive collision issue,
you should turn off auto negotiation for the speed
and duplex of an interface, hardcode the speed
to a lower setting, and change the duplex
to half duplex instead of full duplex.
These speed and duplex settings can be configured
on the networking device or on the client itself
within the Windows, Linux, Unix, and OSX
operating systems under the network adapter settings.
Next, we need to talk about broadcast storms.
Now, a broadcast storm occurs when a network system
is overwhelmed by continuous multicast or broadcast traffic.
Broadcast storms are dangerous to your network
because they can quickly overwhelm switches
and other devices as they struggle to keep up
with the flood of packets that's trying to get processed.
When a broadcast storm occurs,
your network performance is going to decrease rapidly,
and the worst case is it can cause a complete denial
of service in your network.
Remember, a broadcast packet is addressed
at both Layer 2 and Layer 3.
On Layer 2 devices,
the address is FF:FF:FF:FF:FF:FF.
Now if it's at Layer 3,
you're going to see the IP address used
of 255.255.255.255.
Now, a broadcast domain is a logical division
of a computer network in which all of your nodes
can reach each other using the broadcast
at the data link layer, which is Layer 2.
Now, a broadcast domain can be within the same local area
network segment, or it can be bridged
to other local area network segments as well.
Remember, a switch and a Layer 2 device will not break up
broadcast domains because they bridge these things together.
Now instead, you have to reach a router
or a Layer 3 switch to break up the broadcast domain
into smaller broadcast domains.
In general, there's just a couple of main causes
for broadcast storms occurring in your network.
First, you have a singular broadcast domain
that's just way too large.
In this case, the number of clients
will simply create a broadcast storm
when they're conducting their normal operations.
For example, if you have a large enterprise network
that has numerous switches,
they're all interconnecting the network.
This is going to create a really large broadcast domain
because again, switches don't break apart broadcast domains
like a router does.
So if you have a large broadcast domain set up
using ClassB Private Address Ranges like 172.16.0.0/16
you could have up to 65,534 usable IP addresses
and host on that one broadcast domain,
and that's a really large broadcast domain.
Instead, you should break up that broadcast domain
by subnetting out the Class B network into smaller networks
to reduce the number of broadcasts being generated
by those clients on the network.
Between each subnet you're then going to use a router
or a Layer 3 switch
to break up those subnets into separate broadcast domains.
Now, our second cause of broadcast storms occur,
we have a large volume
of DHCP requests on a given broadcast domain.
Whenever a new host connects to a broadcast domain,
they attempt to get an IP address assignment
using the DORA process
of Discover, Offer, Request, and Acknowledge
using the DHCP protocol.
Now, the D or Discover part of this process happens
as a broadcast packet
because the new network client doesn't know the location
of the DHCP server yet,
so this can create a storm of broadcast packets
if the network has a lot of clients try to negotiate
for an IP address all at the same time.
For example, let's say your network device reboots
and all the clients attempt
to renegotiate their DHCP leases,
that can cause a broadcast storm.
If you see a broadcast storm as being caused
by your DHCP configurations,
you need to check if you're using DHCP relays
between your different VLANs.
If you are, you're essentially allowing these VLANs
to be treated as a single broadcast domain for the purposes
of DHCP discovery, and this can lead to broadcast storms
if you have a very large network with a lot of clients.
The third cause of broadcast storms occurring on a network
is going to occur when loops are created
inside of a switching environment.
If you happen to have unmanaged switches
and somebody accidentally cables them together,
this can create an unintentional loop
and this can lead to broadcast storms.
To prevent these, make sure you're enabling BPDUs
or Bridge Protocol Data Units on your managed switches.
Also, you should enforce a maximum number
of MAC addresses per port
because this will also shut down a port if a broadcast storm
starts to go on through that port.
So how can you identify if you're having a broadcast storm?
Well, one of the easiest methods
is to look at your packet counters.
If you know your normal baseline for your network,
and now you see it rapidly increasing way faster
than you normally do, this could be an indication
of a broadcast storm.
For example, let's say you're running a network
that you're used to seeing about 10,000 packets per second,
and now you're seeing 100,000 packets per second.
This could be indicative of a potential broadcast storm.
In this example, you can see our average broadcast
is around 8,700 packets per second,
and we rarely go above 20,000 broadcast packets per second.
So if I see a spike upwards to 100,000 packets
or more per second,
I would know I have a potential broadcast storm on my hands.
Now, another way is to look at your network monitoring tools
and determine the packet loss on your network.
If a broadcast storm starts to occur,
your network devices are going to have a hard time keeping up
with the processing of all the packets on the network,
and so packet loss will rise exponentially.
Now, the most definitive way
to identify a broadcast storm though
is to set up a packet analyzer like Wireshark or TCPdump,
and then you start collecting the traffic on the network.
As you look at that traffic, you're going to look for packets
and see if there's a lot of broadcast packets
that are occurring rapidly.
If so, you're suffering from a broadcast storm.
In this example, you see a Layer 2 broadcast storm
occurring due to an enormous amount
of ARP broadcast being conducted in this network.
Now, in this example, I'm using TCPdump
to see all the broadcast traffic on the network.
To do this, you're going to run the command tcpdump -i,
and then your interface ether broadcast and ether multicast.
This will run TCPdump and only display broadcast
and multicast packets to the screen.
In this example, you can see there are a lot of ARP requests
that are going on because there's a broadcast storm
that's starting to happen.
Remember, the best way
to prevent a broadcast storm is either set up
loop preventions like using BPDUs,
limiting the number of MAC addresses
that can access a given switch port,
and breaking up large broadcast domains
into smaller broadcast domains
using routers and multilayer switches.