Ciao a tutti. Sto facendo degli esperimenti con il multicast routing su linux. Riscontro un comportamento che non mi aspettavo.
Cerco di illustrare i miei esperimenti qui sotto. Mi scuso se risulta pesante la lettura soprattutto da un client di posta che non usa i caratteri a larghezza fissa. Allego lo stesso testo anche come file .txt, forse per qualcuno risulta migliore. Ho preparato (con netkit) una topologia come rappresento sotto. * 0 2 * ↖↘ ↗ ↘ * 1 ←-- 4 * ↘ ↗ * 3 * * Il nodo <1>, oltre ad una rotta verso il nodo <0>, ha 2 rotte verso <2> e <3> e attraverso di queste raggiunge il <4> con un multipath con load-balancing (con peso relativo 10 e 7) Cioè: ip route add default \ nexthop via 1.1.1.3 dev eth0 weight 10 \ nexthop via 1.1.1.2 dev eth2 weight 7 Gli altri nodi hanno tutti una sola rotta, come da disegno. Inoltre, il nodo <1> periodicamente ripulisce la sua tabella di cache, per evitare che una volta scelta una rotta per una certa destinazione venga usata sempre quella. Cioè esegue una volta al secondo: ip route flush cache Ho lanciato sui nodi 2 e 3 tcpdump per verificare dove passano i pacchetti. I test fatti ed i risultati: 1) Dal nodo 0 un ping al nodo 4. I pacchetti passano su 2 e 3 alternandosi all'incirca in base ai pesi usati 2) Dal nodo 0 una connessione TCP al nodo 4. Ho usato nc (netcat). Traffico va da 0 verso 4: I pacchetti passano su 2 e 3 alternandosi all'incirca in base ai pesi usati Traffico va da 4 verso 0: I pacchetti di tipo ACK passano su 2 e 3 alternandosi all'incirca in base ai pesi usati Nell'eventualità che il nodo 3 muore mentre la connessione è aperta: Sia per il traffico da 0 a 4, sia per il traffico da 4 a 0: I pacchetti passano su 2, ma non in maniera costante; la caratteristica di reliability del TCP viene rispettata. 3) Dal nodo 0 invio pacchetti UDP al nodo 4. Ho usato nc (netcat). I pacchetti passano su 2 e 3 alternandosi all'incirca in base ai pesi usati Nell'eventualità che il nodo 3 muore: I pacchetti passano su 2, ma non in maniera costante; quando viene scelta la rotta verso 3 i pacchetti sono persi. 4) Dal nodo 1 un ping al nodo 4. I pacchetti passano su 2 e 3 alternandosi all'incirca in base ai pesi usati 5) Dal nodo 1 una connessione TCP al nodo 4. Ho usato nc (netcat). Traffico va da 1 verso 4: I pacchetti passano o sempre su 2 o sempre su 3 Traffico va da 4 verso 1: I pacchetti di tipo ACK passano o sempre su 2 o sempre su 3 Nell'eventualità che il nodo scelto inizialmente muore mentre la connessione è aperta: Per il traffico da 1 a 4: Dopo un periodo in cui i pacchetti sono tutti persi, circa 20 secondi, i pacchetti cominciano a fluire per l'altra rotta e vi passano da quel momento in poi in modo costante; la caratteristica di reliability del TCP viene rispettata. Per il traffico da 4 a 1: I pacchetti ti tipo ACK (da 1 verso 4) non raggiungono più la destinazione e quindi la comunicazione si interrompe; non riprende più. A meno che non venga inviato del traffico nella direzione opposta, cioè da 1 verso 4. In questo caso dopo un po' viene scelta l'altra rotta e da quel momento la comunicazione riprende in modo costante in ambedue le direzioni. 6) Dal nodo 1 invio pacchetti UDP al nodo 4. Ho usato nc (netcat). I pacchetti passano o sempre su 2 o sempre su 3 Nell'eventualità che il nodo scelto inizialmente muore: Nessun pacchetto raggiunge più la destinazione. In conclusione, tutti i comportamenti riscontrati sono più o meno in linea con quello che mi aspettavo. I punti che mi lasciano perplesso sono 5 e 6. Sembra come se ci fosse una particolare "information base" per il kernel per trovare le rotte per una certa destinazione quando il mittente originale dei pacchetti è proprio il nodo stesso. Vi pare normale come comportamento? Siete a conoscenza di cosa dovrei fare per uniformare il comportamento in 5 e 6 allo stesso che si riscontra in 2 e 3? Avete suggerimenti su strade diverse che dovrei percorrere per ottenere un multicast routing? Se volete allego i comandi per riprodurre l'esperimento (requires netkit) Grazie Luca
Ciao a tutti. Sto facendo degli esperimenti con il multicast routing su linux. Riscontro un comportamento che non mi aspettavo. Cerco di illustrare i miei esperimenti qui sotto. Mi scuso se risulta pesante la lettura soprattutto da un client di posta che non usa i caratteri a larghezza fissa. Allego lo stesso testo anche come file .txt, forse per qualcuno risulta migliore. Ho preparato (con netkit) una topologia come rappresento sotto. * 0 2 * ↖↘ ↗ ↘ * 1 ←-- 4 * ↘ ↗ * 3 * * Il nodo <1>, oltre ad una rotta verso il nodo <0>, ha 2 rotte verso <2> e <3> e attraverso di queste raggiunge il <4> con un multipath con load-balancing (con peso relativo 10 e 7) Cioè: ip route add default \ nexthop via 1.1.1.3 dev eth0 weight 10 \ nexthop via 1.1.1.2 dev eth2 weight 7 Gli altri nodi hanno tutti una sola rotta, come da disegno. Inoltre, il nodo <1> periodicamente ripulisce la sua tabella di cache, per evitare che una volta scelta una rotta per una certa destinazione venga usata sempre quella. Cioè esegue una volta al secondo: ip route flush cache Ho lanciato sui nodi 2 e 3 tcpdump per verificare dove passano i pacchetti. I test fatti ed i risultati: 1) Dal nodo 0 un ping al nodo 4. I pacchetti passano su 2 e 3 alternandosi all'incirca in base ai pesi usati 2) Dal nodo 0 una connessione TCP al nodo 4. Ho usato nc (netcat). Traffico va da 0 verso 4: I pacchetti passano su 2 e 3 alternandosi all'incirca in base ai pesi usati Traffico va da 4 verso 0: I pacchetti di tipo ACK passano su 2 e 3 alternandosi all'incirca in base ai pesi usati Nell'eventualità che il nodo 3 muore mentre la connessione è aperta: Sia per il traffico da 0 a 4, sia per il traffico da 4 a 0: I pacchetti passano su 2, ma non in maniera costante; la caratteristica di reliability del TCP viene rispettata. 3) Dal nodo 0 invio pacchetti UDP al nodo 4. Ho usato nc (netcat). I pacchetti passano su 2 e 3 alternandosi all'incirca in base ai pesi usati Nell'eventualità che il nodo 3 muore: I pacchetti passano su 2, ma non in maniera costante; quando viene scelta la rotta verso 3 i pacchetti sono persi. 4) Dal nodo 1 un ping al nodo 4. I pacchetti passano su 2 e 3 alternandosi all'incirca in base ai pesi usati 5) Dal nodo 1 una connessione TCP al nodo 4. Ho usato nc (netcat). Traffico va da 1 verso 4: I pacchetti passano o sempre su 2 o sempre su 3 Traffico va da 4 verso 1: I pacchetti di tipo ACK passano o sempre su 2 o sempre su 3 Nell'eventualità che il nodo scelto inizialmente muore mentre la connessione è aperta: Per il traffico da 1 a 4: Dopo un periodo in cui i pacchetti sono tutti persi, circa 20 secondi, i pacchetti cominciano a fluire per l'altra rotta e vi passano da quel momento in poi in modo costante; la caratteristica di reliability del TCP viene rispettata. Per il traffico da 4 a 1: I pacchetti ti tipo ACK (da 1 verso 4) non raggiungono più la destinazione e quindi la comunicazione si interrompe; non riprende più. A meno che non venga inviato del traffico nella direzione opposta, cioè da 1 verso 4. In questo caso dopo un po' viene scelta l'altra rotta e da quel momento la comunicazione riprende in modo costante in ambedue le direzioni. 6) Dal nodo 1 invio pacchetti UDP al nodo 4. Ho usato nc (netcat). I pacchetti passano o sempre su 2 o sempre su 3 Nell'eventualità che il nodo scelto inizialmente muore: Nessun pacchetto raggiunge più la destinazione. In conclusione, tutti i comportamenti riscontrati sono più o meno in linea con quello che mi aspettavo. I punti che mi lasciano perplesso sono 5 e 6. Sembra come se ci fosse una particolare "information base" per il kernel per trovare le rotte per una certa destinazione quando il mittente originale dei pacchetti è proprio il nodo stesso. Vi pare normale come comportamento? Siete a conoscenza di cosa dovrei fare per uniformare il comportamento in 5 e 6 allo stesso che si riscontra in 2 e 3? Avete suggerimenti su strade diverse che dovrei percorrere per ottenere un multicast routing? Se volete allego i comandi per riprodurre l'esperimento (requires netkit) Grazie Luca
_______________________________________________ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless