[c-nsp] QoS on an Ethernet Sub-interface
I've got a QoS question for the group; I'm not a QoS buff, at least not on the nitty gritty details. I'm trying to set up some basic QoS on a 3Mbps PtP Ethernet link. One side uses a full interface for the link on a 2821. My side uses a 1Q sub-interface on a hardwired GigE port in a 2821. I can't apply a matching QoS config due to the sub-interface. I found this guide on how to approach QoS on a Ethernet sub-interface. It specifically states that I have to use a hierarchical QoS policy with shaping in the parent before I can use CBWFQ on the sub-int. http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a0080114326.shtml The far side uses this: class-map match-any SIGNAL match ip dscp af41 match ip dscp af31 match ip dscp cs3 class-map match-any VOICE match ip dscp ef match ip rtp 16384 16383 ! policy-map WAN_QOS class VOICE priority percent 35 set dscp ef class SIGNAL bandwidth percent 5 set dscp af31 class class-default fair-queue I'm looking at applying this: class-map match-any voip-rtp match ip dscp ef match ip rtp 16384 16383 ! class-map match-any voip-control match ip dscp af41 match ip dscp af31 match ip dscp cs3 policy-map voip-child class voip-rtp priority percent 35 set dscp ef class voip-control bandwidth percent 5 set dscp af31 ! policy-map voip-parent class class-default shape average ABC ! service-policy voip-child Overall I think that would work though I'm sure it needs some tweaking. My holdup is the shape average value. I'm trying to understand what it is that I'm shaping with that command. Should the shape value be the max I'm allowing for the VoIP classes referenced by the policy map, the max for the link, or some other value that I'm not thinking of? If it is the voip classes will that affect my percentage commands in the child classes? ie, if the shaping was set at 1Mbps would the 35% in the child come out at 350k? Thanks Justin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on an Ethernet Sub-interface
Justin, the shape average is what you are wanting to shape the whole subinterface to in bps, ie if you wanted to shape it to 1Mb then you would have shape average 1024000, sometimes a nicer way to do it is just say shape average percent 100 which will reference the bandwidth statement on the interface instead. You are correct in your second statement that shaping average at 1Mb would result in 350Kb for a class with 35% Cheers Ben Overall I think that would work though I'm sure it needs some tweaking. My holdup is the shape average value. I'm trying to understand what it is that I'm shaping with that command. Should the shape value be the max I'm allowing for the VoIP classes referenced by the policy map, the max for the link, or some other value that I'm not thinking of? If it is the voip classes will that affect my percentage commands in the child classes? ie, if the shaping was set at 1Mbps would the 35% in the child come out at 350k? Thanks Justin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on an Ethernet Sub-interface
On Fri, Aug 29, 2008 at 08:20, Justin Shore [EMAIL PROTECTED] wrote: I've got a QoS question for the group; I'm not a QoS buff, at least not on the nitty gritty details. I'm trying to set up some basic QoS on a 3Mbps PtP Ethernet link. One side uses a full interface for the link on a 2821. My side uses a 1Q sub-interface on a hardwired GigE port in a 2821. Not sure about this one side and my side, but when you use a sub-rate Ethernet service you should apply a HQoS policy (parent shaper + child queues) on both ends of the link. There is no point sending egress traffic at 100Mbps (or even 1000Mbps) speed on your full interface 2821 when the actual pipe is just 3Mbps wide. policy-map voip-child class voip-rtp priority percent 35 set dscp ef class voip-control bandwidth percent 5 set dscp af31 If your Ethernet provider support Ethernet CoS you could also set cos X on the interface where you use 802.1q encapsulation. Unfortunately this is not possible on regular Ethernet interfaces. Some SP's do support DSCP for classification of Ethernet frames, so you might be safe any way. policy-map voip-parent class class-default shape average ABC ! service-policy voip-child This policy should be attached both on the main interface on one end, and the sub-interface at the other end. Note: There has been major improvement in HQoS and LLQ in 12.4(20)T, see the thread: https://puck.nether.net/pipermail/cisco-nsp/2008-August/053616.html -- Pelle ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on an Ethernet Sub-interface
Ben, Thanks for clarifying that. Just so you know, I tried the 'percent 100' option but ran into a snag. I'd get this error whenever I tried to apply the policy to the interface: cir must fall between 8000 and 15440 bps With a little Googling I determined that I had to define an actual bandwidth value instead of a percent for whatever reason. I changed it to 3000 and I could then apply the policy. My code is 12.4(9)T1 which could be the problem. Otherwise that got me up and running. Thanks! Justin Ben Steele wrote: Justin, the shape average is what you are wanting to shape the whole subinterface to in bps, ie if you wanted to shape it to 1Mb then you would have shape average 1024000, sometimes a nicer way to do it is just say shape average percent 100 which will reference the bandwidth statement on the interface instead. You are correct in your second statement that shaping average at 1Mb would result in 350Kb for a class with 35% ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on an Ethernet Sub-interface
Pelle wrote: Not sure about this one side and my side, but when you use a sub-rate Ethernet service you should apply a HQoS policy (parent shaper + child queues) on both ends of the link. There is no point sending egress traffic at 100Mbps (or even 1000Mbps) speed on your full interface 2821 when the actual pipe is just 3Mbps wide. Unfortunately I don't admin the remote end of the link. I'll send them my config and ask them to change it on their side. I agree that line-rate traffic shouldn't be stuffed into a sub-rate queue on the transport provider's side. That's asking for trouble. If your Ethernet provider support Ethernet CoS you could also set cos X on the interface where you use 802.1q encapsulation. Unfortunately this is not possible on regular Ethernet interfaces. Some SP's do support DSCP for classification of Ethernet frames, so you might be safe any way. I don't believe they do. Currently the L2 path isn't 1Q but it may be possible to change that. I'll have to make some inquires. This policy should be attached both on the main interface on one end, and the sub-interface at the other end. Right. That's essentially what we've got. They just had a free port on their 2821 when they set up their end. On our end we had to bring it into a switch and trunk it up to the router. I'm planning on moving the core routing over to the 3560E switch soon to get rid of the router-on-a-stick we have now. Note: There has been major improvement in HQoS and LLQ in 12.4(20)T, see the thread: https://puck.nether.net/pipermail/cisco-nsp/2008-August/053616.html I was reading about that. I would have loaded it the other night but my CF card was too small. I'll have to try that in a later window. Thanks for the info Justin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
