|
⇤ ← Revision 1 as of 2016-01-13 07:33:33
Size: 3758
Comment:
|
← Revision 2 as of 2016-07-28 08:50:47 ⇥
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 9 == In questo passo, siccome il g-nodo [0] non è pieno, possiamo assegnare a 𝜑~-,,N,,-~ un indirizzo ''reale'' ''definitivo'' in esso, cioè modificare il [2, 0] in [0, 0]. O meglio, ciascun nodo che ha una identità in 𝜑~-,,N,,-~ (vale a dire 𝛽~-,,i(1,2),N,,-~, 𝛾~-,,N,,-~ ed 𝜀~-,,N,,-~) modifica l'indirizzo gestito da quella identità. Alcuni comandi vanno dati sui nodi che hanno in 𝜑~-,,N,,-~ la loro identità che gestisce l'indirizzo ''definitivo'', vale a dire solo 𝛾~-,,N,,-~ ed 𝜀~-,,N,,-~. Ad essi dobbiamo aggiungere l'indirizzo IP globale e gli indirizzi IP ''interni'' ai propri g-nodi di livello maggiore del livello di 𝜑, cioè 1. Nel nostro caso, l'indirizzo nella classe 10.0.0.0/24 e quello nella classe 10.0.2.0/24. Dopo vanno cambiate le rotte nella relativa tabella di modo da avere questi indirizzi come source preferiti, "src", per i pacchetti originati dal nodo. Inoltre, su ogni nodo che ha una identità in 𝜑~-,,N,,-~, per ogni rotta verso indirizzi IP ''interni'' ai propri g-nodi di livello minore o uguale al livello di 𝜑, cioè 1, va aggiunta una analoga rotta che abbia quella destinazione espressa come indirizzo IP globale e una per ogni indirizzo IP ''interno'' ai propri g-nodi di livello maggiore del livello di 𝜑. Quindi diamo questi comandi: * nodo 𝛾 . {{{ ip address add 10.0.0.0 dev eth1 ip address add 10.0.2.0 dev eth1 ip route change 10.0.0.2/31 via 169.254.96.141 dev eth1 src 10.0.0.0 ip route change 10.0.0.4/30 via 169.254.253.216 dev eth1 src 10.0.0.0 ip route change 10.0.2.2/31 via 169.254.96.141 dev eth1 src 10.0.2.0 ip route add 10.0.0.1 via 169.254.27.218 dev eth1 src 10.0.0.0 ip route add 10.0.2.1 via 169.254.27.218 dev eth1 src 10.0.2.0 }}} * nodo 𝜀 . {{{ ip address add 10.0.0.1 dev eth1 ip address add 10.0.2.1 dev eth1 ip route change 10.0.0.2/31 via 169.254.96.141 dev eth1 src 10.0.0.1 ip route change 10.0.0.4/30 via 169.254.96.141 dev eth1 src 10.0.0.1 ip route change 10.0.2.2/31 via 169.254.96.141 dev eth1 src 10.0.2.1 ip route add 10.0.0.0 via 169.254.27.218 dev eth1 src 10.0.0.1 ip route add 10.0.2.0 via 169.254.27.218 dev eth1 src 10.0.2.1 }}} * nodo 𝛽 . {{{ ip netns exec ntkv0 ip route add 10.0.0.0 via 169.254.94.223 dev ntkv0_eth1 ip netns exec ntkv0 ip route add 10.0.2.0 via 169.254.94.223 dev ntkv0_eth1 ip netns exec ntkv0 ip route add 10.0.0.1 via 169.254.163.36 dev ntkv0_eth1 ip netns exec ntkv0 ip route add 10.0.2.1 via 169.254.163.36 dev ntkv0_eth1 }}} I percorsi che ogni nodo in 𝜑~-,,N,,-~ aveva memorizzati come nodo con indirizzo [X, 2, 0] valgono ora per il suo indirizzo [X, 0, 0]. Ogni border-nodo in 𝜑~-,,N,,-~ comunica via ETP ai suoi vicini esterni a 𝜑~-,,N,,-~, cioè a 𝛽~-,,B,,-~ e 𝛿, che non è più possibile raggiungere tramite lui l'indirizzo [2, 0]; ma che ora è possibile raggiungere tramite lui l'indirizzo [0, 0]. L'effetto di questo ETP, che contiene solo modifiche a percorsi verso g-nodi di livello 1, è comunque limitato ai nodi del g-nodo di livello 2, cioè a 𝛼 e 𝛽~-,,B,,-~. Nel senso che quando esso raggiunge il nodo 𝛿 non contiene nessuna novità. Quindi diamo questi comandi: * nodo 𝛼 . {{{ ip route add 10.0.0.0/31 src 10.0.0.2 via 169.254.96.141 dev eth1 ip route add 10.0.2.0/31 src 10.0.2.2 via 169.254.96.141 dev eth1 }}} * nodo 𝛽 . {{{ ip route add 10.0.0.0/31 src 10.0.0.3 via 169.254.94.223 dev eth1 ip route add 10.0.2.0/31 src 10.0.2.3 via 169.254.94.223 dev eth1 }}} Di nuovo, i nodi in 𝜑~-,,N,,-~ sono in grado di comunicare con gli altri nodi della rete. Proseguiamo con il [[../Step10|passo 10]]. |
[[https://github.com/lukisi/documentation/blob/master/ita/ModuloQspn/UsoIndirizziVirtuali/Step9.md|Redirect]] |
- Diff for "Netsukuku/ita/docs/ModuloQSPN/Esempio1/Step9"