Perché il traffico di rete Linux passa solo attraverso eth0?


20

Ho due schede di rete sul lato server, eth0? 192.168.8.140 ed eth1? 192.168.8.142. Il client invia i dati a 192.168.8.142 e mi aspetto iftopdi mostrare il traffico per eth1, ma non lo è. Tutte le reti passano attraverso eth0, quindi come posso testare le due schede NIC?

Perché tutto il traffico passa attraverso eth0 anziché eth1? Mi aspettavo di ottenere 1 Gbit / s per interfaccia. Cosa c'è di sbagliato nella mia installazione o configurazione?

server

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

Lato server

# 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!

Lato server

$ 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

1
Sembra che quello che stai davvero cercando sia il collegamento dell'interfaccia: wiki.linuxfoundation.org/networking/bonding
Flexo

@flexo ha perfettamente ragione: a seconda del tuo obiettivo finale, il legame tra le due interfacce di rete può darti più larghezza di banda complessiva, ma le opzioni di legame variano. Il migliore che puoi ottenere è 2 flussi di ~ 1 Gbit e non 1 flusso di 2 Gbit. Inoltre, sono richiesti i servizi di uno switch Ethernet gestito. Allo stesso modo, il legame 4 potrebbe fornire flussi 4x 1 Gbit contemporaneamente.
Criggie,

Risposte:


32

Esistono due possibili modelli di progettazione per uno stack di rete TCP / IP: un modello host forte e un modello host debole. Ti aspetti un comportamento che corrisponda al modello host forte. Linux è progettato per utilizzare il modello host debole. In generale, il modello host debole è più comune in quanto riduce la complessità del codice di routing e quindi potrebbe offrire prestazioni migliori. Altrimenti i due modelli host sono solo principi di progettazione diversi: nessuno dei due è intrinsecamente migliore dell'altro.

Fondamentalmente, il modello host debole significa che il traffico in uscita verrà inviato alla prima interfaccia elencata nella tabella di routing che corrisponde all'indirizzo IP della destinazione (o gateway selezionato, se la destinazione non è raggiungibile direttamente), indipendentemente dall'IP di origine indirizzo .

Questo è fondamentalmente il motivo per cui è generalmente sconsigliabile utilizzare due interfacce fisiche separate se sono necessari due indirizzi IP sullo stesso segmento di rete. Assegnare invece due indirizzi IP per una interfaccia (alias IP: ad es. Eth1 = 192.168.8.142 e eth1: 0 = 192.168.8.140). Se hai bisogno di più larghezza di banda di quella che una singola interfaccia può fornire, unire (o un team, se applicabile) due o più interfacce insieme, quindi eseguire entrambi gli IP sul legame / team.

Modificando una serie di impostazioni sysctl e utilizzando la funzionalità di "routing avanzato" per impostare tabelle di routing indipendenti per ciascuna scheda NIC, è possibile far sì che Linux si comporti come un sistema modello host forte. Ma questa è una configurazione molto speciale, e consiglierei di pensarci due volte prima di implementarla.

Vedi le risposte su Linux Source Routing, Strong End System Model / Strong Host Model? se ne hai davvero bisogno.


Anche la modalità predefinita è una brutta sorpresa se si tenta di modellare il traffico con iptables :)
rackandboneman

Sì, mi sono divertito a implementare il forte modello host in passato. Era richiesto per quel progetto, ma non mi sarei preso la briga di affrontare quel mal di testa per una macchina personale.
Baldrickk,

11

Un altro punto da considerare è che l'interfaccia eth1 è configurata con una subnet mask di 255.255.255.255.

Ciò significa che l'interfaccia eth1 è configurata per non aspettarsi altri dispositivi (host) sulla sua interfaccia di rete. Ciò significa che non sarà in grado di comunicare con il client 192.168.8.142.


2

Dopo molte ricerche, ho scoperto Perché netcat non utilizza l'interfaccia corretta associata all'IP? e questo è lo stesso problema. Come diceva @telcoM, il traffico in uscita verrà inviato alla prima interfaccia e questo è il problema, quindi il modo più semplice per risolverlo è:

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

Questo percorso farà ip route get 192.168.8.135 from 192.168.8.142ritorno eth1 invece di eth0. Quindi tutto funziona come previsto.


3
Se ometti le impostazioni di sistema ARP menzionate nella domanda a cui mi riferivo e hai a che fare con switch e router di livello aziendale, l'amministratore di rete sarà un po 'scontento di te causando inutili messaggi di "flapping dell'indirizzo IP" sul router, come il il sistema può ancora rispondere alle richieste ARP per entrambi gli IP su entrambe le interfacce. Oppure, se si dispone della protezione del dirottamento IP nella rete, potrebbe coinvolgere e disabilitare tutto il traffico al proprio sistema.
telcoM,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.