1 1 00:00:00,610 --> 00:00:02,240 Interface Statistics. 2 2 00:00:02,240 --> 00:00:05,080 In this lesson, we're going to talk about interface statistics 3 3 00:00:05,080 --> 00:00:07,910 and how it's used to monitor our network's performance. 4 4 00:00:07,910 --> 00:00:09,330 Now, if you're new to networking, 5 5 00:00:09,330 --> 00:00:12,420 you may be wondering what exactly is an interface? 6 6 00:00:12,420 --> 00:00:14,500 Well, an interface is just one of the physical 7 7 00:00:14,500 --> 00:00:18,140 or logical switch ports on a router, switch or firewall. 8 8 00:00:18,140 --> 00:00:19,580 In enterprise level devices, 9 9 00:00:19,580 --> 00:00:21,770 each interface can generate its own statistics 10 10 00:00:21,770 --> 00:00:23,910 and maintains its own status. 11 11 00:00:23,910 --> 00:00:26,560 In this lesson, we're going to explore the link state, 12 12 00:00:26,560 --> 00:00:28,250 the speed and duplex status, 13 13 00:00:28,250 --> 00:00:30,360 the send receive traffic statistics, 14 14 00:00:30,360 --> 00:00:32,510 the cyclic redundancy check statistics, 15 15 00:00:32,510 --> 00:00:34,530 and the protocol packet and byte counts 16 16 00:00:34,530 --> 00:00:36,640 that are collected for our network devices. 17 17 00:00:36,640 --> 00:00:37,940 To help guide our discussions, 18 18 00:00:37,940 --> 00:00:40,090 I'm going to be using the output from a Cisco router 19 19 00:00:40,090 --> 00:00:42,920 for an interface called f0/0, 20 20 00:00:42,920 --> 00:00:46,310 which simply means it's a fast Ethernet or Cat5 connection 21 21 00:00:46,310 --> 00:00:49,140 going from this physical interface on slot zero 22 22 00:00:49,140 --> 00:00:51,360 and port zero of a given router. 23 23 00:00:51,360 --> 00:00:53,940 Now, first you can see, we have the Link State. 24 24 00:00:53,940 --> 00:00:55,758 A link state is used to communicate whether or not 25 25 00:00:55,758 --> 00:00:58,470 a given interface has a cable connected to it 26 26 00:00:58,470 --> 00:01:00,990 and a valid protocol to use for communication. 27 27 00:01:00,990 --> 00:01:03,560 For example, if I connected a fast Ethernet 28 28 00:01:03,560 --> 00:01:05,290 unshielded twisted pair cable to the interface 29 29 00:01:05,290 --> 00:01:07,470 on 0/0 of this router, 30 30 00:01:07,470 --> 00:01:09,900 and then plug in the other end into another router 31 31 00:01:09,900 --> 00:01:11,050 to create a connection, 32 32 00:01:11,050 --> 00:01:16,030 I should see fast Ethernet 0/0 is up, line protocol is up. 33 33 00:01:16,030 --> 00:01:18,690 This indicates that the interface is physically up 34 34 00:01:18,690 --> 00:01:21,170 and the protocol is operational. 35 35 00:01:21,170 --> 00:01:23,540 If we're using Ethernet, that means that frames 36 36 00:01:23,540 --> 00:01:26,420 are able to be entering and leaving this interface. 37 37 00:01:26,420 --> 00:01:29,270 Next, we have some information about the interface itself, 38 38 00:01:29,270 --> 00:01:32,300 such as the MAC address and the IP address assigned to it. 39 39 00:01:32,300 --> 00:01:36,030 After that, we see there's an MTU size set of 1500 bytes, 40 40 00:01:36,030 --> 00:01:38,290 which is normally used by default in Ethernet. 41 41 00:01:38,290 --> 00:01:39,700 And then we have the bandwidth 42 42 00:01:39,700 --> 00:01:42,610 is being set at 100,000 kilobits per second, 43 43 00:01:42,610 --> 00:01:45,280 which is 100 megabits per second. 44 44 00:01:45,280 --> 00:01:47,690 This makes sense because I'm using fast Ethernet 45 45 00:01:47,690 --> 00:01:50,320 or Cat5 cabling for our connection. 46 46 00:01:50,320 --> 00:01:52,120 This speed is also used by the router 47 47 00:01:52,120 --> 00:01:53,570 when it's trying to calculate the metrics 48 48 00:01:53,570 --> 00:01:57,200 for the routing protocols like OSPF and EIGRP, 49 49 00:01:57,200 --> 00:01:58,850 since they rely on the connection speed 50 50 00:01:58,850 --> 00:02:01,890 in making their determinations and their link costs. 51 51 00:02:01,890 --> 00:02:03,810 Next, we have the reliability, 52 52 00:02:03,810 --> 00:02:07,430 which is being shown here as 255 out of 255. 53 53 00:02:07,430 --> 00:02:09,860 This means if the connection begins to have more input 54 54 00:02:09,860 --> 00:02:12,960 or output errors, you're going to see the reliability lower. 55 55 00:02:12,960 --> 00:02:15,910 Basically, you read this as reliability equals 56 56 00:02:15,910 --> 00:02:18,900 the number of packets divided by the total number of frames. 57 57 00:02:18,900 --> 00:02:22,510 So, 255, over 255 is the best reliability, 58 58 00:02:22,510 --> 00:02:24,770 and indicates there was no packets or frames 59 59 00:02:24,770 --> 00:02:26,390 that have been dropped so far. 60 60 00:02:26,390 --> 00:02:28,350 txload is our next statistic. 61 61 00:02:28,350 --> 00:02:29,450 And this is going to indicate 62 62 00:02:29,450 --> 00:02:31,610 how busy the router is transmitting frames 63 63 00:02:31,610 --> 00:02:32,860 over this connection. 64 64 00:02:32,860 --> 00:02:36,860 At one out of 255, this router is not very busy at all. 65 65 00:02:36,860 --> 00:02:40,130 rxload is like txload, but instead of transmitting, 66 66 00:02:40,130 --> 00:02:40,963 we're going to be measuring 67 67 00:02:40,963 --> 00:02:44,160 how busy the router is in terms of receiving frames. 68 68 00:02:44,160 --> 00:02:46,600 Next, we have the archetype being used. 69 69 00:02:46,600 --> 00:02:49,060 In this case, we're using ARPA, 70 70 00:02:49,060 --> 00:02:51,640 or the Advanced Research Projects Agency setting, 71 71 00:02:51,640 --> 00:02:54,120 which indicates that we're using standard Ethernet. 72 72 00:02:54,120 --> 00:02:56,230 This is because ARPA develops standard Ethernet, 73 73 00:02:56,230 --> 00:02:58,380 and we're using that for Ethernet frames 74 74 00:02:58,380 --> 00:02:59,830 for our encapsulation. 75 75 00:02:59,830 --> 00:03:01,330 Now, if you're using something different, 76 76 00:03:01,330 --> 00:03:03,420 like a serial link or a frame relay, 77 77 00:03:03,420 --> 00:03:05,970 it would say something different here instead of ARPA. 78 78 00:03:05,970 --> 00:03:07,240 But if you're using Ethernet, 79 79 00:03:07,240 --> 00:03:09,570 you should expect to see ARPA right here. 80 80 00:03:09,570 --> 00:03:11,210 Next, we have the keepalive, 81 81 00:03:11,210 --> 00:03:14,000 and this is set to 10 seconds, which is the default. 82 82 00:03:14,000 --> 00:03:15,200 This is how often the router 83 83 00:03:15,200 --> 00:03:16,710 is going to send a keepalive packet 84 84 00:03:16,710 --> 00:03:18,530 to other devices that it's connected to, 85 85 00:03:18,530 --> 00:03:20,610 to check if they're still up and online. 86 86 00:03:20,610 --> 00:03:22,860 Next, we have a line that says full-duplex, 87 87 00:03:22,860 --> 00:03:26,900 100 megabits per second, 100BaseTX/FX. 88 88 00:03:26,900 --> 00:03:29,243 Now, this indicates whether this interface is using half 89 89 00:03:29,243 --> 00:03:32,900 or full-duplex, and in this case we're using full-duplex. 90 90 00:03:32,900 --> 00:03:34,890 It also tells you what the bandwidth is, 91 91 00:03:34,890 --> 00:03:36,860 and the interface type you're using. 92 92 00:03:36,860 --> 00:03:39,470 In this case, as I said, we're using full-duplex 93 93 00:03:39,470 --> 00:03:42,290 and we're using 100 megabits per second as our bandwidth, 94 94 00:03:42,290 --> 00:03:44,300 and we have a fast Ethernet interface type, 95 95 00:03:44,300 --> 00:03:46,670 and it's either using copper or fiber cabling, 96 96 00:03:46,670 --> 00:03:49,320 because it says TX/FX. 97 97 00:03:49,320 --> 00:03:51,530 Now, next we're going to have our ARP type. 98 98 00:03:51,530 --> 00:03:54,200 And in this case, again, we're going to use ARPA. 99 99 00:03:54,200 --> 00:03:56,830 The timeout here tells us how long each ARP cache 100 100 00:03:56,830 --> 00:03:59,600 is going to remember a binding, and when it will be cleared. 101 101 00:03:59,600 --> 00:04:03,050 In this case, we're using the default time of four hours. 102 102 00:04:03,050 --> 00:04:05,960 The next two lines are the last input, last output, 103 103 00:04:05,960 --> 00:04:07,780 and last clearing of the counters. 104 104 00:04:07,780 --> 00:04:10,100 In this case, the router was just rebooted, 105 105 00:04:10,100 --> 00:04:11,620 so they're all set to zero 106 106 00:04:11,620 --> 00:04:13,450 because they were all just cleared. 107 107 00:04:13,450 --> 00:04:15,090 Next, we have our input queue, 108 108 00:04:15,090 --> 00:04:17,420 which tells us how many packets are in the input queue, 109 109 00:04:17,420 --> 00:04:19,020 and their maximum size. 110 110 00:04:19,020 --> 00:04:22,850 In this case, the maximum size is 75 packets for our queue. 111 111 00:04:22,850 --> 00:04:24,260 Drops is the number of packets 112 112 00:04:24,260 --> 00:04:25,590 that have been dropped so far. 113 113 00:04:25,590 --> 00:04:28,280 Flushes is used to count the Selective Packet Discards 114 114 00:04:28,280 --> 00:04:30,560 that have occurred basically when the router 115 115 00:04:30,560 --> 00:04:33,790 or switch has a sign, it needs to start shedding some load, 116 116 00:04:33,790 --> 00:04:36,360 and it starts dropping packets selectively. 117 117 00:04:36,360 --> 00:04:38,160 SPD is a protocol that's going to drop 118 118 00:04:38,160 --> 00:04:41,460 your lowest priority packets when the CPU becomes too busy, 119 119 00:04:41,460 --> 00:04:42,860 so that way you can save capacity 120 120 00:04:42,860 --> 00:04:46,300 for higher priority packets as a form of quality of service. 121 121 00:04:46,300 --> 00:04:49,110 Now, the total output drops here is at zero. 122 122 00:04:49,110 --> 00:04:50,750 This means that we've had no drops 123 123 00:04:50,750 --> 00:04:53,230 because we never had a full output queue. 124 124 00:04:53,230 --> 00:04:55,450 Since we have a hundred megabit per second connection, 125 125 00:04:55,450 --> 00:04:56,440 as long as we're communicating 126 126 00:04:56,440 --> 00:04:58,710 with another a hundred megabit per second connection, 127 127 00:04:58,710 --> 00:05:01,490 we should see this stay at zero drop packets. 128 128 00:05:01,490 --> 00:05:03,930 If we started using a 20 megabit per second connection, 129 129 00:05:03,930 --> 00:05:05,450 for instance, on our ISP, 130 130 00:05:05,450 --> 00:05:07,560 then we might likely have an experience here 131 131 00:05:07,560 --> 00:05:10,440 with network congestion because we're sending at 100, 132 132 00:05:10,440 --> 00:05:12,550 but they can only take it at 20. 133 133 00:05:12,550 --> 00:05:14,010 That would cause a problem for us. 134 134 00:05:14,010 --> 00:05:16,810 And at that point, some of our packets might get dropped. 135 135 00:05:16,810 --> 00:05:18,440 Next, we have our queuing strategy 136 136 00:05:18,440 --> 00:05:19,870 for our quality of service. 137 137 00:05:19,870 --> 00:05:23,210 In this case, we're sending this as First In, First Out, 138 138 00:05:23,210 --> 00:05:24,960 which is known as FIFO. 139 139 00:05:24,960 --> 00:05:27,320 This is the default for this type of router. 140 140 00:05:27,320 --> 00:05:30,490 Next, we have output queue size and the maximum. 141 141 00:05:30,490 --> 00:05:33,740 Currently, our queue is empty and it's showing zero packets. 142 142 00:05:33,740 --> 00:05:36,590 Now, the maximum queue size here is set at 40. 143 143 00:05:36,590 --> 00:05:38,890 So, if I receive more than 40 packets, 144 144 00:05:38,890 --> 00:05:40,550 the queue is not going to be able to hold it 145 145 00:05:40,550 --> 00:05:42,980 and the rest of those will get dropped. 146 146 00:05:42,980 --> 00:05:45,990 Next, We have our minute input and output rates. 147 147 00:05:45,990 --> 00:05:47,410 Now, here are the average rates 148 148 00:05:47,410 --> 00:05:50,590 at which packets are being received and being transmitted. 149 149 00:05:50,590 --> 00:05:52,400 Packet input is our next line. 150 150 00:05:52,400 --> 00:05:55,960 And here we can see 923 packet inputs was received 151 151 00:05:55,960 --> 00:06:00,960 for a total of 158,866 bytes of data being processed. 152 152 00:06:01,700 --> 00:06:03,950 The next line contains the receive broadcast. 153 153 00:06:03,950 --> 00:06:07,360 And in this case, we received 860 broadcast frames. 154 154 00:06:07,360 --> 00:06:08,540 We also have runts, 155 155 00:06:08,540 --> 00:06:10,840 giants and throttles counted here as well. 156 156 00:06:10,840 --> 00:06:12,720 Now, a runt is an Ethernet frame 157 157 00:06:12,720 --> 00:06:14,880 that is less than 64 bytes in size. 158 158 00:06:14,880 --> 00:06:17,360 It's really small, that's why it's a runt. 159 159 00:06:17,360 --> 00:06:19,400 A giant is any Ethernet frame 160 160 00:06:19,400 --> 00:06:24,400 that exceeds the 802.3 frame size of 1,518 bytes. 161 161 00:06:24,440 --> 00:06:26,830 It's really large, so it's a giant. 162 162 00:06:26,830 --> 00:06:27,970 Throttles are going to occur 163 163 00:06:27,970 --> 00:06:30,940 when the interface fails to buffer the incoming packets. 164 164 00:06:30,940 --> 00:06:33,230 If this is a high number, this is an indicator 165 165 00:06:33,230 --> 00:06:35,380 that you may be having quality of service issues 166 166 00:06:35,380 --> 00:06:36,980 to your end users. 167 167 00:06:36,980 --> 00:06:38,550 Next, we have input errors, 168 168 00:06:38,550 --> 00:06:41,580 CRC, frame, overrun, and ignored. 169 169 00:06:41,580 --> 00:06:43,919 The input error counter will go up whenever the interface 170 170 00:06:43,919 --> 00:06:46,710 is receiving a frame with any kind of error in it. 171 171 00:06:46,710 --> 00:06:49,170 This can be something like a runt, a giant, 172 172 00:06:49,170 --> 00:06:53,090 no buffer available, CRC errors, or other things like that. 173 173 00:06:53,090 --> 00:06:55,520 CRC is the number of packets that were received, 174 174 00:06:55,520 --> 00:06:57,760 but failed the cyclic redundancy checksum, 175 175 00:06:57,760 --> 00:07:00,460 or CRC check upon receiving them. 176 176 00:07:00,460 --> 00:07:02,140 If the checksum generated by the sender 177 177 00:07:02,140 --> 00:07:04,220 doesn't match the one calculated by this interface 178 178 00:07:04,220 --> 00:07:05,700 when it receives that frame, 179 179 00:07:05,700 --> 00:07:08,920 a CRC error is counted and the packet gets rejected. 180 180 00:07:08,920 --> 00:07:11,210 Now, frame is used to count the number of packets, 181 181 00:07:11,210 --> 00:07:12,480 where a CRC error 182 182 00:07:12,480 --> 00:07:15,770 and a non-integer number of octet was received. 183 183 00:07:15,770 --> 00:07:16,970 Overrun is used account 184 184 00:07:16,970 --> 00:07:19,770 how often the interface was unable to receive traffic 185 185 00:07:19,770 --> 00:07:22,060 due to an insufficient hardware buffer. 186 186 00:07:22,060 --> 00:07:24,600 Ignored is going to be used to count the number of packets 187 187 00:07:24,600 --> 00:07:27,040 that the interface ignored since the hardware interface 188 188 00:07:27,040 --> 00:07:28,970 was low on the internal buffers. 189 189 00:07:28,970 --> 00:07:31,110 If you're experiencing a lot of noise on the connection 190 190 00:07:31,110 --> 00:07:32,480 or a broadcast storm, 191 191 00:07:32,480 --> 00:07:35,820 this ignore count will start to rise drastically. 192 192 00:07:35,820 --> 00:07:38,560 Next, we have the watchdog counter, which is used to count 193 193 00:07:38,560 --> 00:07:41,530 how many times the watchdog timer has expired. 194 194 00:07:41,530 --> 00:07:45,770 This happens whenever a packet over 2048 bytes is received. 195 195 00:07:45,770 --> 00:07:47,610 The next line contains the input packets 196 196 00:07:47,610 --> 00:07:49,280 with dribble condition detected, 197 197 00:07:49,280 --> 00:07:51,530 which means that a slightly longer than default frame 198 198 00:07:51,530 --> 00:07:53,080 was received by the interface. 199 199 00:07:53,080 --> 00:07:56,020 For example, we talked about the fact that the MTU size 200 200 00:07:56,020 --> 00:07:58,000 was 1500 bytes by default, 201 201 00:07:58,000 --> 00:08:00,180 but a frame wasn't considered a giant 202 202 00:08:00,180 --> 00:08:03,110 until it reached 1,518 bytes. 203 203 00:08:03,110 --> 00:08:06,760 So, if I got a frame that was 1,510 bytes inside, 204 204 00:08:06,760 --> 00:08:09,000 it's technically above the MTU size, 205 205 00:08:09,000 --> 00:08:10,760 but it's not yet a giant. 206 206 00:08:10,760 --> 00:08:12,670 So it would still be processed, 207 207 00:08:12,670 --> 00:08:15,580 but it would be added here on the dribble condition counter, 208 208 00:08:15,580 --> 00:08:16,926 so I can know that I'm starting to get packets 209 209 00:08:16,926 --> 00:08:19,360 above 1500 bytes. 210 210 00:08:19,360 --> 00:08:21,660 Next, we have the packet output counter, 211 211 00:08:21,660 --> 00:08:23,710 and this is the number of packets that have been sent 212 212 00:08:23,710 --> 00:08:26,290 and the size of those transmissions in bytes. 213 213 00:08:26,290 --> 00:08:28,450 The underrun is the number of times a sender 214 214 00:08:28,450 --> 00:08:30,920 has operated faster than the router can handle, 215 215 00:08:30,920 --> 00:08:34,010 and this causes buffers or drop packets. 216 216 00:08:34,010 --> 00:08:35,880 Next, we have the output errors, 217 217 00:08:35,880 --> 00:08:38,470 and this is just like our input errors, the only difference 218 218 00:08:38,470 --> 00:08:40,260 is we're now counting the number of collisions 219 219 00:08:40,260 --> 00:08:43,190 and the interface resets that are occurring as a result. 220 220 00:08:43,190 --> 00:08:44,150 A collision is counted 221 221 00:08:44,150 --> 00:08:46,450 anytime a packet needs to be retransmitted 222 222 00:08:46,450 --> 00:08:48,450 because an Ethernet collision occurred. 223 223 00:08:48,450 --> 00:08:52,190 Since we're using full-duplex, this number should be zero. 224 224 00:08:52,190 --> 00:08:54,670 If it's not zero, something's wrong. 225 225 00:08:54,670 --> 00:08:56,910 Next, we have the interface reset, 226 226 00:08:56,910 --> 00:08:58,960 and this counts the number of times an interface 227 227 00:08:58,960 --> 00:09:02,410 had to be completely reset since the last reboot. 228 228 00:09:02,410 --> 00:09:05,010 Next, we have unknown protocol drops. 229 229 00:09:05,010 --> 00:09:06,500 Anytime a protocol drops, 230 230 00:09:06,500 --> 00:09:08,930 but our device can't determine what protocol it was, 231 231 00:09:08,930 --> 00:09:11,880 it's going to be listed under the unknown protocol drops. 232 232 00:09:11,880 --> 00:09:12,820 For example, 233 233 00:09:12,820 --> 00:09:15,460 if you're not supposed to receive older types of protocols 234 234 00:09:15,460 --> 00:09:18,260 like IPX traffic and AppleTalk on your router, 235 235 00:09:18,260 --> 00:09:21,090 but somebody sends you a message that's formatted that way, 236 236 00:09:21,090 --> 00:09:22,350 your router is going to drop it, 237 237 00:09:22,350 --> 00:09:24,240 and it's not going to know what it was, 238 238 00:09:24,240 --> 00:09:26,790 because it's not a properly format IP message 239 239 00:09:26,790 --> 00:09:28,080 or an Ethernet frame. 240 240 00:09:28,080 --> 00:09:30,470 So that counter is going to go up. 241 241 00:09:30,470 --> 00:09:33,780 Next, we have babbles, late collision, and deferred. 242 242 00:09:33,780 --> 00:09:35,880 Now, a babble is used to count any frame 243 243 00:09:35,880 --> 00:09:39,920 that is transmitted, that is larger than 1,518 bytes. 244 244 00:09:39,920 --> 00:09:41,450 This is similar to our giants, 245 245 00:09:41,450 --> 00:09:44,010 but we're going to use this when we're transmitting, 246 246 00:09:44,010 --> 00:09:45,350 instead of receiving. 247 247 00:09:45,350 --> 00:09:48,980 A babble is for transmission, a giant is for receive. 248 248 00:09:48,980 --> 00:09:50,320 Late collisions are going to be used 249 249 00:09:50,320 --> 00:09:52,100 to count the number of collisions that occur 250 250 00:09:52,100 --> 00:09:54,930 after the interface started transmitting its frame. 251 251 00:09:54,930 --> 00:09:57,080 And deferred is used to count the number of frames 252 252 00:09:57,080 --> 00:09:58,570 that were transmitted successfully 253 253 00:09:58,570 --> 00:10:01,110 after waiting because the media was busy. 254 254 00:10:01,110 --> 00:10:04,340 So, if your devices are using CSMA/CD 255 255 00:10:04,340 --> 00:10:07,510 or collision detection, it's going to detect the media as busy, 256 256 00:10:07,510 --> 00:10:09,890 it's going to wait, and then it's going to transmit. 257 257 00:10:09,890 --> 00:10:10,870 When this happens, 258 258 00:10:10,870 --> 00:10:13,320 this number is going to go up because it had to wait. 259 259 00:10:13,320 --> 00:10:15,700 Again, we should see zero for late collisions 260 260 00:10:15,700 --> 00:10:16,610 and deferred here 261 261 00:10:16,610 --> 00:10:18,900 because we're using a full-duplex connection, 262 262 00:10:18,900 --> 00:10:20,800 but if we're using a half-duplex connection, 263 263 00:10:20,800 --> 00:10:22,690 there will be some numbers there. 264 264 00:10:22,690 --> 00:10:25,710 Next, we have the loss carrier and the no carrier. 265 265 00:10:25,710 --> 00:10:28,180 This is the number of times that the carrier was lost 266 266 00:10:28,180 --> 00:10:30,300 or not present during the transmission. 267 267 00:10:30,300 --> 00:10:31,570 The carrier we're talking about here 268 268 00:10:31,570 --> 00:10:33,730 is the signal on the connection. 269 269 00:10:33,730 --> 00:10:37,140 Finally, we have the output buffer failures and swapped out. 270 270 00:10:37,140 --> 00:10:39,140 The Output Buffer Failure is going to be used 271 271 00:10:39,140 --> 00:10:41,730 to count the number of times the packet was not output 272 272 00:10:41,730 --> 00:10:43,310 from the output hold queue 273 273 00:10:43,310 --> 00:10:45,550 because of a shortage of shared memory. 274 274 00:10:45,550 --> 00:10:47,170 An Output Buffer Swap Out 275 275 00:10:47,170 --> 00:10:50,080 is going to be the number of packets stored in the main memory 276 276 00:10:50,080 --> 00:10:51,690 when the queue was full. 277 277 00:10:51,690 --> 00:10:53,440 If this number is very high, 278 278 00:10:53,440 --> 00:10:55,070 that means that you're likely experiencing 279 279 00:10:55,070 --> 00:10:56,800 a busy time in your networks. 280 280 00:10:56,800 --> 00:10:59,500 Now, for the exam, you don't need to know all these things 281 281 00:10:59,500 --> 00:11:01,340 and memorize all their definitions, 282 282 00:11:01,340 --> 00:11:03,830 but you should be aware of some key statistics here 283 283 00:11:03,830 --> 00:11:05,070 on the interface. 284 284 00:11:05,070 --> 00:11:08,270 Things like the link state, the speed and duplex status, 285 285 00:11:08,270 --> 00:11:10,380 the send and receive traffic statistics, 286 286 00:11:10,380 --> 00:11:12,600 the cyclic redundancy check statistics, 287 287 00:11:12,600 --> 00:11:14,800 the protocol packet and byte counts, 288 288 00:11:14,800 --> 00:11:17,760 the CRC errors, the giants, the runts, 289 289 00:11:17,760 --> 00:11:19,530 and the encapsulation errors. 290 290 00:11:19,530 --> 00:11:21,410 On the exam, you may get a question 291 291 00:11:21,410 --> 00:11:23,100 that involves troubleshooting a device, 292 292 00:11:23,100 --> 00:11:23,933 and you're going to see 293 293 00:11:23,933 --> 00:11:25,780 an interface statistics screen like this, 294 294 00:11:25,780 --> 00:11:27,790 and then you're going to have to recommend a solution 295 295 00:11:27,790 --> 00:11:28,870 to that problem. 296 296 00:11:28,870 --> 00:11:30,520 For example, if the question asks, 297 297 00:11:30,520 --> 00:11:32,310 why the device is operating slowly, 298 298 00:11:32,310 --> 00:11:34,250 and you see the connection is set to half-duplex 299 299 00:11:34,250 --> 00:11:35,640 instead of full-duplex, 300 300 00:11:35,640 --> 00:11:37,340 that would be a reason for the slowdown, 301 301 00:11:37,340 --> 00:11:39,760 because you effectively cut your bandwidth in half, 302 302 00:11:39,760 --> 00:11:42,100 because there's the listen before transmitting. 303 303 00:11:42,100 --> 00:11:44,230 Or, if you see a large amount of collisions, 304 304 00:11:44,230 --> 00:11:45,740 but you're running full-duplex, 305 305 00:11:45,740 --> 00:11:47,320 that would indicate there's two devices 306 306 00:11:47,320 --> 00:11:48,980 connected to this same switch port, 307 307 00:11:48,980 --> 00:11:50,940 and that is causing you issues. 308 308 00:11:50,940 --> 00:11:53,750 Or, maybe you see there's a lot of CRC errors, 309 309 00:11:53,750 --> 00:11:55,900 this could indicate a dirty fiber connector, 310 310 00:11:55,900 --> 00:11:57,660 or unshielded twisted pair cable 311 311 00:11:57,660 --> 00:12:00,570 that's subject to too much electromagnetic interference. 312 312 00:12:00,570 --> 00:12:02,800 This could be caused by lots of different things, 313 313 00:12:02,800 --> 00:12:04,670 such as your cable being improperly run over 314 314 00:12:04,670 --> 00:12:06,500 a florescent light or near a power line, 315 315 00:12:06,500 --> 00:12:07,850 or something like that. 316 316 00:12:07,850 --> 00:12:08,710 My point is, 317 317 00:12:08,710 --> 00:12:11,150 it's important to be able to read the interface statistics 318 318 00:12:11,150 --> 00:12:12,160 so you can then troubleshoot 319 319 00:12:12,160 --> 00:12:13,540 your network connectivity issues 320 320 00:12:13,540 --> 00:12:14,990 in your routers and switches. 321 321 00:12:16,013 --> 00:12:18,564 (upbeat music)