RE: IPSEC over load-shared T1s (per packet)

["Jan Bervar" <jan () nil si>]

Just my 0.02 EUR... MPPP can be performance intensive on routers, and your 
ISP may not be willing to implement it at all.

Cisco routers can also load-balance on a source-destination hash, which 
means that ideally, L3 sessions are evenly balanced across a number of 
links. In a VPN scenario, this works much better compared to 
per-destination balancing, especially if the number of your VPN peers is 
large and dynamically addressed. Both sides of the link(s) need to enable 
Cisco Express Forwarding, and there is no significant perfomance hit 
involved (provided their and your routers have the memory to handle CEF 
tables).

Cheers,
Jan


firewall-wizards-admin () honor icsalabs com wrote on 20.09.2003 05:51:54:

> I think this is pretty much solved now, but just for the sake of the
> archives:
>
> The problem was pretty much as I guessed (just lucky ;).
>
> The packets were being sent over alternating links in strict 
round-robin,
> which meant that the ESP packets sometimes arrived out of sequence. The
> IPSec implementation was dropping all the ones with seq < currentseq, 
which
> was causing retransmits in the tunneled TCP sessions.
>
> One fix is to use "per destination" load balancing - but that is bad 
because
> if all the traffic is VPN then only one link will get used (only one
> destination).
>
> What I suggested offlist is to look at either ppp-multilink, or 
MUX/DE-MUX -
> both of those will make the link look like one big layer2 pipe, which 
will
> fix the problem and preserve sequencing. PPP Multilink is software, and
> simple. MUX stuff is more complicated but faster and can be more 
flexible.
> I also got queries offlist about the E1/T1 RJ connectors. Yes, I did, 
OK? I
> was curious. Ow.

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards