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
-
Optionskalebksp 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,505Very 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: 236Many 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... -
OptionsForsaken_GA Member Posts: 4,024i 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,505Many 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: 391next 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/ -
OptionsColbyG Member Posts: 1,264VTP or STP related, that'd be my guess.
Edit: If it didn't come back after removing the switch/rebooting, then yea, probably VTP. -
Optionslaidbackfreak Member Posts: 991Best 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,024next 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.