Training Cisco 200-125 CCNA v3.0. Day 12. In-depth study of the VLAN
We’ll devote today's lesson to advanced VLAN learning. Before you begin, let me remind you again, so that you do not forget to share these videos with friends and like on our YouTube channel and in a group on Facebook. Today we will explore three topics: Native VLAN, VTP (VLAN Trunk Protocol) and VTP Pruning function. First, remember what trunking is, and touch on the topics from the last two video lessons.
So, a trunk is a connection that we use to connect one switch to another switch. VLAN is a technology that is applicable only to switches, but any device that speaks the language of encapsulation and is associated with a switch using the .1Q protocol understands everything related to VLAN. Computers do not know anything about this technology.
')
In the following figure, PC1, PC2, and PC4 are part of a blue VLAN, as you recall from the previous lesson, this is VLAN10. The blue line itself does not have anything to do with the VLAN, because the VLAN only affects the port of the switch. Thus, both ports of the left switch belong to VLAN10 and any incoming or outgoing traffic is associated only with this network. The switch knows that the traffic of these blue ports has nothing to do with the red port, because these are two different virtual lines.
VLAN is a concept for switches, so each switch supports the creation and storage of a virtual network database. This is a table that indicates which port corresponds to a specific VLAN. Thus, if the switch receives traffic for PC1, it checks if this traffic is part of VLAN10 and forwards it to the computer. If traffic from PC1 is for PC4, the switch will route it through trunk SW1-SW2. As soon as the traffic enters the trunk port of the first switch, it provides the frame with the VLAN TAG header, which contains the VLAN ID, in our case it is 10. Upon receiving this traffic, the second switch reads the frame information, sees that it is VLAN10 traffic, and forwards it on the blue port for PC4.
Thus, trunking is the process of transferring traffic between two switches, and VLAN TAGS are frame headers that identify a specific virtual network and indicate which network the traffic should be sent to. If by mistake the blue traffic gets to the computer through the red line, it will not even know how to read it. It is as if someone speaks a foreign language with a person who does not know this language. So, the computer is completely incapable of recognizing VLAN tags. The PC3 computer is connected to the switch via the access port, and the traffic we mentioned can only be sent via the trunk port.
All these are features of the 2nd level of the OSI model to which switches belong. In order to better understand the essence of VLAN and tags, we need to think like a switch. Suppose that a switch is a room in which there are 5 people, and you are the owner of this room. Three people numbered 1,2 and 4 belong to the same group, and two numbered 3 and 5 belong to the other, and your duty is to make it so that only people belonging to the same group can talk to each other.
Let's continue the discussion of the concept of native VLAN. As already mentioned, each switch port is associated with a specific VLAN.
For example, two ports of the first switch are connected to VLAN10, a third access port with VLAN20, and the fourth one is a trunk port. In the same way, SW2 is connected to PC4 through the port VLAN10, from PC5- through the access port VLAN20 and to the hub through the trunk port. However, we have one problem - switches are expensive, so a scheme is often used in which two switches are connected to each other through a hub. Two switches are connected to the hub using trunks, but the hub itself knows nothing about the concept of a VLAN, it simply copies the signal. As we have already said, if VLAN traffic is directly sent to the computer, it will drop it, because it will not understand what it is. How can we be with PC6 computer, which is connected to the hub directly, if it is going to communicate with PC4 computer?
Computer PC6 sends traffic that goes to switch SW2. Having received this traffic, the switch sees that the frame does not have a VLAN tag and does not know which network to send it to — VLAN10 or VLAN20. For this case, Cisco has created a technology called the Native VLAN, and the default VLAN1 is the Native VLAN.
Suppose we have another computer, I will draw it over the SW2 switch, and this PC is connected to the switch via port VLAN1. The same computer is located above SW1 and is also connected to it via VLAN1. I will draw another computer under the right switch.
Two computers connected to switch SW2 via VLAN1 can communicate with each other, but are unable to communicate with other computers. When a switch receives untagged traffic through a trunk, it considers that this traffic is addressed to VLAN1, or Native VLAN, and forwards it to computers connected to VLAN1 ports. Similarly, when a switch receives untagged PC6 traffic, it addresses its network VLAN1.
What happens if we have a Cisco IP Phone on the VLAN20 red line that is connected to PC5 and SW2? This is a typical layout of office network equipment. In this case, the concept of Native VLAN is also used. As I said, the computer does not know what VLAN is, and the phone knows. The question is whether we can send data and voice over the same VLAN. This is a very dangerous situation, because if a computer is on the same line as an IP phone, a hacker can easily connect to that link and use Wireshark to intercept voice packets. Then he can convert these voice packets into a sound file and listen in on any telephone conversation. Therefore, in practice, voice traffic and data traffic are never transmitted over the same VLAN line. How can this be customized?
We turn the port to which the IP phone is connected into a trunk port, and we believe that any traffic passing through this port is voice traffic from the VLAN30 network. Any Cisco IP Phone uses 802.1q encapsulation protocol, commonly referred to as .1Q or Dot 1Q. Thus, when the traffic from the phone goes to the corresponding port, the switch understands that it is the voice traffic of VLAN30. We must have another phone that is connected to the SW switch, which is also part of VLAN30.
What then happens to the PC4 computer that is connected to the switch via the access port? After all, the traffic that this computer exchanges with the switch belongs to the blue VLAN10. However, PC5 is connected to a switch via a trunk, and for the trunk we do not configure any VLAN! In this case, the port is operating in trunk mode, not access, so we cannot use the switchport access VLAN # command. It uses the same concept as in the case of the PC6 computer - if the switch receives untagged traffic, it sends it to the port of the native VLAN, by default it is VLAN1.
The question arises whether it is possible to change the native VLAN. The answer is yes, you can do this, for example, in the case of the red line, you can change the native VLAN to VLAN20, and then the switch will direct the red traffic from PC5 to VLAN20. Since both switches are connected by a trunk, switch SW2, having received VLAN20 traffic, considers it as native VLAN traffic and sends SW1 switch as untagged.
Having received this traffic, switch SW1 recognizes it as untagged native traffic, and since its native VLAN is VLAN1, it will send this traffic to this network. If we change the native VLAN, we must do it with caution to make sure that all the native VLAN in all switches have changed in the right way, otherwise it can cause many problems.
It was a short review of the native VLAN, and now we’ll go to the proprietary VTP protocol (VLAN Trunking Protocol). First of all you should remember that, despite its name, VTP is not a trunking protocol.
From previous lessons, we know that there are only 2 trunking protocols: a proprietary Cisco protocol called ISL and the generally accepted 802.1q protocol.
VTP is also a proprietary protocol of Cisco, but does not deal with trunking in the sense of creating backbone connections. Suppose we created VLAN10 on the port of the first switch to which the computer is connected. Next we have a trunk SW1-SW2 and a trunk SW2-SW3. When trunk port SW1 receives computer traffic, it knows that it is VLAN10 traffic and forwards it to the second switch. However, the second switch does not know what VLAN10 is, because nothing but a trunk is connected to it, so in order to receive this traffic and send it further, it creates VLAN10 on its ports. Switch 3 will do the same - receiving traffic on the trunk, it will create VLAN10.
You can create two access ports on SW3, and both will be VLAN10. Suppose that on all 3 switches I want to create another network - VLAN20. This will only be possible after the ports for VLAN20 are created. The more devices, computers, and switches are added to your network, the more difficult it becomes to create new VLANs, so Cisco has automated this process by creating a VTP.
If we create a new VLAN, call it VLAN30, on one of the switches, then on all other switches connected by a trunk, the same VLAN30 network is automatically created.
The updated, updated VLAN database is simply distributed across all switches, and all you have to do is create an access port for the computer. Without this protocol, you will have to manually reconfigure all switches. The disadvantage of VTP is that if you make changes to the VLAN database, it changes the revision number - the revision number. Usually, when you use a switch right out of the box, all settings have a zero revision number. When you add a new VLAN, for example, the tenth, the SW1 database gets revision number # 1. In this case, the second switch says: “OK, you have revision 1, and I have revision 0, so I have to change my revision number to 1 and re-copy all the data from your VLAN table to my table”. The third switch does the same thing.
Suppose now that switch 2 adds itself VLAN20 and changes the revision number to 2, then the first and third switches must do the same. Each time you change a revision number, the protocol checks who has this number higher and changes all other revision numbers to that number, simultaneously updating its VLAN table. Moreover, VTP unconditionally trusts the switch with the highest revision number.
Imagine such a situation. A new employee comes to the company and finds a switch somewhere in the corner that is used to train staff. He does not know anything about this, sees that this switch looks newer, and decides to connect it to the general network. He sets up this switch, connects it, for example, to switch SW2 and creates a trunk. And as soon as he turns it on, your entire network falls! Everything stops working, because the connection between computers and switches is completely lost.
Why did this happen? The maximum revision number of the company's switches is 50, because the company has only 5 VLANs - 10,20,30,40,50. The new switch was used for training, more networks were connected to it, many changes were made to the settings, as a result of which its revision number increased to 100. At the same time, it has only one network in the VLAN database, number 105.
After SW Training connected to SW2 via a trunk, the second switch saw that the beginner has a higher revision number and decided to change his number to the highest one. At the same time, he copied the VLAN table of the new switch, automatically deleting all the existing networks VLAN10,20,30 ...., replacing them with one VLAN105, which had not been in the existing network before. Similarly, the first and third switches arrived, changing the revision number from 50 to 100 and deleting the old networks from the database, because they were not contained in the VLAN table of the SW Training switch.
The SW1 switch has created access ports for the VLAN10 network, but after updating the revision this network disappeared. The switches are arranged in such a way that if the access port is configured to work with a network that is not in the VLAN database, this port is programmatically disabled. The same thing happened with the VLAN20 and VLAN30 networks - the switches did not find them in the updated virtual networks database and simply disconnected the corresponding access ports, after which the existing local network of the company failed.
I assure you that this does not rarely happen in practice. Personally, I witnessed twice the event when the network stopped working due to the fact that someone had connected a new switch. So be careful, because VTP is a very powerful thing. Cisco believes that because of the possibility of a similar problem, VTP is better not to use at all.
There is a network failure prevention mechanism caused by a VTP usage error. This is the VTP domain mechanism, which works this way: if the domain of one of the switches on the network differs from the domain of other switches using the VTP protocol, the switch VLAN database of this switch will not be carried out. However, despite this mechanism, Cisco does not advise using this protocol unless it is absolutely necessary.
However, if you are sure that VTP will help you in creating a network and that you can responsibly approach to setting up switches, you can try using it. VTP has 3 modes: Server, Client and Transparent.
The VTP Server mode allows you to make changes to the network, that is, to create, delete and modify VLANs from the switch command line. By default, this mode is set in all Cisco switches.
I drew three switches, the first one is in Server mode, and the other two are in Client mode. You can create a new VLAN only on the first switch, after which the database will be replicated on the second and third switches. If you try to do this with the second switch, you will get the answer: "I am not a server, so you cannot make such changes to my settings." This is the mechanism for preventing changes. Thus, you can select one of the switches by the server, make changes to its settings, and they will be repeated on the client switches. However, what if you do not intend to use VTP?
To completely stop using this protocol, you need to switch the switch to Transparent mode. At the same time, you do not disable VTP mode, just the switch no longer generates VTP announcements, does not update the VLAN database, and always uses the configuration revision number 0.
Suppose we use the Transparent mode for the second switch. When receiving VTP –information, he will see that this protocol does not apply to it, and will simply transfer this information to the next switch, which is in Client mode, without updating anything in its own settings. Thus, the Transparent mode means the rejection of the use of VTP by a specific switch.
So remember that the Server mode allows you to make changes, the Client mode allows you to receive these changes, and the Transparent mode prevents changes from being applied via the VTP protocol, transferring them further along the network.
Now let's talk about a concept called VTP Pruning. Suppose that on switch SW1 there are two VLAN30 networks, a red VLAN20 network and two blue VLAN10 networks.
Switch SW2 does not have a port for VLAN30. However, by default, SW1 sends tagged VLAN10.20 and 30 traffic over the trunk. As the network administrator, you know that the SW2 switch does not have a VLAN30, but must ensure the correct transmission of any traffic. To do this, you use additional information for traffic originating from SW1 using VTP Pruning. You configure the first switch so that it can transmit only VLAN10 and VLAN20 traffic on a trunk, excluding the possibility of transmitting VLAN30 traffic over a trunk. This is what the concept of VTP Pruning is. In the next video tutorial, we will look at how to implement the settings that I talked about today.
So, we have discussed three concepts: Native VLAN, VTP and VTP Pruning. I hope you understand all of what you have heard. If this is not the case, review the lesson as many times as you see fit, and do not hesitate to ask me questions by email or in the comments to this video.
Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr's users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd 2 times cheaper? Only we have 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199 in the Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $ 99! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?
So, a trunk is a connection that we use to connect one switch to another switch. VLAN is a technology that is applicable only to switches, but any device that speaks the language of encapsulation and is associated with a switch using the .1Q protocol understands everything related to VLAN. Computers do not know anything about this technology.
')
In the following figure, PC1, PC2, and PC4 are part of a blue VLAN, as you recall from the previous lesson, this is VLAN10. The blue line itself does not have anything to do with the VLAN, because the VLAN only affects the port of the switch. Thus, both ports of the left switch belong to VLAN10 and any incoming or outgoing traffic is associated only with this network. The switch knows that the traffic of these blue ports has nothing to do with the red port, because these are two different virtual lines.
VLAN is a concept for switches, so each switch supports the creation and storage of a virtual network database. This is a table that indicates which port corresponds to a specific VLAN. Thus, if the switch receives traffic for PC1, it checks if this traffic is part of VLAN10 and forwards it to the computer. If traffic from PC1 is for PC4, the switch will route it through trunk SW1-SW2. As soon as the traffic enters the trunk port of the first switch, it provides the frame with the VLAN TAG header, which contains the VLAN ID, in our case it is 10. Upon receiving this traffic, the second switch reads the frame information, sees that it is VLAN10 traffic, and forwards it on the blue port for PC4.
Thus, trunking is the process of transferring traffic between two switches, and VLAN TAGS are frame headers that identify a specific virtual network and indicate which network the traffic should be sent to. If by mistake the blue traffic gets to the computer through the red line, it will not even know how to read it. It is as if someone speaks a foreign language with a person who does not know this language. So, the computer is completely incapable of recognizing VLAN tags. The PC3 computer is connected to the switch via the access port, and the traffic we mentioned can only be sent via the trunk port.
All these are features of the 2nd level of the OSI model to which switches belong. In order to better understand the essence of VLAN and tags, we need to think like a switch. Suppose that a switch is a room in which there are 5 people, and you are the owner of this room. Three people numbered 1,2 and 4 belong to the same group, and two numbered 3 and 5 belong to the other, and your duty is to make it so that only people belonging to the same group can talk to each other.
Let's continue the discussion of the concept of native VLAN. As already mentioned, each switch port is associated with a specific VLAN.
For example, two ports of the first switch are connected to VLAN10, a third access port with VLAN20, and the fourth one is a trunk port. In the same way, SW2 is connected to PC4 through the port VLAN10, from PC5- through the access port VLAN20 and to the hub through the trunk port. However, we have one problem - switches are expensive, so a scheme is often used in which two switches are connected to each other through a hub. Two switches are connected to the hub using trunks, but the hub itself knows nothing about the concept of a VLAN, it simply copies the signal. As we have already said, if VLAN traffic is directly sent to the computer, it will drop it, because it will not understand what it is. How can we be with PC6 computer, which is connected to the hub directly, if it is going to communicate with PC4 computer?
Computer PC6 sends traffic that goes to switch SW2. Having received this traffic, the switch sees that the frame does not have a VLAN tag and does not know which network to send it to — VLAN10 or VLAN20. For this case, Cisco has created a technology called the Native VLAN, and the default VLAN1 is the Native VLAN.
Suppose we have another computer, I will draw it over the SW2 switch, and this PC is connected to the switch via port VLAN1. The same computer is located above SW1 and is also connected to it via VLAN1. I will draw another computer under the right switch.
Two computers connected to switch SW2 via VLAN1 can communicate with each other, but are unable to communicate with other computers. When a switch receives untagged traffic through a trunk, it considers that this traffic is addressed to VLAN1, or Native VLAN, and forwards it to computers connected to VLAN1 ports. Similarly, when a switch receives untagged PC6 traffic, it addresses its network VLAN1.
What happens if we have a Cisco IP Phone on the VLAN20 red line that is connected to PC5 and SW2? This is a typical layout of office network equipment. In this case, the concept of Native VLAN is also used. As I said, the computer does not know what VLAN is, and the phone knows. The question is whether we can send data and voice over the same VLAN. This is a very dangerous situation, because if a computer is on the same line as an IP phone, a hacker can easily connect to that link and use Wireshark to intercept voice packets. Then he can convert these voice packets into a sound file and listen in on any telephone conversation. Therefore, in practice, voice traffic and data traffic are never transmitted over the same VLAN line. How can this be customized?
We turn the port to which the IP phone is connected into a trunk port, and we believe that any traffic passing through this port is voice traffic from the VLAN30 network. Any Cisco IP Phone uses 802.1q encapsulation protocol, commonly referred to as .1Q or Dot 1Q. Thus, when the traffic from the phone goes to the corresponding port, the switch understands that it is the voice traffic of VLAN30. We must have another phone that is connected to the SW switch, which is also part of VLAN30.
What then happens to the PC4 computer that is connected to the switch via the access port? After all, the traffic that this computer exchanges with the switch belongs to the blue VLAN10. However, PC5 is connected to a switch via a trunk, and for the trunk we do not configure any VLAN! In this case, the port is operating in trunk mode, not access, so we cannot use the switchport access VLAN # command. It uses the same concept as in the case of the PC6 computer - if the switch receives untagged traffic, it sends it to the port of the native VLAN, by default it is VLAN1.
The question arises whether it is possible to change the native VLAN. The answer is yes, you can do this, for example, in the case of the red line, you can change the native VLAN to VLAN20, and then the switch will direct the red traffic from PC5 to VLAN20. Since both switches are connected by a trunk, switch SW2, having received VLAN20 traffic, considers it as native VLAN traffic and sends SW1 switch as untagged.
Having received this traffic, switch SW1 recognizes it as untagged native traffic, and since its native VLAN is VLAN1, it will send this traffic to this network. If we change the native VLAN, we must do it with caution to make sure that all the native VLAN in all switches have changed in the right way, otherwise it can cause many problems.
It was a short review of the native VLAN, and now we’ll go to the proprietary VTP protocol (VLAN Trunking Protocol). First of all you should remember that, despite its name, VTP is not a trunking protocol.
From previous lessons, we know that there are only 2 trunking protocols: a proprietary Cisco protocol called ISL and the generally accepted 802.1q protocol.
VTP is also a proprietary protocol of Cisco, but does not deal with trunking in the sense of creating backbone connections. Suppose we created VLAN10 on the port of the first switch to which the computer is connected. Next we have a trunk SW1-SW2 and a trunk SW2-SW3. When trunk port SW1 receives computer traffic, it knows that it is VLAN10 traffic and forwards it to the second switch. However, the second switch does not know what VLAN10 is, because nothing but a trunk is connected to it, so in order to receive this traffic and send it further, it creates VLAN10 on its ports. Switch 3 will do the same - receiving traffic on the trunk, it will create VLAN10.
You can create two access ports on SW3, and both will be VLAN10. Suppose that on all 3 switches I want to create another network - VLAN20. This will only be possible after the ports for VLAN20 are created. The more devices, computers, and switches are added to your network, the more difficult it becomes to create new VLANs, so Cisco has automated this process by creating a VTP.
If we create a new VLAN, call it VLAN30, on one of the switches, then on all other switches connected by a trunk, the same VLAN30 network is automatically created.
The updated, updated VLAN database is simply distributed across all switches, and all you have to do is create an access port for the computer. Without this protocol, you will have to manually reconfigure all switches. The disadvantage of VTP is that if you make changes to the VLAN database, it changes the revision number - the revision number. Usually, when you use a switch right out of the box, all settings have a zero revision number. When you add a new VLAN, for example, the tenth, the SW1 database gets revision number # 1. In this case, the second switch says: “OK, you have revision 1, and I have revision 0, so I have to change my revision number to 1 and re-copy all the data from your VLAN table to my table”. The third switch does the same thing.
Suppose now that switch 2 adds itself VLAN20 and changes the revision number to 2, then the first and third switches must do the same. Each time you change a revision number, the protocol checks who has this number higher and changes all other revision numbers to that number, simultaneously updating its VLAN table. Moreover, VTP unconditionally trusts the switch with the highest revision number.
Imagine such a situation. A new employee comes to the company and finds a switch somewhere in the corner that is used to train staff. He does not know anything about this, sees that this switch looks newer, and decides to connect it to the general network. He sets up this switch, connects it, for example, to switch SW2 and creates a trunk. And as soon as he turns it on, your entire network falls! Everything stops working, because the connection between computers and switches is completely lost.
Why did this happen? The maximum revision number of the company's switches is 50, because the company has only 5 VLANs - 10,20,30,40,50. The new switch was used for training, more networks were connected to it, many changes were made to the settings, as a result of which its revision number increased to 100. At the same time, it has only one network in the VLAN database, number 105.
After SW Training connected to SW2 via a trunk, the second switch saw that the beginner has a higher revision number and decided to change his number to the highest one. At the same time, he copied the VLAN table of the new switch, automatically deleting all the existing networks VLAN10,20,30 ...., replacing them with one VLAN105, which had not been in the existing network before. Similarly, the first and third switches arrived, changing the revision number from 50 to 100 and deleting the old networks from the database, because they were not contained in the VLAN table of the SW Training switch.
The SW1 switch has created access ports for the VLAN10 network, but after updating the revision this network disappeared. The switches are arranged in such a way that if the access port is configured to work with a network that is not in the VLAN database, this port is programmatically disabled. The same thing happened with the VLAN20 and VLAN30 networks - the switches did not find them in the updated virtual networks database and simply disconnected the corresponding access ports, after which the existing local network of the company failed.
I assure you that this does not rarely happen in practice. Personally, I witnessed twice the event when the network stopped working due to the fact that someone had connected a new switch. So be careful, because VTP is a very powerful thing. Cisco believes that because of the possibility of a similar problem, VTP is better not to use at all.
There is a network failure prevention mechanism caused by a VTP usage error. This is the VTP domain mechanism, which works this way: if the domain of one of the switches on the network differs from the domain of other switches using the VTP protocol, the switch VLAN database of this switch will not be carried out. However, despite this mechanism, Cisco does not advise using this protocol unless it is absolutely necessary.
However, if you are sure that VTP will help you in creating a network and that you can responsibly approach to setting up switches, you can try using it. VTP has 3 modes: Server, Client and Transparent.
The VTP Server mode allows you to make changes to the network, that is, to create, delete and modify VLANs from the switch command line. By default, this mode is set in all Cisco switches.
I drew three switches, the first one is in Server mode, and the other two are in Client mode. You can create a new VLAN only on the first switch, after which the database will be replicated on the second and third switches. If you try to do this with the second switch, you will get the answer: "I am not a server, so you cannot make such changes to my settings." This is the mechanism for preventing changes. Thus, you can select one of the switches by the server, make changes to its settings, and they will be repeated on the client switches. However, what if you do not intend to use VTP?
To completely stop using this protocol, you need to switch the switch to Transparent mode. At the same time, you do not disable VTP mode, just the switch no longer generates VTP announcements, does not update the VLAN database, and always uses the configuration revision number 0.
Suppose we use the Transparent mode for the second switch. When receiving VTP –information, he will see that this protocol does not apply to it, and will simply transfer this information to the next switch, which is in Client mode, without updating anything in its own settings. Thus, the Transparent mode means the rejection of the use of VTP by a specific switch.
So remember that the Server mode allows you to make changes, the Client mode allows you to receive these changes, and the Transparent mode prevents changes from being applied via the VTP protocol, transferring them further along the network.
Now let's talk about a concept called VTP Pruning. Suppose that on switch SW1 there are two VLAN30 networks, a red VLAN20 network and two blue VLAN10 networks.
Switch SW2 does not have a port for VLAN30. However, by default, SW1 sends tagged VLAN10.20 and 30 traffic over the trunk. As the network administrator, you know that the SW2 switch does not have a VLAN30, but must ensure the correct transmission of any traffic. To do this, you use additional information for traffic originating from SW1 using VTP Pruning. You configure the first switch so that it can transmit only VLAN10 and VLAN20 traffic on a trunk, excluding the possibility of transmitting VLAN30 traffic over a trunk. This is what the concept of VTP Pruning is. In the next video tutorial, we will look at how to implement the settings that I talked about today.
So, we have discussed three concepts: Native VLAN, VTP and VTP Pruning. I hope you understand all of what you have heard. If this is not the case, review the lesson as many times as you see fit, and do not hesitate to ask me questions by email or in the comments to this video.
Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr's users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd 2 times cheaper? Only we have 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199 in the Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $ 99! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?
Source: https://habr.com/ru/post/458560/
All Articles