El comando 'ip addr' muestra 'UP' incluso si no hay una dirección asociada con esa interfaz

16

Me gustaría entender qué se entiende por una interfaz de red activa. Porque ip addro el ifconfigcomando muestra una interfaz como activa incluso cuando no hay ninguna IP asociada.

por ejemplo en RHEL7:

[root@IDCDVAM887 ~]# ifconfig ens256
ens256: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 00:50:56:9e:19:5b  txqueuelen 1000  (Ethernet)
        RX packets 229406  bytes 59265584 (56.5 MiB)
        RX errors 0  dropped 229454  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

(o) 

[root@IDCDVAM887 ~]# ip addr show ens256
5: ens256: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
link/ether 00:50:56:9e:19:5b brd ff:ff:ff:ff:ff:ff

¿Cuál es el uso real de mostrar como UP cuando la interfaz no tiene IP? Creo que cuando no hay IP, ¿no podría haber comunicación al respecto? Entonces, ¿de qué sirve?

iproute Srikanth Ganesan
fuente
1
Las tramas Ethernet pueden hacer más que solo contener paquetes IP.
casey

Respuestas:

17

El LOWER_UPes el estado del enlace Ethernet (u otro protocolo de capa de enlace). Se define como Driver signals L1 up, lo que básicamente significa que el cable está instalado y puede ver otro dispositivo en el otro extremo del cable.

El UPmedio que ha sido habilitado. Usted puede controlar esto (o un script) usando el comando ip link set <device> upof ifconfig <device> up.

Existen otros protocolos, como IPX, que usan Ethernet, pero no tendrán una dirección IP, ya que no forman parte de la pila de protocolos de Internet. Por lo tanto, es perfectamente aceptable que el enlace sea UPpero no tenga una dirección IP.

garethTheRed
fuente
DHCP en realidad se basa en la difusión UDP, que requiere una capa IP (de hecho, se puede enrutar). Otro ejemplo de alternativa históricamente utilizada a IP fue NetBIOS (antes de ser portado a NetBIOS a través de IPX / SPX y luego como NetBIOS a través de TCP / IP)
pqnet
[root @ IDCDVAM887 ~] # ip addr show eno33557248 3: eno33557248: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link / ether 00: 50: 56: 9e: 68: 86 brd ff: ff : ff: ff: ff: ff inet 10.54.2.7/32 scope global eno33557248: 1 valid_lft forever Preferred_lft forever En el formato anterior hay una interfaz virtual 'eno33557248: 1' con alguna IP. ¿Por qué no se muestra UP como separado? ¿Es suficiente mostrar solo la interfaz original como UP?
Srikanth Ganesan
@pqnet: estaba tratando de explicar que la parte "sin IP, sin comunicación" de la pregunta del OP no es cierta. ¡Tal vez no fue el mejor ejemplo entonces! Lo eliminaré, ya que solo causará confusión.
garethTheRed
Esa parte ahora entendí gracias a los dos .. !!!
Srikanth Ganesan
comando ip addr en RHEL7 para una interfaz que ha configurado una interfaz virtual múltiple o un alias que causa mucha confusión sobre cómo saber si está activo o no
Srikanth Ganesan
7

El UPestado es el estado administrativo de la interfaz, es decir, si la interfaz ha sido habilitada. Puede habilitar cualquier interfaz utilizando, por ejemplo,

ip l s eth0 up

Si el cable está enchufado y se establece un enlace, la interfaz también obtendrá el estado operativo de RUNNING.

Muchas tarjetas inhibirán la generación de portadores salientes si el estado administrativo no es UP, y una interfaz que no UPlo es RUNNINGtampoco, así que si configuro

ip l s eth0 down

Esperaría que mi interfaz local perdiera ambos UPy RUNNING, y la interfaz correspondiente en el lado remoto tampoco lo estaría más RUNNING(pero aún UPasí, si habilito mi lado nuevamente, obtendría un enlace).

Sin embargo, ese es solo el enlace Ethernet. Además del enlace, se pueden vincular varios protocolos, uno de ellos es IPv4. De manera predeterminada, IPv4 está vinculado a todas las interfaces que admiten la familia de protocolos.

Cuando el protocolo está vinculado, puedo enviar y recibir paquetes con cualquier dirección asignada a la interfaz. Si no se asigna una dirección, esto simplemente significa que no hay una dirección válida que pueda usarse para los paquetes salientes (por lo que el envío de un paquete falla), ni ninguna dirección de unidifusión a la que se pueda dirigir un paquete entrante que el sistema reconocería como local (por lo tanto, solo se pueden recibir paquetes de difusión / multidifusión).

Esto no concierne a la capa de enlace en lo más mínimo, ya que solo establecerá un enlace.

Ciertos programas, como el cliente DHCP, tienen un permiso especial para enviar paquetes formateados arbitrariamente, completar una dirección de origen de fantasía o 0.0.0.0recibir paquetes que llegan independientemente de si están destinados a la máquina local. Esto se utiliza durante la configuración automática de la dirección IP, donde la solicitud DHCP se envía utilizando una dirección de origen 0.0.0.0y la respuesta del servidor se dirige a la dirección de difusión 255.255.255.255.

Por lo tanto, existe un caso de uso válido en el que los paquetes IP se intercambian incluso sin una dirección vinculada a la interfaz.

Además de IPv4, también hay IPv6, IPX, AppleTalk, etc., que pueden compartir la misma capa física. Tan pronto como se establece el enlace, cualquiera de estos protocolos de nivel superior puede usar su propia secuencia de activación para entrar en un estado operativo.

Simon Richter
fuente
>> una interfaz que no está ARRIBA tampoco puede EJECUTARSE <<. Creo que esto puede no ser aplicable para máquinas solaris x86 donde la interfaz muestra que se ejecuta incluso cuando el estado no es 'UP'. Por ejemplo 1. Sondear una nueva interfaz virtual. root @ IDCDVAM890: ~ # ifconfig net0: 2 plumb 2. Compruebe el estado de la interfaz. EN EJECUCIÓN pero no se asigna ninguna IP. root @ IDCDVAM890: ~ # ifconfig net0: 2 net0: 2: flags = 1000842 <BROADCAST, RUNNING , MULTICAST, IPv4> mtu 1500 index 2 inet 0.0.0.0 netmask 0
Srikanth Ganesan
@SrikanthGanesan, no necesita una dirección IP para tener la interfaz en estado UP o RUNNING, de hecho, la interfaz debe estar UP y RUNNING para que DHCP funcione. Parece que Solaris hereda el estado RUNNING de las interfaces virtuales del padre, pero mantiene un estado UP separado. Eso es algo irregular, puede ser interesante ver si el agente SNMP que envían corrige esto en la vista externa.
Simon Richter
3

una interfaz puede estar "activa" incluso sin ninguna dirección. El estado "arriba" se refiere a la capa de enlace de datos (también conocida como capa 2), es decir, "arriba" significa que puede enviar y recibir paquetes de Ethernet. IP es algo construido sobre ella.

Un ejemplo de configuración en la que una interfaz está activa pero no tiene una IP (y no se le debe asignar una) es cuando la interfaz es un esclavo de puente.

pqnet
fuente
0

mágicamente, si especificas la -4opción o -oneline, entonces realmente mostrará la interfaz "en ejecución" como la imaginaste.

Para que sea más fácil de leer, utilicé la -briefopción, pero no importa la conclusión.

Ver el resultado de la upopción, todavía muestra un DOWNdispositivo.

ubuntu@ubuntu:~$ ip --brief address show up
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             DOWN
enp130s0f0       UP             100.79.223.150/26 fe80::a9e:1ff:fed9:2864/64

Ver el resultado de la -4opción, todo con direcciones, sin DOWNdispositivos.

ubuntu@ubuntu:~$ ip -4 -brief address show
lo               UNKNOWN        127.0.0.1/8
enp130s0f0       UP             100.79.223.150/26

vea el resultado de la -onlineopción, todas con direcciones, sin DOWNdispositivos, pero divididas en IPv4 e IPv6.

ubuntu@ubuntu:~$ ip -oneline address show
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
4: enp130s0f0    inet 100.79.223.150/26 brd 100.79.223.191 scope global enp130s0f0\       valid_lft forever preferred_lft forever
4: enp130s0f0    inet6 fe80::a9e:1ff:fed9:2864/64 scope link \       valid_lft forever preferred_lft forever
osexp2003
fuente