Cisco UC 560 and SFE2010P Shenanigans

Last week we set out to finalise the install of a new CISCO UC 560 and cut over one of our customers ISDN trunks from one carrier to another.

We had configured the UC prior to our site visit in our office, and tested internal calls, hunt groups etc and all was well, however once we were out on-site things that afternoon could have played out a little smoother.

We setup the kit and plugged the UC into the switch, connected one of the handsets, cabled in the on-site server and we noticed that the phone would not register, which we thought was a bit strange. Further investigation revealed that the phone was getting a DHCP address on the data vlan and not able to communicate with the UC.

Now is the part where I should mention that a few weeks back we had a switch fail at another site and the only replacement we had on hand was the Cisco 48port PoE SFE2010P which had been already configured for this particular job. No problems, we did a backup of the configuration (to keep for this job) and then reconfigured the switch for use in the other network. Once the replacement switch arrived we simply restored the configuration from the old switch and off we went…or so we thought.

It turns out that when I restored the backup configuration I logged in and I verified that the restore was successful by checking the system page, which lists the customer name, phone number, location etc, all things that we updated when we first configured the switch and would not be there on a switch directly from the factory. What seems a bit odd was the fact that all the port settings (trunk/access, vlan information etc) were not retained. Hence the issue we now had on-site where the switch had none of the prior port and vlan configuration.

Setting all the ports on the switch as trunks and tagging vlan 90 and 100 on all ports, got the switch back up and running with about 5 mins to spare before we were due to test the successful number port (incoming calls routing properly and the ability to answer them). This was excellent timing as we had already had the cutover date pushed back twice due to external circumstances and this was the last date available this year.

One last odd thing or perhaps bug is related to configuring the UC 560 with CCA. During troubleshooting, the smartport role CCA suggested for the expansion port on the device was set to ip phone+desktop (which was incorrect as we were trying to trunk the UC with the switch), to change this back to switch we had to actually physically unplug the cable from the UC and connect our laptop directly to the UC as CCA would constantly error and not allow us to change the port role while it was connected.

Once the trunks were setup correctly on both devices, the phones registered correctly, we were off and racing, it just seems perplexing that you need to know to remove the cable from the port before you can successfully change the port role. For this reason I thought I would post a small write up about today’s efforts so if I come across this issue again, I wont forget! 🙂

Leave a Reply