|
⇤ ← Revision 1 as of 2016-01-14 10:32:40
Size: 6637
Comment:
|
← Revision 2 as of 2016-07-27 10:27:43 ⇥
Size: 112
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Modulo QSPN - Esempio di uso degli indirizzi virtuali = == Passo 11 == Ora analiziamo alcune delle dinamiche nella rete che possono portare alla rimozione di indirizzi ''di connettività'' sui nodi. Supponiamo che a causa di variazioni nelle condizioni atmosferiche, ora il nodo 𝜀 e il nodo 𝛾 sono a distanza di rilevamento con la loro interfaccia "eth1". Siccome entrambi hanno due identità devono valutare quali archi vanno formati: * L'arco fra le due identità ''definitive'' si forma sempre. Quindi abbiamo 𝜀~-,,N,,-~-𝛾~-,,N,,-~. * L'identità 𝜀~-,,i(2,2),,-~ è ''di connettività'' al livello 2 e ha indirizzo [1, 2, 1]. L'identità 𝛾~-,,N,,-~ ha indirizzo [0, 0, 0] e quindi non appartiene a [1]. Quindi '''non''' abbiamo 𝜀~-,,i(2,2),,-~-𝛾~-,,N,,-~. * Analogamente, l'identità 𝛾~-,,i(2,2),,-~ è ''di connettività'' al livello 2 e ha indirizzo [0, 2, 1]. L'identità 𝜀~-,,N,,-~ ha indirizzo [1, 0, 0] e quindi non appartiene a [1]. Quindi '''non''' abbiamo 𝜀~-,,N,,-~-𝛾~-,,i(2,2),,-~. * L'identità 𝜀~-,,i(2,2),,-~ e L'identità 𝛾~-,,i(2,2),,-~ appartengono entrambe a [1]. Quindi abbiamo 𝜀~-,,i(2,2),,-~-𝛾~-,,i(2,2),,-~. {{drawing:grafo13.adraw}} Diamo questi comandi ai nodi: * nodo 𝛾 . {{{ ip route add 169.254.163.36 dev eth1 src 169.254.94.223 ip netns exec ntkv1 ip route add 169.254.241.153 dev ntkv1_eth1 src 169.254.24.198 }}} * nodo 𝜀 . {{{ ip route add 169.254.94.223 dev eth1 src 169.254.163.36 ip netns exec ntkv1 ip route add 169.254.24.198 dev ntkv1_eth1 src 169.254.241.153 }}} La presenza di un nuovo arco su ciascuna delle 4 identità coinvolte scatena una serie di trasmissioni di ETP, al termine delle quali abbiamo queste nuove conoscenze: * Il nodo 𝛾~-,,N,,-~ conosce un nuovo percorso per [1, 0, 0] costituito dall'arco 𝛾~-,,N,,-~-𝜀~-,,N,,-~. * Il nodo 𝜀~-,,N,,-~ conosce un nuovo percorso per [0, 0, 0] costituito dall'arco 𝜀~-,,N,,-~-𝛾~-,,N,,-~. * Il nodo 𝛽~-,,i(1,2),N,,-~ conosce un nuovo percorso per [0, 0, 0] costituito dagli archi 𝛽~-,,i(1,2),N,,-~-𝜀~-,,N,,-~-𝛾~-,,N,,-~ e un nuovo percorso per [1, 0, 0] costituito dagli archi 𝛽~-,,i(1,2),N,,-~-𝛾~-,,N,,-~-𝜀~-,,N,,-~. * Il nodo 𝛾~-,,i(2,2),,-~ conosce un nuovo percorso per [1, 2, 1] costituito dall'arco 𝛾~-,,i(2,2),,-~-𝜀~-,,i(2,2),,-~. * Il nodo 𝜀~-,,i(2,2),,-~ conosce un nuovo percorso per [0, 2, 1] costituito dall'arco 𝜀~-,,i(2,2),,-~-𝛾~-,,i(2,2),,-~. * Il nodo 𝛽~-,,i(1,2),i(2,2),,-~ conosce un nuovo percorso per [0, 2, 1] costituito dagli archi 𝛽~-,,i(1,2),i(2,2),,-~-𝜀~-,,i(2,2),,-~-𝛾~-,,i(2,2),,-~ e un nuovo percorso per [1, 2, 1] costituito dagli archi 𝛽~-,,i(1,2),i(2,2),,-~-𝛾~-,,i(2,2),,-~-𝜀~-,,i(2,2),,-~. Per il momento non descriviamo i comandi che sui vari nodi queste nuove conoscenze potrebbero scatenare o meno (sulla base dei costi dei vari archi). Rimandiamo questo a dopo per analizzare da subito la possibilità di rimuovere alcuni indirizzi ''di connettività''. Ora il nodo 𝛽~-,,i(1,2),i(2,2),,-~ si domanda se la rimozione del suo indirizzo [2, 2, 1] che è ''di connettività'' ai livelli da 1 a 2, provoca lo split del g-nodo [2, 1] o del g-nodo [1]. Applichiamo la regola generale esposta nel documento di [[Netsukuku/ita/docs/ModuloQSPN/AnalisiFunzionale#ImplementazioneVerificaRimozione|analisi]] con ''i'' = 0 e ''j'' = 2, dove ''i'' è il livello del g-nodo che si dovrebbe rimuovere, il quale è ''di connettività'' ai livelli da ''i'' + 1 a ''j''. Per prima cosa si cerca il livello più piccolo ''k'', partendo da ''i'' + 1, in cui il g-nodo ''g~-,,k-1,,-~(''𝛽~-,,i(1,2),i(2,2),,-~'')'' ha almeno un vicino in ''g~-,,k,,-~(''𝛽~-,,i(1,2),i(2,2),,-~'')''. Nel nostro caso è 1, in quanto [2, 2, 1] (l'equivalente di ''g~-,,k-1,,-~(''𝛽~-,,i(1,2),i(2,2),,-~'')'') ha i vicini [1, 2, 1] e [0, 2, 1] in [2, 1] (l'equivalente di ''g~-,,k,,-~(''𝛽~-,,i(1,2),i(2,2),,-~'')''). Questo è l'insieme dei g-nodi di livello da 0 a 1 che 𝛽~-,,i(1,2),i(2,2),,-~ vede nella sua mappa: {[0, 2, 1], [1, 2, 1], [1, 1], [0, 1]}. Questo è l'insieme dei g-nodi di livello da 0 che 𝛽~-,,i(1,2),i(2,2),,-~ vede nella sua mappa come diretti vicini di [2, 2, 1]: {[0, 2, 1], [1, 2, 1]}. Per ogni elemento ''x'' del primo set, per ogni elemento ''y'' del secondo set, se ''x'' ≠ ''y'', il nodo 𝛽~-,,i(1,2),i(2,2),,-~ è a conoscenza di un percorso per ''x'' che passa per ''y''. Quindi 𝛽~-,,i(1,2),i(2,2),,-~ sa che è possibile rimuovere l'indirizzo ''di connettività'' [2, 2, 1]. In modo del tutto simile il nodo 𝛽~-,,i(1,2),N,,-~ scopre che è possibile rimuovere l'indirizzo ''di connettività'' [2, 2, 0]. {{drawing:grafo14.adraw}} Diamo questi comandi ai nodi: * nodo 𝛽 . {{{ # rimuove 𝛽i12,N ip netns exec ntkv0 ip link delete ntkv0_eth1 type macvlan ip netns del ntkv0 # rimuove 𝛽i12,i22 ip netns exec ntkv1 ip link delete ntkv1_eth1 type macvlan ip netns del ntkv1 }}} * nodo 𝛾 . {{{ # come 𝛾N ip route change 10.0.0.1/32 via 169.254.163.36 dev eth1 src 10.0.0.0 ip route change 10.0.1.1/32 via 169.254.163.36 dev eth1 src 10.0.1.0 ip route change 10.0.2.1/32 via 169.254.163.36 dev eth1 src 10.0.2.0 ip route del 169.254.27.218 dev eth1 src 169.254.94.223 # come 𝛾i22 ip netns exec ntkv1 ip route change 10.0.0.6/31 via 169.254.241.153 dev ntkv1_eth1 ip netns exec ntkv1 ip route change 10.0.1.1/32 via 169.254.241.153 dev ntkv1_eth1 src 10.0.1.0 ip netns exec ntkv1 ip route change 10.0.2.2/31 via 169.254.241.153 dev ntkv1_eth1 ip netns exec ntkv1 ip route del 169.254.42.4 dev ntkv1_eth1 src 169.254.24.198 }}} * nodo 𝜀 . {{{ # come 𝜀N ip route change 10.0.0.0/32 via 169.254.94.223 dev eth1 src 10.0.0.1 ip route change 10.0.1.0/32 via 169.254.94.223 dev eth1 src 10.0.1.1 ip route change 10.0.2.0/32 via 169.254.94.223 dev eth1 src 10.0.2.1 ip route del 169.254.27.218 dev eth1 src 169.254.163.36 # come 𝜀i22 ip netns exec ntkv1 ip route change 10.0.0.0/30 via 169.254.24.198 dev ntkv1_eth1 ip netns exec ntkv1 ip route change 10.0.0.4/31 via 169.254.24.198 dev ntkv1_eth1 ip netns exec ntkv1 ip route change 10.0.1.0/32 via 169.254.24.198 dev ntkv1_eth1 src 10.0.1.1 ip netns exec ntkv1 ip route change 10.0.2.0/31 via 169.254.24.198 dev ntkv1_eth1 ip netns exec ntkv1 ip route del 169.254.42.4 dev ntkv1_eth1 src 169.254.241.153 }}} Possiamo infine verificare che tutti i nodi raggiungono correttamente tutti gli indirizzi IP globali e gli indirizzi IP ''interni'' ai loro g-nodi di livello 1 e 2. |
[[https://github.com/lukisi/documentation/blob/master/ita/ModuloQspn/UsoIndirizziVirtuali/Step11.md|Redirect]] |
- Diff for "Netsukuku/ita/docs/ModuloQSPN/Esempio1/Step11"