¿Por qué el tráfico de red de Linux solo pasa por eth0?

20

Tengo dos NIC en el lado del servidor, eth0? 192.168.8.140 y eth1? 192.168.8.142. El cliente envía datos a 192.168.8.142, y espero iftopmostrar el tráfico de eth1, pero no lo hace. Todas las redes pasan por eth0, entonces, ¿cómo puedo probar las dos NIC?

¿Por qué todo el tráfico pasa por eth0 en lugar de eth1? Esperaba poder obtener 1 Gbit / s por interfaz. ¿Qué hay de malo en mi configuración o configuración?

Servidor

ifconfig

eth0    Link encap:Ethernet  HWaddr 00:00:00:19:26:B0
        inet addr:192.168.8.140  Bcast:0.0.0.0  Mask:255.255.252.0
        inet6 addr: 0000::0000:0000:fe19:26b0/64 Scope:Link
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:45287446 errors:0 dropped:123343 overruns:2989 frame:0
        TX packets:3907747 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000
        RX bytes:66881007720 (62.2 GiB)  TX bytes:261053436 (248.9 MiB)
        Memory:f7e00000-f7efffff

eth1    Link encap:Ethernet  HWaddr 00:00:00:19:26:B1
        inet addr:192.168.8.142  Bcast:0.0.0.0  Mask:255.255.255.255
        inet6 addr: 0000::0000:0000:fe19:26b1/64 Scope:Link
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:19358 errors:0 dropped:511 overruns:0 frame:0
        TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000
        RX bytes:1772275 (1.6 MiB)  TX bytes:1068 (1.0 KiB)
        Memory:f7c00000-f7cfffff

Lado del servidor

# Listen for incomming from 192.168.8.142
nc -v -v -n -k -l 192.168.8.142 8000 | pv > /dev/null
Listening on [192.168.8.142] (family 0, port 8000)
Connection from 192.168.8.135 58785 received!

Cliente

# Send to 192.168.8.142
time yes | pv |nc -s 192.168.8.135 -4 -v -v -n 192.168.8.142 8000 >/dev/null
Connection to 192.168.8.142 8000 port [tcp/*] succeeded!

Lado del servidor

$ iftop -i eth0
interface: eth0
IP address is: 192.168.8.140

TX:             cumm:  6.34MB   peak: 2.31Mb   rates: 2.15Mb  2.18Mb  2.11Mb
RX:                    2.55GB          955Mb           874Mb   892Mb   872Mb
TOTAL:                 2.56GB          958Mb           877Mb   895Mb   874Mb

$ iftop -i eth1
interface: eth1
IP address is: 192.168.8.142

TX:             cumm:      0B   peak:     0b   rates:     0b      0b      0b
RX:                    4.51KB         3.49Kb          3.49Kb  2.93Kb  2.25Kb
TOTAL:                 4.51KB         3.49Kb          3.49Kb  2.93Kb  2.25Kb

$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:00:00:19:26:b0 brd ff:ff:ff:ff:ff:ff
$ ip link show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:00:00:19:26:b1 brd ff:ff:ff:ff:ff:ff
linux networking network-interface alpine-linux Wener
fuente
1
Parece que lo que realmente está buscando es unir interfaz: wiki.linuxfoundation.org/networking/bonding
Flexo
@flexo tiene toda la razón: dependiendo de su objetivo final, la unión de las dos interfaces de red puede proporcionarle más ancho de banda general, pero las opciones de unión varían. Lo mejor que puede obtener es 2 transmisiones de ~ 1 Gbit, y no 1 transmisión de 2 Gbit. Además, necesita los servicios de un conmutador Ethernet administrado. Del mismo modo, la unión 4 podría dar flujos de 4x 1 Gbit a la vez.
Criggie el

Respuestas:

32

Hay dos modelos de diseño posibles para una pila de red TCP / IP: un modelo de host fuerte y un modelo de host débil. Espera un comportamiento que coincida con el modelo de host fuerte. Linux está diseñado para usar el modelo de host débil. En general, el modelo de host débil es más común, ya que reduce la complejidad del código de enrutamiento y, por lo tanto, podría ofrecer un mejor rendimiento. De lo contrario, los dos modelos de host son solo principios de diseño diferentes: ninguno es inherentemente mejor que el otro.

Básicamente, el modelo de host débil significa que el tráfico saliente se enviará a la primera interfaz listada en la tabla de enrutamiento que coincida con la dirección IP del destino (o puerta de enlace seleccionada, si no se puede acceder al destino directamente), independientemente de la IP de origen habla a .

Esto es básicamente por lo que generalmente no es aconsejable usar dos interfaces físicas separadas si necesita dos direcciones IP en el mismo segmento de red. En su lugar, asigne dos direcciones IP para una interfaz (alias de IP: por ejemplo, eth1 = 192.168.8.142 y eth1: 0 = 192.168.8.140). Si necesita más ancho de banda del que puede proporcionar una sola interfaz, enlace (o equipo, si corresponde) dos o más interfaces juntas, y luego ejecute ambas IP en el enlace / equipo.

Al ajustar una serie de configuraciones de sysctl y usar la funcionalidad de "enrutamiento avanzado" para configurar tablas de enrutamiento independientes para cada NIC, es posible hacer que Linux se comporte como un sistema de modelo de host fuerte. Pero esa es una configuración muy especial, y recomendaría pensarlo dos veces antes de implementarla.

¿Ver las respuestas en Linux Source Routing, Strong End System Model / Strong Host Model? si realmente lo necesitas

telcoM
fuente
El modo predeterminado también es una mala sorpresa si se intenta dar forma al tráfico con iptables :)
rackandboneman
Sí, me he divertido implementando el modelo de host fuerte en el pasado. Era necesario para ese proyecto, pero no me molestaría en pasar por ese dolor de cabeza por una máquina personal.
Baldrickk el
11

Un punto adicional a considerar es que la interfaz eth1 está configurada con una máscara de subred de 255.255.255.255.

Esto significa que la interfaz eth1 está configurada para no esperar otros dispositivos (hosts) en su interfaz de red. Esto significa que no podrá comunicarse con su cliente 192.168.8.142.

Curva M
fuente
2

Después de mucha búsqueda, encontré ¿Por qué netcat no usa la interfaz correcta asociada con la IP? , y este es el mismo problema. Como dijo @telcoM, el tráfico saliente se enviará a la primera interfaz, y ese es el problema, por lo tanto, la forma más fácil de resolver esto es:

ip route add default via 192.168.8.142 dev eth1 table 142
ip rule add from 192.168.8.142 table 142

Esta ruta ip route get 192.168.8.135 from 192.168.8.142devolverá eth1 en lugar de eth0. Entonces todo funciona como se esperaba.

Wener
fuente
3
Si omite la configuración de ARP sysctl mencionada en la pregunta a la que me referí, y está tratando con conmutadores y enrutadores de nivel empresarial, su administrador de red estará un poco descontento con usted causando mensajes innecesarios de "aleteo de direcciones IP" en el enrutador, ya que el sistema aún puede responder a las solicitudes ARP para ambas IP en ambas interfaces. O si tiene protección de secuestro de IP en la red, podría activar y desactivar todo el tráfico a su sistema.
telcoM