lkml.org 
[lkml]   [2003]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ANNOUNCE] nf-hipac v0.8 released
    Hi,

    Thanks for your clarification. We've also conducted some tests with
    bridging firewall functionality, and we're very pleased with nf-hipac's
    performance! Results below.

    In the measurements, tests were run through a bridging Linux firewall,
    with a netperf UDP stream of 1450 byte packets (launched from a different
    computer connected with gigabit ethernet), with a varying amount of
    filtering rules checks for each packet.

    I don't have the specs of the Linux PC hardware handy, but I recall
    they're *very* highend dual-P4's, like 2.4Ghz, very fast PCI bus, etc.
    Shouldn't be a factor here.

    1. Filtering based on source address only, for example:
    $fwcmd -A $MAIN -p udp -s 10.0.0.1 -j DROP
    ...
    $fwcmd -A $MAIN -p udp -s 10.0.3.255 -j DROP
    $fwcmd -A $MAIN -p udp -j ACCEPT

    Results:
    rules | plain NF | NF-HIPAC
    | sent | got thru | sent | got thru |
    (n.o) | (Mbit/s) | (Mbit/s) | (Mbit/s) | (Mbit/s) |
    -------------------------------------------------------------
    0 | 956,00 | 953,24 | 956,00 | 953,24 |
    512 | 956,00 | 800,68 | 956,46 | 952,81 |
    1024 | 956,00 | 472,78 | 956,46 | 952,81 |
    2048 | 955,99 | 170,52 | 956,46 | 952,86 |
    3072 | 956,00 | 51,97 | 956,46 | 952,85 |

    2. Filtering based on UDP protocol's source port, for example:
    $fwcmd -A $MAIN -p udp --source-port 1 -j DROP
    ...
    $fwcmd -A $MAIN -p udp --source-port 1024 -j DROP
    $fwcmd -A $MAIN -p udp -j ACCEPT

    Results:
    rules | plain NF | NF-HIPAC
    | sent | got thru | sent | got thru |
    (n.o) | (Mbit/s) | (Mbit/s) | (Mbit/s) | (Mbit/s) |
    -------------------------------------------------------------
    0 | 955,37 | 954,33 | 956,46 | 952,85 |
    512 | 980,68 | 261,41 | 956,46 | 951,92 |
    1024 | N/A | N/A | 956,47 | 952,86 |
    2048 | N/A | N/A | 956,46 | 952,85 |
    3072 | N/A | N/A | 956,46 | 952,85 |

    N/A = Netfilter bridging can't handle this at all, no traffic can pass the
    bridge.

    So, plain Netfilter can tolerate about a couple of hundred rules
    checking for addresses and/or ports on a gigabit line.

    With HIPAC Netfilter, packet loss is very low, less than 0.5%, even with the
    maximum number (of tested) rules, the same amount as without filtering at
    all.


    On Sun, 29 Jun 2003, Michael Bellion and Thomas Heinz wrote:
    > You wrote:
    > >>We are going to test the stuff tomorrow on an i386 and tell you
    > >>the results afterwards.
    >
    > Well, nf-hipac works fine together with the ebtables patch for 2.4.21
    > on an i386 machine. We expect it to work with other patches too.
    >
    > >>In principle, nf-hipac should work properly whith the bridge patch.
    > >>We expect it to work just like iptables apart from the fact that
    > >>you cannot match on bridge ports.
    >
    > Well, this statement holds for the native nf-hipac in/out interface
    > match but of course you can match on bridge ports with nf-hipac
    > using the iptables physdev match. So everything should be fine :)
    >
    > > One obvious thing that's missing in your performance and Roberto's figures
    > > is what *exactly* are the non-matching rules. Ie. do they only match IP
    > > address, a TCP port, or what? (TCP port matching is about a degree of
    > > complexity more expensive with iptables, I recall.)
    >
    > [answered in private e-mail]
    >
    >
    > Regards,
    >
    > +-----------------------+----------------------+
    > | Michael Bellion | Thomas Heinz |
    > | <mbellion@hipac.org> | <creatix@hipac.org> |
    > +-----------------------+----------------------+
    >
    >

    --
    Pekka Savola "You each name yourselves king, yet the
    Netcore Oy kingdom bleeds."
    Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:46    [W:0.023 / U:0.260 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site