Cisco switch and VoIP phone system question.

PiotrIrPiotrIr Member Posts: 236
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?

Comments

  • kalebkspkalebksp 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.
  • tierstentiersten Member Posts: 4,505
    kalebksp wrote: »
    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.
    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.
  • PiotrIrPiotrIr 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...
  • Forsaken_GAForsaken_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.
  • tierstentiersten Member Posts: 4,505
    PiotrIr wrote: »
    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...
    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.
  • PiotrIrPiotrIr Member Posts: 236
    Thanks for your help. Now I'm aware it is never easy.....
  • nice343nice343 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 that
    My daily blog about IT and tech stuff
    http://techintuition.com/
  • ColbyGColbyG 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.
  • laidbackfreaklaidbackfreak Member Posts: 991
    nice343 wrote: »
    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 :-)
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    nice343 wrote: »
    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.
Sign In or Register to comment.