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

Mike Sawicki fifi at HAX.ORG
Thu Jul 29 12:38:51 EDT 2004


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)


More information about the cisco-nsp mailing list