[Ninux-Wireless] multicast routing e comportamento inaspettato

[Luca Dionisi]

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
-------------- parte successiva --------------
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