Troubleshoot assist with Cisco VTP Trunk over Gigabit Laser link

Dear Network Experts,

I have a beginner's knowledge of Cisco, currently studying for CCNA.  We have a problem with our LAN, probably due to a design incompatibility with a gigabit laser link between our HQ building and some smaller business units 200metres away.

HQ has 4 floors plus the ground.  In the comms room on ground there are two 3750G switches in a stack.  This stack is the VTP server for the VTP domain.  Each floor has a 24 port 3560G, connected by a single fibre optic pair to the stack on the ground floor, operating as VTP trunk ports.

The 3560G on the top floor has an additional port in VTP trunk mode - a gigabit ethernet port connected to a gigabit laser head, carries data across to the Laserhead at the small office 200m away.  NOTE:  the laserheads do not do any switching or routing.  They operate only as a "virtual" cable.

Importantly, the laser link carries two "cables" - the data link as described above, and an internal link for management.  This management link is necessary for the laserheads to share status and setup information.  The laserheads have an ethernet port on them, to allow management IP addresses to be assigned to them.  The management ports MUST be plugged into a switch at each end (either standalone or a VLAN).  The management port addresses must be on the same subnet, but it does not need to be part of the production network, although in our case they are.

On the top floor of HQ, the laserhead management port is connected to an ethernet port (access mode) on the 3560G.  The port is a member of our "management" VLAN.

The laserhead data port at the small office connects to a 2960G, again to an ethernet port running in VTP trunk mode.  The laserhead management port similarly connects to an access port in the "management" VLAN on the 2960G.

If the laser beam is interrupted in any way, or if the laser data port is disconnected, for any length of time, network traffic ceases to be passed between the two sites, for around 3 -4 hours (on average).  In other words, a momentary blip in the beam appears to shutdown the link for a few hours.

The laserlink vendor assures us it is due to our network design.  They say the problem would not happen if the laserhead management ports were plugged into standalone switches at each end. I believe this may be the case but we have not tested this yet.

We suspect that it is due to the VLAN information being interrupted, therefore preventing the management VLAN from operating correctly.    I guess spanning-tree might be involved also.  We do not know why the VLAN trunk takes so long to re-establish.  We turned on logging on the trunk ports last night, so I may be able to provide more information on Monday.  We also disabled VTP pruning last night in case it was pruning the management VLAN when the laser went down.

We see a couple of potential solutions, but it would be great if there was a way of configuring Cisco to prevent it.  The vendor wants us to remove Cisco VLANS from the equation but we know Cisco's great - I'm sure we can tweak it! :)  The network design was approved on EE by a couple of Experts, so I believe it is down to the quirkiness of the laser not liking our Cisco design.

I will post more information on Monday but any preliminary ideas would be gratefully received!

Many thanks!
Who is Participating?
support_ferretConnect With a Mentor Author Commented:

After I unplugged and replugged the laserhead on Friday night, I expected it to be back in a few hours (in time for Monday morning).  However, I connected on Sunday and it was still down.  I could not resolve in the usual fashion so I left til Monday morning to ask the vendor to assist.

The vendor was not available so I tried changing the patch lead from the head to the patch panel at the small office location.  The laser link came up immediately.  Interesting as we replaced the patching at the HQ end only a couple months back to improve reliability.

The boss won't let us investigate this further at the moment, as he wants some uptime between the outages.  There may still be an issue, but then the patch lead may have been causing issues from the start.  The laser worked perfectly for the first 3 months, so it could be that the patch leads were on their last legs.  I still don't have an answer for the 3 hour convergence time, but if/when I do, I will get the moderators to reopen the question so I can post it on for future reference.

I am awarding points based on knowledge and reasoning demonstrated, which helped our case with the vendor and gave us confidence in our network design.  Thanks to all for your assistance!
Don JohnstonConnect With a Mentor InstructorCommented:
I don't agree.

If it was that, it would happen to every network when a link failed momentarily. Also, DTP, VTP and CDP data is carried by VLAN 1 which is the default VLAN and does not require VTP.

If you want to prove that VTP isn't the problem, put the client switch at remote site into transparent mode. That will eliminate VTP as an issue.

I cannot think of a switching protocol that would create the symptom you describe a 3-4 hour convergence.

If it were me, I would reduce the link to the basics; no switches. Just a pair of PC's. Then move up to hubs, then unmanaged switches (or managed switches with all features disabled), then managed switches and add features one at a time until you've identified the culprit.

lrmooreConnect With a Mentor Commented:
You can also try making the switchport on the 3560G a routed interface instead of a trunk interface and have a separate subnet(s) in the other building with their 2960 switch manually configured for locally significant vlans.
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

support_ferretAuthor Commented:
thank you to you both for your quick and helpful responses!

It is likely that in the long term that we would look at a routed setup, which may help of course.

In the meantime I will attempt to isolate the problem as donjohnston suggests.  Thank you for the confirmation about convergence also.

Will post results up here as we find them.
packetguyConnect With a Mentor Commented:
What is the MTU set to on the laserheads? If is is less then the switch MTU, that could block transit of large packets, such as those involved in VTP reconvergence. The laser mtu should be large enough to handle the larger switch MTU, plus an extra four bytes or so for vlan tag overhead.
support_ferretAuthor Commented:
thanks for your comment -  we will also verify this.  I believe that MTU is not configurable as the laserheads do not operate as interfaces.  They are more like an invisible cat6 cable if that is the correct analogy! :)
Don JohnstonConnect With a Mentor InstructorCommented:
This isn't an MTU or a VTP problem.

If it were an MTU problem, it wouldn't resolve itself in 3 - 4 hours.

And as for VTP, when a link goes down, the VLAN database on client switches doesn't change, it simple doesn't receive any new updates. The list of VLANs is still there.
Thanks for the update! Good rule of thumb, start at layer 1 always.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.