Archive for the ‘Reference’ tag
Every once and a while I come across the need for a specific tool through Cisco’s website. Though Cisco has improved their website (somewhat) throughout the years, they’ve still to incorporate Google search into their site. Perhaps they’re too proud? Perhaps Cisco is working on their own search engine? Who knows?
Either way, I am going to post a few very useful tolls and their links in this post. It’s nothing original, but hopefully they’ll help be a help to others than just me.
For users who upgrade CUCM from 4.x to 7.x or 8.x, you’ll notice a new indicator below registered devices:
For H.323 gateways, you’ll see a similar (but different) message:
These indicators denote whether the device can support Cisco criteria for secure signaling and media. The CUCM 7.1(3) Release Notes explain what these messages mean. In order to be classified as “trusted”, a device must meet the following criteria:
- Are all devices that are on the call trusted?
- Is the signaling secure (authenticated and encrypted)?
- Is the media secure?
For calls that involve a device that is not trusted, regardless of signaling and media security, the overall status of the call will stay unsecure, and the phone will not display the Lock icon. For example, if you include an untrusted device in a conference, the system considers its call leg, as well as the conference itself, to be unsecure.
A Trusted Device represents a Cisco device or a third-party device that has passed Cisco security criteria for trusted connections. This includes, but is not limited to, signaling/media encryption, platform hardening, and assurance. If a device is trusted, a Security icon displays, and a secure tone plays on supported devices. Also, the device may provide other features or indicators that are related to secure calls. – CUCM 7.1(3) Release Notes
Having finished the CCIE Voice v3 lab, I’ve turned to the CUCM 8.x SRND to look for the latest updates. Here are just a few notes I gathered while on the plane. More to come!
- Limit the number of devices per VLAN to 512, roughly equivalent to two Class C subnets (e.g. 10.4.100.0/23)
- Enable root guard or BPDU guard on all access ports to prevent a rouge switch from taking the Spanning Tree root position. Such an action causes STP re-convergence events and could affect network traffic flows.
- Best practice remains to leave the Layer 2/3 demarcation on the access switches. This is a best practice move from the old standard that placed the demarcation on the distribution switches. With this configuration, Hot Standby Router Protocol (HSRP) or Gateway Load Balancing Protocol (GLBP) virtual gateway addresses are no longer necessary.
- The most apparent advantages to the Layer 3 Access model are: (1) improved convergence, (2) simplified multicast configuration, (3) dynamic traffic load balancing, (4) single control plane, (5) and a single set of troubleshooting tools (for example, ping and traceroute).
- It’s a good idea to use the passive-interface command on all interfaces facing the access layer in order to prevent routing adjacencies to be advertised out through these interfaces. This constitutes a small, but present and unnecessary, CPU drain on the access switches.
- Voice marking for QoS remains at CoS 5 (IP Precedence 5, PHB EF, or DSCP 46).
- Videoconferencing marking for QoS remains at CoS 4 (IP Precedence 4, PHB AF41, or DSCP 34).
- Call signaling for voice and videoconferencing is now classified as CoS 3 (IP Precedence 3, PHB CS3, or DSCP 24) but was previously classified as PHB AF31 or DSCP 26.
Virtual Unified Communications with Cisco UCS
- With the emergence of UC on UCS, there are three virtual switching platforms available for UC applications running on top of VMware: (1) Local VMware vSwitch, (2) Distributed VMware vSwitch, (3) and the Nexus 1000V switch. The Nexus 1000V requires the Enterprise Plus Edition of the VMware ESXi 4.0.
- The virtual machines send traffic to the software switch (options listed above) and then on to the physical UCS Fabric Interconnect Switch (UCS 6100 Series) through its blade server’s Network Adapter and Fabric Extender.
- The UCS 6100 carries both the IP and fibre channel SAN traffic via Fibre Channel over Ethernet (FCoE) on a single wire. IP traffic is sent onward to an IP switch (Catalyst/Nexus) and SAN traffic is sent to a Fibre Channel SAN switch (e.g. Cisco MDS)
- By default, the UCS 6100 creates a fibre-channel priority QoS class for traffic destined for the SAN Switch. This FC QoS class has no drop and marks traffic as CoS 3.
- VMware local/distributed vSwitches and the UCS 6100 cannot map L3 DSCP values to L2 CoS values. Traffic can only be prioritized or de-prioritized within the UCS 6100 based on L2 CoS only.
- UC applications mark L3 DSCP values only. In order to make sure UC on UCS traffic is classified appropriately, you must configure all traffic originating from a blade server Network Adapter to be marked with a single L2 CoS value.
- Nexus 1000V software switch has the ability to map L3 DSCP values to L2 CoS values, and vice versa, like traditional Cisco physical switches such as the Catalyst Series Switches.
The year of 2009 was my Cisco certification marathon. I took nine Cisco Pearson VUE tests in eleven months and received 4.5 certifications: CCENT, CCNA, CCNA Voice, CCVP, CCIE (written). I gave up my life and threw myself into Cisco Press and SRNDs. Truth be told, I loved every minute of it! Well, let me go back and clarify. I loved every minute of it except the sleep deprivation, poor diet, mental fatigue, and bodily stress. Simply put: my brain said, “Thank you!” while my body said, “You jerk!”
During the journey, I learned a lot about myself. Perhaps the greatest lesson I learned was how I best receive and retain information. For me, blogging and creating my own personal study guides were the ticket.
Here’s is one study guide that may be of use to voice folks. It’s for the CCNA Voice exam that will be replaced in February, but it’s an excellent quick reference resource for CUCME. Enjoy! Read the rest of this entry »