Switching Question

Netstudent

I have a sample question that seems odd. Someone fill me in.

Which statement is true?
Answer: This interface may negotiate as a dot1q trunk and operate with the native vlan 1.

int gigabitethernet 3/9
mtu 9216
no ip address
switchport
switchport access vlan 5
switchport trunk encap dot1q
end

Why would we want a port that is a member of a single VLAN have the ability to negotiate as a trunk port? IF it negotiates as a trunk, then that will totally negate the fact that it is a member of a single VLAN. ALso there is no switchport mode command here. So if the link peer is configured with "switchport mode dynamic desirable" will this interface trunk in despite of no mode command?

EdTheLad

Netstudent wrote:

I have a sample question that seems odd. Someone fill me in.

Which statement is true?
Answer: This interface may negotiate as a dot1q trunk and operate with the native vlan 1.

int gigabitethernet 3/9
mtu 9216
no ip address
switchport
switchport access vlan 5
switchport trunk encap dot1q
end

Why would we want a port that is a member of a single VLAN have the ability to negotiate as a trunk port? IF it negotiates as a trunk, then that will totally negate the fact that it is a member of a single VLAN. ALso there is no switchport mode command here. So if the link peer is configured with "switchport mode dynamic desirable" will this interface trunk in despite of no mode command?

If you try the command "show interface gig 3/9 switchport" it would explain things.

D12-7600-1#sh int gig 2/0/12 switchport
Name: Gi2/0/12
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Unknown unicast blocked: disabled
Unknown multicast blocked: disabled

By default a switchport has trunking enabled with a state dynamic desirable, if the farend of the link is able to trunk this local port will exchange DTP messages and try and form a trunk.If the trunking is sucessful the access vlan configuration is not used.If the port cant become a trunk the port will be in access mode and use the configured vlan to tag frames on ingress.
You can set the port to always be a trunk using the command "switchport mode trunk", DTP messages are still sent so its best to disable them using the command "switchport nonegotiate".

The thing that really gets me is when i'm working on Catos and Ios boxes at the same time, the Catos boxes will use the access vlan as their native vlan, every couple of months i foregt this for afew minutes and end up having to troubleshooting links.

Netstudent

oh well that makes sense. I forgot about the switches being in a dynamic trunking state by default. So the lack of the mode command in the code is actually there by default. Thanks Ed.




"The thing that really gets me is when i'm working on Catos and Ios boxes at the same time, the Catos boxes will use the access vlan as their native vlan, every couple of months i foregt this for afew minutes and end up having to troubleshooting links."

Wait I just read that and at first I thought that was only a catOS rule, but after rereading that section, it says that is an IOS rule as well. "When the port is not trunking, the access vlan configuration defines the native vlan."

So is that considered an IOS rule as well as a catOS rule?