Re: UC320, SG200-26P, SA520/SA540 - Will This Setup Work?

telecastle · ‎10-04-2011

Hi,

I have been contracted to setup a small network with a voice system for a small business. I am thinking about using a UC320 for voice and Wi-Fi, SG200-26P as a PoE switch, and SA520 as an Internet firewall and a VPN headend for remote users.

Are these Cisco Small Business products work well together? I have been monitoring the Cisco Small Business line for some time now, and I have witnessed complaints of multiple bugs in these products. However, it appears that Cisco is squashing the bugs and the products are getting better.

The business owner does not have a resource to support complex deployments, and I am not sure he wants to have someone on retainer after the installation is completed. The reason I want to go with UC320 instead of UC500 Series, SG200 instead of SG300 or Catalyst 2960, and SA520 (or SA540) instead of ASA5505 is to reduce the complexity of the entire setup support going forward. On the other hand, I do not want to compromise the functionality and reliability of the network by choosing less complex and less expensive equipment. So, I have a few questions.

1. The UC320 documentation recommends using ESW switches or 300 Series switches; 200 Series switches are not mentioned. Why? Has anyone used SG200 Series with UC320?

2. I'd like to go with SA520 (or SA540) instead of ASA5505. Does the SIP feature of the SA520/SA540 work well with the UC320? Are there any gotchas? The reasons I want to go with SA instead of ASA are Gigabit Ethernet ports in SA instead of 100 Mbps in ASA, and less complicated setup. However, I am apprehensive about the fact that the SA may cripple certain advanced SIP functionality like internal transfers or forwards to external numbers, hairpinned transfers or forwards, etc.

3. The business owner will have several teleworkers. He wants them to have extensions off of his internal PBX. So, does UC320 support remote extensions? Does SA520/SA540 "site-to-site" VPN feature work well? My thinking is to send a Cisco 871 and an IP phone to each teleworker and have a site-to-site tunnel between the SA520/SA540 and each Cisco 871 so that teleworker IP phones could register with UC320 as though they were on the local network. Any thoughts? Has anyone done this?

4. Are there any recommendations for teleworker routers from the Cisco Small Business line that could do a reliable site-to-site tunnel to the SA520/SA540 and that have proper QoS for voice? The reason I am asking is that SA520/SA540 does not have the "easy VPN" feature, and therefore, each Cisco 871 would have to be configured for the "site-to-site" tunnel in CLI, which the business owner will not be able to do. If there is a Cisco Small Business router that can do the job to terminate a site-to-site tunnel to the central office where SA520/SA540 is located, then the business owner may be able to configure those in GUI and send them out to teleworkers in the future.

Thanks!

nalbert · ‎10-04-2011

Telecastle,

Answers

1. SG200 switches work just fine except for SG200-8P(does not support Auto-Smart ports). These switches come with port combinations where some are POE and some are not. So you have to choose wisely.

2. I personally have not seen any issues with SA500 - UC320 interop. They are well tested togather.

3. There is no Support for Teleworkers or remote site in the UC320. It will not work. You need to go with the UC500. UC320 teleworker support is coming 2012.

4.UC500 again is your best bet here.

telecastle · ‎10-04-2011

When you say that "There's no Support for Teleworkers or remote site in the UC320," what exactly do you mean? If there's an IPSec VPN tunnel established between the SA520/540 and a router at a teleworker's residence, how would UC320 even be able to distinguish that the IP phone at the teleworker's location is not on the same LAN (but different VLAN) as the UC320?

I have a similar scenario running with a CUCME behind a Cisco 871 and an IP phone behind a Cisco SOHO 91, with an IPSec VPN tunnel between the 871 and the SOHO 91. The CUCME and the phone are separated by the Atlantic Ocean and a few thousand miles of land mass. The IP phone (Cisco 7941) registers with the CUCME, and the voice quality is perfect. I just fail to understand why this scenario will not work with UC320.

Now, if you try to register an external SIP phone without having an IPSec tunnel between the location with the IP phone and the location with SIP Proxy, I can see why this may not work unless this feature is specifically supported by the SIP Proxy.

Christopher Edgeworth · ‎10-05-2011

Hi,

The UC320W uses some different technolgies from the CUCME and UC500 that do not currently allow the service set to work over a IPSec VPN. To properly support a teleworker solution there is some development effort (read code changes) required. We are working on solutions that are consistent with the UC320W's ease of use and ease of deployment.

Thanks,

Chris

telecastle · ‎10-07-2011

I think I may see now why it may not work. UC320 has a requirement that all SIP trunk traffic leave out of its WAN port. It's a strange requirement, to say the least. This is where the problem may be. With other IP PBX devices, you can send traffic destined to local IP phones, remote IP phones, and to the IPTP (SIP Provider) out of the same port (or the same VLAN). Therefore, you can have your IP PBX set up as a regular IP host with a default route pointing out of its LAN port or voice VLAN interface. This way, when the IP PBX sends traffic to an IP phone on the same subnet (VLAN), it just ARPs for the IP phone's IP address and gets the IP phone's MAC address. When the IP PBX sends traffic to a remote phone located across an IPSec VPN tunnel, because the remote IP phone's IP address is on another subnet, the IP PBX ARPs for the default-gateway's IP address. When the IP PBX sends traffic to the IPTP (SIP Provider), it also ARPs for the default-gateway's IP address.

With UC320 having to always use the WAN port for the SIP trunk traffic, there will have to be a capability to set static routes within UC320 so that when it sends traffic to a remote IP phone located across an IPSec VPN tunnel, it would have a static route to the subnet of the remote IP phone, pointing out of its voice VLAN (where the next-hop Layer 3 device would either be the IPSec VPN headend or would route the packet to the IPSec VPN headend); at the same time, when UC320 sends traffic to the IPTP (SIP Provider), it would use the static (or default) route pointing out of its WAN interface.

If UC320 does not have a capability to have static routes pointing out of different interfaces based on the destination networks, then there still could be a work-around. Specifically, the voice VLAN on the UC320 can be configured with the subnet mask of /24, but the subnet mask on the interface of the Layer 3 device connected to one of UC320's LAN ports is configured with a subnet mask of /25. If all teleworker IP phones are configured with IP addresses in the upper half of the voice VLAN subnet (.130 and higher), UC320 will think that each teleworker IP phone is located on the UC320's voice VLAN, and therefore, it will ARP for the remote IP phone's IP address trying to discover its MAC address. When the next-hop Layer 3 device sees this ARP request, it would respond with its own MAC address so that UC320 would send traffic (destined to the remote IP phone) to that Layer 3 device. At that point, the Layer 3 device would either put the packet in the IPSec VPN tunnel (if the Layer 3 device is also the IPSec VPN headend), or will route the packet to the IPSec VPN headend, which will in turn send it to the teleworker router across an IPSec VPN tunnel. The only feature needed for this work-around is Proxy-ARP capable Layer 3 device connected to one of UC320's LAN interfaces.

I have tried to search for "proxy arp" in the SA500 Administration Guide, and did not find any references to this feature. However, the "Cisco Small Business 3000 Series Managed Switch Firmware 1.1 CLI Administration Guide" describes the global configuration mode "proxy arp" feature" on page 485, and the interface configuration mode "proxy arp" feature on page 486. Therefore, if one of UC320's LAN ports is connected to an SG300 port, and proxy ARP is enabled on the SG300, the work-around I described in the previous paragraph shoud work.

I hope someone could read this long post and critique it. I am about to order UC320, SG300-26P, and SA540, so I need to know if this would work.

Christopher Edgeworth · ‎10-10-2011

Hi,

As we have said several times before on this community Teleworker is not currently supported on the UC320W. There is an explicit featureset required to implement teleworker support in a future feature release. We have heard the community and this is a front runner feature request.

We use IPv4 multicast for a number of critical services in the UC320W. Multicast does not play well with IPSec tunnels.

If you must have a teleworker solution today, then the UC500 solution is your best bet.

Thanks,

Chris

telecastle · ‎10-15-2011

Christopher,

I realize now that teleworkers are not supported and that you guys are working on the teleworker support. Still, I would like to know which services require multicast in the current configuration. I need to implement teleworkers before next year, and I believe the solution I described above may work. SIP does not require multicast, so what are the "critical services" you are speaking of?

Than you!