Cisco Unity Express and Loopback0
I’m currently working on a VOIP project consisting of a pair of UC560s and some SPA508G Phones. Configuration for the project is pretty straight forward as no fancy or complex translation rules need to be created. The client is basically replacing their current antique Nortel system with a modern Cisco solution.
The steps required for me to get the system up to a basic state to perform tests were as follows:
- Configure a DHCP Pool for all IP Phones.
- Copy tftp files for the SPA508G phones to flash.
- Configured UC560 to serve up the files so that the phones are able to download their configuration.
- Basic ephone-dn and ephone configurations to test phones.
- Create and assign IP to loopback interface.
- Configure Service-Engine interface to use loopback interface
- Configure IP address and default-gateway of CUE
- Test connectivity to CUE by pinging interface and also establishing connection.
- Configure user accounts in CUE and assign Voicemail mailboxes to users.
- Perform Tests.
As you can see from the list, this truly is a simple deploy.
All configurations were proceeding just fine until I arrived at step 8. At this stage I should be able to both establish a connection to CUE and also receive replies from pings. However this wasn’t so. For some reason all my ping tests were failing. I checked, rechecked, checked again, then checked again to make sure my configs were correct.
Here’s an example of what the configuration would look like.
!Loopback interface created to use with our Service Engine interface. (Cisco's recommended way of configuring it) interface Loopback0 ip address 192.168.1.1 255.255.255.0 !Service Engine interface used to communicate with the Cisco Unity Express. interface Integrated-Service-Engine0/0 description Loopback interface used to manage integrated application module ip unnumbered Loopback0 service-module ip address 192.168.1.2 255.255.255.0 service-module ip default-gateway 192.168.1.1
Did I miss anything? From the configuration we see that the IP Address of the CUE is 192.168.1.2 and the IP address used to communicate with the CUE is 192.168.1.1 which is the IP of the Loopback interface.
For reasons unknowing to me, this configuration was not working. I was able to successfully establish a session to the CUE, logged in using the same credentials used to login to the UC560 and I was able to proceed with further configurations tasks. I was able to create user accounts, assign them mailboxes, assign Voicemail number so that the application is activated whenever that number is dialed etc. Unfortunately ping tests were still failing and as such when I made a test call to Voicemail, it did not work. There is one step I forgot to include in the list above, and that was to create a dial-peer so that whenever users dialed the Voicemail number it would use that particular dial-peer to transfer the call to the correct destination thereby activating the Voicemail system. This was also completed and the configuration for this can be seen below.
dial-peer voice 2 voip destination-pattern 600 session protocol sipv2 session target ipv4:192.168.1.2 dtmf-relay sip-notify codec g711ulaw no vad
I spent hours researching Cisco’s documentation and reading through different forums. Eventually I saw a user on IPexpert’s OSL was having the same issue. He was able to access and ping CUE whenever he used a physical interface or a SVI as opposed to using a Loopback interface. I decided to test this out for myself by using an SVI, Vlan1 and changed the configuration on the Service Engine to use Vlan1 instead of Loopback0. Of course this worked flawlessly! I was able to ping the CUE IP which enabled me to proceed with my further configuration and testing.
I found the whole thing really interesting, as no where on Cisco’s site mentioned there being instances where the Loopback interface wouldn’t work. Have any of you VOICE folks out there experienced this problem before? Did I miss something with my configs? And please don’t tell me that I needed to reboot/reload/reset CUE as I did this so many times till at one point I had to do a complete factory reset to get basic communication again. 🙂