[VPN] IPSEC over load-shared T1s (per packet)
Dana J. Dawson
djdawso at qwest.com
Fri Sep 19 11:17:48 EDT 2003
Unless you're doing NAT, the CRC of the IP packet will not change. This sounds
more like an issue with out-of-order packets, especially if you have any
fragmentation going on, since some devices don't like out-of-order fragments.
The easiest fix may be to set the MTU of your VPN devices down to avoid
fragmentation completely (1400 or so is probably a good number), but you may
have other options as well. For example, Cisco has some specific commands in
IOS for dealing with fragmentation and PMTU Discovery.
TSimons at Delphi-Tech.com wrote:
> Hello All
> Recently we doubled our internet bandwith to two T1s from the same provider
> that terminate on in the same router on the NOC side.
> We setup IP LOAD-SHARING PER-PACKET on each of the serial links on both
> sides (NOC and Us) in order to get an aggregate 3.0mbit. PER-PACKET routing
> alternates usage of the T1s, one for one...
> Since then, VPN performance has taken a dive. Sniffing out traffic, ESP
> packets are sent 3-4 times before they can be properly decrypted.
> Someone along the way said that using PER-PACKET routing changes the CRC
> value of the packets. Is this correct, has anyone else seen this issue? I
> can't see how the CRC is changed, the hop count isn't changing, the lines
> are identical, and they terminate in the same router, so the last hop is the
> F0/0 interface of the router before getting to the firewall.
> Todd M. Simons
> Senior MIS Engineer
> Dell Tier 1 PA Technician
> Delphi Technology, Inc.
> New Brunswick, NJ
> Note: The contents of this email do not constitute a legally binding
Dana J. Dawson djdawso at qwest.com
Senior Staff Engineer CCIE #1937
Qwest Communications (612) 664-3364
600 Stinson Blvd., Suite 1S (612) 664-4779 (FAX)
Minneapolis MN 55413-2620
"Hard is where the money is."
More information about the VPN