Why the switch allow me to configure a port in trunk mode and in access mode at the same time??
In this example, vlan 10 is configured on access mode, but the native vlan is doing the same thing, in fact when vlan 10 is configured as native vlan, it is be able to receive all NON-Tagged traffic as a normal access port. Am I Right? Why the switch allow to configure both?
Actually, this interface is configured as a trunk. It is the switchport mode command that tells you the mode of the interface. You can have either switchport mode trunk, or switchport mode access. You will never have both trunk and access configured on the same interface, because when you issue this command, it overwrites the previous configuration.
When you have switchport mode trunk, as you have in this case, the switchport access vlan 10 command is ignored.
But because you have the switchport trunk native vlan 10 command, any untagged frames arriving at this port will go to VLAN 10. So the interface behaves as if it is an access port on VLAN 10 simply because the native VLAN is set up that way.
So to summarize:
this interface is indeed a trunk and not an access port
the switchport access VLAN 10 command is ignored
the native VLAN of 10 makes the interface act as if it is an access port on VLAN 10, although it is not.
They told me that General mode is not a Dell proprietary protocol, but it exists also in other manufacturers.
Can you tell me more information about this modeâŚI saw talking about it in Cisco community too, but I canât understand why is needed ( on not Dell switches)âŚ
General mode is indeed available on switches of other vendors as well, including the Cisco small business series of switches. General mode causes ports to function differently for egress and ingress traffic.
For egress, general mode allows a switch to send untagged frames out of an interface, that come from multiple VLANs.
For ingress, all untagged frames must go to the configured native VLAN. This is because, regardless of which VLAN these frames originated from, there is no way to distinguish to which VLAN they belong since they have no tags. By definition, the configured native VLAN is the VLAN on which all incoming untagged frames must be placed.
This means that untagged frames originating from multiple VLANs on SW1 will all end up on the configured native VLAN of the port on SW2.
Now to be honest, after doing some additional research, I find no obvious benefit to the general mode for an interface. There may be an obscure use case where it is beneficial, but I havenât found anything myself. Cisco IOS doesnât support it, but the small office devices do.
Thanks for your reply, I saw that in Dell switches the native vlan not work properly between switches of other manufactures, so I think that General mode is developed as a workaround of this problem.
Hello Rene i want to know what diffrent between trk1-2 in hp and cisco trunk for example when i want to trunk a uplink in hp aruba switch i do this comannd trunk port2 trk3 trunk and tagged in vlan20 tagged trk3
vlan 20
name "IT"
tagged Trk1-Trk3
no ip address
exit
and i want to know how to tagged a port in a vlan in cisco switch can you answer me please?
or at cisco system we do this command
I am not familiar with the CLI of HP/Aruba, however I did some research and found the following.
In the CLI of HP/Aruba, you are able to define trunk groups. These are groups of interfaces that can then be used to configure those interfaces with tagged and untagged VLANs. For example, you can create the following trunk group and call it Trk1 like so:
trunk b23-b24 Trk1 Trunk
You can then reference Trk1 within the VLAN configuration and state that that particular VLAN should be tagged on all ports within the Trk1 group. This can be done like so:
vlan 20
tagged Trk1
exit
This means that VLAN 20 will be tagged on interfaces b23 and b24 since they belong to the Trk1 group.
Now Cisco doesnât have this hierarchical configuration method. You must apply the allowed VLANs on the interface itself rather than referencing the interfaces via trunk groups under the VLAN configuration.
For this reason, you would use the commands you have stated above. For each interface, you must state if it will process tagged frames (trunk mode) and if so, which VLAN tags will be allowed on the port (trunk allowed vlan command).
Hi Rene,
I am, using WS-C2960S-24PD-L switch.
I got % Unrecognized command error message when I was going to config a trunk at interface Gi1/0/14.
CW2960#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
CW2960(config)#interface gi1/0/14
CW2960(config-if)#switchport trunk encapsulation ?
% Unrecognized command
CW2960(config-if)#switchport trunk encapsulation â
I would appreciate very much if you would explain the reason why?
Thank you.
Cisco devices have traditionally supported two encapsulation methods: ISL and dot1q. Newer switches no longer support ISL, so there is only one encapsulation method available. For this reason, the switchport trunk encapsulation command was removed. This is the reason you donât have that option in your device.
Is everything else working correctly in your topology or are you facing other difficulties as well? Let us knowâŚ
Switch A - vlan 50 and vlan 1
Switch B - vlan 50 and vlan 1
PCA is in vlan 50 on Switch A
PCB is in vlan 50 on switch B.
Both switches are connected by an access link.
They are only able to communicate if the access link is assigned to vlan 50
I was testing to see if it actually worked in EVE-NG
I would create a trunk link as best practice though if I were on a LAN without assigning it to a
specific vlan since trunk links have access to all vlans.
This works fine as long as you specify the access vlan as 50 on both switches for the access link G0/0 between them with - Switch(config-if)# switchport access vlan 50
What Rene is saying in the lesson is that for this particular topology that has only one VLAN being sent over the trunk (i.e. VLAN 50), you can technically achieve the same thing either using trunk ports or access ports.
You can either make both ports on both switches access ports on VLAN 50, or make them both trunk ports and allow VLAN 50 on both of them. The result is that frames belonging to VLAN 50 will traverse the link in both cases.
Now if you want to pass more than one VLAN across the link, this can only be achieved using a trunk link.
One might wonder what the âLimited connectivityâ means. This is probably explained by Wendell Odom in his official CCNA textbook (the OCG, or Official Cert Guide). On page 18 of Vol 1.'s Chapter âAppendix P: LAN Troubleshooting,â he says the following:
âA different incorrect trunking configuration results in one switch with an operational state of âtrunk,â while the other switch has an operational state of âstatic access.â When this combination of events happens, the interface works a little. The status on each end will be up/up or connected. Traffic in the native VLAN will actually cross the link successfully. However, traffic in all the rest of the VLANs will not cross the link.â
This is an interesting setup though. For example, if switch SWTâs interface is configured as a trunk, and switch SWAâs interface is configured as an access link, then these are the possibilities:
a) When traffic goes from SWA to SWT: only traffic in the native VLAN will cross the link. Thatâs because SWA will send only untagged (native VLAN) traffic.
b) When traffic goes from SWT to SWA (and thereâs no switchport trunk allowed vlan command configured on SWT): all tagged traffic from SWT is going to get untagged by SWA and received by the hosts in SWAâs native VLAN. This means that hosts on SWA that shouldnât get broadcast traffic from the VLANs that reside on SWT are going to get the traffic. These hosts on SWA are going to be all hosts in SWAâs native VLAN. So every single broadcast traffic on SWT (from every single VLAN that exists on SWT: which means all VLANs from 1 to 4094) is going to be received by the hosts in SWAâs native VLAN.
Iâm sure someone can correct me if I made a mistake.
Take a look at this lesson which talks about trunking and the various options that you can configure for your ports, including dynamic auto and dynamic desirable:
You may also find this lesson concerning DTP helpful as well:
@molnarattila1221 kindly shared with you Ciscoâs official description as well, which is also very helpful. If you have more questions about this topic, feel free to ask!
Where do we use trunk- access (Like the port connected to PC should be access ) Dynamic desirable or Dynamic auto? How do we select either from the trunk or Dynamic desirable?
The answer is⌠it depends. Older switches used to support multiple encapsulation types. Specifically, they supported the IEEE standard of 802.1q as well as Ciscoâs proprietary ISL protocol. As such, the default configuration for a switchport was to automatically detect the encapsulation.
If you wanted to force the port to act as a trunk port, then you had to hardwire the encapsulation to either dot1q or ISL first. So for this reason, the switchport trunk encapsulation dot1q command was necessary before applying the trunk mode.
Now does that mean that DTP is disabled? No. But it does mean that this particular port will not be changed by DTP, but it can affect the port on the other end of the link if it has not been âhardwiredâ in a similar fashion. The lesson on DTP has more information bout this.
