Equipment Support > Hardware By Brand > Cisco > Cisco router advice

Cisco router advice

you may also look at Juniper SRX or J series as they have a better webgui and more XML API capability for management and have websense builtin...

reply to Merry
Tell your VoIP provider to jump into a volcano, and take that EdgeMark crap with them.

The 2911 will certainly handle the routing. However, any content inspection -- blocking a specific application -- will not be doable to any level of satisfaction on the router. It'll only partly work, and significantly slow down the router. If you have licenses for Websense, then continue using it. I'm not sure about IOS integration, but the ASAs (firewalls) do support it.

Edgemarc is not ranked as a good voip products... Shaping and prioritization i.e. QoS is available on almost all business class routers, so it's a no brainer... Cisco has WCCP which redirects the web traffic to another proxy server so I suggested Juniper for its integrated UTM feature with websense...

reply to Merry
EdgeMark I'll give you a few mintues alone with Google.

*pause*

They are made for and marketed exclusively for service providers. The end-user has zero avenues for support, documentation, or software -- it all has to go through the ISP. As a result (i.e. due to only the ISP engineers who had no say at all in their selection, and are banned from speaking in public), They. Completely. F***ing. Suck. Megapath threw one at us for a T1; the result was a 1Mbps T1. Remove that junk and it works at full speed. (the previous SpeakEasy Samsung router was perfect, but megasuck forced us to replace it.)

For it to do any QoS, it has to be in-line, or totally in control of your connection.

reply to Merry
Not sure what the other options are in your area, but based on a past experience of mine with a hosted VoIP solution, I'd stay away from using the Internet as your WAN connectivity to them. At best you'll probably only be able to do QoS going outbound toward the ISP. I think it's usually done using a parent shaper with a child queuing policy underneath. Once it gets past egressing your Internet facing equipment it's all best effort. There's no guarantee the QoS tagging will even be preserved end to end (I had this problem). Even worse they probably won't even honor it.

You don't have any control over how the traffic gets queued coming back to you on the downstream. This could cause some major audio quality problems on your end. Controlling the download link with policing might be possible. I think it causes the TCP windowing to adjust from packets dropped by the policer. Usually this causes the sending servers to back off on how much they're sending you. To my knowledge though it only works on TCP based traffic. You definitely don't want your download link saturated more then the amount you want left for VoIP. For example: 1 Mbps download link while leaving room for receiving 10 simultaneous calls over the WAN at roughly 96 Kbps each. You would need to police anything not coming from that VoIP provider down to roughly 544 Kbps. The thing here is that the maximum download you'll get is that rate, whether those calls are happening or not.

On the LAN side you should be able to just set your switches to trust your 802.1p (if you're dealing with trunks) or DSCP tagging. Although with today's LAN speeds it may not ever kick into gear, but it is a best practice and certainly doesn't hurt anything.

If you want to know more let me know, I'd be happy to share more information. To sum it up though this could turn out to be a difficult project.

reply to Merry
Hasn't been mentioned yet, so I'll ask -- how fast is the connection speed itself, and what type of connectivity
(RJ-45, serial, etc) is being brought in from the ISP?

For 50 users with services, I'd consider the 29xx as a minimum baseline, just be wary of the ISR G2 / IOS 15.x
licencing headgames Cisco is playing.

ZBFW plays pretty good with NBAR, so if you get yourself a 29xx with 3 interfaces, should be easy enough
to do a TRUST / UNTRUST / GUEST ZBFW config.

My 00000010bits.

Regards

It's Comcast business class: 22 mbps down, 5 mbps up. According to Comcast, sometime this month it will be increased to 27 mbps down, 7 mbps up. Comcast's device is an SMC business class gateway. Coax (RG6, I think) to the SMC gateway, then Ethernet between the SMC gateway and our router.

reply to VoIPShaper

Getting a private line such as T1 between your site and the hosted PBX is your best bet for reliable voice connectivity while keeping the Comcast connection strictly for Internet access. Not sure if such solution will be financially feasible.

reply to Merry
As stated by aryoba above, getting a private T1 connection would be a favorable option (depending on your bandwidth needs). Another could be a point to point switched fiber connection. Using the point to point connection just for VoIP related connectivity only will most likely make WAN related QoS easier to deal with.

Not sure how many physical phones you're looking to install, so I'll use my situation at work as an example. In my environment we have a total of ten IP phones. We use the g.711 codec which takes up roughly 96 Kbps each way per call. We have a 2 Mbps x 2 Mbps point to point ethernet switched fiber connection to our hosting provider. Actual voice traffic only traverses this link for outside calls and retrieving voice mail. Other than that, IP phone heartbeats and call control signaling to the remote end are the only thing that uses this link. When a person makes extension to extension calls, the actual voice stream is switched locally. The call control signaling for setting up and tearing down said calls still goes over the WAN link. If the link to the the provider goes down, we can't make any calls internally or externally. Our transport provider preserves our DSCP tagging end to end. I'm not sure if they honor it but it probably doesn't matter since it's a point to point circuit. As far as I know we will never have quality issues unless that circuit is saturated in either direction. Going back to the 96Kbps each way per call, we could have around 21 outside calls over the WAN. As long as the total throughput of all VoIP calls traversing the WAN doesn't exceed the rate we're paying for, we shouldn't ever see quality issues.

There's two ways you could decide on your bandwidth. One is to figure out how many outside calls you expect to have simultaneously. The other way is to assume the potential of all phones making outside calls at the same time. The former being most cost effective while the later giving you more room. Also keep in mind, one call higher than you can fit will send all present calls into the gutter. Every call over that link will suffer!

Now as far QoS is concerned, don't forget that it only kicks into gear when it needs to. From my understanding, it's only necessary where data and voice mix together. In the case of a 100 Mbps switchport with an IP phone with a PC behind it, the port will only start queuing if the port becomes saturated. In the case where it's just an IP phone, this congestion will most likely never happen. I can't think of any VoIP call that would require 100 Mbps of bandwidth. You should make sure your switch is set to trust whatever QoS markings you do use. I believe there's some switches that will rewrite the CoS or DSCP values if you don't trust them. Typically your trusting your values through the entire end to end path. Also if you're going with the PC behind IP phone route, don't forget the 802.1p tags will get stripped off at the router. Typically you use only one of the two tagging methods. In the case of traversing routers between endpoints, it's generally easier to use DSCP marking and call it a day. You can use DSCP marking whether you trunk to the phone or not.

I apologize if this post comes off excessive but I want to share what I learned. I don't want to see you make the same mistakes I did.

If you have any further questions let me know. If you're interested check out this four part blog I found on QoS: »znetworkconsulting.wordpress.com···n-links/ I found it a while ago and it may give you a good insight into QoS and typical configuration.