policy-map on ethernet int 192k - why?? 2

[tbitner]

I'm reviewing a service-policy setup by a consultant that has only 192kb prioritized on an ethernet interface. I don't understand why you would do this on a ethernet int when I have 100mb and no congestion.

policy-map ETHERNET_LLQ
class ETHERNET_VOICE_TRAFFIC
priority 192
class class-default
fair-queue
random-detect
!
interface FastEthernet0
ip address 10.10.1.1 255.255.255.248
speed auto
service-policy output ETHERNET_LLQ
!

Thanks!

 

[imbadatthis]

class ETHERNET_VOICE_TRAFFIC
priority 192


the priority command is creating a Special queue, lets say, that reserves 192kbps bandwidth for your voice traffic.
its not limiting the interface's bandwidth, just saying, reserve 192kbps for this stuff for the packets matching ETHERNET_VOICE_TRAFFIC; anything else that doesn't match (its not voice) send it out, and if you get congested, use random-detect algorithm to drop packets.

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080103eae.shtml

might help .
and i like this part very much "Although the bandwidth guarantees provided by the bandwidth and priority commands have been described with words like "reserved" and "bandwidth to be set aside", neither command implements a true reservation"

We must go always forward, not backward
always up, not down and always twirling twirling towards infinity.

 

[unclerico]

are you sure that this interface doesn't connect to a slower link downstream??

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[burtsbees]

Yeah---map out the network to the edge from this link, and what model router (sounds like a 1700 series?)...

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[tbitner]

The router is a 1750 and the Ethernet side connects to a firewall then to the LAN. It just seems odd that more bandwidth isn't reserved. The Serial side is 384k and it has a similar service-policy.

WanRouter#sh policy-map interface s0
Serial0.300: DLCI 300 -
output : SERIAL_LLQ
Class SERIAL_VOICE_TRAFFIC
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 192 (kbps) Burst 4800 (Bytes)
(pkts matched/bytes matched) 5062/2719547
(pkts discards/bytes discards) 618/814077

From reading the cisco link, during congestion packets will be dropped from this queue. This seems like an issue since I am seeing "pkts discards" and users sometime complain about voice quality. Should I increase the priority on the Serial side higher than 192?

 

[unclerico]

what codec are you using and what is the sample size of voice, is it the default of 20ms?? you need these values plus the maximum number of calls that you want to allow at one time (do you have call admission control enabled??) in order to calculate the bandwidth requirements.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[tbitner]

The voip phones on the LAN (5 total) are from a hosted provider and the codec they're using is G.729. Not sure of the sample size and all phones should be able to make calls simultaneously The router isn't running any sort of CAC, just the service-policies.

 

[burtsbees]

I'm going to say that the output on the LAN side is for incoming VoIP. For the WAN, when you have 5 users for data AND VoIP, 384K I would say is not going to cut it. I say increase the priority for VoIP. I wonder if WRED should be used instead of just straight policing, since you only have 384K.

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[tbitner]

Thanks for the information. My serial interface queueing strategy is FIFO. Will WRED still work or does the interface need to be CB-WFQ? Lastly, if I apply WRED to the policy-map, I need to make sure the voip traffic coming from my LAN has the proper DSCP markings, right?

 

[burtsbees]

I believe so on both counts. However, ultimately you're talking about only fine-tuning, and queuing strategies not making much difference on the small amount of bandwidth you're dealing with here. Let's think about how long a call may last---say one minute. It may take 1/2 of that for the traffic to actually be shaped into its intended reserved bandwidth, especially if others are saturating the line (it would not take much to do so).

Uncle would have more experience than me on this, and he would deserve a star as well IMHO...and thanks for mine, much appreciated.

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!