cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3944
Views
0
Helpful
10
Replies

Cisco 1921 VLAN Routing Question - QoS?

ADynes
Level 1
Level 1

I will be installing two Cisco 1921 Routers to connnect a T1 between two offices.  We are changing out our current AdTran routers as we would like to bridge three VLAN's across the T1 link.  I followed the instructions at

http://www.cisco.com/en/US/tech/tk389/tk815/technologies_tech_note09186a0080094663.shtml to the best of my ability and my two Gigabit Ethernet ports are tied into a bridged virtual interface (BVI1).  I then assigned a IP to BVI1 and another to my Serial0/0/0 then made a route to get to the other side of the T1 and a defualt route out our proxy.

What I want to do now is setup QoS to make sure my voice data gets priority.  I setup a QoS ACL called "Voice" with the TCP and UDP source and destination ports that our phone system uses.  I then setup a QoS policy on the Serial0/0/0 outgoing interface called "VoiceTraffic" and under the "match" list I match DSCP 46 or my "Voice" access rule.  For the action I turned on "Queuing" and set it up for LLQ at 50%.  Does this sound about right?  Is there anything els eI can setup?  I tried ot setup something else on the ethernet side but because they have the BVI I can't.  I read some article sin this forum that said I could still apply QoS to the GigabitEthernet ports even if they are in the bridge group but it doens't let me do that.

Any comments would be appreciated.  Thanks,

-Allan

1 Accepted Solution

Accepted Solutions

EF stands for "express forwarding" and it's dscp value is 46, so the router converts it to EF.

if I am sending a 100Mb file up the T1 then I place a call the call will get the bandwidth and just subtract off of the bandwidth the file being sent is correct? 

If you're uploading a file and the outgoing interface is congested, then yes, the current packet is completed sending and then the voice packets will be prioritized at that point. The problem comes in that even if you have qos, if you don't have enough bandwidth then no amount of qos will help.

It's not actually dedicating 50% of the line at all times...only when voice traffic is using it (things that match my ACL and DSCP 46).

Voice traffic coming through isn't what kicks off the policy. The interface needs to be saturated before the qos policy kicks in. So, yes, the 50% is only during the time of congestion because the llq also polices the traffic and doesn't allow more than 50% and it can go higher than that if congestion isn't present.

HTH,

John

HTH, John *** Please rate all useful posts ***

View solution in original post

10 Replies 10

John Blakley
VIP Alumni
VIP Alumni

From the sound of it, it sounds like it should be okay. Your LLQ percentage seems kind of high to me. What happens is when the interface gets congested, the LLQ takes that percentage off the top. If you have a T1 (1.5Mb), then you're effectively giving about 560k to voice (1.5 * .75 = 1.125 * .50 = 560k-ish). Then the other traffic will fight for remaining bandwidth. Your voice traffic will be fine, but other things may suffer needlessly. Depending on how many users you have, I'd set the llq to be around 10 percent first and see how things go from there.

HTH,

John

HTH, John *** Please rate all useful posts ***

Each office (on either side of the T1) has a MiTel HX5000 phone system and each office has a bunch of digital phones then some IP phones in branches.  Beyond that we have some database programs that go over the line then some DFS shares (that are already limited to like 128k each during the day).

So honestly we rather make sure the voice calls are clear and don't drop more then anything.  I guess the question is, and I want to make sur eI understand this, if I am sending a 100Mb file up the T1 then I place a call the call will get the bandwidth and just subtract off of the bandwidth the file being sent is correct?  It's not actually dedicating 50% of the line at all times...only when voice traffic is using it (things that match my ACL and DSCP 46).  The AdTrans were set to 640Kb dedicated to voice traffic and when we had it at 512k we did have "insufficient bandwidth" alarms on the phone system.

Also as a side note my QoS policy is set to match DSCP 46 or my voice ACL.  Howeverafter saving it and then looking at it the DSCP keeps switching to ef (from 46).  I thought it was switching hex to decimal or something but that conversion isn't making sense to me.

EF stands for "express forwarding" and it's dscp value is 46, so the router converts it to EF.

if I am sending a 100Mb file up the T1 then I place a call the call will get the bandwidth and just subtract off of the bandwidth the file being sent is correct? 

If you're uploading a file and the outgoing interface is congested, then yes, the current packet is completed sending and then the voice packets will be prioritized at that point. The problem comes in that even if you have qos, if you don't have enough bandwidth then no amount of qos will help.

It's not actually dedicating 50% of the line at all times...only when voice traffic is using it (things that match my ACL and DSCP 46).

Voice traffic coming through isn't what kicks off the policy. The interface needs to be saturated before the qos policy kicks in. So, yes, the 50% is only during the time of congestion because the llq also polices the traffic and doesn't allow more than 50% and it can go higher than that if congestion isn't present.

HTH,

John

HTH, John *** Please rate all useful posts ***

We've had the 1.5Mbps T1 for the last 8 years between these two offices.  But we are running out of room on the network  (Re:

https://supportforums.cisco.com/message/3692023 ) and I need to expand.  I'm ok with slow data traffic but I can't lose the voice traffic.

Thanks for your help John....hopefully I setup the routers correctly.  I setup the same voice policy on outgoing for both Serial interfaces so I beleive that's all I need. It seems "simplier" then I thought it would be looking over the config file.

-Allan

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

BTW, do you also protect your VoIP signally traffic?

I would suggest using FQ for your non-LLQ traffic.

The "voice" ACL, from what I've read on my Mitel system and what the old working routers were setup, covers all the in and put ports used for signalling and communication for the phone system so it's part of the rule.  I based my rule on the existing rule which I know works...jsut wasn't sure how to apply it.

What is FQ? 

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

What is FQ?  

Fair-queue.

Right now the only QoS on the existing routers is the same as what I programmed into the new routers and it has been working well.  Is there any reason/benifit to adding to it?

-Allan

Disclaimer

The     Author of this posting offers the information contained within this     posting without consideration and with the reader's understanding  that    there's no implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not   be construed as rendering professional advice of any kind.   Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In     no event shall Author be liable for any damages whatsoever   (including,   without limitation, damages for loss of use, data or   profit) arising  out  of the use or inability to use the posting's   information even if  Author  has been advised of the possibility of  such  damage.

Posting

Allan Dynes wrote:

Right now the only QoS on the existing routers is the same as what I programmed into the new routers and it has been working well.  Is there any reason/benifit to adding to it?

-Allan

Can't really say without knowing your current policy, current traffic loading and service requirements.

However, in general, FQ keeps "bandwidth hogs" from being especially adverse to other traffic.  With FQ, users often perceive network performance as less erratic.

Thanks...I'll look into it. 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco