On Tue, Mar 28, 2017 at 11:32 AM, compdoc <[email protected]> wrote:
> On 03/28/2017 08:41 AM, WebDawg wrote: > > It seems to me that NAT and general firewalls should be easily handled? Am >> I wrong here? I mean, how much hardware do you need for pf to function at >> 1gbps?? Would not offloading help here too? >> > > Ive run tests on AMD and Intel cpus that I happened to have in stock using > BSDRP. This is simple, router only software based on BSD. It has no > services running, (nat, snort, ect) so no overhead to slow it down. > > To get the full bandwidth of gig ethernet required using Intel nics. I > also found that sending or receiving full gigabit was easy even for > low-power cpus. But routing it, meaning in one port and out another, > required a more powerful cpu. > > Of the cpus I had to test, only an Intel i5-2400 (sandy bridge) and a > newer model AMD APU could keep up. All these tests were using standard > x86_64 desktop hardware. No server-based parts were needed. We're currently building a pair boxes with a i7-6850x on a X-99 motherboard with 40G NICs to test the 'new' stuff. Stay tuned. ;-) (Is that 'desktop' enough for you?) These are really to demo for my talk in May: https://conferences.oreilly.com/oscon/oscon-tx/public/schedule/detail/56727 However, I think that router-boards can route full Gig ethernet without > such powerful cpus. Even cheap gigabit network switches can pump gig > ethernet in one port and out another, at full speed. I'm not sure how > router-boards and network switches do this. Im guessing its done using > specialized hardware. > That's some of it. More of it is that "cheap gigabit network switches" only base forwarding decisions on the layer 2 destination address. A router has to do a lot more work. For example: A router much check for minimum length and correct checksum on any input packet. It must decrement the TTL in the IP packet, and, if it's not 0, update the checksum and forward the packet. This may involve discovering a layer 2 address and outbound interface. It also has to look at the layer 3 (IPv4/IPv6) destination, the router must determine the best (longest) match route. It may use a 'default' route if no 'best' route is found. Cheap routing silicon is available. The Ubiquiti Edge Router series uses a small Cavium SoC. There are others (these days mostly ARM based). The problem with cheap routing silicon is that it either doesn't implement, or constrains what you can do for other services typically associated with a firewall. Packet filtering (especially beyond simple, stateless ACLs) is typically not implemented on inexpensive SoCs. Some SoCs have a "NAT offload" function, but it isn't as sophisticated as what you'll find in 'pf'. On the other side of the penny, you can thrown almost any amount of CPU at traditional kernel networking, and you're not going to see the performance of a traditional hardware router. All the stacks (FreeBSD, Linux, other BSDs, Windows) are optimized for delivering packets to an application, not forwarding packets. They've all been designed as "packet at a time", and some of the stacks, e.g. FreeBSD's are overly locked. The lessons of technologies such as netmap are clear. You don't process packet-at-a-time if you want performance. Too much stop-n-go. Too much thrash on (especially) the instruction cache. Our 'netmap-fwd' codebase shows the limit of that approach (albeit with kernel-bypass). None of the urls or examples posted in this thread so far address the > actual throughput of the equipment being used, so dont assume everything > suggested will work at the speed you want. First you have to decide what you're going to measure, and how. I claim that a simple "fill the pipe with large packets" test is useless to understand the performance of the system. All the work is on a per-packet rather than per byte basis, unless you don't have DMA or are doing some type of DPI. Jim _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
