Welcome to Infoblox NetMRI Community Sign in | Join | Help
in Search

Applied Infrastructure

QoS Classification and Marking for VoIP

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.

   -Terry

 

Comments

No Comments

About tslattery

Terry Slattery, CCIE #1026, is a senior network engineer with decades of experience in the internetworking industry. Prior to joining Chesapeake NetCraftsmen as a full time consultant, Terry was the founder and CTO of Netcordia, and inventor of NetMRI, a suite of network management products. Terry started Netcordia as a consulting company in 2000 and transitioned to a network management product company in 2003. During the consulting days, he used his network design and implementation skills to lead a team in the design and implementation of a high availability network at a brokerage clearing house. Terry is the former President and founder of Chesapeake Computer Consultants, Inc., a networking and computer systems training and consulting company. He co-invented and patented the vLab(tm) internet-based remote lab system. He is co-author of the McGraw Hill text Advanced IP Routing in Cisco Networks. Terry led the team that developed the current Cisco IOS user interface under contract to Cisco Systems. Terry is experienced in the design and installation of large TCP/IP based networks and is a successful network protocol instructor. He is the second Cisco Certified Internetworking Expert (CCIE) #1026 and the first outside of Cisco. He enjoys membership on the Vanderbilt University Engineering School’s Industrial Advisory Board and the IEEE.

This Blog

Syndication