Hay diferencia entre una interfaz que está administrativamente activa pero desconectado o administrativamente inactivo .
Desconectado
La interfaz obtiene un carrier down estado. Su manejo adecuado puede depender del controlador de la interfaz y la versión del kernel. Normalmente está disponible con ip link show
. Por ejemplo con un ethernet virtual veth interfaz:
# ip link add name vetha up type veth peer name vethb
# ip link show type veth
2: [email protected]: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 02:a0:3b:9a:ad:4d brd ff:ff:ff:ff:ff:ff
3: [email protected]: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 36:e3:62:1b:a8:1f brd ff:ff:ff:ff:ff:ff
vetha que es administrativamente ARRIBA, muestra NO-CARRIER
y el equivalente operstate LOWERLAYERDOWN
flags:está desconectado.
Equivalente /sys/
también existen entradas:
# cat /sys/class/net/vetha/carrier /sys/class/net/vetha/operstate
0
lowerlayerdown
En la configuración habitual, para una interfaz que está administrativamente activa el portador y estado operativo coincidencia (NO-PORTADOR <=> LOWERLAYERDOWN o LOWER_UP <=> UP). Una excepción sería, por ejemplo, cuando se utiliza la autenticación IEEE 802.1X (detalles avanzados de operstate se describen en esta documentación del núcleo:Estados operativos, pero no es necesario para esta explicación).
ethtool
consulta una API de nivel inferior para recuperar este mismo estado de transportista.
No tener un operador no impide que la configuración de la capa 3 permanezca en vigor. El kernel no cambia direcciones o rutas cuando esto sucede. Es solo que al final un paquete que debería ser emitido no será emitido por la interfaz y por supuesto tampoco llegará ninguna respuesta. Entonces, por ejemplo, intentar conectarse a otra dirección IPv4 tarde o temprano desencadenará nuevamente una solicitud ARP que fallará, y la aplicación recibirá un "Sin ruta al host". Las conexiones TCP establecidas solo ofertarán su tiempo y permanecerán establecidas.
Administrativamente inactivo
Por encima de vethb tiene estado operativo DOWN y no muestra ningún estado del operador (ya que tiene que estar activo para detectar esto. Una interfaz Ethernet física, por supuesto, se comporta de la misma manera).
Cuando la interfaz se cae (ip link set ... down
), el operador ya no se puede detectar ya que el dispositivo de hardware subyacente posiblemente se apagó y el estado operativo se vuelve "inactivo". ethtool
simplemente dirá que tampoco hay un enlace, por lo que no se puede usar de manera confiable para esto (seguramente mostrará algunos desconocidos entradas también, pero ¿existe un esquema confiable para esto?).
Esta vez, esto tendrá un efecto en la configuración de red de la capa 3. El núcleo se negará a agregar rutas usando esta interfaz y eliminará cualquier ruta anterior relacionada con ella:
- el automático (
proto kernel
) Rutas LAN añadidas al añadir una dirección - cualquier otra ruta agregada (p. ej., la ruta predeterminada) en cualquier tabla de enrutamiento (no solo la principal tabla de enrutamiento) dependiendo directamente de la interfaz (
scope link
) o en otras rutas eliminadas anteriormente (probablemente entoncesscope global
) . Como estos no volverán a aparecer cuando se vuelva a activar la interfaz (ip link set ... up
) se pierden hasta que una herramienta de espacio de usuario los vuelve a agregar.
Interacciones del espacio de usuario
Al usar herramientas recientes como NetworkManager, uno puede confundirse y pensar que una desconexión es similar a una interfaz caída. Eso es porque NM monitorea los enlaces y tomará medidas cuando ocurran tales eventos. Para tener una idea el ip monitor
La herramienta se puede usar para monitorear desde scripts, pero actualmente no tiene una salida estable/parsable (no hay salida JSON disponible), por lo que su uso es limitado.
Entonces, cuando se desconecta un cable, es muy probable que NM considere que ya no está usando la configuración actual a menos que una configuración específica lo impida:luego eliminará las direcciones y las rutas por sí mismo. Cuando el cable se vuelva a conectar, NM aplicará su configuración nuevamente:agregará direcciones y rutas (usando DHCP si corresponde). Esto parece lo mismo pero no lo es. Todo este tiempo la interfaz se mantuvo activa , o ni siquiera habría sido posible que NM recibiera una advertencia cuando se restableciera la conexión.
Resumen
-
Es fácil distinguir los dos casos:
ip link show
mostraráNO-CARRIER
+LOWERLAYERDOWN
para una interfaz desconectada, yDOWN
para una interfaz deshabilitada administrativamente. -
configurar una interfaz administrativamente hacia abajo (y hacia arriba) puede perder rutas
-
perder el operador y recuperarlo no interrumpe la configuración de la red. Si el retraso es lo suficientemente corto, ni siquiera debería interrumpir las conexiones de red en curso
-
pero las aplicaciones que administran la red pueden reaccionar y cambiar la configuración de la red, a veces con un resultado similar a un caso administrativamente inactivo
-
puedes usar comandos como
ip monitor link
para recibir eventos sobre interfaces configuradas administrativamente hacia abajo/hacia arriba o cambios de operador, oip monitor
para recibir todos los múltiples eventos relacionados (incluidos los cambios de dirección o ruta) que ocurrirían en este momento o poco después. -
La mayoría
ip
comandos (pero noip monitor
) tener una salida JSON disponible conip -json ...
para ayudar a los scripts (junto conjq
).Ejemplo (continuando desde el primer veth ejemplo):
vethb sigue caído:
# ip -j link show dev vethb | jq '.[].operstate' "DOWN" # ip -j link show dev vetha | jq '.[].operstate' "LOWERLAYERDOWN"
Establecer vethb arriba, que ahora tiene un portador en ambos:
# ip link set vethb up # ip -j link show dev vetha | jq '.[].operstate' "UP"
Esto habla de los 3 estados habituales:administrativamente inactivo , capa inferior hacia abajo (es decir:encendido pero desconectado) o arriba (es decir:operativo).