Weird issues with trunk port on 3850 switches

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.

Hi all,

This weekend I tried to replace a stack of 3750G's with a stack of new 3850's.

The stack of switches has 2 fibre uplinks to the core switches (4506).

It didn't go well, and I had to revert the project.

The stack was all pre-configured in the workshop but could not be tested on the live LAN. When I connected it today, I first connected up 1 of the 2 uplinks. The link went to UP status, and I could see the remote ore switch via CDP, but it would not learn the VLANs (VTP was setup correctly), and looking at the port on the switch, it flashed green, went solid green, then flashed amber. This cycled continuously, whilst the link status remained up.

I debugged spanning-tree but nothing stood out. I tried a replacement SFP, and a different slot but no difference.

I re-connected one of the old 3750's and immediately the link came up stable, and everything was fine.

I then erased the config on the new stack, and simply set the port as trunk, with udld enabled (matching the remote end) (neither switch supports ISL, so the trunk is dot1q). The same issue persisted.

Does anyone have any advice? I am starting to wish I spec'd 3750X's instead!!

Thanks

 

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.

Did the port error disable by any chance? I've had something similar bite me when reconfiguring a fibre SAN switch.

Although having said that if it was error disabling due to light emission being low (which is where I was heading) it wouldn't have come up when you rolled back.

 

Hi,

No the port did not err-disable.

Well, it did when I removed and re-inserted the SFP, but that is a known bug with the IOS I was using! It says the module is not compatible. A shut / no shut fixes it though.....

I have no doubt that the fibre link is good, its something strange with the new switches, but I just cannot work out what!

 

Any other ideas anyone? I have to explain the failure pretty soon and so far am no closer!

I am going to grab a spare 3650 switch, and trunk that to the new stack and see if it behaves. I hope it doesn't, so I can firmly pin the blame on the new switches. Thing is we didn't SmartNet them - tend not to for access switching.

Thanks
Tim

 

I think you are going to need to perform some more troubleshooting while the link is connected. Get some interface stats from both the 4500 and the 3850 while it is connected....are there errors? Is the link set to auto-neg? Try setting manually.

 

Hi,

I have tried as a trunk with and without non-negotiate, and also dynamic desirable and auto. I can always see the remote end via CDP still.

When looking at the counters, there were a small number of packets transferred to the switch, and no errors shown. The same at the other end.

I am likely to be doing testing on this tonight.

 

I would want to prove at the lowest level the link is ok.....Once you have confirmed it isn't a speed/duplex issue (test with auto and manual interface settings) on the 4500, make the fibre port an access port in a specific VLAN, then create that same vlan manually on the 3850 and configure the fibre port also as an access port in this VLAN. Does the interface LED look any different? If it is still cycling green/amber I am pretty sure there is some sort of link issue unrelated to any config on the port at either end. Another step you can add on is connect a PC to the new switch in this same VLAN and do some testing across the network from the PC....and look at the interface.

 

Any joy with this?

If you can see the switch via CDP then layer one and layer2 are good in my opinion...... you need to do a "show int" on both sides and see what it says.... I would also do a "show span int gix/x/x" or whatever to see the spanning tree status of the ports. I would be checking the native vlan on the trunk port to make sure both are the same..... debug VTP? check VTP versions..... had an issue with a 3850 where it was running in VTP version 3 and you cannot create vlans on anything other than the MASTER/PRIMARY SERVER!! let me know how you get on!

Jon

 

I would of agreed layer 1/2 must be fine....but since he said VTP is configured correctly then this should also work if that was the case. Also the port LED status indicates a link issue. So it may be the error is not enough to thwart cdp....but the VTP information is not able to gett across. I don't see the benefit to looking a spanning tree though if there are no VLANs on the switch...

 

Just because VTP is said to be or is assumed to be configured correctly, it doesnt mean it is (no offence Phatboy).... as I stated, the 3850's can run VTP V3.... now I haven't looked into the specifics but what if its not downward compatible or the config needs an extra one liner compared to vtp v2? its the same as the STP check, the benefit of looking at spanning tree aswell is that you get the full picture and if you look at the full picture then you can generally resolve the issue. I agree it is unlikely to be STP but everything is worth looking at; especially when spanning tree is something that can bring down a port (and it will still show the port as up.... and the fact that when it is in its listening/learning state is shows different port LED states - i also wonder how long the port led is in its cycle for, does it ties in with any timers?)

I have found with the graduates I teach in my support team that If they look in specific areas ignoring the information around them then something may be missed. The problem is sometimes you get tunnel vision and focus on areas that are symptoms and not the area where the problem lies.....

If you want some more help on this phatboy then post the configs with the following:

show vtp status
show int gix/x/x switchport
show span int gix/x/x

and the biggest one of all.....

SHOW LOG

Jon

 

For some reason I stopped getting notified about this thread.

We did get the problem resolved, and it was embarrassingly simple..... vtp password

It doesn't show in the running config, so I completely missed it.

Thanks for all the ideas though, good problem solving info. there!

Tim