Options
Cisco switch and VoIP phone system question.
Problem which I have is very strange so I would like to ask you if it is possible.
Today I connected additional Cisco Catalyst switch to a network (they supposed to be separated but unfortunately somebody linked them) which had VoIP phone system. After this operation phones went down. Obviously I disconnected the switch and rebooted all hardware but it didn’t help.
Somebody told me that the reason of problem is I connected second switch with VLANs to the same network and Cisco Catalyst for VoIP has been wiped.
For me it sounds as absurd. I can imagine network conflict caused by second switch, but after disconnection of the device and reboot system everything should came back on line but..... unfortunately I'm not a Cisco engineer.
Could you tell me if it makes any sense please?
Today I connected additional Cisco Catalyst switch to a network (they supposed to be separated but unfortunately somebody linked them) which had VoIP phone system. After this operation phones went down. Obviously I disconnected the switch and rebooted all hardware but it didn’t help.
Somebody told me that the reason of problem is I connected second switch with VLANs to the same network and Cisco Catalyst for VoIP has been wiped.
For me it sounds as absurd. I can imagine network conflict caused by second switch, but after disconnection of the device and reboot system everything should came back on line but..... unfortunately I'm not a Cisco engineer.
Could you tell me if it makes any sense please?
Comments
-
Options
kalebksp
Member Posts: 1,033 ■■■■■□□□□□
Very possible, due to the way VTP (VLAN Trunking Protocol) works if you connect a switch with a higher VTP database version to a network it can wipe out all the existing VLANs and replace them with it's own. To fix it you need to recreate the VLANs. -
Optionstiersten
Member Posts: 4,505
What kalebksp said. The network administrator need to configure VTP correctly and make sure that the switches aren't set to automatically create trunks. Still puzzled as to why they even made that the default. Its just asking for problems like that.Very possible, due to the way VTP (VLAN Trunking Protocol) works if you connect a switch with a higher VTP database version to a network it can wipe out all the existing VLANs and replace them with it's own. To fix it you need to recreate the VLANs. -
OptionsPiotrIr
Member Posts: 236
Many thanks for your reply.
For me it is quite strange as it makes network completely idiot (like me for example) non proof. So if you would like to destroy somebody’s network – add new switch and you don’t need any administrator privileges... -
Options
Forsaken_GA
Member Posts: 4,024
i think every company runs into this at least once.
After that, they learn to enable security and things like bpduguard, as well as learning to shut down any ports that aren't in use. That way, things like this do not happen. -
Optionstiersten
Member Posts: 4,505
Not particularly. You need to connect it to a port that has trunking enabled. If you've got unrestricted access like that anyway then you can already cause havok through other means. You need to secure the trunk ports and implement 802.1x.Many thanks for your reply.
For me it is quite strange as it makes network completely idiot (like me for example) non proof. So if you would like to destroy somebody’s network – add new switch and you don’t need any administrator privileges... -
Optionsnice343
Member Posts: 391
next time before you add a switch to the production network make sure it has a revesion number of 0. Best way would to wipe all config and reload. Also make sure every port that is not trunking is an access port. Problem might have been averted if VTP password was in effect and devices were in "transparent mode". You may also want to look into thatMy daily blog about IT and tech stuff
http://techintuition.com/ -
Options
ColbyG
Member Posts: 1,264
VTP or STP related, that'd be my guess.
Edit: If it didn't come back after removing the switch/rebooting, then yea, probably VTP. -
Options
laidbackfreak
Member Posts: 991
Best way would to wipe all config and reload.
Make sure you erase the vlan database too tho....if I say something that can be taken one of two ways and one of them offends, I usually mean the other one :-) -
OptionsForsaken_GA
Member Posts: 4,024
next time before you add a switch to the production network make sure it has a revesion number of 0. Best way would to wipe all config and reload. Also make sure every port that is not trunking is an access port. Problem might have been averted if VTP password was in effect and devices were in "transparent mode". You may also want to look into that
Current best practice for adding a switch to a network is to put VTP in transparent mode before you hook it up, then it can't wreak havoc with the vlan database. Once you have it up, *then* you can configure VTP in such a way as to ensure it doesn't blow up your network.
Many companies avoid the use of VTP altogether and just put all their switches in transparent mode and do manual vlan administration. Any administrator who deploys VTP, but doesn't take steps to protect the database (ie, disable auto trunking, filter bpdu's from ports that shouldn't have them, shut down all ports that aren't in use) is a flipping idiot and deserves what he gets.
