Differences between revisions 4 and 5
Revision 4 as of 2016-01-13 07:32:03
Size: 5552
Editor: lukisi
Comment:
Revision 5 as of 2016-07-27 10:28:50
Size: 111
Editor: lukisi
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Modulo QSPN - Esempio di uso degli indirizzi virtuali =

== Passo 4 ==
In questo passo assegnamo alla nuova identità di 𝛽, 𝛽~-,,B,,-~, un indirizzo ''definitivo'' nel g-nodo g~-,,1,,-~(𝛼). Per l'esattezza gli assegnamo l'indirizzo ''virtuale'' [2, 1, 0].

Nel disegno seguente gli archi di 𝛽~-,,B,,-~ con 𝛼 e 𝛾 non sono più tratteggiati in quanto 𝛽~-,,B,,-~ fa ora parte della rete.

{{drawing:grafo5.adraw}}

Riassumiamo l'elenco di tutti gli archi ora esistenti coi relativi indirizzi IP link-local:
 * 𝛼-𝛽~-,,B,,-~
 . 169.254.69.30-169.254.96.141
 * 𝛼-𝛽~-,,i(1,2),,-~
 . 169.254.69.30-169.254.27.218
 * 𝛾-𝛽~-,,B,,-~
 . 169.254.94.223-169.254.96.141
 * 𝛾-𝛽~-,,i(1,2),,-~
 . 169.254.94.223-169.254.27.218
 * 𝜀-𝛽~-,,B,,-~
 . 169.254.163.36-169.254.96.141
 * 𝜀-𝛽~-,,i(1,2),,-~
 . 169.254.163.36-169.254.27.218
 * 𝛾-𝛿
 . 169.254.94.223-169.254.253.216
 * 𝛿-𝜇
 . 169.254.253.216-169.254.119.176

Non ci sono, comunque, da fare nuove assegnazioni di indirizzi né di rotte verso nodi vicini.

Poiché il nuovo indirizzo ''definitivo'' di 𝛽~-,,B,,-~ è ''virtuale'' al livello 0, la sua assegnazione non comporta un comando di assegnazione di indirizzo IP globale nella rete per il nodo 𝛽, né di un indirizzo ''interno'' al livello 2, né di un indirizzo ''interno'' al livello 1.

Ora il nodo 𝛽~-,,B,,-~ chiede un ETP completo ai vicini tramite i suoi archi e li processa con questo nuovo indirizzo. Grazie ad essi:
 * Il nodo 𝛽~-,,B,,-~ sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛽~-,,B,,-~-𝛾.
 * Il nodo 𝛽~-,,B,,-~ sa di poter raggiungere il nodo [0, 1, 0] passando per l'arco 𝛽~-,,B,,-~-𝛼.

Quindi diamo questi comandi:
 * nodo 𝛽
 . {{{
ip route add 10.0.0.4/30 via 169.254.94.223 dev eth1
ip route add 10.0.0.2/32 via 169.254.69.30 dev eth1
ip route add 10.0.2.2/32 via 169.254.69.30 dev eth1
ip route add 10.0.1.0/32 via 169.254.69.30 dev eth1
}}}

Il nodo 𝛽~-,,B,,-~ avendo ora completato il suo bootstrap, comunica via ETP ai suoi vicini 𝛼 e 𝛾 tutti i percorsi che conosce. Quindi ora:
 * Il nodo 𝛼 sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛼-𝛽~-,,B,,-~.
 * Il nodo 𝛾 sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛾-𝛽~-,,B,,-~.
 * Il nodo 𝛽~-,,i(1,2),,-~ sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛽~-,,i(1,2),,-~-𝛾.

Sono conoscenze nuove, ma che non cambiano il miglior percorso verso quelle destinazioni per quei nodi. Quindi nessun comando verrà dato.

Inoltre ora:
 * Il nodo 𝛼 sa di poter raggiungere il nodo [2, 1, 0] passando per l'arco 𝛼-𝛽~-,,B,,-~.

Anche questa è una conoscenza nuova, ma l'indirizzo di destinazione è ''virtuale''. Quindi nessun comando verrà dato.

Ora che il nodo 𝛽~-,,B,,-~ ha trasmesso i suoi primi ETP ai diretti vicini 𝛼 e 𝛾, dopo aver atteso qualche istante per permettere la loro processazione da parte di 𝛼 e 𝛾, il nodo 𝛽~-,,i(1,2),,-~ rimuove i suoi archi con nodi che non appartengono al suo g-nodo di livello 2. Si ricordi infatti che il livello più alto in cui i due g-nodi A e B differiscono è 2. Quindi 𝛽~-,,i(1,2),,-~ rimuove il suo arco con il nodo 𝛼.

Questo fa si che il nodo 𝛼 non può più raggiungere il g-nodo [1] passando per l'arco 𝛼-𝛽~-,,i(1,2),,-~. Però abbiamo detto prima che aveva appreso di poterlo fare passando per l'arco 𝛼-𝛽~-,,B,,-~.

Va quindi cambiata, dal nodo 𝛼, la rotta verso 10.0.0.4/30, sostituendo il gateway 𝛽~-,,i(1,2),,-~ con 𝛽~-,,B,,-~. Va poi rimossa, dal nodo 𝛼, la sua rotta verso 𝛽~-,,i(1,2),,-~.

Va poi rimossa, dal nodo 𝛽, la rotta di 𝛽~-,,i(1,2),,-~ verso 𝛼, e vanno rimosse o cambiate le rotte che eventualmente si appoggiavano su tale arco.

Quindi diamo questi comandi:
 * nodo 𝛼
 . {{{
ip route change 10.0.0.4/30 src 10.0.0.2 via 169.254.96.141 dev eth1
ip route del 169.254.27.218 dev eth1 src 169.254.69.30
}}}
 * nodo 𝛽
 . {{{
ip netns exec ntkv0 ip route change 10.0.0.0/30 via 169.254.94.223 dev ntkv0_eth1
ip netns exec ntkv0 ip route del 169.254.69.30 dev ntkv0_eth1 src 169.254.27.218
}}}

Ora il nodo 𝛽~-,,B,,-~, avendo rimosso un suo arco, comunica le variazioni apportate alla sua mappa tramite un ETP agli altri vicini. Quindi il nodo 𝛾, al ricevere tale ETP, sa che non può più raggiungere il g-nodo [0] passando per l'arco 𝛾-𝛽~-,,i(1,2),,-~. Però abbiamo detto prima che aveva appreso di poterlo fare passando per l'arco 𝛾-𝛽~-,,B,,-~. Va quindi cambiata, dal nodo 𝛾, la rotta verso 10.0.0.0/30, sostituendo il gateway 𝛽~-,,i(1,2),,-~ con 𝛽~-,,B,,-~.

Quindi diamo questi comandi:
 * nodo 𝛾
 . {{{
ip route change 10.0.0.0/30 src 10.0.0.6 via 169.254.96.141 dev eth1
}}}

Riassumiamo l'elenco degli archi ora presenti e il grafo che descrive la rete.
 * 𝛼-𝛽~-,,B,,-~
 * 𝛾-𝛽~-,,B,,-~
 * 𝜀-𝛽~-,,B,,-~
 * 𝛾-𝛽~-,,i(1,2),,-~
 * 𝛾-𝛿
 * 𝛿-𝜇
 * 𝜀-𝛽~-,,i(1,2),,-~

{{drawing:grafo6.adraw}}

Temporaneamente, il nodo 𝛽 non è in grado di comunicare con gli altri nodi della rete in quanto ha solo indirizzi ''virtuali'' al livello 0. Nonostante questo, il nodo è perfettamente in grado di inoltrare pacchetti provenienti da altri nodi e destinati ad altri nodi nella rete. Quindi sebbene 𝛽 sia un nodo punto di articolazione, il grafo resta connesso.

Proseguiamo con il [[../Step5|passo 5]].
[[https://github.com/lukisi/documentation/blob/master/ita/ModuloQspn/UsoIndirizziVirtuali/Step4.md|Redirect]]

Netsukuku/ita/docs/ModuloQSPN/Esempio1/Step4 (last edited 2016-07-27 10:28:50 by lukisi)