Chapter 1 – Introduction
It’s not enough to simply configure a few VLANs on a switch and think you’re done. You also have to know how to connect devices to your switch, and for that matter, how to connect switches to other switches.
So this time we’re looking at interfaces. This includes types of interfaces that you might use, problems that you might face, and how to troubleshoot them when they go wrong.
Chapter 2 – Connecting Interfaces
Switches come with various types of interfaces. The most common ones you will see are RJ45 and transceivers.
This is the RJ45 port and cable. RJ45 refers to the connector on the end of the cable, not the cable itself. The cable is known as a CAT cable. There are various CAT standards, like CAT-5 and CAT-6.
These are the cables that you commonly use to connect devices like workstations, pointers, some servers, and so on. We commonly see these types of connections running at 1-gigabit, but they can also run at 10-gig.
This is a transceiver port. It’s different as we can add a transceiver to the switch to control what the port does. Basically, a transceiver is a hardware module that we buy and insert into the switch.
This means that we can use different transceivers to achieve different goals. For example, we may have a transceiver to connect two switches using fibre optic cable at 10-gig.
Or we may use another transceiver to connect servers to our switches using copper cabling.
Or we may have a different transceiver again to connect two different buildings together using long-range fibre, at 1-gigabit.
The advantage is that we can mix and match the types of interfaces we use in a single switch.
These transceivers use standards like SFP, SFP+, and QSFP. An SFP transceiver supports 1-gig, while SFP+ supports 10G, and sometimes 25-Gig.
QSFP, or Quad-SFP, is a larger connector, which is used for higher speed applications. It’s really just four SFP+ transceivers joined together. It can handle speeds from 40 to 400-Gig.
But even though they’re different physically, they operate in much the same way. For example, we can configure both of these port types with VLANs, IP addresses, and things like these.
This is where we see a separation between the layers of the OSI model. The details at layer-1 can be different, while layers 2 and 3 can be the same.
One physical difference worth noting is that the RJ45/CAT type of cabling supports different interface speeds. For example, 100-Meg, 1-Gig, 10-Gig, and others.
When two devices are connected, they will negotiate the best speed that they can both run at. This means that one device may need to slow down to support the other device.
This is a feature called autonegotiation, and it’s on by default. It’s particularly useful on a switch where a variety of different devices connect.
We can override this, and set the speed manually if we want to.
To do this, we first enter interface configuration. Let’s add a description while we’re here, just to show how it’s done.
Then, we disable auto-negotiation with the no negotiation auto command.
The speed is set with the speed command. If we use a question-mark, we can see the speeds that this interface supports.
Let’s set this one to 100-Meg.
Transceivers are a bit different. They are physical modules that are installed into the switch port, and are hard-coded to a certain speed.
I learned this the hard way years ago, when I had a 10-Gig switch and a 1-Gig ASA firewall. I use a copper DAC cable to connect them.
The DAC cable, as shown here, is a copper cable with a transceiver built into each end. They’re sometimes known as twinax cables.
Anyway, the problem is that the transceivers on the ends were hardcoded for 10-Gig, but the firewalls would only support 1-Gig.
I thought I could use the speed command to change the switch end to 1-Gig to match the firewall, but it just doesn’t work that way. Transceivers have a fixed speed, that we can’t change.
When two devices are connected to each other, they can operate in full-duplex or half-duplex mode.
In full-duplex mode, the interface can send and receive at the same time. In half-duplex mode, it can only send or receive at any given time. As you can imagine, full-duplex is far more efficient.
These days, full duplex is used in most cases. In fact, for interfaces to operate at 10-Gig or faster, full duplex is mandatory.
On interfaces 1-Gig or slower, we can change the duplex mode. I don’t often do this, but sometimes you’ll be asked to try it for troubleshooting.
Let’s try changing a few interfaces to half duplex mode. We can configure a range of interfaces using the range keyword. This can save us some time
Just as before, we need to start by disabling auto-negotiation. You can probably guess that under normal circumstances, two devices will work out if they want to use full or half duplex, just like they did when negotiating speed.
Using the duplex command, we can see the different options we have. Not many really, so let’s just set these interfaces to half duplex.
Even though we will use full duplex wherever we can, you will find that in many cases, service providers still use half duplex in some cases.
When a service provider deploys a fibre service to your premises, which could be for internet, voice, WAN, or something else, they can use either one or two cores of fibre, as shown here.
If there are two cores, one will be used for sending data, while the other receives data. That makes it full duplex.
On the other hand, they may only give you one core of fibre. In this case, it is half duplex, as it can send or receive, but not both at the same time.
I’m not completely certain why they do this. I think it’s because it’s so expensive to run new fibre in conduits underground. When they’re running new fibre they will usually run a lot more than they need, so they can connect more customers later.
So, if they run 144 cores of fibre along the street, they can support 144 customers at half-duplex, or only 72 customers at full duplex.
In the end, they’re still able to get the speeds that they promise you over a single core.
What if auto-negotiation were to fail? In this case, there are a few rules that interfaces need to follow:
- Use the slowest supported speed, which is usually 10-Meg
- If the speed is 10 or 100-Meg, use half duplex
- For other speeds, use full duplex
Cisco switches have the built in ability to sense the speed of other switches, so if auto-negotiation fails, they will try to set the speed accordingly. If that fails, they fall back on the rules we’ve just discussed.
Where we can run into trouble is if one side is full duplex, while the other is half duplex. This is called a duplex mismatch. This could happen due to a fault, or a configuration error on our part.
When operating in half-duplex, the rules are the same as when connected to an old hub. It needs to use CSMA/CD to detect collisions. Full duplex on the other hand, does not.
Therefore, if one side is in full duplex, and the other is in half duplex, one side will use CSMA/CD, and the other won’t. The half-duplex side will think there are collisions when there aren’t, and will back-off, resend frames, and so on.
The ultimate result is that the link will work, but it will have degraded performance.
Quiz
Here are two questions for you to consider. Pause the video and have a think about them, or come back later on and give them a try.
Chapter 3 – MTU and Frame Size
I’m sure you’re aware that all data is broken into manageable chunks before it’s sent over the network.
We often call these chunks of data packets, which is fine. Technically though, at layer-2 they’re called data frames, and at layer-3, they’re called packets.
There’s a few reasons for breaking our traffic into packets. For one, if there’s more than one path to a destination, some packets could take one path, and some could take the other.
More importantly though, if some packets are dropped, it’s easier to resend a few packets than resending everything.
Or for some traffic types, it’s ok to just ignore a few missing packets.
The big question is, how big should each packet be?
The Ethernet standard says that each normal frame should be no larger than 1518 bytes, or 1522 bytes with a VLAN tag.
That includes all data and headers. There are normally 18 bytes of headers, or 22 with a VLAN tag, so the payload can be up to 1500 bytes.
Sometimes we will enable a feature called jumbo frames. This allows us to grow the frame size to around 9000 bytes. There are pros and cons to this, which I won’t get into right now. Just be aware that jumbo frames exist, which allow us to put more information into a single frame.
Inside the frame we have a payload, which is probably an IP packet. This has its own headers and payload.
The largest IP packet, including payload and headers, that an interface can send is called the MTU, or Maximum Transmission Unit. This is 1500 bytes by default.
On a rare occasion we might want to change this value. For instance, if a device along the path somewhere can’t handle a packet this big.
Or, we might be using a technology that adds more headers to the packet or frame, which leaves less space for the payload. We’ll see an example of this when we look at VPNs later in the series.
Let’s take a look at how we might change the MTU on a switch’s interface. This of course, is under the interface configuration.
Then we simply use the mtu command, followed by the size.
So you might be wondering, what happens if a device tries to send a packet that’s larger than the MTU? Remember that the MTU could change somewhere along the path.
If this happens, then the packet will need to be fragmented. This is where the packet is broken into smaller pieces, so each piece is smaller than the MTU.
The receiving device then takes all the fragments and reassembles them into the original packet.
We don’t want fragmentation. This impacts performance by making various devices work harder than they need to. So where you can, configure the MTU correctly. And if you don’t need to change it, just leave it as it is.
Quiz
What about enabling jumbo frames on your internet connection? Do you think that’s possible? Have a think about it, maybe do some of your own research, and see what you find. Maybe discuss it in the comments section if you want to.
Chapter 4 – Interface Status
Let’s get a bit more practical, and see how we can confirm if our interfaces are working correctly.
First, we’ll take a look at what interfaces we have with show interface description. These are the descriptions we add to interfaces during configuration. Here we have an interface connecting to a router, and another interface connecting to a switch.
Now we’ll get some high level information with show interface status. In the port column we can see the interface itself, and right next to that is the name, or description.
The status column tells us right away if the interface is connected to something or not. If this does not say connected, you probably need to check if the cable is connected at both ends.
The vlan column will show the VLAN ID if this is an access port, or it will show trunk if it’s a trunk port.
The duplex column shows if this interface is in full or half-duplex. If there’s an ‘a’ here, it means that this interface is configured to use auto-negotiation.
The speed column is much the same.
And finally the Type column. This shows the interface type. This will vary depending on what interfaces are available on your switch or router.
Another way we could look at it is with show interfaces summary.
This shows the interfaces over on the left, as well as a lot of counters. The key to understanding the counters is listed above the table.
But let me summarise. The first three columns are queues. These are holding areas for packets while they’re being processed. These values should stay low. If they start growing, then your switch is not processing packets fast enough.
The next four columns are the receive and transmit rate in bits per second and packets per second. Anything with an RX refers to the receive rate, while TX is transmit. As you can see, not much has happened on this switch since it started up.
If we see that the rates are approaching the limit of the link, then it might be time to upgrade the link.
So imagine that we suspect a particular interface is causing problems. We can dig deeper into this with show interfaces, followed by the interface that we want to look at. In our case, show interfaces gi0/1.
This brings up a lot of information, which can be intimidating at first. We’ll just pick out some interesting bits.
In the first line, we can see that the interface is up, and the line protocol is also up.
The interface being up refers to the physical interface. If this is down, then the cable is most likely unplugged. If it’s listed as administratively down, then we’ve manually shut down the interface.
If the physical interface is down, then the line protocol will also be down. If the interface was up and the line protocol was down, this might indicate a cable fault, or a mismatch in configuration between the two devices. If this happens, check if the speed, duplex, and trunk settings are the same at both ends of the link.
On the next two lines we can see:
- The interface type, such as gigabit ethernet
- The MAC address and Burned in Address
- The description
The following two show us:
- The MTU of this interface, as we discussed earlier
- The bandwidth of this interface in Kilo-bit per second; 1,000,000 would be 1-Gig
- Then reliability, txload, and rxload
- These are values out of 255, which is an 8 bit number
- Reliability refers to how much this interface is dropping packets; we want this number to be 255, which is 100% reliable
- Txload and rxload is how much of the bandwidth is being used for transmitting and receiving
- A load of 255 means that the interface is at 100% capacity, which would not be good
Further down the list we can see:
- Duplex setting – usually full-duplex
- The speed, such as 1000Mbps
- The media type
Much of this is the same information we got from other commands. There are often several different ways to get the information we need.
Just past half way we can see 5-minute averages of the input and output rate. Sometimes we have high levels of traffic in short bursts, and other times it might be for a long time.
So, if the 5 minute average is quite high, then we have a sustained high traffic rate. If it’s regularly near maximum, we need to look at upgrading our links.
The large section at the bottom includes various counters. This includes how many packets and bytes the interface has received and transmitted, and how many are multicast.
There are a lot of other counters too:
- Collisions are when ethernet collisions have occurred
- This can happen if you have an old-fashioned hub in place
- Or it can be caused if the cable is too long
- Runts are packets that are discarded because they’re too small. That is, less than 64 bytes. This is generally a byproduct of collisions
- Giants are packets that are discarded due to being too big
- That is, if the frame is bigger than 1518 bytes, and it can’t be fragmented for some reason
- CRC means the checksum on the frame has failed
- This could be because the frame is being corrupted somewhere, or a bad cable, or the cable is too long, or interference from an outside source
There’s a lot of information in there, and this can be overwhelming. So here’s a pro tip! We can filter the output just to show the parts we’re interested in.
Firstly, we can pipe any command through the include command. This will only display lines that match our input. If you’re familiar with Linux, it’s like a simple version of grep.
Here, we’re filtering our previous output to only show lines that include the word rate. This makes it much simpler, if we know what we’re looking for.
We could even use this to look at the rates for all interfaces at once. But notice that it doesn’t give us the interface name when we do this, making it hard to tell which interface has a high data rate.
So, let’s get fancy. The include command uses regex. If you’re not familiar with what regex is, it’s an advanced method of matching things.
So what we can do is use include, then put the words rate and Ethernet inside brackets. Notice that they’re separated by the pipe character? In regex, this means ‘or’, so we’re asking to see any line that includes the word rate or the word Ethernet. This tidies thing up a bit.
Here’s the next tip… First, let’s look at the counters for interface gig0/1 again.
There’s a lot of counters, and maybe a lot of errors. But how long have they been there? Do these represent a current problem, or is this from a year ago?
What we can do is clear these counters, with the clear counters command. This can be done for all interfaces or just the ones we want.
Now, we can look at the counters again, and see if the error counts are going up, or staying at zero. If they’re going up, we have a problem right now.
Quiz
Here’s an interesting question for you to consider. Can you see what might be wrong with this interface, based on this output?
Lab
Here’s another opportunity for you to test your skills in the lab. This is the same topology as the last video, so I’m sure you’re comfortable with it.
This time, the customer has reported network issues. You have been given the task of collecting troubleshooting information, as well as shutting down redundant interfaces.
Are you up to the challenge?
End Scene
When we connect multiple switches together, we need to consider the impact of loops in the network. Spanning Tree is the technology that helps us to manage this.
In the next video, we’re going to look at how spanning tree works in detail.