Archive for the 'Dennis Hartmann' Category

Data Center Ethernet and the Nexus Switches

Published December 21, 2009 Data Center , Dennis Hartmann Leave a Comment
Tags: , ,

Small Computer System Interface (SCSI) hard drives have been the preferred method of hard drive storage for servers in enterprise networks for a long time. The Serial attached SCSI (SAS) standard is an electrical standard in which SCSI hard drives are chained together and identified by a SCSI ID. SCSI is an electrical standard which only allows devices to be connected up to 10 meters (32.8 feet) from the server.

Fibre Channel (FC) is an optical standard that allows SCSI hard drives to be connected at much further distance depending on the type of fibre optical cable and laser used to drive the signal. Small form factor pluggable (SFP) optical transceivers are used in director switches, storage arrays, and director switches to create a storage area network (SAN). SAN is sent over storage switches, while LAN data traffic is sent over data switches.

Fibre Channel over Ethernet (FCoE) is a technology that is aimed to replace the director switches of the SAN infrastructure by allowing servers to transfer both data and storage traffic over 10 Gigabit Ethernet interfaces using server network interface cards (NIC) that have both fibre channel and Ethernet chipsets.

Fibre Channel frames have a maximum payload size of 2112 bytes, but the FCoE encapsulation process results in a 2179 byte frame. Jumbo frames must be enabled on Cisco Nexus switches to accommodate the overhead of the Ethernet and FCoE header and trailers. Ethernet jumbo frames can accommodate frame sizes of up to 9,216 bytes (9K). The transmission of fibre channel traffic over a data center infrastructure represents some challenges that Ethernet was not originally designed around. Fibre channel does not tolerate frame loss. The Ethernet infrastructure that will transmit FCoE traffic must be designed to be lossless, resulting in zero frame loss.

Cisco Nexus switches are designed around data center bridging’s low latency and low loss requirements.  Cisco’s priority flow control (PFC) is an important technology that is based on the IEEE 802.3x link level pause frame, but the technology can now be implemented at the IEEE 802.1p class of service (CoS) level.  IEEE 802.3x pause frames are used to flow control Ethernet devices that are aggressive sending data when there is congestion on an uplink. IEEE 802.3x flow control operates at the link level causing all traffic to be delayed when this condition arises. The PFC implementation allows Cisco to flow control individual class of service (CoS) values similar to the IEEE 802.1Qbb working group. Since PFC handles congestion at the CoS level, FCoE traffic can be mapped to a CoS value that does not receive a PAUSE frame while the lower priority traffic receives a pause frame. PFC will help guarantee a lossless FCoE environment.

Cisco Nexus switches support a pre-standard version of backward congestion notification (BCN) draft IEEE 802.1Qau standard. BCN allows the Cisco Nexus switches to communicate congestion to end stations and server where PFC only allows congestion throttling at the CoS level on a link by link basis.

Data center bridging exchange (DCBX) protocol allows Cisco Nexus switches to dynamically discover the data center capabilities of other Nexus switches by leveraging negotiation parameters of the Link Layer Discovery Protocol (LLDP).

The Nexus data center switches provide a migration path to fibre channel over Ethernet at a competitive cost, while running at a lower power footprint than previous switching solutions.

Author: Dennis Hartmann

Data Center Ethernet

Published December 14, 2009 Data Center , Dennis Hartmann 1 Comment
Tags: ,

Data center environments have two infrastructures currently. Servers in the data center are connected to the local area network (LAN) and storage area network (SAN) infrastructures. Fibre Channel over Ethernet (FCoE) provides a mechanism to transfer both fibre channel and network traffic over the same unified Ethernet fabric.

Servers connect to the LAN infrastructure through at least two Gigabit Ethernet (1Gbps) network interface cards (NIC) teamed together to provide redundancy and higher throughputs. Most high performance computing servers have six to ten Gigabit Ethernet interfaces to provide adequate throughput to the server. The Cisco 6500 series switch has been the most popular LAN switch in data center environments for nearly a decade. 10 Gigabit Ethernet (10GE) is a technology that has been used over the past eight years to provide higher capacity uplinks between switches.

High performance servers utilize SCSI hard drives that have a distance limitation of about 10 meters (32.8 feet). Fibre channel was designed to overcome the distance limitations of SCSI, while utilizing SCSI drives for storage by using SCSI as an upper layer protocol. Fibre channel (FC) host bus adapters (HBA) provide connectivity to the SAN through director class switches sold by EMC and other storage vendors. Fibre Channel HBAs operate at speeds of 1, 2, 4, and 8 Gbps, but 8Gbps FC HBAs are not widely adopted at the time of this writing.

FCoE converges the LAN NIC and SAN HBA functionality into one 10GE NIC card that provides an HBA and 10GE ASIC (application specific integrated circuit). Emulex and QLogic are the pioneers of this technology at the time of this post. The 10GE NICs are available as a single or dual port solution. The 10GE interfaces connect to FCoE interfaces on the Cisco Nexus 5000 switches, which will provide connectivity to both the LAN and the SAN, eliminating the need for FC director switches and HBAs saving real estate, power, and cost in the data center. Servers utilizing the PCI express 1.1 (8x or 16x) standard will support wire rate 10GE speeds.

Converging storage and network traffic onto the same infrastructure provides a unified I/O (input/output) fabric. The Nexus 5000 series switch provides 20 (5010) or 40 (5020) 10GE interfaces for data center network connectivity with the option of one (5010) or two (5020) expansion slots that allow the following connectivity options allowing enterprises to migrate to FCoE:

  • 8 port FC card (1/2/4 Gbps supported)
  • 4 port FC card / 4 port 10GE FCoE
  • 6 port 10GE FCoE

Author: Dennis Hartmann

References

Cisco UC Lab Environment

Published December 8, 2009 Dennis Hartmann , Unified Communications Leave a Comment
Tags:

The best first step to learning a new technology is to take a class on the particular subject. Global Knowledge’s new  ACUCW1 and ACUCW2 classes (previously CMBA, ACCMU, or ACUCM+) are a good place to start on your understanding of Cisco Unified Communications Manager (CUCM).

However, if you don’t have any previous exposure to the product you’re taking a class on, the experience is sometimes analogous to taking a drink from a fire hydrant; there’s a lot of information coming at you. So, I recommend that new Cisco UC students set up a work (or home) lab environment to practice the labs on their own.

VMWare server or workstation is the most cost effective way to run CUCM in a lab environment (it can be downloaded for free online). Cisco Unity is the only Cisco UC product that is officially supported in VMWare at the time of this writing, but other Cisco UC products work fine in a lab environment.

I recommend a minimum of an Intel Duo Core processor on your laptop and a lot of DRAM. Each virtual machine normally requires at least 1 gigabyte of DRAM to run at an acceptable level. A laptop or desktop with 3GB or more of DRAM will allow you to run both Unity and CUCM on one machine.

You will need to create a virtual machine of CUCM from the CUCM installation disks if you do not have access to an existing virtual machine. I suggest asking your Cisco systems engineer (SE) or account manager (AM) for a working virtual machine image so you do not have to go through the challenges of finding the CUCM installation disks. Buying the Cisco NFR (not for resale) UC kit is another option that will provide you with demo copies of all Cisco UC products with demo licenses.

I recommend performing the lab guide 2 to 3 times after class to raise your proficiency level with the CUCM product. Most of the labs from the ACUCW1/ACUCW2 classes can be performed with two CIPC phones, two CUCM publisher servers (clusters) and at least 3 phones (CIPC or 7900 series phones).

Two phones would register with CUCM server1 and one phone would register with CUCM server2. The phone registered with CUCM server 2 would be configured with a dial plan that maps to the Global Knowledge outside phone. Server 1 and server 2 will need Non-Gatekeeper Controlled Inter-Cluster Trunks or SIP Trunks pointing to each other.

Cisco IP Communicator (CIPC) is a software-based phone that can be used on two laptop or desktop computers that will allow you to get your testing started very cheaply. Only one Unity or Unity Connection virtual machine is required to do the voicemail portion of the labs.

Author: Dennis Hartmann

Cisco Unity Tools Depot

Published December 4, 2009 Dennis Hartmann , Unified Communications Leave a Comment
Tags:

There are various graphical user interface (GUI) applications that can be used in Cisco Unity that will assist in the administration, management, troubleshooting, reporting, and integration of Cisco Unity.  These tools are accessible via the Cisco Unity Tools Depot in Cisco Unity.

When you launch Cisco Unity Tool Depot from the Unity program group on the Cisco Unity server, the Tools depot defaults to Tool News.  If the Cisco Unity server has Internet access, the depot cross references the various tools against a database at www.ciscounitytools.com.  A revision history is displayed and updated versions of the tools can be downloaded.  Jeff Lindborg maintains the Cisco Unity Tools website where you can sign up to an E-Mail distribution list where you are notified of updated tool availability automatically via E-Mail.

The Unity Tools Depot is a tabbed page.  On the left hand side of the page, you will see the various tool categories.  This information is displayed in the screen capture below:

In the screen capture below, I accessed the Administration Tools folder and single clicked the Advanced Settings Tool.  A tutorial will be displayed on the right hand side of the page that will explain the functions of the tool.  At the bottom of the page (on the right hand side) there is normally a revision history of the tool.  Additional information and videos regarding the tool usage are available at www.ciscounitytools.com (click the search icon and perform a search on the tool name). The tool can be launched by double clicking the icon on the left hand side of the page.

There are a lot of great utilities in the Cisco Unity Tools Depot. My personal favorite tool is the Port Status Monitor.  You can learn a lot regarding Cisco Unity’s operation by running this tool and analyzing the output when calls are placed into the Unity system.

Have fun playing with the tools.

 

Author: Dennis Hartmann

Cisco IP Phone Audio Codecs

Published November 23, 2009 Dennis Hartmann , Unified Communications Leave a Comment

Cisco IP phones support a variety of different audio codecs. In this post, I will explain some of the differences and explain which versions of CUCM and the Cisco IP phones support the various audio codecs.

Audio codecs are responsible for sampling human speech (a sine waveform) and representing human speech on a communications network (IP in our case). The digital signal processor (DSP) on the Cisco IP phone is responsible for sampling voice and the ASIC (application specific integrated circuit) is responsible for packetizing the audio sample with an IP/UDP/RTP header.

All 7900 series Cisco IP phones support the G.711 and G.729 audio codec. G.711 is a 64kbps audio codec that has been used on the public switched telephone network (PSTN) for many decades. G.711 is considered a toll quality audio codec. G.711 utilizes 80kbps of bandwidth on the network due to the 16kbps of overhead incurred when sampling voice every 20 milliseconds (ms). G.711 has a mean opion score (MOS) rating of 4.0.

The G.729 audio codec is a compressed audio codec, normally utilized on wide area network (WAN) links where bandwidth is limited. G.729 calls are sampled at 8kbps. The packetization overhead of 16kbps brings G.729 call bandwidth consumption to 24kbps without factoring layer 2 link overhead. G.729 voice has a MOS rating of 3.8, bringing the user experience very close to that of G.711 voice. G.729 quality degrades fast in unfavorable network conditions (packet loss). Packet loss must be kept under 1% to maintain high quality G.729 phone calls.

Cisco introduced the G.722 and iLBC audio codecs in Cisco Unified Communications Manager (CUCM) 6.0. G.722 and iLBC will work on any Cisco Type B phone (7906, 7970, 79×1, 79×2, 79×5), but will not work on the older Cisco Type A phones (7905, 7910, 7912, 7940, 7960). G.722 is a high definition audio codec that provides much higher audio fidelity than G.711. G.711 has a frequency response range of 8khz, while G.722 has a range of 16khz. A wideband audio handset is required to fully experience the quality of G.722. The wideband audio handset ships with all 79×2 and 79×5 phone models, but can be ordered for the 7970 or 79×1 model phones. G.722 uses compression and has a bandwidth impact of 64kbps before packetization (same as G.711).

iLBC (Internet Low Bandwidth Codec) is an Internet Engineering Task Force (IETF) open standard that has been used by Skype. iLBC is a compressed audio codec that utilizes 16kbps of bandwidth (32kbps after packetization). iLBC uses 8kbps more bandwidth than the G.729 compressed audio codec, but the quality of iLBC does not degrade as fast as G.729 when packet loss occurs.

Author: Dennis Hartmann


Editor’s Note: For more on this topic, consider taking the CVOICE: Cisco Voice over IP training class.

Resource Reservation Protocol (RSVP)

Published November 19, 2009 Dennis Hartmann , Unified Communications Leave a Comment
Tags:

Resource Reservation Protocol (RSVP) is a quality of service (QoS) mechanism that was first introduced in the Internet Engineering Task Force (IETF) RFC 1633 (1994). RSVP was introduced as an integrated services model for implementing end-to-end QoS in the data network. RSVP provides an end-to-end guaranteed quality of service and relies on signaling mechanisms transmitted from source to destination. RSVP is a topology aware QoS mechanism, while the differentiated services model only makes a per hop guarantee, referred to as a per hop behavior (PHB). RSVP’s greatest disadvantage is the signaling messages that must be process level switched by every router in the end to end path.

Many enhancements (RSVP passthrough, RSVP refresh reductions) have been made to the RSVP protocol in an effort to make the protocol more scalable, but the application in real world networks is still too processor intensive to be considered in any considerable size deployment. Service providers will not perform QoS guarantees using customer-initiated RSVP path messages due to the millions of microflows (IP sessions) that can possibly traverse service provider cores at the same time. Some service provider networks use RSVP-initiated MPLS Traffic Engineering tunnels in MPLS networks for the application of customer macro-flow tunnels. Service providers do not react to customer initiated RSVP signaling messages. Customer RSVP signaling is passed through the service provider cloud, while the service provider performs QoS based on the differentiated services code point (DSCP) marking.

RSVP initiated phone calls can be synchronized from Cisco Unified Communications Manager (CUCM) as of CUCM 5.0. RSVP must be enabled on every router from source to destination unless the passthrough model is being utilized. The passthrough model does not guarantee QoS because passthrough devices may not implement any QoS. RSVP implementation in CUCM requires IOS 12.4(6T) or later and CUCM 5.0 or later. The configuration of RSVP requires a Media Termination Point (MTP) configuration on the router which will act as an RSVP agent to CUCM.

I will not get into the details of implementing RSVP on CUCM since I do everything in my power to avoid the use of the RSVP protocol. I do not recommend the use of RSVP in CUCM even though it is the only topology aware call admission control (CAC) mechanism. The burden on the route processor is far too great and the RSVP mechanism is quite complex to properly provision in CUCM and the routers. Consider the deployment of an H.323 gatekeeper to provide CAC functionality in a production network.

Author: Dennis Hartmann

Cisco Nexus 7000 and Virtual Device Contexts

Published October 30, 2009 Data Center , Dennis Hartmann Leave a Comment
Tags: ,

The Cisco Nexus 7000 data center switch provides layer 3 capabilities in the Nexus data center product lineup using the Cisco NX-OS operating system. The Nexus data center switch is the first Cisco switch to provide virtual device context (VDC) capabilities that allow the data center switch to be logically segmented into up to four different switches (device contexts).

When the Nexus 7000 switch is first booted, all interfaces of all line cards in the modular switch platform are placed in the default VDC (VDC 1). Up to four VDCs can be created, including the default VDC, but an interface can only belong to one VDC. Interfaces from different line cards can be placed in different VDCs. Once an interface is placed into a VDC, the interface can no longer be managed in the default VDC context.

Each VDC is configured by name, but a VDC identifier is assigned automatically in the order in which the VDCs were configured. The following configuration will create a VDC called Highpoint and assign all 32 ports of line card 18 in the Nexus 7018 10GE line card:

  • N7000#config t
  • N7000(config)#vdc Highpoint
  • N7000(config-vdc)#allocate interface Ethernet 18/1 – 32

Ethernet ports 18/1 – 32 have been assigned to the Highpoint VDC and will not show up if the show interface brief command while in the default VDC context.  The show vdc command will display all VDC names, VDC IDs, and mgmt 0 interface MAC address. The Mgmt 0 interface is an Ethernet-based interface on the supervisor module of the platform. The show vdc membership command will display all VDCs and the interfaces to which they are applied.

To switch the configuration mode from the default VDC to the Highpoint VDC context, use the following commands:

  • N7000(config-vdc)#end
  • N7000#switchto vdc Highpoint

It is recommended to change the hostname of each VDC to change the configuration prompt to indicate which VDC you are configuring. NX-OS uses the switchname command instead of the standard Cisco IOS hostname command. To switch back to the default VDC context, use the switchback or exit commands. Each VDC is managed as if it were a separate switch.

Guest Author: Dennis Hartmann

Editor’s Note: You can read more from Dennis on the Global Knowledge Unified Communications blog.

New Second Gen Routers from Cisco

Published October 22, 2009 Dennis Hartmann , Routing & Switching Leave a Comment

Cisco has announced new ISR G2 (integrated services router – second generation) routers, saying they deliver:

a new borderless workspace experience through service virtualization, video-ready capabilities, and operational excellence.

Occasional guest author Dennis Hartmann reviews the new router models and reports that they have form factors akin to the 1800, 2800, and 3800 series routers they are meant to replace and introduce support for new hardware components. Read the rest of Dennis’ review here.

Cisco UC Conferencing

Published September 30, 2009 Dennis Hartmann , Unified Communications Leave a Comment
Tags: ,

This blog will discuss some of the conferencing capabilities in Cisco Unified Communications. Cisco Unified Communications Manager (CUCM) supports software and hardware conferencing capabilities, but the capabilities are limited when compared to dedicated conferencing solutions.

CUCM is a server-based platform that supports ad-hoc and “meet me” software conferencing features out of the box. Software conferencing is limited to the G.711 audio codec and 48 conference participants by default. CUCM limits the number of conferencing participants to ensure that the audio conferencing mixing capabilities of the IP Voice Media Streaming Application (IPVMA) service does not affect the call processing capabilities of CUCM.

A stand-alone 7845 server dedicated to conferencing capabilities can be tuned to accommodate up to 256 conference participants. The IPVMA call count service parameter would need to be tuned to increase the number of conference participants supported. It is advisable to set the Run Flag of the other IPVMA media resource to “False” if CUCM will be performing a large number of conference terminations.

Mixed mode conferences between different audio codecs (e.g. G.711 and G.729) are normally a requirement in centralized call processing deployment architectures, where branch locations do not have any local call processing resources. Mixed mode audio conferences are supported in hardware (DSPs registered for conferencing) or in the Meeting Place dedicated conferencing platforms (Meeting Place, Meeting Place Express, Meeting Place Express – Video Telephony).  G.729 to G.711 transcoders are not supported in conjunction with the software conferencing in CUCM.

CUCM conferencing does not support queuing, reservations, or security. If these features are a conferencing requirement, then Meeting Place rich media conferencing solutions should be considered.  Cisco IP phones have a conference list softkey that will display the participants of the conference call by caller ID. The conference controller can then select a conference participant and remove them from the conference with the remove softkey.

Many other conferencing options are covered in the Implementing Cisco Unified Communications IP Telephony, Part 1 (CIPT1 v6.x/7.x) class.

Author: Dennis Hartmann

Cisco Pulls the Plug on HP

Published September 23, 2009 Dennis Hartmann Leave a Comment
Tags:

Cisco Unified Communications (UC) platforms run on server hardware provided by Hewlett Packard (HP) or IBM. The following UC platforms are supported on various IBM and HP platforms:

  • Cisco Unified Communications Manager (CUCM)
  • Cisco Unified Communications Manager Business Edition (CUCMBE)
  • Cisco Unified Unity
  • Cisco Unity Connection (CUC)
  • Cisco Emergency Responder (CER)
  • Cisco Unified Presence Server (CUPS)
  • Meeting Place Express (MPE)
  • Meeting Place Express – Video Telephony (MPE-VT)
  • Cisco Unified Contact Center Express (UCCX)
  • Cisco Unified Mobility Advantage (CUMA)
  • Cisco Unified Contact Center Enterprise

HP has recently announced a line of data networking switches that competes with Cisco’s switching business. Cisco and HP have been competing fiercely in the data center line of business, and it seems like the partnership between HP and Cisco is eroding. Cisco is encroaching on HP’s server market with the introduction of Cisco Unified Computing and the Nexus line of switches with the fiber channel over Ethernet (FCoE) support.

One week prior to the writing of this blog, the Cisco account team told us that Cisco will no longer be selling HP-branded servers for Cisco UC platforms. In the future, Cisco will also not be supporting new UC integrations on HP servers purchased by customers. Cisco will be looking to replace IBM servers with their own branded servers in the future.

Links

Author: Dennis Hartmann

Next Page »

Subscribe in a Reader

Subscribe by Email

Follow us on Twitter

Featured Courses

Archives

Cisco Live 2010