[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Can we kill net-tools, please?



 ❦ 30 décembre 2016 18:55 +1000, Russell Stuart <russell-debian@stuart.id.au> :

>> When you need to decide how to route the packet, you need to do a
>> route lookup. If the route entry you find happens to be a blackhole
>> route, you drop the packet. You didn't do any additional work.
>
> I bet the bash authors use that argument when they add another feature.
> In reality all code has a cost.

The only additional cost is the cost to check if the routing entry is a
blackhole (while the check for anything else already exists). Even
FreeBSD supports this feature since a long time.

> Do you remember Van Jacobson's suggestion for speeding up Linux's
> network stack?  (It's mentioned in his Wikipedia page.)  I was lucky
> enough to be at linux.conf.au when he first presented it.  He provided
> working code and some very impressive benchmarks.  It went nowhere
> because of that cost thing - the code doesn't have to be executed in
> order to slow down development.  I think Linux's networking mob pretty
> much gave up after the ipchains to iptables transition.  Now stuff
> doesn't get ripped out and replaced, instead new ideas are bolted onto
> the side - creating a bigger ball of wax that's even harder to move.
> Which is how we got to having the ability to drop packets added in so
> many different places.

The flexibility is also what people like with Linux. Dropping a packet
in Netfilter is not an universal solution. Notably, it implies enabling
the Netfilter hooks (and paying a huge performance penalty). It also
implies dropping the packet after the creation of the skb struct, the IP
handling and (in most cases) the conntrack handling.

This can be far too late in certain cases (like deflecting a DoS
attack), hence the need to be able to drop earlier (even adding filters
directly in the NIC).

Blackhole routing has its own use: advertising in routing protocols and
avoid endless loops when a packet has an unreachable destination (when a
more specific route should have been available).

>> Those benchmarks show huge differences between Linux distributions
>> for a kernel-related task. Like all phoronix benchmarks, it should
>> not be trusted.
>
> Maybe you trust Facebook's opinion instead (it's weird - that wasn't
> easy to write):
>
>    http://www.theinquirer.net/inquirer/news/2359272/f

Yes, I trust them far more as they are good open source
players. However, a job posting is not a benchmark showing an order of
magnitude of difference with FreeBSD.
-- 
Wrinkles should merely indicate where smiles have been.
		-- Mark Twain

Attachment: signature.asc
Description: PGP signature


Reply to: