Firewall for small business with high throughput …



  • What about this setup?

    https://www.supermicro.nl/products/system/1U/5018/SYS-5018D-FN4T.cfm

    I have seen threads about :

    • AES-NI
    • DPDK support (enabled software only)
    • Intel QuickAssist

    Does this setup have support for this? When will the three techonologies be available in pfSense?



  • Actually this is the same product as the XG-1540 in the pfSense store (https://store.pfsense.org/XG-1540/), except the second batch SoC (1541 instead 1540) with a little higher clock.
    There are many threads in this forum talking about AES-NI (supported), DPDK (will be supported in the future), QuickAssist (will be supported in the near future).





  • Does this setup have support for this?

    • AES-NI, yes
    • DPDK, yes, but it must also be finding its way into the CE (Community Edition) version of pfSense
    • QAT, no or only over an external adapter (PCIe) but it must also be finding its way into the CE (Community Edition) version of pfSense

    When will the three techonologies be available in pfSense?

    • AES-NI, is in
      Present in all pfSense versions
    • QAT will be perhaps in the version 2.4 or 3.0 inside
      perhaps not available in the CE version of pfSense
    • DPDK will be perhaps in the version 2.4 or 3.0 inside
      perhaps not available in the CE version of pfSense


  • Any suggestions between the two?

    https://www.supermicro.nl/products/system/1U/5018/SYS-5018D-FN4T.cfm

    • Power
    • 10 Gbit
    • CPU Mhz

    http://www.supermicro.nl/products/system/1U/5019/SYS-5019S-L.cfm (Intel® Xeon® processor E3-1200 v5)

    • CPU MHz
    • Power
      ...

    Or are they equally good? Is there something between the two that would affect latency much to choose one over the other? Are there any other considerations?



  • @Sealr0x:

    Any suggestions between the two?

    https://www.supermicro.nl/products/system/1U/5018/SYS-5018D-FN4T.cfm

    • Power
    • 10 Gbit
    • CPU Mhz

    http://www.supermicro.nl/products/system/1U/5019/SYS-5019S-L.cfm (Intel® Xeon® processor E3-1200 v5)

    • CPU MHz
    • Power
      ...

    Or are they equally good? Is there something between the two that would affect latency much to choose one over the other? Are there any other considerations?

    The E3 line has more raw power, but note that the chassis limits to 45W without additional cooling. (There are plenty of low-power E3 CPUs, just something to be aware of.) If you think you might at some point in the near future go 10G, the D1541 is attractive and probably cheaper. (But even if you are, a lot of people use 10G fiber rather than copper, so that might not be the best motherboard choice.) Both have a card slot so you can throw in whatever 10G or multiport adapter you might need in the future. If you are considering VPN, the E3 will be significantly faster than the D1541 between the clock speed and the improved skylake AES performance. For just plain firewalling it's a wash between the two, they'll both do 1G without breaking a sweat.



  • Interesting that AES performance is much better on E3 than D1541, I didn't know that. Thanx for a really good answer!

    I'm also planning to run Snort, Squid + Antivirus (calmd), SquidGuard, pfBLockerNG+DNSBL ntopng  and eventually some more packages @ RAM 16 GB.

    No problem to still get >1Gb or more throughput?

    BlueKobold? Your opinion on the above?



  • Interesting that AES performance is much better on E3 than D1541, I didn't know that. Thanx for a really good answer!

    But with 8 Core and 16 Threads and with a viewing eye to upcoming pfSense version it
    might be better if the raw power against CPU core will be changing at any day, because
    the version 3.0 will be written totally new, as I am informed, so it might be better to get
    many core then only the pure CPU power as today. And if also packets will be more and
    more multi-core threaded it can be a really hit for the entire system to get more core and
    threads.

    I'm also planning to run Snort, Squid + Antivirus (calmd), SquidGuard, pfBLockerNG+DNSBL ntopng  and eventually some more packages @ RAM 16 GB.

    Better to take 8 GB but DDR4-2400 ECC RAM that might be faster as I see it right.

    No problem to still get >1Gb or more throughput?

    This might be not a real problem in my eyes.

    BlueKobold? Your opinion on the above?

    Well not so easy to answer, but it depends more on the real goal that must be archived by you!

    • If you want to drive heavy VPN tunnels with the optimum on throughput I will consider to the
      Intel Xeon E3-12xxv3 also pending on his more horse power, Intel QAT can be easily inserted
      by buying a QAT Card from ADI or Netgate if really needed, to pimp that appliance, but DPDK
      is not really able to insert and also only 4 CPU Cores are available in that set up.
    • The Xeon D-15xx platform is serving 8 CPU cores ands with a look forward
      to the many or more installed packets could be more a gain and the DPDK
      feature will be also available and likes above together with a QAT adapter
      it can be pimped or tuned up. And together with faster RAM (DDR4-2400)
      and the ability to insert a M.2 SSD would be rounding it up more then the
      Intel E3 solution, also the two 10 GbE Ports might be a better way to
      connect servers and/or NAS devices to that or perhaps 10 GBit/s capable
      switches for the LAN and DMZ would be more hitting my personal interests
      as given by the other solution! All in all if the main concern is not on VPN
      I would go with the Intel Xeon D-15xx board!!!!


  • @BlueKobold:

    Interesting that AES performance is much better on E3 than D1541, I didn't know that. Thanx for a really good answer!

    But with 8 Core and 16 Threads and with a viewing eye to upcoming pfSense version it
    might be better if the raw power against CPU core will be changing at any day, because
    the version 3.0 will be written totally new, as I am informed, so it might be better to get
    many core then only the pure CPU power as today. And if also packets will be more and
    more multi-core threaded it can be a really hit for the entire system to get more core and
    threads.

    Nobody ever won betting more slower processors against fewer faster processors for this sort of application. Efficiently parallelizing is hard, and introduces overhead. Compare, for example, E3-1260Lv5 to D1541. Both are 45W parts, the first runs at 2.9GHz and turbos to 3.9, the second runs at 2.10GHz and turbos to 2.7GHz. The first has 4 cores, the second has 8 cores. It's going to be a lot easier to keep the utilization high on the E3 than the D. And the E3 gets the architectural improvements that came with skylake, which make a noticeable difference with crypto workloads. I actually find the smaller Ds more attractive than the higher count parts, but intel has priced them too high (probably to keep from undercutting the xeon E series). So while a 2 or 4 core D would be perfect from a specification standpoint, they're just not cost effective when the E series is a couple of bucks more and a newer microarchitecture. That said, for 10G applications a D1518 should be noticeably cheaper than a E3-1260Lv5 plus a good 10G card, and that would make that platform a no-brainer. Maybe some future advancement will make the D1541 a better choice, but I'd personally pick the thing that's faster now and which probably will be faster in the future. For this workload. For something like in-memory databases the Ds will go to 128G and have a ton of threads available to your java vms, but that's not relevant here. If you need 10G now, a D might be cheaper, then it makes sense because both of these are fine choices. Otherwise, the cheaper/better solution is the E, and if down the road there's a need for 10G it'll be cheaper to buy a card than it is today. Or you'll throw this whole system out and buy something better and cheaper in a few years. The first rule of computers is "don't buy something you don't need today because you think it might be useful tomorrow". The stories I could tell…


  • LAYER 8 Moderator

    • The Xeon D-15xx platform is serving 8 CPU cores ands with a look forward

    Please notice that the Xeon-D platform isn't 8 cores only. The 1518 only has 4 cores whereas the 1587 comes along with 16(!) cores.

    That said, for 10G applications a D1518 should be noticeably cheaper than a E3-1260Lv5 plus a good 10G card, and that would make that platform a no-brainer. Maybe some future advancement will make the D1541 a better choice, but I'd personally pick the thing that's faster now and which probably will be faster in the future.

    I agree with VAMike. We had that same discussion a few months ago for our datacenter front firewalls. We got 3 D-1518s as the NIC setup is really great on those devices! 6 1Gbps ports AND 2 SFP+ is a rare catch and a real cost saver. Also we did the math if we'd really hit a limit with this device, the 154x or 158x would probably be equally limited as well, as there isn't THAT much difference between the max GHz on those devices and more cores might even get you near to nothing depending on your workload. So if the Xeon-D is showing to be too low, we'd have to step up bigger anyway :)

    Another point to be taken into consideration is, that most often firewalls are running 3 or more years so the hardware should be supported. The Atom C2xxx and Xeon-Ds are mentioned as communication/embedded SOCs from Intel with a far longer support timeline as conventional Intel Core processors. So that may play into your buying habit, too.

    That said, even as we don't actually try to saturate the 10G links, we use the 10G SFP+ Ports on the units as a VLAN Trunk for multiple project VLANs and the 1G lines for multiple WANs, MGMT net etc. So far working great. WebUI could be a bit more responsive - the old Xeon E5 bigwigs we had before were way faster displaying the GUI and PHP. But that's not surprising as those were Xeons with 3,4GHz core speed. Compared with the 2,2GHz on the Xeon-Ds that different is noticable. But as pfSense progresses, hopefully there'll be API functionality so the UI can run separate from the firewall :) And then we'll perhaps see a nice CLI as well (one can dream) :D



  • Thank you for all the great answers! I will contemplate this and make a decision.


Log in to reply