cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
483
Views
10
Helpful
5
Replies

Trunking and Access Ports

srogers
Level 1
Level 1

I have a 3560 switch that has ports fa0/1 - 24 configured as trunks:

description IP_phone/PC

switchport trunk encapsulation dot1q

switchport trunk native vlan 10

switchport trunk allowed vlan 10,100,200

switchport mode trunk

switchport voice vlan 100

no ip address

srr-queue bandwidth share 10 10 60 20

priority-queue out

mls qos trust device cisco-phone

mls qos trust dscp

no mdix auto

spanning-tree portfast

and my uplink to my 3750 configured as an access port:

switchport access vlan 1622

switchport mode access

no ip address

srr-queue bandwidth share 10 10 60 20

priority-queue out

mls qos trust dscp

From what I have read this is backwards. I would like your thoughts as well as how encap/decapsulation works in this setup. Thanks in advance.

5 Replies 5

Edison Ortiz
Hall of Fame
Hall of Fame

Shayne,

It all depends upon your needs. If you need to forward just *one* VLAN between switches, configuring the port in access mode would be the right configuration. If you plan on creating a VTP Server/Client model between switches, then you must trunk the port since you need to forward multiple VLAN information between the 2 devices.

I recommend using the industry standard dot1q as the trunk encapsulation if you want to proceed with trunking between these switches. You may also want to prune VLANs in order to prevent unwanted traffic over this link.

As for the IP_Phone/PC ports, they need to be trunked due to having 2 VLANs (one for data and one for voice).

HTH,

Thanks for the reply.

I thought when connecting switches the packets needed to be encapsulated and decapsulated using either dot1q or isl, or is that just for switches other than cisco? What is confusing is that if you trunk the 2 switches you use the command "switchport trunk allow vlan *,*... This clearly states multiple vlans are allowed to pass from switch to switch. I would have expected with the ports in access mode to only allow the vlan assigned to the port "switchport access vlan 1627" in this case only vlan 1627 to pass traffic.

Shayne,

When connecting switches *and* forwarding multiple VLANs via the links, packets must be tagged with trunk encapsulation dot1q or isl. However, if you only need to forward one VLAN information and avoid any extra traffic, configuring an access vlan would be the right choice.

This concept applies to any switches, cisco or non-cisco.

If you trunk the 2 switches, all VLANs stored in their respective VLAN DBs will be forwarded unless you use the 'allow vlan' option.

If you reference my original post ports 1 -24 are trunks but the link to my 3750 is an access port. What you are saying is the only vlan that should travel over the link is the access port vlan. Yet my access port is carrying 3 vlans from the trunked ports. I am confused?

Shayne,

"What you are saying is the only vlan that should travel over the link is the access port vlan."

If you configure a port 'mode access' only one VLAN will be forwarded to the device connected to this port.

If this device, a switch on this case, only services one VLAN - then configuring the uplink port with 'mode access' would be the correct configuration here.

If you want to forward VTP information, you need to configure the port as trunk. From your configuration, it looks like you don't have the need to.

Your current workstation ports need to be configured as trunk since you have voice and data services. Voice resides in a different VLAN and Data resides in another VLAN. Only one copper cable is available for these 2 services/vlans so that's the reason you need to trunk it. But even then, as you see, you have a native VLAN on the trunk which functions are the 'access' vlan. That is done with this command.

switchport trunk native vlan 10

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco