QOS, Frame - LLQ sucks 2

[JayNEC]

I've implemented QOS over frame-relay (for VOIP) with the standard proceedure several times now. It sucks every time.
LLQ, with LFI, priority queue for VOIP etc everything Cisco recommends for VOIP of Frame-relay. When there's not a really heavy load it's fine of course. When I put a HEAVY load on it, say with UDP Speed Test:

http://www.mycgiserver.com/~skybuck/)

it craps out. With the QOS there, it shouldn't.

With my PPP T1's I can run the UDP speed test and spew tons of UDP as fast as I want over the pipe and I don't lose calls or dialtone. I've frequently used custom queuing with T1's instead of LLQ.

So, is it the frame providers that are dropping the ball, or the router not prioritizing correctly?

 

[jneiberger]

What is the size of your priority queue at the site with 384K CIR?

 

[JayNEC]

184k for that site. the site I cut and pasted was recently upgraded to 512k from 384...

 

[jneiberger]

I would suggest removing the LFI config, and then consider tuning your tx-ring interface parameters. That probably won't fix your problem, but it would be interesting to see if it improves the issue. Take a look at CCO for details about tuning the tx-ring.

I don't remember the details of how to set it, but on a 2620 with a full T1 I was using the following values:

tx-ring-limit 14
tx-queue-limit 14

You'll have to do some research to verify whether or not those are valid for your hardware or link speed.

 

[E1Designs]

Jay, would you be willing to help me? I am no expert in this VoIP world but am having an issue here. LEt me give the specifics.

2x Cisco 1721's, ONLY doing routing. There is a PIX 506e at the branch office which is the VPN tunnel to a PIX 501 at the branch office. It also takes care of the firewall at each location. There is a SRW2016 switch at the branch office and 3 SRW2024's at the main office.

The main office has an Altigen server, the branch office has a MultiVoIP (MVP-410) box. Currently rujning 729 as 711 sounded awful. 729 sounds bad as well, as it cuts in and out.

Each site has a T1, the main and branch locations. My questions is how would I go about setting up QoS so that the calls sound better. I want the T1 to be throttled as much as possible without the calls suffering whatsoever. Would I do it in the switches and the routers? Just one? I am new to this QoS jazz, not the networking side of things, so I would think I can catch on quickly.

Thanks!!!

P.S. Sorry for the thread jack ;/

 

[JayNEC]

Just a minute...
jneiberger it turns out that the port speeds according to the provider are 384k and 512k.
So, should the interface be changed to reflect that?

 

[JayNEC]

E1Designs
You say that Each site has a T1, and a VPN? So the T1 is to an ISP?
In that case, there isn't a lot that can be done. The internet is a best effer delivery no matter what you do. That may change in the future...
You can only hope to prioritize the outbound traffic via the routers possibly. I'm still fuzzy on your setup.

 

[jneiberger]

JayNEC, I'm sure the port they're referring to is the PVC. I was referring to the actual speed of the T1 (fractional or not), but you already answered that question.

I don't see anything obviously wrong with your config except for the LFI stuff that doesn't need to be there. Try taking that out and then tweaking your tx-ring-limit settings and let us know if that helps out.

If it doesn't, we'll just keep troubleshooting until we figure it out!

 

[E1Designs]

JayNEC,

Right, each site has a T1, one from XO the other ELI. The branch office has a permanent VPN tunnel to the main office via the PIX's.

My curiosity is how can I do some form of QOS? Whether it is via switches, routers, anything...

Each branch site has a MultiVoIP box, which handles H323 and that is where the problem lies apparently. As IP to IP calls seem to be ok.

Not sure if it is mere tuning or if QoS is a must...

 

[JayNEC]

You really can't do any QOS over the internet. It's strictly a best effort system. The routers are in front of the VPN so they can't see anything but encrypted (encapsulated) traffic - which means that there is no way for them to discern your VOIP from your data traffic anyway.
The Pix MAY be able to do some QOS within the VPN but I'm not sure. That would help a little, but the encrypted traffic is still subject to being lost on the 'net.
729 probably sounds better than 711 because it requires much less bandwidth so the likelyhood of VOIP packets getting through is higher. You could also raise the packetization rate, default is probably 20ms but you could change that to 10. It would cause more bandwidth needs but a lost packet would have less impact (loss of 10ms of sound data vs 20ms)

 

[E1Designs]

JayNEC,

Thank you for the feedback. I have changed the packetization to 10 and it does sound much better. Watching the stats on the PIX, it is showing about 400 outside interface and 300 inside interface with just 2 calls. Granted this is G711, it is also concerning. I have adjusted the packetization to 10ms and it sounds much better. My concern is that John Doe begins a download of a large piece of imagery which is 130 MB. The T1 then hits the roof, how can I provide QoS at the switch so that voice gets priority outbound and inbound versus the download? Or is that what you are telling me that it is not possible?

Thanks Again.

 

[JayNEC]

You can't. The switch is going to be a minimum of 10mbs.
That's way more than a T1, so any QOS that you implement on a switch is not going to address the T1's bottleneck.

The QOS needs to occur at the interface that handles the queuing for the T1 which is the router. But as I said before, your router can't see what kind of traffic is passing through it. All the traffic looks the same because it's encapsulated by the VPN tunnel. So, the QOS needs to happen on the PIX before it's encapsulated and sent into the VPN.
You also cannot truly prioritize inbound traffic. Once it hits your interface (switch or router or PIX) it's already passed over the pipe and already used the bandwidth.

 

[E1Designs]

I was afraid of this. Essentially you're saying VoIP is meant for a LAN and I am attempting to traverse this technology via a WAN.

That about sums it up?

 

[JayNEC]

No, it's the fact that you're traversing a VPN WAN over the internet....
It works fine over private WAN's that you have control of.

 

[njgpeck]

Sorry to jump in here, but I've setup similiar. I've got Point-to-Point T1's connecting to our main site and VOIP running to each site. I've got a policy map in place on each router, identifying the VOIP traffic and setting priority to Critical. Here is an example:
!
ip access-list standard voice
permit ip 10.10.20.101
etc....
!
route-map voice permit 10
match ip address voice
set ip precedence critical
!
ip local policy route-map voice


Right now I've got the "ip policy route-map voice" statement on my FastEthernet port (connects to branch LAN) but should it be on the Serial port (connecting to the T1)? Any thing else I should have in place?

We don't have any encryption going on, so the router's can see the packets just fine. I haven't had a chance to test a call while overloading the bandwidth yet, but figured that would be my next step.

Thanks, Nic



If at first you don't succeed....then sky diving isn't for you.

 

[jneiberger]

njgpeck, Do you have QoS configured anywhere?

 

[E1Designs]

JayNEC,

So if we owned the router at each location and were still using a VPN tunnel it would not matter, we have to remove the VPN tunnel? I am sorry for the constant banter of questions, just trying to get a for sure grip on it. It seems that the VPN tunnel is the issue and if we had our own routers at each location using T1's from let's say XO, then we could manage this?

Thanks!!!

 

[jneiberger]

E1Designs,

The answer is quite simple: you have no control over how your voice traffic will behave over the Internet; therefore, if you decide to run voice traffic through a VPN tunnel over the Internet then you're implicitly accepting the risk involved.

You must be able to establish end-to-end quality of service to guarantee good voice quality. Since you have no control over quality of service on the Internet, it's folly to expect high quality VoIP. You may get it, but don't count on it.

A private WAN is an entirely different matter. In that situation, you have complete control over QoS.

HTH,
John

 

[E1Designs]

jneiberger,

That helps out a great deal, thank you.

 

[njgpeck]

jneiberger,

So what I have setup isn't establishing QOS? I thought by flagging these packets as critical it would accomplish the same thing.

We are using Nortel IP phones, which have the abiltiy to tag packets, but haven't been able to get it to work yet.

So is what I have in place now worthless?

Thanks,
Nic

If at first you don't succeed....then sky diving isn't for you.

 

[jneiberger]

You've done the first step in QoS: classifying and marking your packets. The next step is to configure queueing to establish how the different classes of traffic are treated. You don't have any queueing configured, just marking.

In fact, what you've really done is Policy-Based Routing, without the routing portion. If I were you, I'd stop using PBR and start using Low Latency Queueing (LLQ) or Class-based Weighted Fair Queueing (CB-WFQ). Look those up on Cisco's site for lots of configuration guides and examples.

HTH,
John