It appears that from best practices Call Manager should work with a single voice VLAN configuration and some larger scope of DHCP server to support bigger deployments. I wander if you have any suggestions on adding additional voice VLAN into existing Call Manager cluster to add additional and separate DHCP scope from CCM cluster. Whould it be possible and than recommended to CCM expand deployment by adding DHCP scope to allow for additional /24 network and than add additional voice VLAN to allow for such expansion? If yes can you guys suggest the best way to build it on the switches fabric?
Multiple voice vlans should not be an issue, don't think it is against any good practice.
The implementation would require creating a vlan, assigning it to the relevant ports (as voice vlan) and then creating an additional scope and optionally relaying requests from the new vlan to the dhcp server.
The "Best Practice" recommends a separate Voice VLAN for buildings/Floors. This way something effecting one VVLAN (like a broadcast storm) won't take down the whole voice network. So, yes using multiple VLAN's and Multiple DHCP Scopes is highly encouraged.
Campus Access Layer
The access layer of the Campus LAN includes the portion of the network from the desktop port(s) to the wiring closet switch.
Proper access layer design starts with assigning a single IP subnet per virtual LAN (VLAN). ***Typically, a VLAN should not span multiple wiring closet switches; that is, a VLAN should have presence in one and only one access layer switch (see Figure 3-2). This practice eliminates topological loops at Layer 2, thus avoiding temporary flow interruptions due to Spanning Tree convergence. However, with the introduction of standards-based IEEE 802.1w Rapid Spanning Tree Protocol (RSTP) and 802.1s Multiple Instance Spanning Tree Protocol (MISTP), Spanning Tree can converge at much higher rates. More importantly, confining a VLAN to a single access layer switch also serves to limit the size of the broadcast domain. There is the potential for large numbers of devices within a single VLAN or broadcast domain to generate large amounts of broadcast traffic periodically, which can be problematic.
When you deploy voice, Cisco recommends that you enable two VLANs at the access layer: a native VLAN for data traffic and a voice VLAN under Cisco IOS or Auxiliary VLAN under CatOS for voice traffic.
Separate voice and data VLANs are recommended for the following reasons:
Address space conservation and voice device protection from external networks
Private addressing of phones on the voice or auxiliary VLAN ensures address conservation and ensures that phones are not accessible directly via public networks. PCs and servers are typically addressed with publicly routed subnet addresses; however, voice endpoints should be addressed using RFC 1918 private subnet addresses.
QoS trust boundary extension to voice devices
QoS trust boundaries can be extended to voice devices without extending these trust boundaries and, in turn, QoS features to PCs and other data devices.
Protection from malicious network attacks
VLAN access control, 802.1Q, and 802.1p tagging can provide protection for voice devices from malicious internal and external network attacks such as worms, denial of service (DoS) attacks, and attempts by data devices to gain access to priority queues via packet tagging.
Ease of management and configuration
Separate VLANs for voice and data devices at the access layer provide ease of management and simplified QoS configuration.
From this CCM SRND doc;
Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x
I very much appreciate your advise in this matter. I should essentially copy Rob's reply and forward it to one of the TAC guys since they recommended different approach. I also found day later the SRND CCM 4.x document as well and I have digested similar scope of recomendations. I think I know which is the best direction to move now. Thanks again - guys.
First off, you are most welcome! I can't think of what other model this person might have recommended? When we first built our Voice network we used a single Voice VLAN on a "flat" Network. Bad idea! But who knew! We found that (as I noted before) any issue in one area affected phones in every area :( Hard to isolate and troubleshoot.
We have continued to try and improve our Voice and Data network using Cisco "Best Practice" designs of which, not having VLAN's span multiple switches, let alone multiple areas is surely paramount!
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...