Ian MacKinnon wrote: > >> >> On Thu, Jun 07, 2007 at 02:50:14PM +0100, Ian MacKinnon wrote: >>> Hi All, >>> >>> Given the config below for a vpn tunnel, when I add the command "qos >>> pre-classify" to the crypto map and the tunnel interface, I get really >>> bad slowdown of traffic. >>> >>> 2. Questions, is anybody using qos pre-classify to prioritise voice? >>> And I just wonder if trying to shape the tunnel and shape the phyiscal >>> interface is wrong. >>> >>> thanks >
Hello, I think that you should choose to apply the service policy either a. only on the tunnel interface without "qos pre-classify" or b. only on the physical interface with "qos pre-classify" on both tunnel and crypto maps. It depends on whether the physical interface is a congestion point (if eg. you route also other tunnels through this interface). Note that at least from what I've read so far, in case you use the second method, you should also include the "crypto map GRE" in the tunnel interface also. There is also another issue that needs a bit of investigation and perhaps someone knows the answer: In case we apply the service policy on the physical interface (with qos pre-classify) does this mean that the LLQ/shaping happens after the crypto engine? If we apply it on the tunnel interface without "qos pre-classify" does the LLQ/shaping happen before the crypto engine? If the above are true, I think that the second one would be a preferred method to avoid anti-replay issues with IPsec, in case the physical interface is not the congestion point. John _______________________________________________ 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/