From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Mon Jan 26 2009 - 19:32:33 ARST
> Do you really need to worry about whether the tunnel interface experiences
congestion though?
Totally depends. If you implement a service-policy on a tunnel interface
vs. the physical interface it's associated with, you had better be shaping
to induce "back pressure," which is just another word for congestion.
Otherwise you just get FIFO. Per the link originally posted:
"When an interface becomes congested and packets start to queue, you can
apply a queuing method to packets waiting to be transmitted. Cisco IOS
logical interfaces do not inherently support a state of congestion and do
not support the direct application of a service policy that applies a
queuing method. Instead, you need to apply a hierarchical
<http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfmcli2.h
tml#wp1022062> policy as follows:"
(goes on to show an example of a classic hierarchical policy with shaping in
the parent policy and LLQ in the child policy)
Whether or not you implement QoS on the tunnel interface or the physical
depends on many factors. Consider a case of a hub and many spokes, for
example. Let's say each spoke has a 1 Mbps Internet connection and the hub
has a 45 Mbps DS-3. What would I shape the physical interface at the hub
to? 1 Mbps so as not to overrun any one individual spoke? I don't think
so! So in this case, ideally, you'd shape your tunnel interface. Problem
is that this precludes any type of mGRE solution, such as DMVPN. With Phase
3, it's my understanding that we can now apply hierarchical policy on a
per-SA basis, which would neatly solve the dilemma.
If I understood Jason correctly, he was eyeing the physical interface as
potentially a means to avoid needing a hierarchical policy. Same basic
principals apply as before, though. If you're dealing with a serial
interface or something that reasonably stands a chance of truly experiencing
congestion, you might consider a non-hierarchical solution. Otherwise, you
still need to look at artificially inducing that congestion in a parent
policy. And I certainly wasn't suggesting that "everything everywhere" is
all now 10/100/1000! My comment was specific to the mobile systems I'm
involved with fielding. All of the vendors of the EVDO cellular data cards,
etc, have gone the way of Ethernet in favor over serial (thankfully). I can
assure you that none of the WAN pipes available to these mobile solutions
ever approaches 10 Mbps, let alone 100 or 1000 Mbps (and we'll just see how
WiMax comes along)! So shaping to induce congestion to in turn allow for
LLQ behavior to ever kick in is a very common thing in production indeed.
Regards,
Scott
From: David Bass [mailto:davidbass570@gmail.com]
Sent: Monday, January 26, 2009 1:21 PM
To: Darby Weaver
Cc: Scott M Vermillion; Jason Madsen; Cisco certification
Subject: Re: QoS Over GRE
Do you really need to worry about whether the tunnel interface experiences
congestion though? To me it was more important to configure the policy on
the physical interface and then make sure the policy applied to that
interface reflected any bandwidth issues that might be encountered. Then
using the pre-class command to make sure the the packets were treated as
desired when leaving the interface as well as in transit.
I thought about incorporating policing as well, but decided against it...
Has anyone else done this in production and have any thoughts?
On 1/26/09, Darby Weaver <ccie.weaver@gmail.com> wrote:
I have a project where the links are not 10/100/1000 but are instead bundled
T-1's and so they will experience congestion at some point. The project is
at least 30-days out though. Keep me in mind if you want to see the
results. FYI - LLQ is definately a part of the solution and GRE tunnels may
be included due to the exact requirements but I'm still investigating and
I'm not certain the additional overhead in my scenario is worthwhile to use
the technology in this case. I hope to get the chance to mock it up this
week or at worst NLT than next week. Time does fly.
On 1/25/09, Scott M Vermillion <scott_ccie_list@it-ag.com> wrote:
>
> Wow, this just hit my inbox! List is slowly grinding to a halt again,
> evidently.
>
> The real question I guess is whether or not that physical interface you're
> talking about will ever experience congestion? If not, again, your LLQ is
> just kind of taking up space in the configs. I still occasionally get
> involved with mobile/tactical systems and this is something I sometimes
run
> into. Used to be a lot of the cellular data cards had serial interfaces,
> so
> I really could experience congestion. Now everything is 10/100/1000, so I
> can't ever experience congestion (until I hit the cell network but by then
> it's too late!). Whether or not I apply QoS to the tunnel or the physical
> depends on specifics of the system, how many tunnels I'm feeding into the
> given interface, whether or not I'm doing IPSec or just GRE, etc. Also, I
> do a lot of DMVPN with these mobile systems, with mGRE everywhere (even on
> the spokes since they often hit multiple Head End routers), to which (as
> far
> as I know) you still cannot apply a service policy, so I have no choice
but
> to deal with the physical interfaces for QoS. But now with DMVPN Phase 3,
> we're supposed to be able to do per-SA QoS. Man, that'll be sweet! Can't
> wait to try it out (and would love to hear from anyone who already has)...
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Jason Madsen
> Sent: Sunday, January 25, 2009 8:53 AM
> To: Cisco certification
> Subject: Re: QoS Over GRE
>
> oh...forgot to mention that initially it looks like the way to do it is
via
> QoS Pre-Classification and nested MQC. although, I wonder if simply
> applying a non-nested priority MQC to the physical interface that the
> tunnel
> uses and then applying QoS Preclass on the tunnel if that would work?
>
> Jason
>
> On Sun, Jan 25, 2009 at 8:49 AM, Jason Madsen <madsen.jason@gmail.com
> >wrote:
>
> > does anyone have any experience in doing priority-queuing over GRE
> > tunnels? I found an article by Cisco, but I can't say that it's all
that
> > I'm looking for.
> >
> > I don't want to do any QoS other than priority-queuing over the tunnels
> > unless required.
> >
> > Here's the one link I found:
> >
> >
> >
>
>
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a0080
> 17405e.shtml
> >
> > ...looking for more.
> >
> > Jason
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:40 ARST