Se rimuovo una connessione di rete, il mio host UNIX non dovrebbe semplicemente usare l'altra?

Un problema interessante

Se al MacBook Pro sono collegate due connessioni di rete e ne rimuovo una, la rete non dovrebbe semplicemente utilizzare l'altra?

Beh, non è andata ieri sera - quando sono andata a letto, mia moglie mi ha chiesto di un cavo Ethernet che avevo attraversato la cucina, e pensando che la connessione wireless avrebbe gestito il traffico se fosse stata rimossa, le ho detto solo di rimuovi il cavo ethernet, ritira la linea fuori dalla cucina, chiudi la porta e vai a letto, mentre mi giro ... :-D

Questa mattina, Mac Mail e altri strumenti (Safari) non sono stati in grado di accedere a Internet, anche se c'era una connessione wireless al mio router WiFi. Quindi, ho riavviato ingenuamente sia Mail che Safari, e non riuscivano ancora a vedere Internet.

Quindi, ho aperto Rete in Preferenze di Sistema e ho cambiato l'ordine in modo che il Wi-Fi arrivasse prima, non secondo, come in:

E immediatamente, Safari e Mail sono stati ricollegati a Internet.

Ho pensato che TCP / IP avrebbe semplicemente usato l'interfaccia di rete che è disponibile se l'altro non lo fosse?

Questo mi porta a una domanda più generale: come dividere il traffico di rete per sfruttare entrambe le interfacce di rete, aumentando così il mio throughput?

Ottima domanda tra l'altro! Mi è successa una situazione simile quando lavoravo per Intel, ma non ricordo che le interfacce non si commutassero automaticamente quando una di esse era disconnessa.

La mia risposta riguarda la tua domanda generale

Questo mi porta a una domanda più generale: come dividere il traffico di rete per sfruttare entrambe le interfacce di rete, aumentando così il mio throughput?

Ora, se avessi due interfacce Ethernet (al contrario di Ethernet e WiFi), potresti usare una tecnologia nota come Link Aggregation per " collegare " due interfacce simili per far pensare al tuo computer che fosse una singola connessione Ethernet. Il protocollo di rete che fornisce questa funzionalità è chiamato LACP (protocollo di controllo dell'aggregazione dei collegamenti). Sfortunatamente, al fine di eseguire Link Aggregation, non solo la doppia scheda di rete deve supportare questa funzionalità, ma anche i dispositivi a cui ci si sta collegando devono supportare LACP e avere tutte le sue impostazioni uguali a quelle sul lato client. Questa funzione è comune su router e switch di fascia alta, ma la maggior parte delle apparecchiature di fascia consumer non supporta questa funzionalità.

Poiché il tuo adattatore WiFi e il tuo adattatore Ethernet sono due interfacce totalmente separate, non puoi semplicemente unire i due insieme e ottenere un throughput maggiore. Ciò è dovuto anche al fatto che la velocità di collegamento teorica di Wireless (varia in base alla tecnologia utilizzata) ed Ethernet (10/100/1000) è piuttosto diversa. Secondo Wikipedia

Nella maggior parte delle implementazioni, tutte le porte utilizzate in un'aggregazione sono dello stesso tipo fisico, come tutte le porte in rame (10/100 / 1000BASE ‑ T), tutte le porte in fibra multimodale o tutte le porte in fibra monomodale. Tuttavia, tutto lo standard IEEE richiede che ogni collegamento sia full duplex e tutti abbiano una velocità identica (10, 100, 1.000 o 10.000 Mbit / s).

Molti switch sono indipendenti da PHY, il che significa che uno switch potrebbe avere una miscela di rame, SX, LX, LX10 o altri GBIC. Pur mantenendo lo stesso PHY è il solito approccio, è possibile aggregare una fibra 1000BASE-SX per un collegamento e una 1000BASE-LX (percorso più lungo e diversificato) per il secondo collegamento, ma l'importante è che la velocità sia 1 Full duplex Gbit / s per entrambi i collegamenti. Un percorso potrebbe avere un tempo di transito leggermente più lungo, ma lo standard è stato progettato in modo da non causare problemi.

Ho appena testato il failover con il mio Mac mini. Ho configurato due interfacce di rete, Ethernet e WiFi. Entrambi erano in regola all'inizio del test, con Ethernet con precedenza nell'ordine di servizio.

Ho ripetuto il test alcune volte, osservando diversi indicatori di rete. Il failover su WiFi è avvenuto come ci si aspetterebbe. Un pacchetto di ping rilasciato alla disconnessione; nessuno è caduto al momento della riconnessione.

`en0` -  Built-in Broadcom Gigabit Ethernet  
`en1` -  Built-in Apple Wireless Network Adapter

Console.app segnala questi messaggi quando estraggo RJ-45:

2014-04-26 1:14:40.000 PM kernel[0]: AppleBCM5701Ethernet [en0]: Link down (womp disabled, proxy idle)
2014-04-26 1:14:41.267 PM configd[54]: network changed: v4(en1:192.168.2.22, en0-:192.168.2.122) DNS! Proxy! SMB

Uno è pingstato lasciato cadere.

Dopo aver ricollegato il cavo Ethernet, questi messaggi sono stati registrati:

2014-04-26 1:14:47.000 PM kernel[0]: Ethernet [AppleBCM5701Ethernet]: Link up on en0, 1-Gigabit, Full-duplex, Symmetric flow-control, Debug [796d,2321,0de1,0300,cde1,3c00]
2014-04-26 1:14:47.901 PM configd[54]: network changed: v4(en0+:192.168.2.122, en1) DNS! Proxy! SMB

Nessun pacchetto rilasciato.

A ha route monitormostrato una raffica di rotte cambiate.

In breve: su Mac OS X, versione 10.9.2, in esecuzione su un Mac Mini di metà 2011, il failover funziona come previsto.

Quindi, perché non potrebbe essere successo per te ...? Ho pensato che uno dei motivi potrebbe essere un dongle ricetrasmettitore Thunderbolt che non riporta una caduta del corriere nel kernel, ma nella cattura dello schermo sembra che il sistema sia consapevole che non esiste una connessione Ethernet.

Il problema è ripetibile e, in tal caso, quali messaggi vengono registrati?

I log di questo particolare evento sono ancora accessibili?

Non ho molta familiarità con i computer Macintosh, ma sono con reti Ethernet e TCP / IP. Oltre a utilizzare un qualche tipo di aggregazione / condivisione di link / schema di divisione, la risposta alla tua domanda "perché non ha usato l'altro link" è ... dipende da quale interfaccia (s) le applicazioni in questione sono vincolate, se possono trovare un altro percorso e così via.

Alcuni concetti vedo che molte persone nuove al networking hanno problemi con ...

• Ethernet NON è TCP / IP. TCP / IP NON è Ethernet.
• Gli indirizzi IP NON sono assegnati al tuo computer; Sono assegnati all'indirizzo MAC della scheda di interfaccia di rete.
• I dati vengono inviati sulla rete MAPPANDO un indirizzo IP all'indirizzo MAC corrispondente (e viceversa), utilizzando l'ARP - Address Resolution Protocol.
• All'interno di ogni singolo segmento di una rete, ogni indirizzo, sia esso un indirizzo MAC Ethernet o TCP / IP, DEVE essere univoco. Pensalo come il tuo telefono - Immagina quanto ti annoieresti se dovessi condividere il tuo telefono con i tuoi vicini in modo che avessero lo stesso numero di telefono di te. Il Telco dovrebbe chiamarti entrambi, e poi tu e il tuo vicino dovreste capire chi stava chiamando e per quale di voi.

Tenendo presente quanto sopra, dovrebbe iniziare a capire perché hai perso la "connettività". La tua connessione cablata ha un indirizzo MAC che è mappato a un indirizzo IP e il tuo wireless ha una diversa e unica coppia di indirizzi MAC / IP. Tra il tuo computer e il tuo router, queste coppie di MAC / IP vengono utilizzate per identificare dove inviare i dati di rete. MA .. se un collegamento fallisce, né il tuo computer né il tuo router hanno un modo facilmente fattibile per "cambiare" improvvisamente l'indirizzo di origine / destinazione si accoppia dopo il fatto.

Pensalo come l'ufficio postale. Qualcuno ti scrive una lettera e ha messo il tuo nome e indirizzo sulla busta. E se ti trasferissi? Senza fare nulla per reindirizzare la tua posta, verrebbe comunque recapitata al tuo vecchio indirizzo e non la vedresti mai. Naturalmente, come ho detto, potresti averlo reindirizzato / inoltrato, ed è quello che fanno alcuni schemi di aggregazione - ma per farlo richiedono hardware o software aggiuntivo, proprio come l'ufficio postale ha bisogno di ulteriori lavoratori / macchine per ordinare e reindirizzare il tuo la posta. Non è qualcosa che accade da solo.

Molte applicazioni "si legano" anche a una specifica interfaccia di rete - Senza un'associazione, sarebbe come dire a uno sconosciuto di "chiamarmi domani" senza dare loro il numero da chiamare. Non avrebbero modo di sapere come contattarti. Allo stesso modo, il client di posta deve comunicare al server di posta quale indirizzo IP restituire i dati. Di solito accade in modo trasparente perché gli indirizzi di origine e destinazione sono incorporati nelle intestazioni dei pacchetti.

Ora, dato quello che hai descritto, non tutto quanto sopra si applica a te. In un sistema correttamente configurato, la maggior parte delle connessioni in uscita dovrebbe effettivamente trovare qualsiasi interfaccia disponibile per essere in grado di inviare traffico di rete e man mano che router e switch diventano più sofisticati, la traduzione automatica degli indirizzi avviene senza che sia necessario alcun hardware / software aggiuntivo. Ma ci sono ancora altri problemi da affrontare; Uno di questi è la metrica dell'interfaccia (priorità), che sembra essere il tuo problema originale.

Senza che gli venga detto che può usare l'altra interfaccia, il tuo computer ha provato solo la prima interfaccia del tuo elenco. Per quanto ne sappia, la seconda interfaccia potrebbe essere collegata a una struttura di lancio nucleare e tutti i dati inizieranno la WW3 .. Non è una buona idea, anche se estrema :-P Comunque, il punto è, senza che tu lo configuri per farlo, il tuo il computer non ha un cervello reale per capire che l'altra connessione funzionerà come la prima. Ecco perché ha iniziato a funzionare dopo averlo correttamente configurato in "failover".

Ancora una volta, man mano che i computer e i sistemi operativi diventano più sofisticati, sempre più spesso escono fuori dalla scatola preconfigurati per fare questo tipo di cose automaticamente in questi giorni .. ma comprendere i problemi e le configurazioni sottostanti ti aiuterà a capire e correggere i problemi quando si verificano. Allo stesso modo, non sono del tutto sicuro su come i computer Macintosh sono configurati per gestire te situazioni, ma capisco che le più recenti quelle basate su un * x degli ultimi anni hanno generalmente una solida gestione e logica del up / down iface.

Un altro possibile problema / causa dei sintomi esatti potrebbe essere nelle tabelle di routing. In generale, quando lo stack TCP / IP tenta di instradare un pacchetto di dati, cerca l'indirizzo di destinazione nella tabella di routing. Se trova una corrispondenza esatta, invia per impacchettare l'interfaccia assegnata. Se non trova una corrispondenza esatta, ma trova una corrispondenza ravvicinata / mascherata, invierà il pacchetto all'interfaccia assegnata. Se non trova alcuna corrispondenza, invierà il pacchetto a qualunque sia il "gateway predefinito" per consentire al gateway di decidere come instradare il pacchetto.

Tuttavia, può esserci solo un gateway predefinito! Questo perché il computer (beh, lo stack TCP / IP del tuo computer) non è in grado di determinare dove inviare il pacchetto, quindi deve inviarlo al gateway per prendere quella decisione. Tuttavia, se avessi due gateway predefiniti, il tuo computer non saprebbe a quale inviarlo, dal momento che non è in grado di determinare dove inviare il pacchetto! Il tuo computer avrebbe un esaurimento nervoso nel tentativo di decidere e alla fine dividere per zero, che sappiamo non sarebbe buono ..

Ancora una volta, il modo in cui si configura il sistema influirebbe sul modo in cui risponde quando il collegamento assegnato al gateway predefinito si interrompe improvvisamente. Ma questo ci riporta alla configurazione: il tuo computer dovrebbe sapere che se il gateway predefinito diventa inaccessibile, dovrebbe passare al gateway predefinito dell'altro iface. Sembra che sia quello che alla fine ha fatto una volta cambiata la priorità delle schede di rete, motivo per cui ha ripreso a funzionare.

Scusa se tutto è chiaro come fango! Ma per aiutarti a diagnosticare questo tipo di problemi, scopri come utilizzare alcuni degli strumenti di diagnostica di rete come 'arp' (ti dice quale MAC è associato / mappato a un indirizzo IP, o viceversa) e 'route' (dirà come proverà a instradare i pacchetti in base all'indirizzo di destinazione).