22 Jul
2015
22 Jul
'15
2:40 p.m.
On Wed, Jul 22, 2015 at 12:05 PM, Will Gwin <N5KH(a)n5kh.org> wrote:
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. 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.
Recall that the original suggestion was to null route unused subnets.
This is a routing operation, not a filtering operation. The ASICs
should handle it fine.
Better logic would be to use an IGP to only advertise valid subnets.
This way traffic without a destination would be dropped at UCSD's edge
(or wherever the IGP reached). Brian mentioned that administrative
access to the campus border router would be required--this isn't
completely true. To be effective, the IGP would only have to reach
beyond the bottleneck (in this case, put it right in front of amprgw
instead of all the way back at the border). If you request traffic for
44/8, you're going to get all of it. If you only request traffic for a
few subnets, that'll be a lot less data to send through your filter
rules.
Tom KD7LXL
3. I liked Tom Hayward's idea to automatically
filter netblocks
that aren't activated in the portal / DNS. That seems like a very
cheap way to knock out known bogus traffic. Ideally this would be
done at the farthest edge of the network to prevent the traffic from
ever even reaching the Dell server.
It's a good idea but unfortunately impractical; to do so requires
administrative access to the campus border router that we don't have.