Home > Cisco > Cisco Unity Express and Loopback0

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:

  1. Configure a DHCP Pool for all IP Phones.
  2. Copy tftp files for the SPA508G phones to flash.
  3. Configured UC560 to serve up the files so that the phones are able to download their configuration.
  4. Basic ephone-dn and ephone configurations to test phones.
  5. Create and assign IP to loopback interface.
  6. Configure Service-Engine interface to use loopback interface
  7. Configure IP address and default-gateway of CUE
  8. Test connectivity to CUE by pinging interface and also establishing connection.
  9. Configure user accounts in CUE and assign Voicemail mailboxes to users.
  10. 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. 🙂

Advertisements
  1. @welles
    September 3, 2011 at 8:55 PM

    I remember having a similar issue a couple years go on a UC540. I moved CUE off the loopback and put it on the a VLAN. I was *told* the reason for it being on a loopback was in case an interface or VLAN went down, it would not take CUE down. I figured, well if a VLAN does go down, bigger issues might be around. So I just put CUE on a VLAN and set that VLAN to never go down(and I can’t remember the exact command I used for that).

    And, at that time, if it wasn’t done via CCA, Cisco TAC(not really TAC—that might have changed now???) would not assist unless it was via CCA, or exact to the guidelines they had. 🙂

  2. September 3, 2011 at 9:04 PM

    I’ve also heard that TAC wouldn’t support you unless you configured it using CCA. Really don’t know the reasoning behind that, as the UC500 series is basically CME and CUE pre-installed on a box. Where as if you have a 2800 ISR, you’d have to purchase the correct software and install it.

  3. April 25, 2012 at 2:03 AM

    Probably way too late to be of any help here, but a static route to the SE would have done the trick.

    ip route 192.168.1.2 255.255.255.255 Integrated-Service-Engine1/0

  4. Paul S
    July 31, 2012 at 6:21 PM

    Yes. Reload the router will do the trick, assuming you have configured the static route as jason mentioned. If you use ospf, add this “ip ospf network point-to-point” under the loopback interface to allow ospf routing to other routers in the network.

  5. December 11, 2013 at 9:17 PM

    Thanks for ones marѵelous posting! I actually enjoyed
    reading it, you can be a great author.I will be sure to bookmark your
    blog and may come back in the foreѕeeable future. I
    want to encourage you to ultimately continue your great posts, have a
    nice day!

  6. David Martinez
    April 10, 2015 at 8:32 PM

    I know I am incredibly late but it may help someone else who comes across this. If that was indeed your entire config for the CUE then you needed the route pointing to the service engine. Of course my first assumption was that you never opened the service engine interface since you never mentioned issuing a show ip interface brief to see if the interface was online. I personally always tend to forget to issue the no shut at the service engine interface.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: