Unity Connection-CUCME Lab 2 – CUCME Setup

Lab 2 will focus on setting up CUCME for Unity Connection. Since CUCME was covered in depth in the CUCME-CUE Labs, and the focus of these labs is Unity Connection, I will keep the CUCME side basic. Advanced CUCME calling feature will be kept to a minimum.

Unity Connection-CUCME System Setup Prerequisites

Prior to configuring the CUCME phone tasks, the router requires the specific CUCME files to be installed on the router flash. These labs will be based on CME 7.1 and IOS 12.4(22)YB1.

If this task hasn’t been previously completed, now is the time to so. There are a couple of ways to accomplish this prerequisite. The processes and procedures for installing the CUCME files on the router flash are described in the Installing and Upgrading Cisco Unified CME Software chapter of the Cisco Unified Communications Manager Express System Administrator Guide. A further discussion is covered in CUCME-CUE Lab 2 – Baltimore Basic CUCME System Setup and CUCME-CUE Lab 3 – New York Basic CUCME System Setup.

Lab 2.1 – Unity Connection-CUCME Setup Tasks

1. Configure CUCME on the Baltimore, Los Angeles, and New York routers based on the information provided in Unity Connection-CUCME Scenario Background. You may not use the CUCME setup utility or any sort of auto registration process.

2. Baltimore phones should be SCCP; Los Angeles and New York phones should be SIP Phones.

3. Each phone and should also be able to customize their ringtones beyond the default chirp ringtone.

4. Each user’s phone should also display his/her name and full E.164 number.

5. Each CUCME router should be configure to support the appropriate localization, time-zone, a 12 hour time format, and a Month-Day-Year format.

6. Enable the wideband codec by default for all phones.

7. Create an appropriate E.164 dial-pattern.

8. Configure VOIP between all three locations. Ensure that the default VOIP codec is the wideband codec.

9. Transfer between all locations should be supported.

10. Configure the PRI at each location to support only 4 channels (to conserve DSP resources).

11. In the event of a WAN failure, calls should use the PSTN, but without users having to dial more than four digits. Use only a single dial-peer with a single translation rule to accomplish this task. You may not use a prefix.

12. Enable transcoding to support G.711, G.722, and G.729.

13. Enable Conferencing and Transcoding resources for all three locations.

14. Provide an audible alert when someone joins or leaves a conference. The alerts should be different for joining and leaving.

15. Baltimore should support eight attendees at the conference bridge. Baltimore should support both Ad-hoc and Meet-Me conferencing.

16. Enable Music on Hold for both internal and external callers.

17. Create the appropriate GUI Administrator parameters.

Unity Connection-CUCME Lab 1 – Initial Configuration

Unity Connection-CUCME Lab 1 Prerequisites

Prior to beginning the basic IP Setup for this series of Unity Connection-CUCME Labs, configure the Adtran Atlas 550 to support the simulated PSTN dial plan depicted in diagram in Unity Connection / CUCME Labs – Background. Please refer to VOIP Fundamentals Lab 1 - PSTN Setup on how to configure the Adtran for the dial plan depicted in CUCME-CUE Scenario Background.

The Unity Connection-CUCME labs also assume that you have the appropriate IOS files, CUCME files, and CUE files. These labs also assume that you have valid CCO access and licenses for any files that you may be downloading and installing on your lab equipment.

These labs will be based on CME 7.1 and IOS 12.4(22)YB1. If you need to upgrade the IOS refer to the Cisco Unified CME and Cisco IOS Software Version Compatibility Matrix. For now, my recommendation is not to install the CME files. I will cover that in a subsequent lab.


Lab 1.1 Unity Connection-CUCME– Initial IP Network Setup Tasks

1. Configure the IP addressing based on the diagram in Scenario Background.
2. Configure R7 to serve as the frame relay switch for WAN. Set the clocking to 512000.
3. Make sure you have an “external” NTP clocking source for your LAB. (Note, depending on your own lab, this may vary. I will discuss my configuration below.)
4. Configure the Frame Relay connections as a point-to-point interfaces.
5. Provide a loopback interface on each router.
6. Configure your LAN networks as depicted the Scenario Background posting.
7. On the Baltimore Router, the connection between the router and Ethernet Switch Module must be over a Layer 2 trunk.
8. Configure IP Services on each router to support IP Phones. Reserve the first 16 IP addresses accordingly.
9. Configure the LAN ports so that Phones receive their appropriate IP information and any PCs on those LAN ports receive their appropriate IP information.
10. Configure OSPF routing for the network. The WAN/Frame Cloud should use Area 0; Baltimore Area 1; New York Area 2; Los Angeles as Area 3.
11. The loopbacks should be placed into each area accordingly; these routes should be depicted in the route tables as /24 networks.
12. Configure the 10.1.1.0 network on each router as internet path. The subnet should not be routed via OSPF.
13. Verify that IP Phones at each location receive IP Addresses.
14. Test connectivity. Ping the DNS server from each subnet and each device. Ping phones from multiple locations to multiple locations. Etc.


Lab 1.2 Unity Connection-CUCME Verification

Although not exactly identical to the CUCME-CUE Lab 1 Setup, much of the configuration set up is very similar. Therefore, for the sake of brevity I will provide the configs below and highlight some differences.

1. Below is a snippet of router config on R7, which shows the configuration of the router as a Frame Relay switch. The router also synchronizes with an Internet NTP server.

ISP Router:
!
hostname ISP
!
ip host r1 2066 10.1.1.4
ip host r2 2067 10.1.1.4
ip host r3 2068 10.1.1.4
ip host r4 2069 10.1.1.4
ip host r5 2070 10.1.1.4
ip host r6 2071 10.1.1.4
ip host s1 2072 10.1.1.4
!
frame-relay switching
!
!
interface FastEthernet0/0
ip address 10.1.1.4 255.255.255.0
duplex auto
speed auto
ntp broadcast
!
!
interface Serial0/0/0
description frame-relay link to Baltimore
no ip address
encapsulation frame-relay
no fair-queue
clock rate 512000
frame-relay lmi-type cisco
frame-relay intf-type dce
frame-relay route 102 interface Serial0/0/1 201
!
interface Serial0/0/1
description frame-relay to New York
no ip address
encapsulation frame-relay
clock rate 512000
frame-relay lmi-type cisco
frame-relay intf-type dce
frame-relay route 201 interface Serial0/0/0 102
frame-relay route 203 interface Serial0/1/0 302
!
interface Serial0/1/0
description frame-relay link to Los Angeles
no ip address
encapsulation frame-relay
clock rate 512000
frame-relay lmi-type cisco
frame-relay intf-type dce
frame-relay route 302 interface Serial0/0/1 203
!
line 1/0 1/15
no exec
transport input all
!
ntp source FastEthernet0/0
ntp update-calendar
ntp server 198.82.1.201

2. The pertinent configuration parameters for the Baltimore CUCME router setup is below. Note, the Baltimore router has a EtherSwitch Service Module (NME-16ES-1G-P).

Baltimore CUCME Router:

baltimore#sh run
!
ip dhcp excluded-address 10.1.11.1 10.1.11.15
ip dhcp excluded-address 10.1.12.1 10.1.12.15
!
ip dhcp pool VOICE
network 10.1.12.0 255.255.255.0
update dns
default-router 10.1.12.1
option 150 ip 10.1.12.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
ip dhcp pool DATA
network 10.1.11.0 255.255.255.0
update dns
default-router 10.1.11.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
ip ospf network point-to-point
!
interface FastEthernet0/0
ip address 10.1.1.101 255.255.255.0
duplex auto
speed auto
!
!
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/2/0.102 point-to-point
ip address 172.16.1.1 255.255.255.252
ip ospf network point-to-point
snmp trap link-status
frame-relay interface-dlci 102
!
!
interface GigabitEthernet1/0
no ip address
!
interface GigabitEthernet1/0.10
description Baltimore Management
encapsulation dot1Q 10 native
ip address 10.1.10.1 255.255.255.0
!
interface GigabitEthernet1/0.11
description Baltimore Data
encapsulation dot1Q 11
ip address 10.1.11.1 255.255.255.0
!
interface GigabitEthernet1/0.12
description Baltimore Voice
encapsulation dot1Q 12
ip address 10.1.12.1 255.255.255.0
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.0 0.0.0.255 area 1
network 10.1.10.0 0.0.0.255 area 1
network 10.1.11.0 0.0.0.255 area 1
network 10.1.12.0 0.0.0.255 area 1
network 172.16.1.0 0.0.0.3 area 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!
ntp source FastEthernet0/0
ntp update-calendar
ntp server 10.1.1.4
end

3. Configuring the EtherSwitch Service Module (NME-16ES-1G-P) via a Layer 2 trunk was described in CUCME-CUE Lab 1 – Initial Configuration. Below is the configuration.

Baltimore EtherSwitch Service Module:

baltimore-sw#sh run
!
!
vlan 10
name Baltimore-Management
!
vlan 11
name Baltimore-Data
!
vlan 12
name Baltimore-Voice
!
!
!
interface FastEthernet1/0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 11
switchport voice vlan 12
spanning-tree portfast
!
!omitted!
!
!
interface GigabitEthernet1/0/2
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 10-12
switchport mode trunk
spanning-tree portfast trunk
!
interface Vlan10
description Baltimore-Management
ip address 10.1.10.2 255.255.255.0
!
interface Vlan11
description Baltimore Data
ip address 10.1.11.2 255.255.255.0
!
interface Vlan12
description Baltimore Vlan
ip address 10.1.12.2 255.255.255.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.10.1
!
ntp source Vlan10
ntp server 10.1.1.4

4. The configuration for the New York City CUCME router, which is the “hub” site for Ballplayers, LLC, is as follows.

New York CUCME Router:

newyork#sh run
!
p dhcp excluded-address 10.1.21.1 10.1.21.15
ip dhcp excluded-address 10.1.22.1 10.1.22.15
!
ip dhcp pool VOICE
network 10.1.22.0 255.255.255.0
update dns
default-router 10.1.22.1
option 150 ip 10.1.22.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
ip dhcp pool DATA
network 10.1.21.0 255.255.255.0
update dns
default-router 10.1.21.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.0
ip ospf network point-to-point
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 1
ip address 10.1.1.102 255.255.255.0
!
interface FastEthernet0/0.20
encapsulation dot1Q 20 native
ip address 10.1.20.1 255.255.255.0
!
interface FastEthernet0/0.21
encapsulation dot1Q 21
ip address 10.1.21.1 255.255.255.0
!
interface FastEthernet0/0.22
encapsulation dot1Q 22
ip address 10.1.22.1 255.255.255.0
!
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/2/0.201 point-to-point
ip address 172.16.1.2 255.255.255.252
ip ospf network point-to-point
snmp trap link-status
frame-relay interface-dlci 201
!
interface Serial0/2/0.203 point-to-point
ip address 172.16.1.6 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 203
!
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.0 0.0.0.255 area 2
network 10.1.1.0 0.0.0.0 area 0
network 10.1.20.0 0.0.0.255 area 2
network 10.1.21.0 0.0.0.255 area 2
network 10.1.22.0 0.0.0.255 area 2
network 172.16.1.0 0.0.0.255 area 0
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!
ntp source FastEthernet0/0.1
ntp update-calendar
ntp server 10.1.1.4

5. Configuration for Los Angeles shares similarities with both Baltimore and New York. At the moment, I am using the same 3750 switch to service both New York and Los Angeles. The LA router does have a four-port fast Ethernet HWIC. However, I do not have the upgrade power supply to provide POE on these ports. Once I obtain the new power supply, I will modify LA to support it phone locally.

Los Angeles CUCME Router:

losangeles#sh run
ip dhcp excluded-address 10.1.31.1 10.1.31.15
ip dhcp excluded-address 10.1.32.1 10.1.32.15
!
ip dhcp pool VOICE
network 10.1.32.0 255.255.255.0
update dns
default-router 10.1.32.1
option 150 ip 10.1.32.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
ip dhcp pool DATA
network 10.1.31.0 255.255.255.0
update dns
default-router 10.1.31.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
ip ospf network point-to-point
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 1
ip address 10.1.1.103 255.255.255.0
!
interface FastEthernet0/0.30
description LosAngeles Management
encapsulation dot1Q 30 native
ip address 10.1.30.1 255.255.255.0
!
interface FastEthernet0/0.31
description LosAngeles Data
encapsulation dot1Q 31
ip address 10.1.31.1 255.255.255.0
!
interface FastEthernet0/0.32
description LosAngeles Voice
encapsulation dot1Q 32
ip address 10.1.32.1 255.255.255.0
!
!
interface FastEthernet0/3/0
!
interface FastEthernet0/3/1
!
interface FastEthernet0/3/2
!
interface FastEthernet0/3/3
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/2/0.302 point-to-point
ip address 172.16.1.5 255.255.255.252
ip ospf network point-to-point
snmp trap link-status
frame-relay interface-dlci 302
!
!
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.0 0.0.0.255 area 3
network 10.1.30.0 0.0.0.255 area 3
network 10.1.31.0 0.0.0.255 area 3
network 10.1.32.0 0.0.0.255 area 3
network 172.16.1.4 0.0.0.3 area 0
!
ip forward-protocol nd
!
ntp source FastEthernet0/0.1
ntp update-calendar
ntp server 10.1.1.4


6. As discussed above, I am sharing one 3750 switch for the LAN side of both New York and Los Angeles. The switch also provides internet access for my lab. As such, I have to configure the 3750 carefully so that I avoid using it to route traffic and bypassing the “WAN”.

First, I configure the appropriate VLANs and VLAN interfaces to support NY and LA.

!
interface Vlan1
ip address 10.1.1.3 255.255.255.0
!
interface Vlan20
ip address 10.1.20.2 255.255.255.0
!
interface Vlan21
ip address 10.1.21.2 255.255.255.0
!
interface Vlan22
ip address 10.1.22.2 255.255.255.0
!
interface Vlan30
ip address 10.1.30.2 255.255.255.0
!
interface Vlan31
ip address 10.1.31.2 255.255.255.0
!
interface Vlan32
ip address 10.1.32.2 255.255.255.0

Secondly, I configure the interfaces to support each router. Note the differences between the configuration to support Baltimore as compared to NY and LA.

!
interface FastEthernet1/0/1
description R1 FA0/0 (baltimore)
spanning-tree portfast
!
interface FastEthernet1/0/2
description R2 FA0/0 (newyork)
switchport trunk encapsulation dot1q
switchport trunk native vlan 20
switchport trunk allowed vlan 1,20-22
switchport mode trunk
spanning-tree portfast trunk
!
interface FastEthernet1/0/3
description R3 FA0/0 (losangeles)
switchport trunk encapsulation dot1q
switchport trunk native vlan 30
switchport trunk allowed vlan 1,30-32
switchport mode trunk
spanning-tree portfast trunk
!

The next step is to configure static routes that basically tells any IP traffic from hosts connected to the switch to use NY as the next hop. From NY, the traffic will be routed dynamically via OSPF.

ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip route 1.1.1.0 255.255.255.0 10.1.20.1
ip route 2.2.2.0 255.255.255.0 10.1.20.1
ip route 3.3.3.0 255.255.255.0 10.1.20.1
ip route 10.1.0.0 255.255.0.0 10.1.20.1
ip route 172.16.1.0 255.255.255.0 10.1.20.1

The switch ports for NY and LA phones are configured appropriately. Again, compare the differences between a port that supports LA phones versus a port that supports NY phones.

!
interface FastEthernet1/0/9
description LA PHONE PORT
switchport trunk encapsulation dot1q
switchport trunk native vlan 31
switchport voice vlan 32
spanning-tree portfast
!
!
interface FastEthernet1/0/13
description NY PHONE PORT
switchport trunk encapsulation dot1q
switchport trunk native vlan 21
switchport voice vlan 22
spanning-tree portfast
!

7. Finally, ping tests across the Lab setup verify end-to-end connectivity. The first ping test below demonstrates the ability to ping from the Baltimore EtherSwitch module to my Windows 2003 AD/DNS server (10.1.20.10).

baltimore-sw#ping 10.1.20.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.20.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/9 ms

Another test from Los Angeles verifies the ability to ping a phone on Baltimore’s EtherSwitch module.

losangeles#ping 10.1.12.16

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.12.16, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/13/20 ms

And finally, a ping test from New York to a phone associated with LA verifies connectivity. Note the delay, which suggests that the path between the two is via the WAN link. If the delay was between 1ms and 4ms, this would have suggested the path remained within the switch.

newyork#ping 10.1.32.20

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.32.20, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms


Unity Connection-CUCME Lab 1 Wrap Up

Not much in this lab relating to Unity or CUCME for that matter. The next lab will build out our CUCME configuration in anticipation of moving towards Unity Connection integration.

Unity Connection-CUCME Scenario Background

Ballplayers, Inc. is a sports marketing firm with locations in New York City, NY and Baltimore, MD. The firm represents both current and retired athletes and their associated marketing ventures. After successfully pilot Cisco Unified Communications Manager Express and Cisco Unity Express between New York and Baltimore, the firm’s CIO Fuzzy Dunlop has given you the go ahead to expand the pilot. This new phase will add Los Angeles as third CUCME location. Finally, CUE will be replace with a centralized Cisco Unity Connection integrated messaging solution.

Below is a high-level design of the Cisco Unity Connection Pilot.

The table below describes the IP Adressing & PSTN configuration.

The first Lab will walk through the requirements to configure the routing between Baltimore, New York, and Los Angeles.

Unity Connection Labs Coming!

It has been a while since my previous posts. I am in the planning stages of some Unity Connection 7.0 labs. While they are still very much on the drawing board, the basic concept will be to take three CUCME locations and provide a centralized Unity Connection solution.


For some future planning purposes, I am changing some of the dial plan and IP addressing. As a result, while the previous CUCME-CUE labs will be helpful for reference, these labs will deviate a bit from the structure in those previous labs.


I am probably a week or two out before I start posting. I need to finish building my LDAP/AD directory and test out installing Unity Connection in VMWare ESX. Below is a teaser of the topology that I am developing.