|
Size: 9491
Comment:
|
← Revision 3 as of 2016-07-27 10:29:58 ⇥
Size: 111
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Modulo QSPN - Esempio di uso degli indirizzi virtuali = == Passo 8 == In questo passo assegnamo alle nuove identità in 𝜑~-,,N,,-~, un indirizzo ''definitivo'' nel g-nodo ''N''. Per l'esattezza gli assegnamo l'indirizzo ''virtuale'' [2, 0]. Nel disegno seguente gli archi che collegano nodi che ora fanno parte della rete non sono più tratteggiati. {{drawing:grafo10.adraw}} Poiché i nuovi indirizzi ''definitivi'' sono ''virtuali'' al livello 1, la loro assegnazione non comporta un comando di assegnazione di indirizzo IP globale nella rete per i nodi in 𝜑~-,,N,,-~, né di un indirizzo ''interno'' al livello 2. I nodi in 𝜑~-,,N,,-~ avevano già assegnato un indirizzo ''interno'' al livello 1. Ora ogni border-nodo in 𝜑~-,,N,,-~ chiede un ETP completo ai vicini che non appartengono a 𝜑~-,,N,,-~ tramite i suoi archi e li processa con questo nuovo indirizzo. Grazie ad essi: * Il nodo 𝜀~-,,N,,-~ sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝜀~-,,N,,-~-𝛽~-,,B,,-~. * Il nodo 𝜀~-,,N,,-~ sa di poter raggiungere il g-nodo [1] passando per l'arco 𝜀~-,,N,,-~-𝛽~-,,B,,-~. Il percorso sarebbe 𝜀~-,,N,,-~-𝛽~-,,B,,-~-𝛾~-,,i(2,2),,-~. Si tratta di un percorso che rimarrà valido per poco tempo in quanto l'arco 𝛽~-,,B,,-~-𝛾~-,,i(2,2),,-~ sparirà presto. Ma a quel punto potrà avvalersi di un altro percorso, 𝜀~-,,N,,-~-𝛽~-,,i(1,2),N,,-~-𝛾~-,,N,,-~-𝛿 che verrà scoperto a breve. * Il nodo 𝛾~-,,N,,-~ sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝛾~-,,N,,-~-𝛽~-,,B,,-~. * Il nodo 𝛾~-,,N,,-~ sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛾~-,,N,,-~-𝛿. Quindi diamo questi comandi: * nodo 𝜀 . {{{ ip route add 10.0.0.2/31 via 169.254.96.141 dev eth1 ip route add 10.0.2.2/31 via 169.254.96.141 dev eth1 ip route add 10.0.0.4/30 via 169.254.96.141 dev eth1 }}} * nodo 𝛾 . {{{ ip route add 10.0.0.2/31 via 169.254.96.141 dev eth1 ip route add 10.0.2.2/31 via 169.254.96.141 dev eth1 ip route add 10.0.0.4/30 via 169.254.253.216 dev eth1 }}} I border-nodi in 𝜑~-,,N,,-~ potrebbero anche chiedere un ETP ai vicini che appartengono a 𝜑~-,,N,,-~, ma effettivamente non lo otterrebbero perché questi non hanno completato il loro bootstrap. Invece bisogna notare che i nodi in 𝜑~-,,N,,-~ che non sono border-nodi, sebbene chiedano un ETP completo a tutti i loro vicini e non ne ricevono nessuno, non devono considerare fallito il loro ingresso nella rete. Tra l'altro essi hanno ricevuto dalla loro precedente identità alcuni percorsi verso g-nodi di livello inferiore a 1 (il livello della migrazione). Poi i border-nodi in 𝜑~-,,N,,-~ avendo completato la fase di bootstrap ritrasmettono un ETP completo ai vicini. In questo modo le conoscenze riprendono a propagarsi sia ai nodi interni a 𝜑~-,,N,,-~ che al di fuori. Riassumiamo queste nuove conoscenze: * Il nodo 𝛽~-,,B,,-~ sa di poter raggiungere il g-nodo [2, 0] passando per l'arco 𝛽~-,,B,,-~-𝜀~-,,N,,-~. * Il nodo 𝛽~-,,B,,-~ sa di poter raggiungere il g-nodo [2, 0] passando per l'arco 𝛽~-,,B,,-~-𝛾~-,,N,,-~. Supponiamo che preferisca il precedente arco 𝛽~-,,B,,-~-𝜀~-,,N,,-~. . Per ora, siccome l'indirizzo di destinazione è ''virtuale'', questo non comporta alcun comando. * Il nodo 𝛽~-,,B,,-~ sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛽~-,,B,,-~-𝛾~-,,N,,-~. Già sapeva di poterlo fare passando per l'arco 𝛽~-,,B,,-~-𝛾~-,,i(2,2),,-~. Per ora non cambia la rotta che già aveva impostata. * Il nodo 𝛼 sa di poter raggiungere il g-nodo [2, 0] passando per l'arco 𝛼-𝛽~-,,B,,-~. . Per ora, siccome l'indirizzo di destinazione è ''virtuale'', questo non comporta alcun comando. * Il nodo 𝛿 sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛿-𝛾~-,,N,,-~. Già sapeva di poterlo fare passando per l'arco 𝛿-𝛾~-,,i(2,2),,-~. Questo nuovo percorso è certamente migliore, quindi cambia la rotta che già aveva impostata. * Per quanto sopra, il nodo 𝛾~-,,i(2,2),,-~ apprende il percorso verso il g-nodo [0] costituito dagli archi 𝛾~-,,i(2,2),,-~-𝛿-𝛾~-,,N,,-~. Per ora tale percorso non migliora il vecchio 𝛾~-,,i(2,2),,-~-𝛽~-,,B,,-~, quindi non cambia la rotta che già aveva impostata. * Per quanto sopra, il nodo 𝛽~-,,i(1,2),i(2,2),,-~ apprende il percorso verso il g-nodo [0] costituito dagli archi 𝛽~-,,i(1,2),i(2,2),,-~-𝛾~-,,i(2,2),,-~-𝛿-𝛾~-,,N,,-~. Per ora tale percorso non migliora il vecchio 𝛽~-,,i(1,2),i(2,2),,-~-𝛾~-,,i(2,2),,-~-𝛽~-,,B,,-~, quindi non cambia la rotta che già aveva impostata. Tra l'altro il gateway sarebbe rimasto lo stesso. * Per quanto sopra, il nodo 𝜀~-,,i(2,2),,-~ apprende il percorso verso il g-nodo [0] costituito dagli archi 𝜀~-,,i(2,2),,-~-𝛽~-,,i(1,2),i(2,2),,-~-𝛾~-,,i(2,2),,-~-𝛿-𝛾~-,,N,,-~. Per ora tale percorso non migliora il vecchio 𝜀~-,,i(2,2),,-~-𝛽~-,,B,,-~, quindi non cambia la rotta che già aveva impostata. * Il nodo 𝛽~-,,i(1,2),N,,-~ sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝛽~-,,i(1,2),N,,-~-𝜀~-,,N,,-~. * Il nodo 𝛽~-,,i(1,2),N,,-~ sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝛽~-,,i(1,2),N,,-~-𝛾~-,,N,,-~. Supponiamo che preferisca il precedente arco 𝛽~-,,i(1,2),N,,-~-𝜀~-,,N,,-~. * Il nodo 𝛽~-,,i(1,2),N,,-~ sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛽~-,,i(1,2),N,,-~-𝛾~-,,N,,-~. * Il nodo 𝛽~-,,i(1,2),N,,-~ sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛽~-,,i(1,2),N,,-~-𝜀~-,,N,,-~. Il percorso sarebbe 𝛽~-,,i(1,2),N,,-~-𝜀~-,,N,,-~-𝛽~-,,B,,-~-𝛾~-,,i(2,2),,-~. Supponiamo che preferisca il precedente arco 𝛽~-,,i(1,2),N,,-~-𝛾~-,,N,,-~. * Il nodo 𝜀~-,,N,,-~ sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝜀~-,,N,,-~-𝛽~-,,i(1,2),N,,-~. Questo percorso di sicuro non è migliore di quello che già conosceva attraverso l'arco 𝜀~-,,N,,-~-𝛽~-,,B,,-~. * Il nodo 𝜀~-,,N,,-~ sa di poter raggiungere il g-nodo [1] passando per l'arco 𝜀~-,,N,,-~-𝛽~-,,i(1,2),N,,-~. Per ora di sicuro il nodo preferisce il percorso che conosceva: 𝜀~-,,N,,-~-𝛽~-,,B,,-~-𝛾~-,,i(2,2),,-~. * Il nodo 𝛾~-,,N,,-~ sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝛾~-,,N,,-~-𝛽~-,,i(1,2),N,,-~. Per ora di sicuro il nodo preferisce il percorso che conosceva: 𝛾~-,,N,,-~-𝛽~-,,B,,-~. * Il nodo 𝛾~-,,N,,-~ sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛾~-,,N,,-~-𝛽~-,,i(1,2),N,,-~. Il percorso sarebbe 𝛾~-,,N,,-~-𝛽~-,,i(1,2),N,,-~-𝜀~-,,N,,-~-𝛽~-,,B,,-~-𝛾~-,,i(2,2),,-~. Supponiamo che preferisca il precedente arco 𝛾~-,,N,,-~-𝛿. Quindi diamo questi comandi: * nodo 𝛽 . {{{ ip netns exec ntkv0 ip route add 10.0.0.2/31 via 169.254.163.36 dev ntkv0_eth1 ip netns exec ntkv0 ip route add 10.0.2.2/31 via 169.254.163.36 dev ntkv0_eth1 ip netns exec ntkv0 ip route add 10.0.0.4/30 via 169.254.94.223 dev ntkv0_eth1 }}} * nodo 𝛿 . {{{ ip route change 10.0.0.0/30 via 169.254.94.223 dev eth1 src 10.0.0.5 }}} Ora i border-nodi in 𝜑~-,,N,,-~, avendo trasmesso i primi ETP e atteso qualche istante per la loro processazione da parte dei vicini, con le loro identità in 𝜑~-,,i(2,2),,-~ rimuovono i loro archi con nodi che non appartengono al loro g-nodo di livello 2. Si ricordi infatti che il livello più alto in cui i due g-nodi ''M'' e ''N'' differiscono è 2. Quindi 𝜀~-,,i(2,2),,-~ rimuove il suo arco con 𝛽~-,,B,,-~ e 𝛾~-,,i(2,2),,-~ rimuove il suo arco con 𝛽~-,,B,,-~. Ricordiamo che: * Il nodo 𝛽~-,,B,,-~ conosce un percorso verso il g-nodo [1] per l'arco 𝛽~-,,B,,-~-𝛾~-,,N,,-~. * Il nodo 𝛾~-,,i(2,2),,-~ conosce un percorso verso il g-nodo [0] per l'arco 𝛾~-,,i(2,2),,-~-𝛿. * Il nodo 𝛽~-,,i(1,2),i(2,2),,-~ conosce un percorso verso il g-nodo [0] per l'arco 𝛽~-,,i(1,2),i(2,2),,-~-𝛾~-,,i(2,2),,-~. * Il nodo 𝜀~-,,i(2,2),,-~ conosce un percorso verso il g-nodo [0] per l'arco 𝜀~-,,i(2,2),,-~-𝛽~-,,i(1,2),i(2,2),,-~. Quindi diamo questi comandi: * nodo 𝛽 . {{{ ip r change 10.0.0.4/30 via 169.254.94.223 dev eth1 src 10.0.0.3 ip route del 169.254.241.153 dev eth1 src 169.254.96.141 ip route del 169.254.24.198 dev eth1 src 169.254.96.141 }}} * nodo 𝜀 . {{{ ip netns exec ntkv1 ip route change 10.0.0.0/30 via 169.254.42.4 dev ntkv1_eth1 ip netns exec ntkv1 ip route del 169.254.96.141 dev ntkv1_eth1 src 169.254.241.153 }}} * nodo 𝛾 . {{{ ip netns exec ntkv1 ip route change 10.0.0.0/30 via 169.254.253.216 dev ntkv1_eth1 ip netns exec ntkv1 ip route del 169.254.96.141 dev ntkv1_eth1 src 169.254.24.198 }}} Aggiorniamo il disegno. {{drawing:grafo11.adraw}} Gli stessi border-nodi in 𝜑~-,,N,,-~ che hanno rimosso questi archi, ora comunicano le variazioni apportate alla loro mappa tramite un ETP agli altri vicini. Si aggiungono queste conoscenze: * Il nodo 𝛽~-,,i(1,2),i(2,2),,-~ non ha più il percorso 𝛽~-,,i(1,2),i(2,2),,-~-𝛾~-,,i(2,2),,-~-𝛽~-,,B,,-~ per raggiungere il g-nodo [0], ma solo 𝛽~-,,i(1,2),i(2,2),,-~-𝛾~-,,i(2,2),,-~-𝛿-𝛾~-,,N,,-~. Dovrebbe cambiare la rotta che aveva impostata, ma il gateway rimane lo stesso quindi non darà alcun comando. Non risultano necessari altri comandi. Proseguiamo con il [[../Step9|passo 9]]. |
[[https://github.com/lukisi/documentation/blob/master/ita/ModuloQspn/UsoIndirizziVirtuali/Step8.md|Redirect]] |
- Diff for "Netsukuku/ita/docs/ModuloQSPN/Esempio1/Step8"