Salve Alessandro, ora non ricordo di preciso e non conosco la tua soluzione specifica, ma sicuro non sia un problema tecnologico? Mi spiego, hai lo stesso mac address per entrambe le interfacce? Potrebbe essere che non uscendo pacchetti dalla scheda di rete lo switch a valle (per la storia del backward learning) non faccia il forward dei pacchetti sulla giusta porta. Altro problema potrebbe essere che il link di backup prima di diventare active debba essere sicuro che il primario è andato giù, per evitare problemi di flapping della interfaccia. Problemi di questo tipo sono molto difficilmente risolvibili, ci sono casi di interfacce che comunicano parzialmente (solo qualche coppia di fili), oppure (mi pare successo in australia) di porte con condensatori che quando si surriscaldavano andavano giù, poi tornavano su nel tempo di qualche secondo, giusto il tempo per far riconvergere il rapid spanning tree ad una nuova soluzione (master e backup si continuavano a scambiare di ruolo) Tutto questo per dire che ci sono meccanismi di timeout e di controllo che cercano di prevenire queste situazioni. Un capitolo a parte potrebbe essere fatto sulle connessioni tcp... In conclusione: prova con wireshark a vedere se sono mac diversi e se effettivamente non escono pacchetti oppure non arrivano le risposte! Saluti Just my .02$ Gianfranco Sent from my Yahoo Mail for Android |
| On 04/08/2013 05:15 PM, Alessandro Baggi wrote: > Salve ragazzi, > stavo facendo delle prove per il channel bonding active-backup. > Ho come mulo da test un pc hp di circa 8 anni con due schede di rete: > > 1) integrata Broadcom Corporation NetXtreme BCM5751 GB [eth1] > 2) scheda pci 3com 3c905C-TX/TX-M Fast Ethernet [eth0] > > > Di seguito riporto la configurazione: > > iface bond0 inet static > address ip > netmask ... > gateway ... > slaves eth0 eth1 > bond-miimon 100 > bond-updelay 200 > bond-downdelay 200 > bond-mode 1 > > > Il test parte con active slave su eth0. Scollegando il cavo di eth0 > passano da 5 ai 30 secondi prima di riuscire ad attivare lo slave eth1 > causando una perdita di pacchetti. > Una volta attivato lo slave eth1, la rete comincia a funzionare. A > questo punto ricollego il cavo della eth0 e eth1 rimane active slave > come richiesto. > Scollegando il cavo di eth1, viene effettuato immediatamente il cambio > di active slave su eth0 senza perdita di pacchetti. > Effettuando di nuovo la prima operazione (scollegando eth0) il problema > si manifesta di nuovo. > > In un primo momento stavo utilizzando uno switch at-8326GB di circa 10 > anni. Pensando che avesse qualche problema, ho collegato uno switch da 5 > porte netgear, ma il problema permane. > > Considerando che la 3com è molto vecchia potrei pensare ad un problema > sulla scheda di rete. > > > Da cos'altro può dipendere questo comportamento? > > Vi ringrazio in anticipo. > > Un saluto, Alessandro. > Salve lista, ho effettuato altre prove, cambiando le schede di rete ma il problema permane. -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-REQUEST@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmaster@lists.debian.org To UNSUBSCRIBE, email to debian-italian-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: [🔎] 516459DF.7050005@gmail.com" target=_blank >http://lists.debian.org/[🔎] 516459DF.7050005@gmail.com |