RE: [fw-wiz] IPSEC over load-shared T1s (per packet)

From: Pano Xinos (pano.xinos_at_ca.mci.com)
Date: 09/22/03

  • Next message: Chris Ditri: "[fw-wiz] Tranparent bridge" 
    To: "Jan Bervar" <jan@nil.si>, "Ben Nagy" <ben@iagu.net>
Date: Mon, 22 Sep 2003 10:20:44 -0400

    Hi All,

    My experience has been that load-sharing per-destination on Cisco routers
    is nowhere near evenly balanced. Typically I've seen anything between
    90%:10% and 60%:40% traffic ratios/ulitization (it has never been 50%:50%
    when doing per-destination routing). The main issue is the sequence of
    packets and the anti replay feature of IPSec (don't remember who discussed
    it i na previous email...). AFAIC, you may be better off doing some QoS to
    shunt IPSec packets down a single link and run regular traffic over the
    other link. If redundancy is not an issue, simply get a bigger pipe to
    handle all traffic.

    Cheers!

    Pano

    At 09:17 AM 9/22/03 +0200, Jan Bervar wrote:
    >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

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

  • Next message: Chris Ditri: "[fw-wiz] Tranparent bridge"