I’m working on a QoS job and we’re not trusting the phones. I presume that most everyone has heard of the hacking that some fellows did to break into a hotel’s network by using a small program that made their PC look like a Cisco phone. The switch then trusted the phone-a-like-PC and they were able to gain access to the corporate network. So why would you trust a phone, particularly if the phone is located in an untrusted location, like a lobby or a classroom?
So the voice network has its own address space and is separate from the corporate network. That has made life relatively easy for doing QoS because an ACL can be used to determine which packets are likely to be voice without having to run NBAR (Network Based Application Recognition). The ACL specifies UDP and that both the source and destination addresses have to be in the VoIP address space. It’s pretty easy in this case.
But in other networks, some people allocate the VoIP subnets out of various chunks of their network address space. That makes it exceedingly difficult (well, at least tedious) to provide security betwen the VoIP address space and the corporate address space as well as identifying VoIP data packets.
Using a single chunk of address space for VoIP may not jump out at you initially, until after you’ve deployed it and then decide that it needs to be secure or that you need to add QoS (hmmm, you didn’t do QoS up front… welcome to the club – many people put it off in order to get the phones deployed). Then you find that the access lists you need are very, very long and difficult to maintain. But readdressing is also a big pain.
Thinking of it up front during the design phase makes a big, big difference in the amount of work that goes into your deployment and into maintaining the system. My recommendation: go back and readdress the phones. Sure, it is a hit in productivity to do it, but you’ll have much fewer security and voice quality problems as a result. (Imagine convincing a SOX auditor that your 5 page access list is correct.)
Plan, plan, plan. Then build.
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html