[ninux-dev] Diff della topologia

Clauz clauz at ninux.org
Mon Nov 10 15:03:31 CET 2014


On 11/10/2014 11:06 AM, Nemesis wrote:
> On 11/10/2014 10:45 AM, Clauz wrote:
>> On 11/09/2014 11:34 PM, Nemesis wrote:
>>> @Clauz: per quanto riguarda tutte le feature del vecchio parser, hai una
>>> vaga idea di come potremo riportarle su questo nuovo? Ho paura che
>>> alcune cose saranno toste perchè forse lo script che sta dentro nodeshot
>>> 0.9 fa molte cose specifiche per noi... o sbaglio? Spero di sbagliarmi
>>> ... :D
>> La notte porta consiglio: forse abbiamo un problema di design. Provo a
>> spiegarlo.
>>
>> Sulla rete di ninux Roma (ma non so quanto sia specifico di ninux Roma)
>> abbiamo alcuni link wireless fatti in questo modo:
>>  - da una parte del link wireless un apparato che NON parla OLSR, con
>> indirizzo IP IP_A
>>  - dall'altra parte del link wireless un apparato che parla OLSR e che
>> annuncia in HNA una subnet che comprende IP_A
>>
>> Esempi di questo setup sono il link tra i nodi Namex (10.162.0.27) e
>> Ninux (HNA 10.162.0.0/24), oppure tra Halnet-2 (10.135.4.254), Halnet-3
>> (10.135.5.253) e Halnet (HNA 10.135.4.0/24 e HNA 10.135.5.0/24).
>>
> 
> Ma questo caso che hai citato è la faccenda del link layer2? Quali altri
> casi speciali ci sono?

Penso che sia quella stessa faccenda, ma in realta' non e' layer2: si
tratta in generale di un link layer3 tra un nodo che parla OLSR e uno
che non lo parla.

Un altro caso speciale che mi viene in mente: molte isole annunciano
dentro OLSR come HNA le network apprese dalle altre isole tramite BGP.
Questo portava, grazie al check IP->HNA spiegato nella precedente
e-mail, ad avere link disegnati tra isole molto distanti.

Quindi attualmente lo script usa molto grezzamente una costante
HNA_COUNT_THRESHOLD (settata a 12) per evitare di considerare i nodi che
annunciano piu' di HNA_COUNT_THRESHOLD HNA diverse [*].

> In questo tipo di casi io si potrebbe dare la possibilità a nodeshot di
> gestirli evitando di twistare netdiff.
> 
> Ad esempio: sul nuovo nodeshot potremmo creare i link speciali
> manualmente e potremmo fare in modo che non vengano gestiti dal
> componente che aggiorna la topologia. Poi magari dopo qualche tempo esce
> fuori che un sacco di altra gente che usa netdiff ha lo stesso problema
> e si implementa una soluzione direttamente in netdiff.
> 
> E' solo un esempio per rendere l'idea che non dobbiamo provare a
> risolvere tutto subito, possiamo procedere un passo alla volta.
[CUT]

Vedo che tra le opzioni hai scelto "algoritmo dello struzzo", la mia
preferita :) L'importante e' essere coscienti che esistono queste eccezioni.

Clauz

[*]
https://github.com/ninuxorg/nodeshot/blob/0.9.x/nodeshot/scripts/read_topology_hna.py#L379



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/ninux-dev/attachments/20141110/0a7d53c6/attachment-0001.sig>


More information about the ninux-dev mailing list