atcomsystems.ca/forum Forums VOIP Phones & IP PBX Cisco Telephones and Systems The install finally begins - UC560

So today was the big day. After 9 months of research, quotes, more quotes, meetings, then purchasing, fighting over pricing changes, re-cabling the locations etc. It has begun.

I will try and keep a log of the install and how things are going, I will also try and post items that bite me in the ass and just plain silly items that come up.

Here is a quick over view of our install:

Cisco UC560 connected to a PRI
Cisco SF300 48 port POE switch
Cisco 2960S 24 port POE switch
Cisco ASA 5510 firewall
72 IP phones - 1 7945G, 1 509G, 70 504g
4 ATA adapters
11 locations
Cisco 891W at each remote location
Cisco SF302 8 port switch for 2 locations.

As you can see we are a Cisco shop.

We started today with the UC itself and the main switch. UC and switch mounted in the rack.

First step was to update all the IOS's. Why on earth they do not ship new equipment with current IOS installed I do not know. That process ate up an hour while the UC did its upgrade, good time for lunch.

Once the upgrade was complete we started the UC initial config wizard.

We created the user spreadsheet, scanned all the phone MAC's and mapped them to users. Then created the xml file to import into the UC.

- Issue - you must add your licenses before you can add the users, this is sort of ass backward as the wizard allows you to add licenses later in the wizard!!??

Once that was completed we successfully imported the users.

- Issue - you cannot use "-" in users names, this causes issues with any users that have "-" in their lastnames. You can use and "_" but that is not acceptable to users, so we just eliminated the "-" and the space. Users also cannot have a space in their first name, so any worker with names such as Betty Sue, must be listed as bettysue, or some other workaround.

After we sorted those issues out, we came to the Blast/Hunt group page. The first thing that popped up is the fact that you are limited to 10 blast groups, which is not listed anywhere in the paperwork. Since we have the need of 12 total blast groups, I have an issue to sort out.

As we were configuring the blast groups we got to group #10 and the wizard promptly crashed. Which caused the loss of another 30-40 minutes as we had to recreate all the groups and assign users.

Once we stepped through that we completed the wizard with some basic settings for the AA stuff.

As a last item for the day we plugged in the switch, plugged in a phone to see if it would talk to the UC.

The phone updated itself, picked up the correct extension and allowed a network connection to pass through the phone to the world.

All in all a good day, couple glitches but nothing to major.

Tomorrow starts the heavy lifting with the updating/registering of all the phones and some testing at remote locations.

I will try and post up again tomorrow with any items/issues/successes.

On that SF300 switch...make sure you load the 1.1.2.0 firmware image on it. Older versions (1.1.1.8 and below) have a MAC table bug. Entries no longer expire and new entries don't come in, and the stuck entries are ignored. This causes port flooding; the switch would behave like a hub, sending multicast traffic to all ports with all traffic. When I called Cisco support they told me that it appears after 49.8 days of uptime. Reboot and it behaves for 49 more days. Cisco initially sent me beta firmware with the fix, but they have since fixed this in 1.1.2.0. Good luck on your install, let us all know how it goes!

Thanks, that was the first thing we did when we pulled the switch out. Currently sitting at 1.1.2

Biggest issue we are having today is the UC email integration. Cannot get it to pass voicemail to email.

I can ping the 10.1.10.1 and 10.1.10.2 addresses from the mail server but cannot ping the mail server from the 10.1.10.2 interface. Will update if I find a solution.

Okay big problem.

Inside phones - the ones connected at the main admin office, work like a charm. Plug them in and off they go.

Remote sites - nothing. No connect nothing.

Now the fun begins in trying to track things down.

My setup -

Main admin site -
192.168.0.0/24 - data
10.1.100.0/24 - voice

Remote sites - they start at 192.168.5.0/24 and go up in 5 increments. 192.168.10.0/24 etc.

Phones pick up an IP from the local routers giving them the IP from the 192.168.5.0 etc ranges. They will not attempt to grab an IP from the 10.1.100.0 subnet.

I have tried adding the ip helper-address of 10.1.100.1 but still nothing.

I have added static routes on the remote sites pointing them to the UC data connection.

I tried turning off the firewall at the remote sites to see if that was the issue, still no go.

I am taking a break from it now as I see if I can sort out why things are not doing what they are supposed to.

Ok, so you've separated your voice and data network which is a very good practice. How are you getting the VLAN tags to your remote sites? GRE tunnel? Site-to-site VPN? Sounds like the voice VLAN tags are being stripped out by the remote edge routers.

Each site has a site to site VPN using the 871/891 to the ASA.

And yeah I think its partly a VLAN issue.

But its also not pushing the 10.1.100.0 traffic through the VPN tunnel. Right now the only traffic passing through the tunnel is the 192.168.0.0/24

If I set up static route on the remote sites of:

ip route 10.1.100.0/24 192.168.0.15 (UC Data IP)

then run a tracert to 10.1.100.1 its not passing through the tunnel to 192.168.0.15, its going out the WAN port and being dropped on the outside.

If I run tracert to 192.168.0.15 its two hops:
192.168.10.1
192.168.0.15

Once I get it sorted out on one site, the rest should be easy, its always the first one!

As mentioned many times at this site (any system is only as good as the installing company). Why are you installing this and not the company you purshed it from?

Major routing issues methinks.

Do the ASA and 891Ws have Smartnet coverage?

If so, just submit a TAC request and let them walk you through the configuration.

If this isn't an option, I have done a setup similar to what you are doing with ASAs on both ends and could probably get you some config examples. In my case, I setup two networks at the remote site, each with it's own subnet and VLAN. Then we routed both of them through the VPN tunnel to the main office, where they each connected to a corresponding network.

So using your addressing scheme, the first office would have:

192.168.5.0/24 routed to 192.168.0.0/24
10.1.105.0/24 routed to 10.1.100.0/24

You also need to decide if you want a split tunnel on the data network so computers at remote sites can access the net without going through the main office.

Then on the 891W, create VLANs for each network. Set the switchports to send voice traffic to the voice VLAN (The phones will automatically configure to the voice VLAN using CDP). Create DHCP for the voice network (Optional if there is only 1 or 2 phones, but I'd do it to be consistent across all sites).

Big caveat - I have done the above with an ASA5505 at the remote site. I don't know if an 891W can do all this. Again, TAC would be my first call tomorrow if I were in your shoes.

Good luck and thanks for sharing your experience!

Wouldn't the remote routes point to the edge ASA in front of the UC and not the UC itself? I haven't set up an ASA yet (only PIX), but those routes might not be correct. 192.168.0.15 is the destination, but not necessarily the next hop or gateway to get there. The ASA might be looking for an address it knows, such as the address of another ASA in the site to site configuration. Some VPNs also use virtual gateways within the VPN address pool, such as 172.16.0.1.