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

Re: Can we kill net-tools, please?



On Thu, 2016-12-29 at 11:38 -0800, Russ Allbery wrote:
> It certainly doesn't provide a man page that doesn't start with a BNF
> syntax description.  The iproute2 documentation is awful.
> 
> Also, this is not at all easy to parse:
>
> # ip -o address
> 1: lo    inet 127.0.0.1/8 scope host lo\ valid_lft foreverpreferred_lft forever

All true.  In particular the documentation produced by kernel's
networking group is a pet hobby horse of mine.  To paraphrase an old
joke - you can't complain about most of it, because it doesn't exist.
[0]

When it comes to parsing they look equally bad once you have used them
for a while.  Worse from my point of view they are both unnecessarily
difficult to scrape in a script.  The "ip" does have one outstanding
attribute though - it is complete.  ifconfig doesn't list multiple ipv4
address (but does list multiple ipv6 addresses - what's up with that?).
 route can't handle multiple routing tables let alone routing rules. 
The equivalent of "ip tunnel" doesn't exist - and it goes on and on. 
net-tools might still be useful for configuring your laptop - but it's
now useless for any serious networking work.

To me this thread looks like a bunch of old men grumbling that the
young'ins have taken over what they created and turned the tools they
were comfortable with into something unrecognisable.  It's true - they
did do that, and it's true it was unnecessary.  They could have just
extended net-tools.  But this is how the young'ins have behaved for
time immemorial - when they take over the reins from the previous
generation and make it their own.  Look on the bright side.  They've
given the kernel's networking stack a large array of new tools that
weren't envisaged when net-tools was conceived - like QoS.


[0] Now I've started, the Linux kernel's networking stack is a mess.
    From the outside it looks like a mob of warning tribes, each 
    developing with their own way of doing the same thing.  To people 
    not familiar with it this will sound like a hyperbolic claim.  So 
    lets consider one simple task: dropping a packet.

    - Did you know the routing table can drop a packet?
      "ip route add w.x.y.z/c blackhole" and
      "ip route add w.x.y.z/c prohibit" and
      "ip route add w.x.y.z/c unreachable" all do that.

    - The traffic control engine can "police" packets.  You can "shot"
      a packet during policing.  (Being Australian, I find this odd,
      but I'm sure US citizens will be comfortable with it).

    - Traffic control engine schedulers can also drop packets, (as well
      as move them like a bridge, create duplicates and a lot of other
      things).

    - Iptables can drop packets.  This how most people do it.

    - The new nftables can drop packets. 
      
    Not only can they drop packets, each has their own way of figuring
    out what packets to drop.  Which means each must pull apart the
    packet to see it it matches, so the same work is being repeated
    over and over again.

    This has real impacts.  One is this spaghetti you see at the API 
    level is reflected underneath, making for one large, complex, hard 
    to understand and consequently fragile lump of code.  Another is 
    the the BSD networking stack is faster than Linux - sometimes near 
    an order of magnitude faster(!)

    http://www.phoronix.com/scan.php?page=article&item=netperf-bsd-linux

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: