📜 ⬆️ ⬇️

Hard parting with Net-Tools

It's no secret that it's time for Net-Tools to honor its resignation. Yes, many admins and me, including, are familiar with ifconfig , route , netstat commands before Pavlov’s conditioned reflex. At first glance, there is no reason to change something, but the best is as always the enemy of the good.




Let's find out why Net-Tools no longer the same and how to switch to iproute2 painlessly from it.


What is wrong with ifconfig?


What are the complaints about Net-Tools and how justified are they?



 root ~ $ ifconfig dummy0:1 1.2.3.4 up root ~ $ ifconfig dummy0 dummy0 Link encap:Ethernet HWaddr FE:50:31:E6:14:17 BROADCAST NOARP MTU:1500 Metric:1 [...] 


 ip addr add 192.168.1.2/24 brd + dev eth0 


 root ~ $ ifconfig tun0 root ~ $ tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.0.254.6 PtP:10.0.254.5 Mask:255.255.255.255 


 root ~ $ ip addr add 192.168.13.37/32 peer 192.168.13.38 dev eth0 root ~ $ ifconfig eth0 192.168.13.37 


 Icmp: 3327 ICMP messages received 17 input ICMP message failed ICMP input histogram: destination unreachable: 3151 timeout in transit: 56 


CategoryNetstatNstatDifference
Ip617+11
Ip61432+18
Icmp629+23
Icmp62546+21
Tcptenten0
Udp7eight+1
Udp6foureight+4
UdpLite015+15
UdpLite607+7
TcpExt48116+68
IpExteleven17+6

All of these shortcomings are due to the fact that the project did not develop too long - the last release was in 2011, and the core and network stack went far ahead during this time. To be fair, it should be noted that recently the work on the project has resumed, but this is unlikely to lead to significant changes in the code base.


Retraining to iproute2


With iproute2 you can get everything the same as with Net-Tools and even more, but only the syntax and output of commands to the terminal will be different. To be honest, the readability of some ip commands suggests that the new is not always the best .





The following two commands are designed to replace ifconfig without additional keys.


 (5:520)$ ip -c link 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff 

With the -c output will be colored and more readable.


 (5:521)$ ip -c addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/24 brd 192.0.2.255 scope global eth0 

View the routing table briefly.


 (5:522)$ ip ro 

The entire routing table.


 (5:523)$ ip ro list table all broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 local 10.0.0.1 dev eth0 proto kernel scope host src 10.0.0.1 broadcast 10.0.0.0 dev eth0 proto kernel scope link src 10.0.0.1 local 212.64.94.251 dev ppp0 proto kernel scope host src 212.64.94.251 broadcast 10.255.255.255 dev eth0 proto kernel scope link src 10.0.0.1 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local ::1 dev lo proto none metric 0 pref medium local fe80::5166:f6f:fea2:29f dev lo proto none metric 0 pref medium local fe80::fa61:45ff:f1e0:109e dev lo proto none metric 0 pref medium local fe80::f5c4:ff:efbf:0455 dev lo proto none metric 0 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev ppp0 proto kernel metric 256 linkdown pref medium ff00::/8 dev eth0 metric 256 pref medium ff00::/8 dev ppp0 metric 256 linkdown pref medium ff00::/8 dev lo metric 256 pref medium 

Note that the output of commands from the iproute2 set is often not trivial to parse in the script. This does not add to the popularity of maintainers who are trying to throw Net-Tools out of the distribution.


View the physical addresses of neighbors from the ARP cache. For clarity, the options with Net-Tools and iproute2 we write next.


 (5:524)$ arp -a (5:525)$ ip neigh show 

We now turn to the settings . Raise the interface.


 (5:501)$ ifconfig eth0 up (5:502)$ ip link set eth0 up 

Turn off the interface.


 (5:503)$ ifconfig eth0 down (5:504)$ ip link set eth0 down 

Set the IP address.


 (5:504)$ ifconfig eth0 192.168.0.77 netmask 255.255.255.0 broadcast 192.168.0.255 (5:505)$ ip addr add 192.168.0.77/24 broadcast 192.168.0.255 dev eth0 

Unlike Net-Tools , iproute2 also allows you to delete an IP address.


 (5:506)$ ip addr del 192.168.0.77/24 dev eth0 

Add secondary address.


 (5:507)$ ifconfig eth0:1 10.0.0.1/8 (5:508)$ ip addr add 10.0.0.1/8 dev eth0 label eth0:1 

Add a route.


 (5:509)$ route add -net 192.168.4.0/24 dev eth2 (5:510)$ ip route add 192.168.4.0/24 dev eth2 

And delete it the same.


 (5:511)$ route del -net 192.168.4.0/24 dev eth2 (5:512)$ ip route del 192.168.4.0/24 dev eth2 

Add a default route (aka gateway).


 (5:513)$ route add default gw 192.0.2.1 (5:514)$ ip route add default via 192.0.2.1 

We reviewed only the basic monitoring and configuration commands, a little less than the full list of iproute2 commands by reference .


Nstat instead of netstat


Nstat, in contrast to its older counterpart, issues only SNMP metrics in a strictly defined order and outputs them all.


 (5:526)$ nstat -a #kernel IpInReceives 69783 0.0 IpInDelivers 69469 0.0 IpOutRequests 68643 0.0 ... 

Another difference is that netstat shows the cumulative value of metrics from the moment the OS starts, while nstat defaults to a delta of values ​​and therefore the first time you run both commands, the values ​​will be the same. In order for nstat to nstat as usual, you need to run it with the -s .


 (5:527)$ nstat -sa #  

With the --zero we only get zero values.


 (5:528)$ nstat --zero #kernel IpInReceives 0 0.0 IpInHdrErrors 0 0.0 IpInAddrErrors 2 0.0 IpForwDatagrams 0 0.0 IpInUnknownProtos 0 0.0 IpInDiscards 0 0.0 (...) 

I don’t know whether this is good or bad, but nstat can still produce results in json format.


 (5:528)$ nstat --json {"kernel":{"TcpInSegs":2,"TcpOutSegs":4,"Ip6InReceives":2,"Ip6InDelivers":2,"Ip6OutRequests":4,"Ip6InOctets":776,"Ip6OutOctets":770,"Ip6InNoECTPkts":2,"TcpExtTCPHPHits":1,"TcpExtTCPHPAcks":1,"TcpExtTCPOrigDataSent":2}} 

Ss instead of netstat


The ss command overlaps the functionality of Netstat , in terms of displaying information about network connections, makes it faster and digs deeper. While netstat climbs into /proc behind every sneeze and loses pace, ss via Netlink interface quickly downloads information from the kernel.


 (5:529)$ sudo ss --summary Total: 348 (kernel 352) TCP: 15 (estab 9, closed 1, orphaned 0, synrecv 0, timewait 1/0), ports 0 Transport Total IP IPv6 * 352 - - RAW 1 0 1 UDP 3 3 0 TCP 14 12 2 INET 18 15 3 FRAG 0 0 0 

It is gratifying that the syntax of both teams is similar, so it will not take long to get used to.


 (5:530)$ ss -t State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 0 192.168.1.2:43839 108.160.162.37:http ESTAB 0 0 192.168.1.2:43622 199.59.149.201:https ESTAB 0 0 192.168.1.2:33141 83.170.73.249:ircd ESTAB 0 0 192.168.1.2:54028 74.125.135.125:xmpp-client 

However, ss allows you to literally climb under the hood tcp connections.


 (5:531)$ sudo ss --tcp --info |tail -n 1 cubic wscale:4,7 rto:280 rtt:71.541/13.487 ato:40 mss:1460 cwnd:100 bytes_acked:465157 bytes_received:513194 segs_out:604 segs_in:937 send 16.3Mbps lastsnd:86100 lastrcv:85680 lastack:5050 pacing_rate 32.7Mbps rcv_rtt:12120 rcv_space:186376 

It has it all: delivery confirmation timers, round-trip road, cubic channel overload control mechanism and much more.


Push around Net-Tools


There is no consensus on this issue in the Linux community yet. In OpenSuse in 2009 plenum was held a discussion ensued on this issue, but they did not go for tough measures, but RedHat and Fedora decided in 2011 that they had had enough , and since the 7th version, RHEL did not install Net-Tools . In 7.1 there was an unsuccessful attempt to return it, which shows the inescapable popularity of Net-Tools . In Debian Linux, after an unsuccessful attempt in 2009 to declare Net-Tools obsolete and begin the process of replacing it, they did not recall this for several years, and recently the dispute resumed with a new force. The fact is that in Debian there is still a significant amount of packages dependent on it. In Gentoo, as always, you decide whether to install or not, but there are no dependencies on the subject.


 (5:532)$ equery depends net-tools * These packages depend on net-tools: net-misc/openvpn-2.3.12 (!iproute2 ? sys-apps/net-tools) 

It seems to me personally that for the time being there is no reason to refuse Net-Tools where it is possible. If you have two and a half network interfaces on a local host, including a loopback, you can safely continue to use these programs, but on a decent combat or even on a test server, iproute2 will still be preferable, no matter how hard your fingers twitch your old teams. Sooner or later, all Linux distributions and even Debian will stop installing this package by default, and then knowledge of the commands from the iproute2 set will be quite useful, although this moment may not come soon.


Used materials



')

Source: https://habr.com/ru/post/320278/


All Articles