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