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