Go Premium for a chance to win a PS4. Enter to Win


Troubleshoot assist with Cisco VTP Trunk over Gigabit Laser link

Posted on 2009-04-04
Medium Priority
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 1600 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 200 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.
Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

LVL 11

Assisted Solution

packetguy earned 200 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 1600 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

Get Certified for a Job in Cybersecurity

Want an exciting career in an emerging field? Earn your MS in Cybersecurity and get certified in ethical hacking or computer forensic investigation. WGU’s MSCSIA degree program was designed to meet the most recent U.S. Department of Homeland Security (DHS) and NSA guidelines.  

Question has a verified solution.

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

I recently attended Cisco Live! in Las Vegas, a conference that boasted over 28,000 techies in attendance, and a week of hands-on learning hosted by a solid partner with which Concerto goes to market.  Every year, Cisco displays cutting-edge technol…
WARNING:   If you follow the instructions here, you will wipe out your VTP and VLAN configurations.  Make sure you have backed up your switch!!! I recently had some issues with a few low-end Cisco routers (RV325) and I opened a case with Cisco TA…
NetCrunch network monitor is a highly extensive platform for network monitoring and alert generation. In this video you'll see a live demo of NetCrunch with most notable features explained in a walk-through manner. You'll also get to know the philos…
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …

877 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