cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
365
Views
0
Helpful
5
Replies

Migration of Access Switch and Implementation of new Cat6500

tbogie_gvds
Level 1
Level 1

Readers,

I have an issue when trying to migrate trunk connections off two access switches (hwbssw35a and hwbssw35b) from hwbwcata to hwbwcatc. The access switches, and presumably devices directly connected to it, can no longer can access distant networks. This is manifested by the access switches no longer prompting for a TACAC's username / password.

The issue is consistent when the access switch trunk connection is migrated from hwbwcata to hwbwcatc. When the change was backed out, all issues went away.

hwbwcatc is relatively new to the network. Ideally hwbwcata is supposed to be replaced with hwbwcatc. Unfortunately the process of moving all switch and server connections has been staged and so the whole activity has been undertaken over a period of time.

I have provided a pretty picture which shows the trunk connections. A lab was put together to simulate the environment with 3560 switches and 2800 routers as we don't have a bunch of spare 6500's laying around. I initially thought the issue was due to the use of isl and dot1q trunks but we had resolved the issue by turning off ip routing on the simulated catc but the production network didn't respond the same way the lab did :-(

I have also attached the 'show tech' output of the three core switches and two access switches.

Your help and advice is appreciated.

Timothy

5 Replies 5

vishwancc
Level 3
Level 3

Hi Tbogie,

What i understood is since the TACAC server is not reachable if this is the problem

Could you check from the switch if you could ping the TACAC sever.

You could try this by removing the TACAC config and use default login.

If are are not able to reach the server check for connectivity path and routes.

You could also enable debug AAA authentication and check the messages.

Chao

Vishwa

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Timothy,

if you have a management vlan in your network you need to verify that is propagated correctly on all switches including the new hwbwcatc.

The easiest way to check this is to verify that all core switches agree on the root bridge ID of that vlan.

use show spanning-tree vlan X

if this doesn't happen there is a chance that the Vlan X is partitioned.

Another important aspect that you should verify is the native vlan setting:

with 802.1Q trunks a native vlan mismatch will cause problems like the ones you see if the two devices think untagged frames belong to different vlans

Edit:

I see you have ISL trunks to the access switches so the last note doesn't apply

you have a VRRP group on the management vlan.

Without connecting access layer switches to catc can you ping cata ip address in vlan1 ?

Hope to help

Giuseppe

Giuseppe,

I have attached the results. There are ping results from both of the access switches in their pre-change (that is current) condition. Your help is very much appreciated.

Thanks,

Timothy

Hello Timothy,

the ping results to the new catc are not so good as we could expect

91% instead of 100%

if the loss in pinging catc was 100% the management vlan would be partitioned but it is 10%.

so the vlan is not partioned

I would investigate the etherchannel links between catc and cata and catb.

I saw in the sh tech that the configuration of member links is not identical: some member links have spanning-tree portfast enabled other are missing the command

see

interface GigabitEthernet1/21

description Member of Port Channel to HWBWCATA

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 2 mode on

!

interface GigabitEthernet1/22

description Member of Port Channel to HWBWCATA

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

>>> spanning-tree portfast disable

channel-group 2 mode on

!

Hope to help

Giuseppe

Giuseppe,

The ping results are not good. There must be a reason for it.

I think I understand what you mean by partitioning (that is, the use of routers to seperate the network) so Yes, each VLAN does tend to go across to all the switches.

I took another look at the PortChannels between the core switches. It turns out that there is only one active link between them. I have attached the output of a show int for the physical interfaces all three of the switches.

Ultimately this means is that the interfaces that don't have portfast disabled are in a down state.

I have also included VTP and VLAN information. Please refer to the attachment.

Thanks,

Timothy

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: