Chapter 1 – Introduction
Welcome to the start of the CCNA training series! We’re going to take the network fundamentals that you already know, and build on them to take you to the next level. If you don’t have the fundamentals yet, don’t worry, we have a series on that too.
In section 1 of this series, we’re looking at layer-2 technologies. In this video, we’re moving quickly through switching, VLANs, and trunking.
Chapter 2 – Switching
The basic function of switches is to connect devices to the network. Of course they can do far more, but every other feature they have is to support connecting devices.
Primarily, switches work at layer-2. When we think about layer-2, we think about things like MAC addresses, Ethernet frames, and VLANs.
A lot of modern switches also support some layer-3 functions. That’s IP addresses, routing, and that sort of thing. For this section of the series, we’re going to focus on layer-2.
We commonly use the Ethernet protocol in our networks. Each Ethernet frame has a source MAC address, and a destination MAC address.
Ethernet, and layer-2 in general, is used to deliver frames from one hop to the next. This means that with each hop, the source and destination MAC will be updated. The source will be the device that’s sending, and the destination will be the next hop along the path.
This process is called frame rewrite.
Switches don’t count as hops in this sense. That is, they don’t update the source and destination MAC addresses of each frame that passes through them.
So what are switches for? Connectivity. All devices need to be connected to each other in some way. But we can’t literally connect each device directly to every other device. Imagine how many cables would be needed!
Instead, the switch uses a process called Frame Switching. Instead of connecting devices directly to each other, devices connect to switches. As you can see, this is so much simpler.
When a frame arrives at a switch, the switch decides which link or interface to send the frame out of. This makes sure the frame gets to the correct destination.
The next question is, how does a switch know which link to send the frame on? It does this by learning the MAC addresses of connected devices, and the interfaces they are connected to. These details are stored in the MAC address table.
When a frame arrives at a switch port, the switch takes a look at the destination MAC address. Remember that this is in the Ethernet header.
It looks for this MAC address in the MAC address table. Here is finds the port that the MAC address belongs to. It then forwards the frame out of this port.
We should ask ourselves, what happens if the MAC address we’re looking for is not in the MAC table?
This means that the switch hasn’t learned about this MAC yet. In this case, it will flood the frame out of all ports.
That means a lot of devices will get the frame. Most will ignore it, as it’s not meant for them. The correct device will send its reply, which the switch will see. The switch can then learn which interface this device is connected to, and add the entry to the MAC address table for next time.
Do you want to see what a real MAC address table looks like? From the CLI we can use the command show mac-address-table. Here we can see all the MAC addresses that the switch knows about, and the port that should be used to reach them.
Entries don’t stay here forever. Once an entry is learned, a timer starts. If more traffic involving that MAC address is seen, then the timer resets. But, if the timer expires, the entry is removed from the table.
This is one way the switch keeps the table fresh. For example, we might have a laptop that we disconnect from one port, and then connect to another port. If the MAC address table didn’t clean up after itself, traffic might get sent out the wrong interface.
Quiz
If you’re planning on taking the CCNA exam, we have a few extra resources to get you ready. These include study notes, quizzes, flashcards, stranscripts, and command line summaries.
Check the video description to get a link to each of these resources.
Usually quiz explanations are for members of the site. However, I’ve made all the quizzes in this video available to everyone, to see if you like them.
Chapter 3 – VLANs
We’ve had a quick review on switching in a simple network. But as networks grow and become more complex, we will usually need to divide it up into logical parts.
We do this by configuring a VLAN. VLANs create one or more logical networks on a physical switch.
It’s kind of like dividing a switch into a few smaller switches. Some ports can be a part of one VLAN, other ports can be in a different VLAN, and they can be separate from each other.
There are a few reasons we might want to do this.
The obvious one is to separate some traffic from other traffic. This could be for security, or perhaps to keep our customers separated.
We might use VLANs to group certain traffic together. For example, we could create a VLAN just for voice traffic, that is, phone calls. This makes it easier to give this traffic a higher priority than other traffic.
Or, we could group devices into VLANs. It’s quite common to put servers in one VLAN, printers in another, and PC’s in yet another VLAN. This is often done so we can put a firewall between these VLANs to apply security policies between them. We’ll look at this more in a later section of this video series.
We recently talked about broadcast domains. As we saw, broadcasts are limited to the local network. Each VLAN is a different network, so creating VLANs creates smaller broadcast domains.
There are many different reasons we might use VLANs. Don’t worry too much about listing them all out. As you gain experience, you will start to appreciate their value and when to use them. For now, we’re just going to focus on how they work, and how they’re configured.
In the switch’s CLI, we’re going to create three VLANs with IDs 10, 20, and 30. This is as simple as typing vlan and the VLAN ID. We can optionally give each one a name. I recommend this as it makes it easier to see what each VLAN is for later on.
If you’re not yet familiar with Cisco’s Command Line Interface, I have a video on that to help get you started. See the description for a link.
We can have up to 4094 VLANs on a switch. Of course, it would be rare to need that many. We only need three for now, which are for Workstations, Servers, and printers.
When we’re done, we can check the VLANs that we’ve created with show vlan brief.
You can see the three VLANs that we created, and a few others. For example, Cisco reserve four VLANs for special use. We can’t move or change these.
It’s interesting to know that historically, Cisco broke the VLAN range into two smaller ranges. VLANs 1 to 1001 were known as the Normal range, while they called VLANs 1006 to 4094 the Extended range. This is just a Cisco thing, other vendors don’t do this.
The other VLAN that we didn’t create is VLAN 1, the default VLAN. Until we make any changes, all ports are members of this VLAN. We’ll talk more about this VLAN later.
Quiz
I hope that’s all making sense so far. Here’s two more questions to think about to challenge your understanding.
Chapter 4 – VTP
What if you have a lot of switches. Let’s say you manage the network for a university campus, which might have 500 switches. Wouldn’t it be nice if we didn’t have to configure VLANs on each one?
Years ago, Cisco created a technology called VTP, or Virtual Trunking Protocol. This is no longer in the exam, but you might see it in the real world, so I’ll give you a brief overview.
VTP would allow us to configure VLANs on a single switch, and then have this config automatically pushed out to all the other switches. This means that they wouldn’t need to be configured manually.
Switches are configured with one of three modes; Server, Client, or Transparent.
Servers are configured with a list of VLANs. One or more server switches send this list in VTP messages, which go to all switches in the VTP domain.
The VTP domain name is also included in these messages.
Client switches receive these messages, and will pass them on to other clients. Additionally, they will automatically configure the VLANs they see in the list. As long as they are in the same VTP domain of course.
The result is that you only configure the VLAN list on the server switch, not on all switches.
Be warned though, the VLAN list overwrites whatever is already configured. So, if you make a mistake on the server, you may cause a problem across all switches in your network.
Transparent switches see the VTP messages, but they only pass them on. They don’t configure any VLANs. These switches will still need manual VLAN configuration.
Over time, most people have found that VTP is more trouble than it’s worth. As we said, mistakes can bring down your network. Plus, there are better ways to configure your switches from one location, which we’ll talk about in another section of this video series.
So, I would recommend that you just set the switches to transparent mode. This will ignore any VTP messages, so your VLANs won’t be overwritten.
If you run the command show vtp status, you can see what mode your switch is in. In this case, you can see that this switch is a VTP server.
So to change it, we jump into configuration mode, and type in vtp mode transparent.
Quiz
There is a danger to put a switch that was previously configured into a live network. Can you think what that danger might be, and how we can avoid it?
Chapter 5 – Access vs Trunking
We need to add interfaces to VLANs, and when we do, we have two options; We can configure access ports or trunk ports.
Access ports are the interfaces that regular devices connect to. That includes workstations, printers, phones, and other devices like that.
Trunk ports are most commonly used when we’re connecting one switch to another switch. However, there are cases where we might connect servers to trunk ports too.
Let’s start by configuring an access port. Under the interface, we set the switchport mode to access. We then configure the VLAN ID that we want this port to belong to. Now, when we connect a device, all traffic entering or exiting this interface is part of that VLAN.
To check which interfaces belong to which VLANs, enter the command show vlan brief. Here we can see that interface gigabit 0/1 belongs to VLAN 10, which is the workstations VLAN.
We usually think of an access port as belonging to only one VLAN, however there’s an exception. This is when we have a phone and a workstation connected to the same port.
Usually, the physical phone will connect to the switch, as the workstation will connect to a port on the back of the phone.
In a case like this, we would configure a VLAN for voice traffic. In this example, we’ll make it VLAN 40, and give it the name Voice.
Then, we’ll enter interface gig0/1, and configure it with an additional voice VLAN, using the switchport voice vlan command.
When we run show vlan brief again, we can see that the voice VLAN has been created, but isn’t showing on the interface. I picked an interface that was down, so it’s not showing here.
So to check it, we can run show interfaces gi0/1 switchport. Here we can confirm the access mode VLAN, and the voice VLAN that are configured on this port.
Let’s go back to trunk ports. As I said earlier, these are commonly used when connecting two switches together.
They’re also used a lot when connecting to servers, as most servers now have virtual switches inside them, and virtual servers connected to those virtual switches. We’ll look at virtual servers and virtual switches in another section of this series.
Trunk ports are capable of carrying more than one VLAN at a time. They do this by adding the VLAN ID to each frame.
There are two possible ways of doing this. The old way is using a protocol called ISL. This is out of date, so we won’t look at it any further.
The right way to do it is with an encapsulation standard called 802.1Q. This takes the ethernet header in the frame, and adds in a small tag. This tag contains the VLAN ID.
So if a switch needs to forward a frame from one switch to another, it will add this tag, and the receiving switch will know which VLAN this frame belongs to.
This process is often called tagging, and you can probably see why. In fact, while Cisco refers to a trunk port, other vendors call this a tagged port.
It’s really simple to configure a trunk port. Under the interface, we first need to select the type of encapsulation.
This comes back to those two methods I spoke of earlier; ISL or 802.1Q. You’ll notice a third option, negotiate. We’ll talk about that soon. As I said, dot1q is the option we want.
Next, we simply set the switchport mode to trunk.
We can get a bit of information with the show interface trunk command. Here we can see the encapsulation type, as well as the VLANs that are allowed on this trunk link. By default, all VLANs are allowed, as long as they have been defined on the switch.
We can limit our trunk link to certain VLANs if we want to. This is called VLAN pruning, because we’re pruning off the VLANs that we don’t want to allow.
Personally, I always set an allowed list of VLANs as a matter of best practice, rather than leaving them all on.
Let’s go back into that interface, and then use the switchport trunk allowed command to provide a list of allowed VLANs.
I would like to issue a strong warning here. When we use this command, we will overwrite the existing list of VLANs allowed on this trunk interface with the list we provide. Many people, including myself, have made this mistake and caused a network to go down.
If we look at this interface again now, we can see that we’ve updated the list of VLANs that are allowed.
On occasion, some traffic will arrive at a trunk port with no VLAN tag. As you can imagine, we call this untagged traffic.
There are a few cases where we might see this. For example, if a workstation is connected to a trunk port rather than an access port. Or, when a cheap and nasty switch that doesn’t understand VLANs is connected to a good switch. There’s even some traffic that switches send to each other that is untagged.
So you might be thinking, ‘The receiving switch needs the tag to know which VLAN the traffic belongs to. So what happens if there is no tag?’
That’s a good question, and one that has confused many people. But it’s not as tricky as it sounds. On a trunk port, there is a special VLAN called the Native VLAN. By default, VLAN 1 is the native VLAN.
When untagged traffic arrives on a trunk port, it is assumed to be part of the native VLAN. So, by default, any untagged traffic will be part of VLAN 1.
We can change the native VLAN to another VLAN if we want to. We just configure the interface with the switchport trunk native vlan command, and give it a new VLAN ID.
Notice that we’re getting a few syslog messages reporting a native VLAN mismatch? This is because CDP, that is, Cisco Discovery Protocol, has detected that the switch on the other end of the link still has VLAN 1 as the native VLAN.
It’s important that the Native VLAN matches at both ends of the link. You’ll even notice that spanning-tree has blocked the link. We’ll talk about that more in two videos time.
If you need to verify the Native VLAN on an interface, use the show interfaces switchport command. We can see that the Trunking Native Mode VLAN is set to 10.
Quiz
You can probably work out how to tell if an interface is a trunk using the MAC table. Can you see how it’s done?
Chapter 6 – DTP
Cisco provides an automatic option for configuring trunk links, called Dynamic Trunking Protocol, or DTP. This is a Cisco only option, which is turned on by default.
Earlier we use the command switchport mode trunk. This manually configures a trunk link. As long as this is configured on both ends of the link, the link will be a trunk.
But rather than manual configuration, we can configure the link as dynamic. There are two types of dynamic configuration, called auto and desirable. The results depend on what we configure at each end of the link.
First, let’s think about the desirable option. If this is configured, the switch actively tries to convert this link into a trunk. This will succeed if the other end is configured as desirable, auto, or trunk.
Let’s see the configuration. We have two switches connected to each other. We first enter interface configuration mode. Then we configure switchport mode dynamic desirable.
Although you can’t see it here, the switch on the other side of the link is configured as dynamic auto.
If we run show interfaces trunk, we can see that the mode is set to desirable. In the status column, we can see that this link has successfully become a trunk link.
When the auto option is configured, we’re telling the switch that we’re happy if this interface becomes a trunk, but don’t actively try.
That means that if the other end tries to configure a trunk link, this interface will agree, and the interface will become a trunk port.
What happens if we change our interface to dynamic auto? That means that both sides of the link are configured as auto now.
When we run show interfaces trunk again, we get no results, as this link hasn’t become a trunk. From this we can see that if both sides are configured as auto, the link will not become a trunk.
If we show the interface, but add switchport at the end, we get extra information. See the operational status here?
So you see that the particular combination of settings will determine whether the link becomes a trunk or remains an access port.
One recommendation I can share is to avoid configuring one side manually as a trunk, and the other side manually as an access port.
We can dig up a bit more information with show dtp interface. It’s not particularly exciting, but it may prove useful if you’re troubleshooting.
DTP sends messages between the two switches to convert a link to a trunk. If we want, we can disable this entirely by configuring the interface with switchport trunk nonegotiate.
This is something that you might consider if you’re connecting a Cisco switch to another vendor, or you’re connecting a switch that you manage to a switch that someone else manages.
Personally, I don’t use DTP in practice. I always manually configure my trunk ports. I find it has a lower chance of security problems, like configuring a trunk link where there isn’t supposed to be one. It’s really up to your preference though.
Quiz
There are two more quiz questions for you to think about. Perhaps think about question 9 in particular, which involves admin more VLANs to a trunk link, without breaking the ones that are already there.
Lab
There’s another way you can test out your skills. Most of the videos in this series will have a lab accompanying them on networkdirection.net.
I’ve built them using the Cisco CML lab software, but you can use another product if you want. Your options include GNS3, EveNG, and Packet Tracer.
In this lab, you have a customer who wants this network built. You need to configure the four switches to meet their requirements. Once that’s done, you can try some troubleshooting.
These labs are usually reserved as a bonus for Patreon supporters, but this one is available to everyone, to see if you like it.
End Scene
Please continue to the next video, where we will look at interfaces. This includes connecting interfaces, MTU and frame size, and troubleshooting interface status.