support_ferret
asked on
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.
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!
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!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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! :)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thanks for the update! Good rule of thumb, start at layer 1 always.
ASKER
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.