Solved

Troubleshoot assist with Cisco VTP Trunk over Gigabit Laser link

Posted on 2009-04-04
8
1,095 Views
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.

ISSUE:
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!
0
Comment
Question by:support_ferret
  • 3
  • 2
  • 2
  • +1
8 Comments
 
LVL 50

Assisted Solution

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

0
 
LVL 79

Assisted Solution

by:lrmoore
lrmoore earned 50 total points
Comment Utility
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.
0
 
LVL 1

Author Comment

by:support_ferret
Comment Utility
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.
0
 
LVL 11

Assisted Solution

by:packetguy
packetguy earned 50 total points
Comment Utility
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.
0
Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

 
LVL 1

Author Comment

by:support_ferret
Comment Utility
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! :)
0
 
LVL 50

Assisted Solution

by:Don Johnston
Don Johnston earned 400 total points
Comment Utility
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.
0
 
LVL 1

Accepted Solution

by:
support_ferret earned 0 total points
Comment Utility
Update:

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

Expert Comment

by:lrmoore
Comment Utility
Thanks for the update! Good rule of thumb, start at layer 1 always.
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

We've been using the Cisco/Linksys RV042 for years as: - an internet Gateway - a site-to-site VPN device - a leased line site-to-site subnet-to-subnet interface (And, here I'm assuming that any RV0xx behaves the same way as an RV042.  So that's …
Creating an OSPF network that automatically (dynamically) reroutes network traffic over other connections to prevent network downtime.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), 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…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

743 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

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now