"Cat / proc / net / dev" y "ip -s link" muestran estadísticas diferentes. ¿Cuál miente?

8

Noto que /proc/net/devdice eth3 tiene 1753 drops. ip -s linkmuestra 0 dropped. ¿Por qué hay una diferencia? ¿De dónde provienen los diferentes datos? ¿Cuál es el correcto?

He eliminado los datos adicionales.

# uname -a
Linux example09 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux

# lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.4 (squeeze)
Release:        6.0.4
Codename:       squeeze

# cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth3:1258629839430 12545003042    0 1753    0     0          0  10594858 6666255952912 10026428444    0    0    0     0       0          0

# ip -s link
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:15:17:96:0b:61 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    244248462  3955476484 0       0       0       10595400
    TX: bytes  packets  errors  dropped carrier collsns
    683632524  1436809416 0       0       0       0
linux networking ip ablackhat
fuente
Igual que aquí. Parece un rollover de enteros de 32 bits en los programas de espacio de usuario ( ifconfighace lo mismo aquí) pero, según bc, no 1258629839430%(2^32)es 204421702244248462, así que no estoy seguro de que sea eso (a menos que haya ejecutado ip~
40 MB
@DerfK Sí, aproximadamente 40 MB suena bien. Fueron solo unos segundos, pero es un servidor ocupado.
ablackhat

Respuestas:

11

En una máquina Squeeze, confíe /proc/net/dev. Es una forma más directa y confiable de ver los mismos datos.

Para el caso particular del recuento eliminado, no puedo explicar el problema exacto, pero puedo observarlo en otros cuadros de Squeeze. Si me importara, lo reportaría como un error a Debian (y sugeriría que alguien lo haga e informe aquí).

Ambos toman el número del tx_droppedcampo de net_device_stats. En /proc/net/dev, la línea es generada por dev_seq_printf_statsdesde net/core/dev.c.

ipva, como de costumbre, a través de netlink, y más precisamente para estadísticas de dispositivos de red, rtnetlink. La estructura pasó al espacio de usuario, rtnl_link_stats.

La estructura nativa usa unsigned longs, rtnetlinkusa __u32, se realiza una conversión más o menos implícita copy_rtnl_link_stats.

Es bastante fácil detectar que la versión de 32 bits se está utilizando desde el comienzo de la estructura, rx_packets: mientras /proc/net/devmuestra 1258629839430, ipmuestra 244248462, que corresponde aproximadamente a los últimos 32 bits (más algunos bytes más entre comandos); Lo mismo con el recuento de paquetes.

Aquí está el número de crujidos para esos 2 primeros campos:

% echo '1258629839430 % (2^32)'|bc; echo 244248462
204421702
244248462
% echo '12545003042 % (2^32)'|bc; echo 3955476484 
3955068450
3955476484

Las cosas mejoraron con la introducción de IFLA_STATS64:

  • en el núcleo (de commit 10708f37ae729baba9b67bd134c3720709d4ae62, disponible en sentido ascendente en v2.6.35 y posterior)
  • en iproute2 (desde commit 8864ac9dc5bd5ce049280337deb21191673a02d0, disponible en sentido ascendente en v2.6.33-36 y posterior).
Pierre Carrier
fuente
Genial, esto es exactamente lo que estaba buscando.
ablackhat
-2

En la mayoría de los dispositivos, / proc / net / dev se lee desde los contadores de hardware. Otras estadísticas se actualizan desde la pila de red en las estructuras del dispositivo.

Es más probable que las caídas no coincidan, ya que pueden ser hechas por el hardware: el destino del paquete mac no es ni del dispositivo ni de multidifusión, y el dispositivo no es promiscuo: el hardware descarta directamente el paquete, la pila nunca sabrá que existió.

Finalmente, puede que se pregunte por qué no sincronizarlos o siempre usar estadísticas de hardware. Cuando la pila descarta un paquete por cualquier motivo, no puede actualizar el contador de hardware, y para la depuración es útil saber que puede encontrar cada uno para rastrear dónde se cayó el paquete.

Espero que esto ayude

blanqueador
fuente