-: Collisions and broadcast storms. 2 2
In this video, we're going to discuss collisions 3 3
and broadcast storms, how to identify them 4 4
and how to overcome them. 5 5
First, collisions. 6 6
A collision occurs on your network 7 7
when something happens to the data 8 8
as it's sent through the physical network medium 9 9
and it's prevented from reaching its final destination. 10 10
Now, most of the time, a collision occurs 11 11
when two hosts on the network 12 12
are transmitting at the same time 13 13
and therefore, their signals get combined 14 14
on the network medium and become unreadable. 15 15
Now, a collision can occur in both wired 16 16
and wireless networks. 17 17
If you think back to earlier lessons on ethernet, 18 18
you learn how CSMA CD worked 19 19
or on wireless networks how we use CSMA CA. 20 20
You remember that collisions are possible 21 21
on both of these types of networks 22 22
and we have to figure out a way to get through them. 23 23
Now, to prevent collisions, 24 24
you need to architect your networks 25 25
with smaller collision domains 26 26
because this decreases the chance 27 27
of a collision happening. 28 28
A collision domain is a network segment 29 29
connected by a shared medium or through repeaters 30 30
where simultaneous data transmissions can collide 31 31
with one another. 32 32
Now, if we connect all of our devices to a hub, 33 33
all of those devices are going to share 34 34
a single collision domain. 35 35
Similarly, if we're all connected 36 36
to the same wireless access point, 37 37
we're all going to be treated as being a part 38 38
of the same collision domain. 39 39
To break apart those collision domains 40 40
into smaller collision domains, 41 41
we need to use any layer 2 device, 42 42
like a switch or a bridge. 43 43
Now, when we replace a hub with a switch, 44 44
each switch port becomes its own collision domain 45 45
and this completely prevents all the collisions 46 46
from occurring on that switch port 47 47
between the switch and that client device 48 48
if you're connecting it directly to it. 49 49
So, how can you detect collisions and why are they so bad? 50 50
Well, the first indication 51 51
that you might have excessive collisions 52 52
is when your network performance starts to go bad. 53 53
After all, anytime you have collisions 54 54
on an ethernet-based network, 55 55
the devices are going to pick a random backoff timer 56 56
and then they're going to retransmit. 57 57
So, if you have a collision, 58 58
it never requires two additional transmissions 59 59
to get that data sent back out from the sources 60 60
to those destinations. 61 61
If you have a lot of collisions, 62 62
this causes an exponential decline 63 63
in the performance of your networks throughput. 64 64
Another way you can more accurately determine 65 65
if collisions are occurring on your network, 66 66
is to run the show interface command on your network device 67 67
and then look at the statistics 68 68
for the different switch ports. 69 69
Let's take a look at a few examples here. 70 70
First, let's look at this example 71 71
where we can see the collision counter is increasing. 72 72
We expect to see zero collisions, 73 73
but as the collisions begin to occur, 74 74
the interface statistics are going to start climbing upwards. 75 75
If you're using hubs in your network, 76 76
you're going to have some collisions occur and that's fine. 77 77
This only becomes a problem 78 78
when you start to have too many collisions 79 79
and your network performance starts to deteriorate. 80 80
That said, if you're running a switch base network 81 81
and you really should be, 82 82
then you shouldn't have collisions occurring 83 83
and this would be an indication 84 84
that something is not working the way you designed it. 85 85
Next, we could also see the deferred counter increasing. 86 86
Now, the deferred counter is going to count the number of times 87 87
the interface has tried to send a frame, 88 88
but, they found the carrier busy at the first attempt. 89 89
This is called carrier sensing. 90 90
Again, if you're running a switch, 91 91
you should not see a deferred counter rising 92 92
because nobody should be waiting to transmit. 93 93
Now, if you're using a hub based network, 94 94
this is going to be a normal part of your network operations 95 95
and it shouldn't be a concern. 96 96
Next, we have late collisions. 97 97
Now, this occurs when a collision is detected 98 98
after 5.12 microseconds, 99 99
which is the amount of time it takes 100 100
for the 512 bit of a frame to be sent. 101 101
This is displayed under the late collision counter 102 102
in the interface statistics. 103 103
A late collision by itself indicates a problem, 104 104
but not the root cause. 105 105
Instead, the cause is usually an incorrect cable being used, 106 106
a bad network interface card 107 107
or the use of too many hubs on the network. 108 108
Finally, we have excess collisions. 109 109
Basically, there is a limit to the number of times 110 110
the device can back off from transmitting 111 111
and wait when it experiences a collision 112 112
to retransmit again. 113 113
When the collision occurs, 114 114
it's going to choose a backoff timer 115 115
and then it tries retransmitting again. 116 116
If it detects another collision, 117 117
it picks a new backoff timer and tries again. 118 118
It'll keep doing this for up to 16 times 119 119
but on the 16th time, 120 120
it's going to give up and simply just drop that frame. 121 121
In this case, it's marked by the interface statistic 122 122
as an excessive collision. 123 123
Now, if you want to display 124 124
the exact number of excessive collisions, 125 125
you can enter the command show controller ethernet 126 126
on your network platform 127 127
and the excessive collision counters will be displayed. 128 128
If you're experiencing excessive collisions, 129 129
this is going to indicate a problem in the network. 130 130
Usually, this is caused by devices 131 131
using full duplex communication 132 132
over a shared ethernet segment, like a hub 133 133
or you have a broken network interface card 134 134
or you simply have too many clients 135 135
connected to the same collision domain. 136 136
To overcome an excessive collision issue, 137 137
you should turn off auto negotiation 138 138
for the speed and duplex of an interface, 139 139
hardcode the speed to a lower setting and change the duplex 140 140
to half-duplex instead of full-duplex. 141 141
These speed and duplex settings can be configured 142 142
on the networking device or on the client itself 143 143
within the windows, Linux, Unix, 144 144
and OS X operating systems 145 145
under the network adapter settings. 146 146
Next, we need to talk about broadcast storms. 147 147
Now a broadcast storm occurs 148 148
when the network system is overwhelmed 149 149
by continuous multicast or broadcast traffic. 150 150
Broadcast storms are dangerous to your network 151 151
because they can quickly overwhelm switches 152 152
and other devices as they struggle to keep up 153 153
with the flood of packets that's trying to get processed. 154 154
When a broadcast storm occurs, 155 155
your network performance is going to decrease rapidly 156 156
and the worst cases 157 157
it can cause a complete denial of service in your network. 158 158
Remember, a broadcast packet is addressed at both layer 2 159 159
and layer 3. 160 160
On layer 2 devices, 161 161
the address is FF FF FF FF FF FF. 162 162
Now, if it's at layer 3, 163 163
you're going to see the IP address used of 255.255.255.255. 164 164
Now, a broadcast domain is a logical division 165 165
of a computer network in which all of your nodes 166 166
can reach each other using the broadcast 167 167
at the data link layer, which is layer 2. 168 168
Now, a broadcast domain 169 169
can be within the same locally or network segment 170 170
or it can be bridged 171 171
to other local area network segments as well. 172 172
Remember, a switch and a layer 2 device 173 173
will not break up broadcast domains 174 174
because they bridge these things together. 175 175
Now instead, you have to reach a router 176 176
or a layer 3 switch, 177 177
to break up the broadcast domain 178 178
into smaller broadcast domains. 179 179
In general, there's just a couple of main causes 180 180
for broadcast storms occurring in your network. 181 181
First, you have a singular broadcast domain 182 182
that's just way too large. 183 183
In this case, the number of clients will simply create 184 184
a broadcast storm 185 185
when they're conducting their normal operations. 186 186
For example, if you have a large enterprise network 187 187
that has numerous switches, 188 188
that are interconnecting the network, 189 189
this is going to create a really large broadcast domain 190 190
because again, switches don't break apart broadcast domains 191 191
like a router does. 192 192
So, if you have a large broadcast domain setup 193 193
using class B private address ranges like 172.16.0.0/16, 194 194
you could have up to 65,534 usable IP addresses and hosts 195 195
on that one broadcast domain 196 196
and that's a really large broadcast domain. 197 197
Instead, you should break up that broadcast domain 198 198
by subnetting out the class B network into smaller networks 199 199
to reduce the number of broadcast being generated 200 200
by those clients on the network. 201 201
Between each subnet, you're then going to use a router 202 202
or a layer 3 switch, to break up those subnets 203 203
into separate broadcast domains. 204 204
Now our second cause of broadcast storms occur, 205 205
we have a large volume of DHCP requests 206 206
on a given broadcast domain. 207 207
Whenever a new host connects to a broadcast domain, 208 208
they attempt to get an IP address assignment 209 209
using the DORA process 210 210
of discover, offer, request and acknowledge 211 211
using the DHCP protocol. 212 212
Now, the D or discover part of this process 213 213
happens as a broadcast packet because the new network client 214 214
doesn't know the location of the DHCP server yet. 215 215
So, this can create a storm of broadcast packets 216 216
if the network has a lot of clients trying to negotiate 217 217
for an IP address all at the same time. 218 218
For example, let's say your network device reboots 219 219
and all the clients attempt to renegotiate 220 220
their DHCP leases. 221 221
That can cause a broadcast storm. 222 222
If you see a broadcast storm 223 223
is being caused by your DHCP configurations, 224 224
you need to check if you're using DHCP relays 225 225
between your different VLANs. 226 226
If you are, you're essentially allowing these VLANs 227 227
to be treated as a single broadcast domain 228 228
for the purposes of DHCP discovery 229 229
and this can lead to broadcast storms 230 230
if you have a very large network with a lot of clients. 231 231
The third cause of broadcast storms occurring on a network 232 232
is going to occur when loops are created 233 233
inside of a switching environment. 234 234
If you happen to have unmanaged switches 235 235
and somebody accidentally cables them together, 236 236
this can create an unintentional loop 237 237
and this can lead to broadcast storms. 238 238
To prevent these, make sure you're enabling BPDUs 239 239
or Bridge Protocol Data Units on your managed switches. 240 240
Also, you should enforce 241 241
a maximum number of MAC addresses per port, 242 242
because this will also shut down a port 243 243
if a broadcast storm starts to go on through that port. 244 244
So, how can you identify if you're having a broadcast storm? 245 245
Well, one of the easiest methods 246 246
is to look at your packet counters. 247 247
If you know your normal baseline for your network 248 248
and now you see it rapidly increasing way faster 249 249
than you normally do, 250 250
this could be an indication of a broadcast storm. 251 251
For example, let's say you're running a network 252 252
that you're used to seeing about 10,000 packets per second 253 253
and now, you're seeing 254 254
a hundred thousand packets per second. 255 255
This could be indicative of a potential broadcast storm. 256 256
In this example, you can see our average broadcast 257 257
is around 8,700 packets per second 258 258
and we rarely go above 20,000 broadcast packets per second. 259 259
So, if I see a spike upwards to a hundred thousand packets 260 260
or more per second, 261 261
I would know I have a potential broadcast storm on my hands. 262 262
Now, another way is to look at your network monitoring tools 263 263
and determine the packet loss on your network. 264 264
If a broadcast storm starts to occur, 265 265
your network devices are going to have a hard time 266 266
keeping up with the processing 267 267
of all the packets on the network. 268 268
And so, packet loss will rise exponentially. 269 269
Now, the most definitive way 270 270
to identify a broadcast storm though, 271 271
is to set up a packet analyzer like Wireshark or TCP dump 272 272
and then you start collecting the traffic on the network. 273 273
As you look at that traffic, 274 274
you're going to look for packets 275 275
and see if there's a lot of broadcast packets 276 276
that are growing rapidly. 277 277
If so, you're suffering from a broadcast storm. 278 278
In this example, you see a layer 2 broadcast storm occurring 279 279
due to an enormous amount of art broadcast 280 280
being conducted in this network. 281 281
Now, in this example, 282 282
I'm using TCP dump to see all the broadcast traffic 283 283
on the network. 284 284
To do this, you're going to run the command TCP dump-I 285 285
and then your interface, 286 286
ether, broadcast and ether multicast. 287 287
This'll run TCP dump and only display broadcast 288 288
and multicast packets to the screen. 289 289
In this example, 290 290
you can see there are a lot of AARP requests 291 291
that are going on because there's a broadcast storm 292 292
that's starting to happen. 293 293
Remember, the best way to prevent a broadcast storm 294 294
is either set up loop preventions like using BPDUs, 295 295
limiting the number of Mac addresses 296 296
that can access a given switch port 297 297
and breaking up large broadcast domains 298 298
into smaller broadcast domains 299 299
using routers and multi-layer switches. 300 300
(soft music)