23 Jul
2015
23 Jul
'15
12:43 a.m.
On 7/22/15 10:27 PM, David Ranch wrote:
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.
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.
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. 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. 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