On 7/22/15 10:27 PM, David Ranch wrote:
Linux's ipfwadm and ipchains were stateless "packet filters" but iptables has been fully stateful for many many years. We are now at the cusp of nftables on Linux which makes things even more programmable though I don't know about the performance.
My mistake. It's been years since I was actively comparing the different fire-walling methods in use by Linux. I went hardware for years and only within the last few years went to software, when I went OpenBSD due to native IPsec support as well as pf.
Filtering at a router is a sure fire way to bring throughput to a crawl. Proper campus routers are designed with ASICs optimized for routing in hardware, and fire-walling is done in software.
Modern ASIC based firewalls can handle 100,000s of stateless filters on a per interface basis.
Note I said 'router', not 'firewall'. Routers are designed from the silicon up to forward packets, reduce broadcast domains and connect networks. Firewalls are designed from the silicon up to restrict the flow of packets. Yes firewalls will forward packets from one network to another, but their primary purpose is inspection and restriction.
I have seen enterprise small office routers handle 450~500mbps of straight routing but max out around 40mbps when fire-walling because it's CPU bound. The results are similar when stepping up to large chassis routers.
It depends on the class of devices you're buying. There are many inexpensive Enterprise grade firewalls (always stateful) that can run many 100s of Megabit and a few thousand dollars will get you into the 10G+ range.
Again, please note that I said 'router', not 'firewall'. As to the type of router I was referring to in that specific example was a Cisco enterprise branch router. Campus and data center grade routers do minimal traffic filtering if any due to the CPU hit they incur, hence why large hardware firewalls exist. Proper tool for the job.
Yeah.. but we don't need that throughput or scale.
The current configuration was choking, hence the discussion. Brian has worked with CAIDA and resolved the congestion for now.
Just statelessly filtering at the border edge with a modern router would solve much of these issues.
Please note that router and firewall are not the same thing. They can do the same job, but not as effectively as the device purpose built for the job. Also Brian already stated:
The port 'em0' is connected to a 1G switch which is in turn connected at 10GbE to the building infrastructure switch/router.
and
to do so requires administrative access to the campus border router that we don't have.
Fire-walling is done at the AMPR edge, but traffic was overwhelming the current configuration. Moving filtering to the provider router is technologically improper and operationally restricted, hence my suggestion to split filtering and tunneling onto separate machines to increase capacity.
The suggestion Tom made of running an IGP to selectively advertise only subnets which have valid destinations via the tunnels would also restrict the amount of traffic that will ultimately be blocked from reaching the firewall. This type of routing combined with a large null route is a common practice in large enterprise networks. Reducing the amount of traffic that is going to get blocked from reaching the AMPR edge will help system load but won't help with the timeouts due to slow [or down] tunnel peers.
As this thread has demonstrated, there are a few different ways to increase capacity of the AMPR gateway. While it may not be necessary at this time, it's still useful information to have for whoever is going to be responding next time there is an issue. -- Will