Re: [Ninux-Wireless] Corso di sopravvivenza alla WBMv3 domani (martedi') sera
On 05/04/2010 04:49 PM, cl...@ninux.org wrote: > On 04/28/2010 01:50 PM, cl...@ninux.org wrote: >> On 04/26/2010 08:42 AM, cl...@ninux.org wrote: >>> Ciao. >>> Vi vorrei ricordare che domani sera ci sarebbe la prima parte del corso >>> di sopravvivenza alla battaglia delle mesh (la seconda parte martedi' >>> della settimana prossima), sotto forma di seminario, in collaborazione >>> con il SabaziaLug, e quindi ad Anguillara Sabazia, h. 21.30. >>> >>> Ovvero, dal sito [1]: >>> >>> * Martedì 27 aprile 2010 - Metti un pinguino nel router * >>> Come compilare, installare ed utilizzare OpenWrt, una distribuzione >>> Linux per sistemi embedded. Prima lezione del corso di sopravvivenza >>> alla battaglia delle mesh [2]. >>> >>> * Martedì 4 maggio 2010 - Come farsi le mesh con Linux * >>> Teoria e pratica del routing e dei protocolli di routing per reti a >>> maglia. Seconda lezione del corso di sopravvivenza alla battaglia delle >>> mesh [2]. >>> >>> ciauz, >>> Clauz >>> >>> [1] >>> http://www.sabazialug.org/Iniziative/Seminari-Linux-One-shot-primavera-2010.html >>> [2] http://battlemesh.org >> >> >> La presentazione di ieri: >> http://wiki.ninux.org/Presentazioni?action=AttachFile&do=get&target=seminariosabazialugPinguinoNelRouter.pdf > > > Reminder: questa sera seminario sulle reti mesh! ATTENZIONE: seminario spostato a martedi' 11 maggio! Motivo: la maggior parte delle persone interessate a partecipare aveva altri impegni. Clauz signature.asc Description: OpenPGP digital signature ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
[Ninux-Wireless] nuova lista not-wireless (Beta!)
Ciao. Da qualche giorno e' in sperimentazione (il beta va di moda) una nuova mailing list di ninux.org non moderata e dedicata agli "off-topic". Per l'iscrizione: http://ml.ninux.org/mailman/listinfo/not-wireless Vediamo come va, Clauz signature.asc Description: OpenPGP digital signature ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Corso di sopravvivenza alla WBMv3 domani (martedi') sera
On 04/28/2010 01:50 PM, cl...@ninux.org wrote: > On 04/26/2010 08:42 AM, cl...@ninux.org wrote: >> Ciao. >> Vi vorrei ricordare che domani sera ci sarebbe la prima parte del corso >> di sopravvivenza alla battaglia delle mesh (la seconda parte martedi' >> della settimana prossima), sotto forma di seminario, in collaborazione >> con il SabaziaLug, e quindi ad Anguillara Sabazia, h. 21.30. >> >> Ovvero, dal sito [1]: >> >> * Martedì 27 aprile 2010 - Metti un pinguino nel router * >> Come compilare, installare ed utilizzare OpenWrt, una distribuzione >> Linux per sistemi embedded. Prima lezione del corso di sopravvivenza >> alla battaglia delle mesh [2]. >> >> * Martedì 4 maggio 2010 - Come farsi le mesh con Linux * >> Teoria e pratica del routing e dei protocolli di routing per reti a >> maglia. Seconda lezione del corso di sopravvivenza alla battaglia delle >> mesh [2]. >> >> ciauz, >> Clauz >> >> [1] >> http://www.sabazialug.org/Iniziative/Seminari-Linux-One-shot-primavera-2010.html >> [2] http://battlemesh.org > > > La presentazione di ieri: > http://wiki.ninux.org/Presentazioni?action=AttachFile&do=get&target=seminariosabazialugPinguinoNelRouter.pdf Reminder: questa sera seminario sulle reti mesh! Clauz signature.asc Description: OpenPGP digital signature ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] multicast routing e comportamento inaspettato
2010/5/4 ZioPRoTo (Saverio Proto) : >> multipath > > che io sappia il Kernel non fa multipath su base pacchetto ma su base > rotte, quindi ha una cache con delle rotte che manda sempre sullo > stesso percorso. Non sono sicuro di aver capito. Penso che la cache di cui parli sia quella che io svuoto con il comando "ip route flush cache". Stando a quanto ho capito io, quando il kernel deve inoltrare un pacchetto esamina prima le rotte in questa tabella cache (che dovrebbe essere l'implementazione della FIB [1]) Se non ne trova allora consulta le tabelle, diciamo, master. Trovata qui una soluzione, oltre ad usarla la memorizza anche nella tabella cache. Pensavo che la stessa procedura fosse seguita per i pacchetti che deve inviare (piuttosto che inoltrare) Invece in questo caso pare che dopo aver scelto una rotta non la abbandona nemmeno se cancello la tabella cache. [1] http://en.wikipedia.org/wiki/Forwarding_information_base > > Saverio > ___ > Wireless mailing list > Wireless@ml.ninux.org > http://ml.ninux.org/mailman/listinfo/wireless > ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] multicast routing e comportamento inaspettato
> multipath che io sappia il Kernel non fa multipath su base pacchetto ma su base rotte, quindi ha una cache con delle rotte che manda sempre sullo stesso percorso. Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] multicast routing e comportamento inaspettato
2010/5/4 ZioPRoTo (Saverio Proto) : >> Sto facendo degli esperimenti con il multicast routing su linux. >> Riscontro un comportamento che non mi aspettavo. > > Mmm sei sicuro ? Mi dai la tua definizione di "multicast". > > Mi sa che stai facendo esperimenti su un altra cosa. Forse multipath ? multipath si :D ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] multicast routing e comportamento inaspettato
> Sto facendo degli esperimenti con il multicast routing su linux. > Riscontro un comportamento che non mi aspettavo. Mmm sei sicuro ? Mi dai la tua definizione di "multicast". Mi sa che stai facendo esperimenti su un altra cosa. Forse multipath ? Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
[Ninux-Wireless] multicast routing e comportamento inaspettato
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 ad
