Lagg support in 1.2.1-RC1?



  • Hi all,

    I come from an OpenBSD and pf background and just recently started with pfSense.  So far, I am loving it!
    I am trying to clean up a customer's network but am running into a limitation with the current state of pfSense.

    The customer has two gigE Internet connections in a standard Multi-WAN setup.  During peak tarffic, they are consuming around 1500mbps.  The LAN side of this is just one subnet.  So I can't really split things in to different gigE interfaces.  Ideally, I would like to aggergate two LAN-facing gigE NICs with LACP such that I have this:

    em0:            WAN1
    em1:            WAN2
    lagg0:           LACP(em2,em3)

    I know that at present, I can't use the pfSense GUI to set up a lagg group but can I create this group under FreeBSD and then have pfSesne use this interface?  I have briefly searched through some posts and it would seem that this should be possible, but with some caveats.  I guess what I am wondering is even if this is technically possible or configurable, would you reccommend such a config for a site that has such high traffic?

    Cheers,

    /Jason



  • I would like to know the same thing, I'll wait with interest.

    You will get at least 2 posts telling you "its not supported"



  • Lagg support is in 1.3, I mean 2.0. I did some tests using a failover lagg group. There were initially some bugs, but ermal fixed them very quickly after I reported them.



  • So the tests that you did were with 1.3/2.0?
    Are you saying that I should use pfSense 1.3/2.0 in a multi-WAN, lagg-LAN setup without too much difficulty?
    How stable is it under high traffic?

    Also, I am not wanting a failover group but a link aggregation using LACP.
    I really need the 2 gigabit pipe from that network.

    Cheers,

    /Jason



  • I only did some simple failover testing with a lagg group as the WAN, but the GUI allows you the load-balancing options also. 2.0 is ALPHA, so there could be some rough edges. I would not put it into production without doing a lot of off-hours testing first. Also review the issues on the 2.0 testing board.


Log in to reply