It depends on the platform you choose. If you use a 2960 for example, it doesn’t give you the choice of encapsulation. This is because in the real world, it only supports a single encapsulation type which is dot1q.
If you use a 3560 multilayer switch, you will see the choice of encapsulation is available. Indeed you will see the following:
Switch(config-if)#switchport mode trunk
Command rejected: An interface whose trunk encapsulation is "Auto" can not be configured to "trunk" mode.
Switch(config-if)#
These switches initially have an encapsulation mode of auto, which is set for access ports. This limitation is a remnant of when ISL was used in the past, but ISL is now an almost obsolete Cisco proprietary trunking protocol. In order to configure the port as a trunk, you must first choose the encapsulation mode like so:
Just a question. Sometimes on Packet Tracer when I say " Switchport mode trunk" on SW1 and if I say “Switchport mode dynamic desirable” on SW2, it shows me n-802.1q on sh int tr. What the hec is n-802.1q? If its negotiate does that mean trunk is already established?
If you have switchport mode trunk on one end of the link, you are manually configuring that port to be in trunk mode. With switchport mode dynamic desirable on the other end of the link, you are configuring it to negotiate with the other switch.
So because one end is configured manually as a trunk, the dynamic desirable end of the link will detect that, and automatically become whatever the other side is. So it becomes a trunk.
Now because a negotiation took place in order for the switch to determine the mode of the port, this is considered a negotiated configuration. The n-802.12q indicates that this is a trunk (802.1q) that has been configured as a trunk through a negotiation process (n-).
In the lesson you will find a table that shows what mode a port will have if each end is configured with a particular mode. Here is that table showing the case in which you have trunk configured on one end and dynamic desirable on the other:
Can you help me to understand how work and how configure the hybrid-port on trunking protocol.
At my job (an ISP company), I see many times this type of configuration, for example when is needed a TOR switch configuration for Esxi servers., but I’m not familiar at all with it.
It is related with the native vlans but the ports are configured on a switch like hybrd-port…that make me very confused
I saw this topic but can you explain me how it works and when I have to use it ,maybe with any example topology where this configuration is needed? Exist any lesson about that?
Unlike Access and Trunk ports, the Hybrid port does not have exactly the same meaning across all vendors. Each vendor will use a different terminology for various types of ports that have particular extra features beyond a simple trunk or access port.
Hybrid ports resemble trunk ports in many ways, but adds additional port configuration
features. In addition to the characteristics described for trunk ports, hybrid ports have these abilities:
Can be configured to be VLAN tag unaware, C-tag aware, S-tag aware, or S-custom-tag
aware.
Ingress filtering can be controlled.
Ingress acceptance of frames and configuration of egress tagging can be configured
independently
Carrier networks often use QinQ with an outer and inner VLAN tag to separate customer traffic. The C-tag mentioned in the above quote is the Customer tag, or the inner tag, and the S-tag is the Service tag or the outer tag.
So a hybrid port is able to provide additional features that are useful to carriers. An example of a configuration of a hybrid port along with several of the features it delivers can be found at the following Cisco documentation:
Because this is not part of any exam content, and because for Cisco, it is a feature that is limited to a particular specialized kind of switch, there are no lessons concerning this on the site.
I have switch in DC IN which server (172.25.185.129/26 ) VLAN 282 and user VLAN 182 10.25.182.0/24 have configured . At level -6 i have one more switch which have user VLAN and Server vlan also. The server in the datacentre have two nic, one is connected to server network in DC and communicate to user network at level 6. And another network user vlan 10.25.182.0 /24 have configured. This user vlan cant communicate with another user vlan at Level 6. And also it cant communicate with this gateway. However the L2 switch at DC can reach gateway 10.25.181.1 .
Why the same vlan cant reach ? However different VLAN (282 AND 182 ) can reachable.
Please advice . Will appreciate your help.SECL6SWITCH.txt (61.3 KB) DCR4R11-SW01-DC-SEC.txt (18.8 KB)
After a brief look at your configuration files, I see that the two switches are connected using a port channel which is configured as a trunk that passes all VLANs between the two switches. This means that if the VLANs are configured correctly on the access ports with the correct VLAN numbers, users should be able to communicate with each other between switches.
However, looking again at your configurations, I see that there is no VLAN 182 on the DC switch, so there is something that’s not right with the VLANs.
Take a look at your VLAN configurations across the two switches again to ensure that the configuration is correct.
The first 8 ports are in VLAN 182 on the DC switch. From the switch i can reach gw 10.25.182.1 . However the I connect VLAN 182 to my laptop , unable to connect gateway.
Kindly let me know if u need any other information then i will send .
Unfortunately I don’t see VLAN 182 on the DC switch. I see VLAN 282 on ports Ge0/1 to Ge0/23. Here is an excerpt from your DCR4R11-SW01-DC-SEC.txt file:
When troubleshooting such issues, it’s not always enough to simply share a configuration file to find a fault. You need all troubleshooting tools at your disposal, namely CLI commands and active testing.
Even so, looking at the configuration files, I see that there is a port channel created on both devices, and this port channel is configured as a trunk which passes all VLANs. However, on the DC switch, I notice that there is no channel-group command on the TE interfaces resulting in an incomplete etherchannel configuration. Without CLI access to confirm this, I can only assume that this is the source of the problem you’re dealing with.
Thanks Rene. It was a good lesson, although I noticed on IOL L2 images, dynamic auto and desirable modes appear to be disabled. I have VIRL though so managed to lab it with one of the L2 IOS images from there.
DTP is a protocol that is used for convenience. When you use it ports can negotiate to function as either access or trunks based on what they perceive at the other end of the link. The danger here occurs when a malicious user is connected to an access port of a switch that is configured to operate with DTP. The user can “trick” the switch into thinking the computer is a switch, and it can create a trunk between the switch and the computer. This will give the computer access to other VLANs that it is not allowed to have.
For this reason, it is always a good idea to disable DTP on the ports of switches. DTP should not be confused with VTP which is a different protocol.
So Administrative Mode Should only be set as 802.1q for switches and operational mode should be set as manually : switchport mode trunk ? & Switchport no negotiate ?
and access ports should manually configured
with this threats can be minimized in the network ?
do we really need dynamic desirable or dynamic auto in real life networks ? or it’s just in lab environment ? if yes where its used ?
It is considered best practice to disable DTP on a trunk using the switchport nonegotiate command. This will ensure that the interface will only enter the mode that you manually configure, either trunk or access. This way, you can avoid any security issues.
The only situation in which DTP would be useful is if you constantly rearrange your network topology, connecting and disconnected switches and hosts. If this is the case, you would connect a PC to a port on the switch, and it will automatically become an access port, or if you connect one switch to another, it will automatically become a trunk. This way you can avoid the need to constantly manually configure ports.
But it is rare to have a production network where this is the case, so outside of a lab environment, DTP in the vast majority of cases can be more harmful than good.
