[c-nsp] Best configuration for IPSEC/GRE and QoS

[Luan Nguyen]

Hi Mike,
There is a very good paper on CCO about V3PN
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns241/c649/ccmigration_09186a00801ea79c.pdf
with Cisco IOS, IPSEC/GRE preserves the ToS bytes automatically.  qos
pre-classify preserve other fields  of the IP Header.  In your case, you
don't want to do any fancy queuing withint the GRE itself so I don't think
you would need qos pre-classify feature.
I would try the following:

ip access-list extended HUB
permit GRE any any (or more specific to your network if you want to)
!
class-map match-all HUB
match access-group name HUB
!
policy-map SPLIT
class HUB
bandwidth percent 90
class class-default
fair-queue
random-detect
!
interface WAN
service-policy output SPIT

Hope that help a bit.  Let me know if it doesn't work...when i have some
free time could help you test it as well :)

Regards,

luan




From: "Mike Sawicki" <fifi at hax.org>
To: <cisco-nsp at puck.nether.net>
Sent: Thursday, July 29, 2004 12:38 PM
Subject: [c-nsp] Best configuration for IPSEC/GRE and QoS


> I've been struggling for a couple weeks now to find the most ideal
> QoS configuration for an IPSEC/GRE design that's in service.  We
> have several branch offices with independent Internet connections
> (T1) terminating into our hub router.  All routers are running 3des
> code and have the hardware accelerators, etc. etc..
>
> Users at the branch offices browse the web and use other misc.
> Internet services directly over their local 'Net connections using a
> NAT pool.  Any communications with networks sourcing from within our
> enterprise are advertised to them via the IPSEC/GRE tunnels.
>
> I would like to prioritize all tunnel traffic with the most fascist
> policing possible, giving back only extra resources to misc.
> traffic.  I've tried about 6 combinations of policing, strict
> bandwidth prioritization of the IPSEC packets, declaring a policed
> cir, and several other methods.  Does anyone out there have a solid
> recommendation they could make that they are using in a similar
> design?  Currently, no matter what I try, I get output drops on the
> T1 interfaces at all offices.. even if they are only using an
> average of 200-300kbit/s on output.  What seems to be happening is a
> strict conforming of packets to the T1 limit, which is creating
> drops.  I would like to have the packets fair-queued or shaped
> by flow rather than dropped, but that doesn't seem to be working.
>
> I have looked at the following page:
>
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns109/networking_solutions_white_paper09186a0080189048.shtml
>
> which talks about using something called "qos pre-classify" which
> should allow you to match against packets prior to encapsulation.
> Since the routes we advertise to the offices vary and change freely
> I don't want to have to install static acls for all pre-encapsulated
> traffic if I can help it.  Ideally I just want the IPSEC or GRE to
> be properly prioritized with minimal discards.
>
> Thanks.
> -- 
> Mike Sawicki (fifi at HAX.ORG)
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/