1. Home
  2. Cisco Systems
  3. Trunking between CatOS and IOS

Trunking between CatOS and IOS

1) The plan was to make the uplink port connected from Distribution switch to CoreSW as Trunk, so thought of doing the changes in Distribution switch and then CoreSW 2) Logged in Distribution switch, entered the following commands in the interface Gig0/49 connected to Coresw Distribution switch# show run int gig 0/49 ! interface GigabitEthernet0/49 switchport trunk encapsulation dot1q switchport mode trunk allowed vlan all 3) Then logged into CoreSWand entered the below command on the interface 1/30 connected to distribution switch

set trunk 1/30 desirable negotiate 1-4094 =E2=80=93 (Here is the messup !!= !)

All Access switches connected to Distribution switch, started going down and not reachable =EF=81=8C, parallely we got this STP error In CoreSw

CoreSW > (enable) set trunk 1/30 desirable negotiate 1-4094 Vlan(s) 1-4094 already allowed on the trunk Please use the 'clear trunk' command to remove vlans from allowed list. Port(s) 1/30 trunk mode set to desirable. Port(s) 1/30 trunk type set to negotiate. Core switch> (enable) 2009 Jul 30 21:37:50 DST -07:00 %ETHC-5- PORTFROMSTP :Port 1/30 left bridge port 1/30

2009 Jul 30 21:37:53 DST -07:00 %ETHC-5-PORTTOSTP:Port 1/30 joined bridge port 1 /30 2009 Jul 30 21:37:54 DST -07:00 %SPANTREE-2-RX_1QNONTRUNK: Rcved 1Q- BPDU on non- trunk port 1/30 vlan 50 from 00-19-56-bd-a1-b1 2009 Jul 30 21:37:54 DST -07:00 %SPANTREE-2-RX_1QPVIDERR: Rcved pvid_inc BPDU on 1Q port 1/30 vlan 50 from 00-19-56-bd-a1-b1 2009 Jul 30 21:37:54 DST -07:00 %SPANTREE-2-RX_BLKPORTPVID: Block 1/30 on rcving vlan 50 for inc peer vlan 1 4) So, we reverted all the changes by using the command =E2=80=9Cclear trun= k 1/30=E2=80=9D on CoreSW- 5) Then, took console access to all of these non reachable Acc Switch, there the uplink port was err-disabled with the following logs: Jul 30 21:44:13.616 PDT: %PM-4-ERR_DISABLE: loopback error detected on Gi0/1, putting Gi0/1 in err-disable state . Jul 30 21:44:14.622 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down . Jul 30 21:44:15.646 PDT: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down Re enabled err-disabled ports in all the non reachable access switches with shut, no shut command 6) From the logs from the core switch highlighted above we thought, its due to the native vlan clash, hence we thought of configuring the trunk port=E2=80=99s native vlan as 50 7) So, again logged in Distribution switch and tried with the below commands: interface GigabitEthernet0/49 switchport trunk native vlan 50 switchport mode dynamic desirable switchport trunk encapsulation dot1q switchport trunk allowed vlan 50,56

And in CoreSwitch the same command set trunk 1/30 desirable negotiate 1-4094 (Again same issue and these are the errors in Coreswitch this time

Core switch> (enable) 2009 Jul 30 23:40:42 DST -07:00 %SPANTREE-2- RX_1QNO NTRUNK: Rcved 1Q-BPDU on non-trunk port 1/30 vlan 50 from 00-19-56-bd- a1-b1

Core switch> (enable) 2009 Jul 30 23:45:26 DST -07:00 %SPANTREE-2- PORTUNB LK: Unblock previously inc port 1/30 on VLAN 50

Again, all the Access switches connected to Distribution switch-a become not reachable, so again we repeated the same above steps and reverted all the config to the old setup

Reply to
Jitin
Loading thread data ...

When setting up a trunk, you can't set one side to explicitly trunk, and the other side to negotiate trunking. You need to set up both sides the same, which you did in the second try, but in that one you incorrectly set the default VLAN to 50.

1) The plan was to make the uplink port connected from Distribution switch to CoreSW as Trunk, so thought of doing the changes in Distribution switch and then CoreSW 2) Logged in Distribution switch, entered the following commands in the interface Gig0/49 connected to Coresw Distribution switch# show run int gig 0/49 ! interface GigabitEthernet0/49 switchport trunk encapsulation dot1q switchport mode trunk allowed vlan all 3) Then logged into CoreSWand entered the below command on the interface 1/30 connected to distribution switch

set trunk 1/30 desirable negotiate 1-4094 - (Here is the messup !!!)

All Access switches connected to Distribution switch, started going down and not reachable ?, parallely we got this STP error In CoreSw

CoreSW > (enable) set trunk 1/30 desirable negotiate 1-4094 Vlan(s) 1-4094 already allowed on the trunk Please use the 'clear trunk' command to remove vlans from allowed list. Port(s) 1/30 trunk mode set to desirable. Port(s) 1/30 trunk type set to negotiate. Core switch> (enable) 2009 Jul 30 21:37:50 DST -07:00 %ETHC-5- PORTFROMSTP :Port 1/30 left bridge port 1/30

2009 Jul 30 21:37:53 DST -07:00 %ETHC-5-PORTTOSTP:Port 1/30 joined bridge port 1 /30 2009 Jul 30 21:37:54 DST -07:00 %SPANTREE-2-RX_1QNONTRUNK: Rcved 1Q- BPDU on non- trunk port 1/30 vlan 50 from 00-19-56-bd-a1-b1 2009 Jul 30 21:37:54 DST -07:00 %SPANTREE-2-RX_1QPVIDERR: Rcved pvid_inc BPDU on 1Q port 1/30 vlan 50 from 00-19-56-bd-a1-b1 2009 Jul 30 21:37:54 DST -07:00 %SPANTREE-2-RX_BLKPORTPVID: Block 1/30 on rcving vlan 50 for inc peer vlan 1 4) So, we reverted all the changes by using the command "clear trunk 1/30" on CoreSW- 5) Then, took console access to all of these non reachable Acc Switch, there the uplink port was err-disabled with the following logs: Jul 30 21:44:13.616 PDT: %PM-4-ERR_DISABLE: loopback error detected on Gi0/1, putting Gi0/1 in err-disable state . Jul 30 21:44:14.622 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down . Jul 30 21:44:15.646 PDT: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down Re enabled err-disabled ports in all the non reachable access switches with shut, no shut command 6) From the logs from the core switch highlighted above we thought, its due to the native vlan clash, hence we thought of configuring the trunk port's native vlan as 50 7) So, again logged in Distribution switch and tried with the below commands: interface GigabitEthernet0/49 switchport trunk native vlan 50 switchport mode dynamic desirable switchport trunk encapsulation dot1q switchport trunk allowed vlan 50,56

And in CoreSwitch the same command set trunk 1/30 desirable negotiate 1-4094 (Again same issue and these are the errors in Coreswitch this time

Core switch> (enable) 2009 Jul 30 23:40:42 DST -07:00 %SPANTREE-2- RX_1QNO NTRUNK: Rcved 1Q-BPDU on non-trunk port 1/30 vlan 50 from 00-19-56-bd- a1-b1

Core switch> (enable) 2009 Jul 30 23:45:26 DST -07:00 %SPANTREE-2- PORTUNB LK: Unblock previously inc port 1/30 on VLAN 50

Again, all the Access switches connected to Distribution switch-a become not reachable, so again we repeated the same above steps and reverted all the config to the old setup

Reply to
Thrill5

To get this kind of issue you need loops and spanning tree, since you are getting ports blocked.

Spanning tree, VLANs and big campus networks need to be managed to control the L2 and L3 boundaries.

What may be happening is that spanning tree is blocking so that some VLANs are partitioned so that devices on those VLANs cannot get to the right default gateway.

Maybe you need to sit down and look at the VLAN map for the campus. Have you got the same VLAN used in different places which are meant to stay isolated?

Have you got a mix of spanning tree per VLAN and spanning tree per switch?

Also are you running VTP?

stuff about CatOS & IOS on a Cat 6500

formatting link
this is the general 6500 page for config examples
formatting link
Here is a Cisco switch guide on best practice

CatOS

formatting link
formatting link

Reply to
Stephen

I honestly have not bored into this one, however it did occur to me that the issue might be that VTP is changing the VLAN configuration on some of your switches as soon as the trunk comes up.

The best idea is to disable VTP. I forget the details now. Someone will I am sure come up with some advice. VTP mode transparent - sounds familiar.

In case there is any doubt - my view is that VTP is evil and that it should be disabled. Decades ago, a few people thought that it supported their paranoia and quite liked it. The reality is that it is a problem waiting to bite you.

Is my, perhaps somewhat jaundiced, view:)

Reply to
bod43

Thrill5,

Can you pls elaborate a bit - I dont really agree to what you are saying. The basic definition of Switchport mode dynamic desirable is thta it actively attempts to convert to trunk and becomes trunk if nei is set to trunk /desirable/auto

Reply to
Jitin

ios command: vtp mode transparent

CatOS will be something similar starting "set "

Reply to
Stephen

Well the proof is in the pudding. When set to auto/desirable, trunking is enable if it negotiated by both sides of the link. When you set one side to explictly trunk, it does just that, trunking is ON. If the other side is set to desirable, the other side tries to negotiate trunking, but the side that is set to trunk isn't trying to negotiate anything, it is trunking. It is the same concept as negotiating speed and duplex, If you set one side to auto/auto and you set the other to 100/full you will have a problem.

Thrill5,

Can you pls elaborate a bit - I dont really agree to what you are saying. The basic definition of Switchport mode dynamic desirable is thta it actively attempts to convert to trunk and becomes trunk if nei is set to trunk /desirable/auto

Reply to
Thrill5

VTP makes sure that the VLAN configuration in the VTP domain is synchronized. Once up and running VLAN's don't disappear on one switch unless you delete them on another one. By the same token, if you add a VLAN, that VLAN is added to all the switches in the same VTP domain.

VTP can be dangerous, especially if every switch is configured as VTP server. I always configure distribution switches as VTP server, and all the access switches VTP client. I also use a unique VTP domain name at every location. That way, if someone reuses a switch that was pulled out of a different location, and the VLAN database wasn't cleared, and it happens to be configured for VTP server, it won't cause a problem. But then again, I also have a standard for VLAN assignments, so the VLAN numbers are the same anyway.

Reply to
Thrill5

VTP is dangerous. Unless you are running VTPv3, of which I have no opinion.

Don't have to be VTP server. VTP client is quite capable to overwrite database.

formatting link
Regards, Andrey.

Reply to
Andrey Tarasov

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.