<div dir="ltr">Spax spenderesti due parole su BGP, come esperienza nazionale ninux ?<div><br></div><div>In realtà già con 150nodi OLSR produrrebbe un over-head superiore eppoi come ricordo bene su Scooreggione la tabella di routing era praticamente illeggibile, lunghissima, uno spregio...</div>
<div>OLSR sulla dorsale ci stà tutto ma sui nodi foglia che vogliono annunciare il loro routing forse è più conveniente batman,</div><div><br></div><div>ad ogni modo personalmente pare che configurare entrambi sia un atto dovuto, specie perchè nelle nostra argomentazioni vi sono troppe zone buie per ritenerci con la coscienza a posto :)</div>
<div>Quindi sperimentare, iniziare, decidiamo i paletti e i confini della nostra ricerca e un modo di stimare i risultati attesi.</div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> mesh di distribuzione (tra apparati domestici, a 2.4GHz) utilizzano </span><span style="font-family:arial,sans-serif;font-size:13px">batman-adv e contano come un unico nodo olsr</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Stai dicendo che il "segmento" batman si serve poi di un unico nodo OLSR per propagare a livello applicativo la tabella conpresiva dei nodi ?</span></div>
<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> Utilizzare un protocollo layer 2 per la dorsale invece non mi sembra </span><span style="font-family:arial,sans-serif;font-size:13px">appropriato, ma sicuramente dovremmo valutare le alternative layer 3, </span><span style="font-family:arial,sans-serif;font-size:13px">vale a dire babel e batman-bmx. </span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Spiega perché non ti sembra appropriato.</span></div><div><font face="arial, sans-serif">Le nostre dorsali non sono sempre tra ip della stessa rete (<a href="http://172.17.0.0/16">172.17.0.0/16</a>) ? </font></div>
<div><font face="arial, sans-serif">Il discorso è essendo la backbone sullo stesso livello fisico degli altri dispositivi perché rinunciare al layer 2 ?</font></div><div><span style="font-family:arial,sans-serif"> </span><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Il giorno 09 dicembre 2013 15:20, Vincenzo Pirrone <span dir="ltr"><<a href="mailto:linuspax@gmail.com" target="_blank">linuspax@gmail.com</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Il 09/12/2013 13:34, Giuseppe De Marco ha scritto:<br>
><br>
> ROUTING<br>
><br>
> Due parole sui protocolli papabili. Vi è inoltre la volontà di<br>
> formalizzare/documentare per le newentry.<br>
><br>
> OLSR è un protocollo Link-State e Proattivo (table-driven).<br>
> Il link-state (routing basato sullo stato del collegamento) utilizza il<br>
> concetto di mappa distribuita, ossia un elenco di tutti i link della rete<br>
> con relativo costo. Tutti i routers hanno una copia di tale mappa che<br>
> viene aggiornata in continuazione<br>
><br>
><br>
> Ogni nodo, periodicamente, usa la tecnica del flooding, chiamata in<br>
> questo caso Link State Broadcast, per inviare a tramite tutti i suoi<br>
> link diretti un messaggio Link State Packet (LSP), contenente tutte le<br>
> informazioni sui link tra il mittente del messaggio e tutti i suoi vicini.<br>
> Alla ricezione di tale messaggio, ogni router, aggiorna la propria<br>
> routing table e lo rispedisce a tutti i suoi vicini diretti tranne<br>
> quello da cui arriva tale<br>
> messaggio.<br>
><br>
> In questo modo tutti i routers hanno sempre memorizzata la mappa della<br>
> rete aggiornata in una struttura ad albero ed il cammino più conveniente<br>
> si ottiene con un algoritmo shortest path ( vedi Dijkstra ).<br>
><br>
> Il fatto che OLSR sia table-driven (ovvero guidato da tabelle di<br>
> scambio) ha un vantaggio e uno svantaggio:<br>
><br>
> PRO: Tutti i possibili percorsi di routing vengono calcolati e<br>
> modificati senza sapere se verranno in futuro utilizzati ( visione a<br>
> 360° della rete ). Otteniamo una tabella di routing biblica, immensa,<br>
> omnicomprensiva (impossibile da consultare senza grep !).<br>
><br>
> CONTRO: FLOOD e carico di sistema. il primo scaturisce dall'attività<br>
> di annunciazione di ogni nodo, il secondo scaturisce dal fatto che lo<br>
> "shortest-path" richiede elaborazione computazionale pari al numero di<br>
> nodi. Quindi più si espande la rete più questi due fattori crescono.<br>
> La propagazione di tutte le tabelle di tutti i nodi<br>
> riduce la banda disponibile (over-head di rete), il carico<br>
> computazionale ai dispositivi<br>
> riduce la reattività degli stessi.<br>
><br>
> Ad ogni modo per OLSRd non è necessario questo flooding venga inviato da<br>
> tutti i nodi, ma basta che<br>
> a inviarlo siano un ristretto numero di vicini del nodo comunicante.<br>
> Questo set di nodi prende il nome di MPR (Multipoint Relays) -<br>
> definito anche Optimized Flooding (MPR).<br>
><br>
> La tecnica MPR nasce dall’osservazione che in una situazione di broadcast<br>
> non ottimizzato ogni nodo riceve più volte le stesse informazioni causando<br>
> un notevole spreco di banda e di potenza di calcolo.<br>
><br>
> L ’RCF di OLSR descrive inoltre un semplice algoritmo euristico per<br>
> calcolare il<br>
> sottoinsieme di MPR. L’Optimized Flooding fa si che un nodo elegga tra i<br>
> suoi vicini (nei-<br>
> ghbor) il minimo insieme che consente di raggiungere tutti i 2-hop-neighbor<br>
> (tutti i vicini a distanza di due hop). Serve quindi capire quanti MPR deve<br>
> avere ogni nodo (tuning) e quali informazioni topologiche far distribuire ai<br>
> propri MPR: chiedo a SPAX e GIGI quali parametri vorremmo analizzare<br>
> al fine di argomentare le esperienze trascorse.<br>
><br>
> andiamo a BATMAN, questo si basa piuttosto che sul Link-State, usando<br>
> le tabelle di routing come media, sul Distance-Vector che si basa<br>
> sull’algoritmo di Bellmann-Ford.<br>
> Ogni nodo mantiene un database con le distanze minime tra se stesso e<br>
> tutte le possibili destinazioni.<br>
> A intervalli regolari invia ai nodi adiacenti un distance-vector, un<br>
> insieme di coppie indirizzo-distanza, chiamate annunci. La distanza è<br>
> espressa come numero di hop o con criteri più generali che tengono<br>
> conto di velocità, carico e affidabilità dei collegamenti.<br>
><br>
> A partire da tali dati, utilizzando l’algoritmo di Bellman-Ford, il<br>
> router co-<br>
> struisce una tabella che associa ad ogni destinazione conosciuta la distan-<br>
> za che lo separa dalla destinazione e il primo passo del percorso calcolato.<br>
> Quando riceve il distance-vector, un nodo puù usare queste informazioni per<br>
> ricalcolare la sua tabella di routing e, a differenza dei Link-State, questo<br>
> messaggio non viene forwardato.<br>
><br>
> Con BATMAN un router ricalcola le proprie tabelle se:<br>
><br>
> • cade una linea attiva direttamente connessa<br>
> • riceve da un router vicino un annuncio per una destinazione non cono-<br>
> sciuta<br>
> • riceve da un router vicino un annuncio per una destinazione già nota,<br>
> ma a costo più basso rispetto a quello memorizzato<br>
> • riceve da un router vicino un annuncio per una destinazione che lo stesso<br>
> router aveva già annunciato precedentemente con costo più elevato<br>
> • scade il tempo massimo di vita (TTL) per una destinazione in tabella<br>
><br>
> Sicuramente a fare più paura è l'ultima condizione, ovvero la<br>
> scadenza del TTL, perchè si traduce in tempi di attesa per aspettare<br>
> che il dispositivo "sperimenti" nuovi percorsi (andando a<br>
> casaccio...Con il pericolo di creare loops...), poichè trovare il<br>
> percorso migliore richiede più tempo<br>
> non avendo l’intera topologia a disposizione per il calcolo e questa<br>
> complessità si traduce nella pratica in velocità di convergenza più bassa.<br>
><br>
> la configurazione dei router risulta molto più semplice e la<br>
> necessità di memoria (RAM) in essi è bassa poichè ogni router deve<br>
> memorizzare solo le informazioni sui collegamenti da se stesso verso gli<br>
> altri nodi<br>
> e non sull’intera rete, questo si traduce in un minor costo.<br>
><br>
> Quello che un nodo batman annuncia si chiama Originator Messages e<br>
> contiene solo il primo hop verso una destinazione (e non tutto lo<br>
> scibile come le tabelle floddate da OLSR).<br>
><br>
> A seguito della terza generazione di Batman è stata ideata la versione<br>
> Advanced che consente di gestire il routing a livello 2 per mezzo di<br>
> un modulo del kernel.<br>
><br>
> Confronti utili:<br>
><br>
> Se la rete supera le centinaia di nodi OLSR impiega molte risorse per<br>
> il calcolo del path più corto, mentre batman divide la conoscenza e<br>
> delega il routing agli hop di competenza.<br>
><br>
> Una rete mesh basata su B.A.T.M.A.N. viene inondata a intervalli regola-<br>
> ri da Originator Messages fino a che non vengono ricevuti dal destinatario<br>
> almeno una volta o finche il pacchetto non viene perso causa fine del TTL<br>
> o problemi di comunicazione. Il protocollo ritiene significativa ogni<br>
> perdita<br>
> di pacchetti per trovare il percorso migliore.<br>
<br>
Ottima sintesi! ho già wikizzato<br>
<a href="http://tracker.hlcs.it/projects/ninux/wiki/BATMAN_vs_OLSR" target="_blank">http://tracker.hlcs.it/projects/ninux/wiki/BATMAN_vs_OLSR</a><br>
<br>
><br>
> DOMANDA: è capitato che OLSR forwardasse roba vecchia di nodi andati<br>
> giù ? Con Batman questo non sarebbe possibile.<br>
<br>
Coi 4 nodi che abbiamo non credo possa succedere, non so a Roma..<br>
<br>
><br>
> Per integrare i due, piuttosto che avere entrambi sui medesimi nodi<br>
> non sarebbe meglio e innovativo (dati gli scopi di ninux) sperimentare<br>
> soluzioni miste con l'adozione di messaggi HNA per gli annunci a<br>
> sistemi differenti (OLSR->HNA->BATMAN e viceversa).<br>
><br>
> Potremmo sperimentare newSPIG con OLSR e Capizzanux con Batman i quali<br>
> comunicano tramite HNA ? Sarebbe il primo esperimento ufficiale dentro<br>
> ninux oppure a Roma hanno già fatto ?<br>
<br>
A Roma è stato fatto. Alcune zone utilizzano batman a livello di<br>
distribuzione, e la subnet viene annunciata tramite HNA proprio come hai<br>
detto. è descritto anche sul paper dell'architettura della rete<br>
<a href="http://blog.ninux.org/wp-content/uploads/2012/06/NinuxRoma-RoutingArchitecture-DocumentVersion0.pdf" target="_blank">http://blog.ninux.org/wp-content/uploads/2012/06/NinuxRoma-RoutingArchitecture-DocumentVersion0.pdf</a><br>
<br>
> Serve quindi capire quanti MPR deve<br>
> avere ogni nodo (tuning) e quali informazioni topologiche far distribuire ai<br>
> propri MPR: chiedo a SPAX e GIGI quali parametri vorremmo analizzare<br>
> al fine di argomentare le esperienze trascorse.<br>
<br>
Sul tuning di OLSR mi trovi impreparato XD<br>
<br>
> CONTRO: FLOOD e carico di sistema. il primo scaturisce dall'attività<br>
> di annunciazione di ogni nodo, il secondo scaturisce dal fatto che lo<br>
> "shortest-path" richiede elaborazione computazionale pari al numero di<br>
> nodi. Quindi più si espande la rete più questi due fattori crescono.<br>
<br>
In ogni caso credo che i problemi sorgano quando si arriva ai ~1000<br>
nodi, il che si può ovviare con un po' di pianificazione:<br>
- mesh di distribuzione (tra apparati domestici, a 2.4GHz) utilizzano<br>
batman-adv e contano come un unico nodo olsr<br>
- per il routing tra isole si ulizza BGP (se si tratta di link cablato)<br>
oppure un'altra istanza di OLSR che annuncia in HNA l'intera isola (se<br>
link wireless).<br>
<br>
Utilizzare un protocollo layer 2 per la dorsale invece non mi sembra<br>
appropriato, ma sicuramente dovremmo valutare le alternative layer 3,<br>
vale a dire babel e batman-bmx.<br>
<br>
BTW qualcuno sa dove trovare i risultati dei test dell'utlimo battle mesh?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Vincenzo Pirrone<br>
Twitter: @spax_arm<br>
PGP Key ID: 5CF5047D<br>
<br>
</font></span><br>_______________________________________________<br>
Calabria mailing list<br>
<a href="mailto:Calabria@ml.ninux.org">Calabria@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/calabria" target="_blank">http://ml.ninux.org/mailman/listinfo/calabria</a><br>
<br></blockquote></div><br></div>