Question Concerning Trunking dot1q

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

I had to configure some ports today. The encapsulation command didn't work.

switchport trunk encapsulation dot1q

I am thinking that since ISL is no longer supported that when you trunk a port it defaults to encapsulation dot1q. Can anyone chime in?

In any event, it trunked and there wasn't a problem. I just want to know for my peace of mind.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

That's weird.

What series switch were you using ? Because if it was a cat switch, then you shouldn't have had any problems.

I'm not sure whether a port has the capacity to tag itself by default, but I do know that you have to encapsulate it manually if you're going to configure vlans and use a router to segment the domains.

I know that you can configure a port to negotiate it's own tagging. i.e

Switch(config-if)# switchport trunk encapsulation negotiate

With this option, you specify the port to negotiate with the neighboring port to tag the trunk with either ISL or dot1q, depending on the configuration capabilities of the neighboring port.

 

Naw, I'm not sure about this anymore now. I'm gonna have to fire up the switches and see.

 

NetEyeBall,

In order to use ISL, which is a Cisco proprietary protocol, all switches needs to be Cisco. Since that may not be the case, the "open standard" version is 802.1q or "dot1q."

The "encapsulation command" is used in interface configuration mode.

Switch> enable
Switch#config t
Switch(config)#int fax/x
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#exit
Switch(config)#exit
Switch#

Verify that the switchport is configured as a trunk:

Switch> enable
Switch# config t
Switch(config)# int fax/x
Switch(config-if)#switchport mode trunk
Switch(config-if)#exit
Switch(config)#exit
Switch#

Also, verify that the switch port is a member of the VLANs that you want VLAN information to be passed down the trunk to the switch or router.

Remember, 802.1q Trunking has the "feature" known as the "Native VLAN" which is NOT encapsulated.

I hope this helps.

 

Okay I erased NVRAM on one of my switches and had a look at the default settings on one of the ports.

It appears the default is "negotiate" for administrative trunking.

I think this means that further encapsulation of this interface is unnecessary, since the port will automatically negotiate ISL or dot1q tagging with the connected port of a neighboring switch.

I don't know if this applies to all other catalyst switches though. The one I'm using is a 3550.

3550/1#sh int fa0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
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
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none
3550/1#

 

Okay, this is getting interesting.

I erased the startup config on my other switch, also a 3550 and then stuck a crossover cable in the fa0/1 ports of both switches.

Now the readouts have changed somewhat. The administrative trunking encapsulation is still "negotiate". But now the operational trunking encapsulation has defaulted to "isl".

I've got the same readouts on both switches.

Interesting.

I'm gonna experiment with this further and see what gives.


3550/1#sh int fa0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: isl
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
Protected: false
Unknown unicast blocked: disabled
--More--  Unknown multicast blocked: disabled

Appliance trust: none
3550/1#

 

Okay, without encapsulating or trunking either fa0/1 port on either switch, I still was able to establish connectivity between two newly created vlans.

The default trunking on both ports is "isl" as of now.

Now I'm going to check and see what happens if I encapsulate one of the ports with dot1q. Would the default administrative trunking kick in and negotiate a link between both switches ?

Well, let see.

3550/1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3550/1(config)#vlan 10
3550/1(config-vlan)#name experiment
3550/1(config-vlan)#exit
3550/1(config)#int vlan 10
00:06:22: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
3550/1(config-if)#ip address 192.168.2.1 255.255.255.0
3550/1(config-if)#exit
3550/1(config)#exit
3550/1#
00:06:50: %SYS-5-CONFIG_I: Configured from console by console
3550/1#

3550/2>
3550/2>en
3550/2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3550/2(config)#vlan 10
3550/2(config-vlan)#exit
3550/2(config)#int vlan 10
3550/2(config-vlan)#name experiment
3550/2(config-if)#
00:14:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
3550/2(config-if)#ip address 192.168.2.2 255.255.255.0
3550/2(config-if)#exit
3550/2(config)#exit
3550/2#ping
00:15:18: %SYS-5-CONFIG_I: Configured from console by console
3550/2#ping 192.168.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
3550/2#

 

Thanks both of you for your help. It is a brand new 6513 switch. I didn't look at the IOS version however. It was right at shift change and I was multitasking ordering a replacement switch for another hospital and doing this. So my attention was split a bit.

 

Well, I changed the encapsulation on switch 2 to dot1q and then pinged switch 1 and the ping was successful. Not just that, but the trunking on the fa0/1 port on switch 1 automatically changed itself to dot1q. So now the encapsulation on both switchports is currently dot1q and both switches can ping each other.

Bear in mind that I didn't configure the vtp operating mode or domain name on either switch and no manual trunking was done.

Conclusion ?

Switch 1 negotiated the new tagging for itself automatically. That means that the default administrative trunking overode the default operational trunking and the negotiate feature kicked in as soon tagging was changed on the neighboring switch (switch 1).

Bear in mind that the 3550 is a layer 3 switch however. I have no idea whether the same thing would work on a layer 2 switch.



3550/2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3550/2(config)#int fa0/1
3550/2(config-if)#switchport trunk encapsulation dot1q
3550/2(config-if)#e
00:50:42: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
00:50:42: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to down
3550/2(config-if)#exit
3550/2(config)#
00:50:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
3550/2(config)#exit
3550/2#
00:50:52: %SYS-5-CONFIG_I: Configured from console by console
00:51:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up.
3550/2#ping 192.168.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
3550/2#sh interface trunk

Port Mode Encapsulation Status Native vlan
Fa0/1 desirable 802.1q trunking 1

Port Vlans allowed on trunk
Fa0/1 1-4094

Port Vlans allowed and active in management domain
Fa0/1 1,10

Port Vlans in spanning tree forwarding state and not pruned
Fa0/1 1,10
3550/2#

3550/1>en
3550/1#sh interface trunk

Port Mode Encapsulation Status Native vlan
Fa0/1 desirable n-802.1q trunking 1

Port Vlans allowed on trunk
Fa0/1 1-4094

Port Vlans allowed and active in management domain
Fa0/1 1,10

Port Vlans in spanning tree forwarding state and not pruned
Fa0/1 1,10
3550/1#ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
3550/1#

 

Wow.

Was the IOS a Cisco IOS or a CatOS ? Because if it was CatOS, that could have been the problem.

 

It was IOS. I will go back into it on my next work night and check it out in more depth. It was part of a migration and the engineers are new and didn't have access to the switch. So they had me work on it.

 

Man, you're lucky. I wish I could get my hands on a 6500.

 

I don't know about lucky...just set up range of ports for vlan 1...which is default anyways so I am not sure why they requested it. lol...and then set up two ports to be a trunk.

But you know I enjoy my job. I am being put back on network troubleshooting so that is VERY VERY good news and my schedule is going to move back to a more normal night schedule rather then an absurd night schedule which I am on now. So I will have time again to start studying. 4 months of not really being able to study has definately hurt.


Just as a general practice I wouldn't ever put any port into auto negotiate or anything like that. I always code what I want. Speed, Duplex, Switch Port, or Trunk. You never know when the auto negotiate gremlins might come out and try to mess up your network. But then thats just my .02 cents.

What say you guys?

 

Agreed.

But I'll try anything on my home lab. Sometimes it works, sometimes it doesn't. But everything's worth trying at least once.