Troubleshoot assist with Cisco VTP Trunk over Gigabit Laser link

Posted on 2009-04-04
Last Modified: 2012-05-06
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!
Question by:support_ferret
  • 3
  • 2
  • 2
  • +1
LVL 50

Assisted Solution

by:Don Johnston
Don Johnston earned 400 total points
ID: 24067097
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.

LVL 79

Assisted Solution

lrmoore earned 50 total points
ID: 24067127
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.

Author Comment

ID: 24067808
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.
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

LVL 11

Assisted Solution

packetguy earned 50 total points
ID: 24070498
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.

Author Comment

ID: 24070769
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! :)
LVL 50

Assisted Solution

by:Don Johnston
Don Johnston earned 400 total points
ID: 24071207
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.

Accepted Solution

support_ferret earned 0 total points
ID: 24098141

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!
LVL 79

Expert Comment

ID: 24122553
Thanks for the update! Good rule of thumb, start at layer 1 always.

Featured Post

Flexible connectivity for any environment

The KE6900 series can extend and deploy computers with high definition displays across multiple stations in a variety of applications that suit any environment. Expand computer use to stations across multiple rooms with dynamic access.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Multiple MPLS Circuits Connecting to LAN 3 46
TL-R470T+ and Cisco ASA 2 21
Public IP Address - Subnet 4 36
Cisco 800 router unable to connect through TPG network 12 24
Problem Description:   Couple of months ago we upgraded the ADSL line at our branch office from Home to Business line. The purpose of transforming the service to have static public IP’s. We were in need for public IP’s to publish our web resour…
Network ports are the threads that hold network communication together. They are an essential part of networking that can be easily ignore or misunderstood, my goals is to show those who don't have a strong network foundation how network ports opera…
After creating this article (, I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor ( If you're interested in additional methods for monitoring bandwidt…

821 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question