En algún momento, en algunos materiales de enseñanza (de Linux Foundation) sobre Linux que encontré, se menciona lo siguiente:
ipEl comando es más versátil y más eficiente queifconfigporque usa sockets netlink en lugar de llamadas al sistema ioctl .
¿Alguien puede dar más detalles sobre esto porque no puedo entender lo que sucede debajo del capó?
PD: Conozco este tema sobre esas herramientas, pero no aborda esta diferencia específica sobre cómo funcionan
Respuestas:
El ifconfigcomando en sistemas operativos como FreeBSD y OpenBSD se actualizó en línea con el resto del sistema operativo. Hoy en día puede configurar todo tipo de configuraciones de interfaz de red en esos sistemas operativos y manejar una variedad de protocolos de red. Los BSD proporcionan ioctl()soporte para estas cosas.
Esto no sucedió en el mundo de Linux. Hay, hoy, tres ifconfigcomandos:
ifconfigde GNU inetutilsjdebp% inetutils-ifconfig -l
enp14s0 enp15s0 lo
jdebp% inetutils-ifconfig lo
lo Link encap: Loopback local
inet addr: 127.0.0.1 Bcast: 0.0.0.0 Máscara: 255.0.0.0
UP LOOPBACK MTU EN EJECUCIÓN: 65536 Métrica: 1
Paquetes RX: 9087 errores: 0 descartados: 0 desbordamientos: 0 trama: 0
Paquetes TX: 9087 errores: 0 descartados: 0 desbordamientos: 0 operador: 0
colisiones: 0 txqueuelen: 1000
RX bytes: 51214341 TX bytes: 51214341
jdebp%
ifconfigde NET-3 net-tools jdebp% ifconfig -l
ifconfig: la opción --help 'proporciona información de uso.-l' not recognised.
ifconfig:
jdebp% ifconfig lo
lo: flags = 73 <ARRIBA, LOOPBACK, RUNNING> mtu 65536
inet 127.0.0.1 máscara de red 255.0.0.0
inet6 :: 1 prefixlen 128 scopeid 0x10 <host>
inet6 :: 2 prefixlen 128 scopeid 0x80 <compat, global>
inet6 fe80 :: prefixlen 10 scopeid 0x20 <enlace>
loop txqueuelen 1000 (Loopback local)
Paquetes RX 9087 bytes 51214341 (48.8 MiB)
Errores RX 0 caídos 0 desbordamientos 0 fotograma 0
Paquetes TX 9087 bytes 51214341 (48.8 MiB)
Errores de TX 0 descartados 0 desbordamientos 0 transportista 0 colisiones 0
jdebp%
ifconfigde (versión 1.40 de) el conjunto de herramientas nosh jdebp% ifconfig -l
enp14s0 enp15s0 lo
jdebp% ifconfig lo
lo
enlace loopback corriendo
dirección de enlace 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00
dirección inet4 127.0.0.1 prefijo 8 bdaddr 127.0.0.1
dirección inet4 127.53.0.1 prefijo 8 bdaddr 127.255.255.255
dirección inet6 :: 2 alcance 0 prefijo 128
dirección inet6 fe80 :: alcance 1 prefijo 10
dirección inet6 :: 1 alcance 0 prefijo 128
jdebp% sudo ifconfig lo inet4 127.1.0.2 alias
jdebp% sudo ifconfig lo inet6 :: 3/128 alias
jdebp% ifconfig lo
lo
enlace loopback corriendo
dirección de enlace 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00
dirección inet4 127.0.0.1 prefijo 8 bdaddr 127.0.0.1
dirección inet4 127.1.0.2 prefijo 32 bdaddr 127.1.0.2
dirección inet4 127.53.0.1 prefijo 8 bdaddr 127.255.255.255
dirección inet6 :: 3 alcance 0 prefijo 128
dirección inet6 :: 2 alcance 0 prefijo 128
dirección inet6 fe80 :: alcance 1 prefijo 10
dirección inet6 :: 1 alcance 0 prefijo 128
jdebp% Como puede ver, los inetutils de GNU y las herramientas de red NET-3 ifconfigtienen algunas deficiencias marcadas, con respecto a IPv6, con respecto a las interfaces que tienen múltiples direcciones, y con respecto a funcionalidades similares -l.
El problema de IPv6 es, en parte, algún código faltante en las herramientas mismas. Pero, en general, se debe al hecho de que Linux no proporciona (como lo hacen otros sistemas operativos) la funcionalidad IPv6 a través de la ioctl()interfaz. Solo permite que los programas vean y manipulen direcciones IPv4 a través de las redes ioctl().
En cambio, Linux proporciona esta funcionalidad a través de una interfaz diferente send()y recv()en una familia de sockets de direcciones especial y algo extraña AF_NETLINK.
Los GNU y NET-3 ifconfigs podrían se han ajustado para utilizar esta nueva API. El argumento en contra de hacerlo fue que no era portátil para otros sistemas operativos, pero estos programas en la práctica ya no eran portátiles de todos modos, por lo que no era un gran argumento.
Pero no fueron ajustados, y permanecen como se mencionó hasta el día de hoy. (Algunas personas trabajaron en ellos en varios puntos a lo largo de los años, pero las mejoras, por desgracia , nunca llegaron a los programas. Por ejemplo: Bernd Eckenfels nunca aceptó un parche que agregara alguna capacidad de API de enlace de red a las herramientas de red NET-3 ifconfig, 4 años después de que se haya escrito el parche).
En cambio, algunas personas reinventaron completamente el conjunto de herramientas como un ipcomando, que usaba la nueva API de Linux, tenía una sintaxis diferente y combinaba varias otras funciones detrás de una interfaz de estilo moderno .command subcommand
Necesitaba una ifconfigque tuviera la sintaxis de línea de comandos y el estilo de salida de FreeBSD ifconfig(que ni el GNU ni el NET-3 ifconfigtienen, y que ipciertamente no tiene). Entonces escribí uno. Como prueba de que uno podría escribir un ifconfigque usa la API de netlink en Linux, lo hace.
Entonces, la sabiduría recibida sobre ifconfig, como lo que usted cita, ya no es realmente cierta. Ahora no es cierto decir que " ifconfigno usa netlink". La manta que cubría dos no cubre tres.
Es siempre ha sido falso decir que "netlink es más eficiente". Para las tareas que uno realiza ifconfig, en realidad no hay mucho en cuanto a la eficiencia entre la API de netlink y la ioctl()API. Uno realiza casi el mismo número de llamadas a la API para cualquier tarea dada.
De hecho, cada llamada a la API son dos llamadas al sistema en el caso de netlink, a diferencia de una en el ioctl()sistema. Y podría decirse que la API de netlink tiene la desventaja de que en un sistema muy utilizado incorpora explícitamente la posibilidad de que la herramienta nunca reciba un mensaje de confirmación informándole del resultado de la llamada a la API.
Está, además, falso decir que ipes "más versátil" que el GNU y NET-3 ifconfigs , ya que utiliza enlace de red . Es más versátil porque realiza más tareas, haciendo cosas en un gran programa que se haría con otros programas distintosifconfig . No es más versátil simplemente a fuerza de la API que utiliza internamente para realizar esas tareas adicionales. No hay nada inherente a la API sobre esto. Se podría escribir una herramienta todo-en-uno que utiliza el FreeBSD ioctl()API, por ejemplo, e igualmente bien estado que es "más versátil" que las individuales ifconfig, route, arp, y ndpcomandos.
Se podría escribir route, arpy ndplos comandos de Linux que utilizan la API de enlace de red, también.
ifconfig. nosh Guide . SoftwaresEl estándar ifconfigque tenemos en muchas distribuciones está en desuso por varias razones. Habla de una manera anticuada y limitada con el kernel y, de hecho, ya no comprende todas las configuraciones de red. No podrá manipular algunas configuraciones de red, tales ifconfigversiones con las que puede hacerlo ip. Además, el ifconfigsoporte para espacios de nombres de red es limitado.
Como cuento anecdótico, encontré un alias de IP de interfaz que solo son visibles en ipy no en SuSE ifconfig.
En cuanto a las diferencias bajo el capó: De ifconfig vs ip: Cuál es la diferencia y la comparación de la configuración de red
Aunque
ippuede parecer un poco complejo en el primer sitio, es mucho más amplio en funcionalidad que ifconfig. Está funcionalmente organizado en dos capas de Networking Stack, es decir, Layer 2 (Link Layer), Layer 3 (IP Layer) y hace el trabajo de todos los comandos mencionados anteriormente del paquete net-tools.Si bien en
ifconfigsu mayoría muestra o modifica las interfaces de un sistema, este comando es capaz de realizar las siguientes tareas:
Mostrar o modificar las propiedades de la interfaz.
Agregar, eliminar entradas de caché ARP y crear una nueva entrada ARP estática para un host.
Visualización de direcciones MAC asociadas a todas las interfaces.
Mostrar y modificar tablas de enrutamiento del núcleo.
Uno de los aspectos más destacados que lo separa de su antigua contraparte ifconfig es que este último utiliza ioctl para la configuración de la red, que es una forma menos apreciada de interacción con el kernel, mientras que el primero aprovecha el mecanismo de socket de enlace de red para el mismo, que es un sucesor mucho más flexible de ioctl para la intercomunicación entre el núcleo y el espacio del usuario utilizando rtnetlink (que agrega la capacidad de manipulación del entorno de red).
Acerca del uso / ventajas de netlink: De LJ - Kernel Korner - Por qué y cómo usar Netlink Socket
Netlink socket es un IPC especial que se utiliza para transferir información entre el núcleo y los procesos de espacio de usuario. Proporciona un enlace de comunicación full-duplex entre los dos a través de API de socket estándar para procesos de espacio de usuario y una API especial de kernel para módulos de kernel. El conector Netlink utiliza la familia de direcciones AF_NETLINK.
.....
¿Por qué las funciones anteriores usan netlink en lugar de llamadas al sistema, ioctls o sistemas de archivos proc para la comunicación entre el mundo del usuario y el del núcleo? Es una tarea no trivial agregar llamadas al sistema, ioctls o archivos de proceso para nuevas funciones; corremos el riesgo de contaminar el núcleo y dañar la estabilidad del sistema. Sin embargo, el socket de Netlink es simple: solo se necesita agregar una constante, el tipo de protocolo, a netlink.h. Luego, el módulo del kernel y la aplicación pueden comunicarse utilizando API de estilo socket inmediatamente.
....
Netlink socket es una interfaz flexible para la comunicación entre aplicaciones de espacio de usuario y módulos de kernel. Proporciona una API de socket fácil de usar tanto para las aplicaciones como para el kernel. Proporciona funciones de comunicación avanzadas, como full-duplex, E / S almacenadas, multidifusión y comunicación asíncrona, que están ausentes en otros IPC de kernel / espacio de usuario.
ipmás versátil, porque todo tipo de características interesantes son simplemente imposibles de hacer usando ioctls en Linux (porque los ioctls no están allí y probablemente nunca lo estarán).