Differences between revisions 4 and 5
Revision 4 as of 2016-01-13 07:32:23
Size: 15737
Editor: lukisi
Comment:
Revision 5 as of 2016-01-17 16:16:04
Size: 15769
Editor: lukisi
Comment:
Deletions are marked like this. Additions are marked like this.
Line 91: Line 91:
Ogni nodo in 𝜑, per tutti i suoi archi crea un duplicato che sarà di 𝜑~-,,N,,-~. Poi modifica gli archi vecchi, quelli che rimangono in 𝜑~-,,i(2,2),,-~. Per gli archi che aveva con altri nodi in 𝜑 questo duplicato collega la pseudo-interfaccia nuova nell'uno e nell'altro nodo, mentre per gli archi che aveva con altri nodi che non appartengono a 𝜑 questo duplicato collega la pseudo-interfaccia nuova nell'uno con la vecchia interfaccia nell'altro. Nel dettaglio: Ogni nodo in 𝜑, per tutti i suoi archi crea un duplicato che sarà di 𝜑~-,,N,,-~. Poi modifica gli archi vecchi, quelli che rimangono in 𝜑~-,,i(2,2),,-~. Per gli archi che aveva con altri nodi in 𝜑 ora l'arco in 𝜑~-,,i(2,2),,-~ collega la pseudo-interfaccia nuova nell'uno e nell'altro nodo, mentre per gli archi che aveva con altri nodi che non appartengono a 𝜑 ora l'arco in 𝜑~-,,i(2,2),,-~ collega la pseudo-interfaccia nuova nell'uno con la vecchia interfaccia nell'altro. Nel dettaglio:

Modulo QSPN - Esempio di uso degli indirizzi virtuali

Passo 7

In questo passo simuliamo l'ingresso di un nuovo nodo che forza la migrazione del g-nodo di livello 1 [1, 1] nel g-nodo di livello 2 [0], che è non saturo.

Ora nella rete si aggiunge il nodo 𝜆 collegato solo al nodo 𝜀. Esiste l'arco 𝜀-𝜆, ma tale arco non è ancora comunicato al modulo QSPN in quanto il nodo 𝜆 non fa ancora parte della rete.

grafo8.adraw

Il nuovo nodo si assegna questo indirizzo link-local:

  • 𝜆 = 169.254.109.22

Si aggiunge questo arco all'elenco:

  • 𝜀-𝜆

Diamo questi comandi ai nodi:

  • nodo 𝜀
  • ip route add 169.254.109.22 dev eth1 src 169.254.163.36
  • nodo 𝜆
  • ip link set eth1 up
    ip address add 169.254.109.22 dev eth1
    ip route add 169.254.163.36 dev eth1 src 169.254.109.22

Il nodo 𝜆 vuole fare da gateway per una sottorete di due nodi gestita autonomamente. Quindi vuole riservarsi un g-nodo di livello 1.

Al livello più alto la rete è satura, non si può costituire un nuovo g-nodo di livello 2. Il nodo 𝜆 vuole entrare in g2(𝜀) = [1] ma è saturo. Come soluzione si sceglie di far migrare tutto il g-nodo 𝜑 = g1(𝜀) = [1, 1] in [0], ma che resti come virtuale in [1] prendendo il primo identificativo virtuale libero nel g-nodo di livello 2 [1], cioè 2. Quindi diventa [2, 1].

I due g-nodi di livello 2 interessati dalla migrazione di 𝜑 sono stati evidenziati nel disegno e contrassegnati con le lettere M e N.

Si noti che il livello più alto in cui i due g-nodi M e N differiscono è 2.

Il g-nodo 𝜑 migra in una operazione atomica, cioè tutti i suoi nodi migrano insieme, senza attendere l'uno le operazioni dell'altro. Alcune operazioni sulle proprie strutture dati interne le faranno tutti i nodi. Alcuni comandi per il sistema operativo andranno dati su tutti i nodi.

Le trasmissioni di ETP dovute ai cambi di indirizi di 𝜑 invece le faranno solo i border-nodi e le comunicheranno solo all'esterno. Le richieste di un ETP completo le faranno solo i border-nodi ai nodi esterni. Con gli ETP ricevuti i border-nodi acquisiranno nuovi percorsi e propagheranno ai nodi interni questi percorsi con ETP che viaggeranno solo internamente.

Procediamo.

Ogni nodo del g-nodo 𝜑, per ognuna delle interfacce di rete gestite dal demone ntkd nel network namespace default, costruisce una pseudo-interfaccia a cui associa un nuovo indirizzo IP link-local. Poi le sposta in un nuovo network namespace (che chiamiamo in questo esempio "ntkv1").

Diamo questi comandi ai nodi:

  • nodo 𝛽
  • ip link add dev ntkv1_eth1 link eth1 type macvlan
    ip netns add ntkv1
    ip link set dev ntkv1_eth1 netns ntkv1
    ip netns exec ntkv1 ip link set dev ntkv1_eth1 address 92:16:EB:BD:34:98
    ip netns exec ntkv1 sysctl -w net.ipv4.conf.ntkv1_eth1.arp_ignore=1
    ip netns exec ntkv1 sysctl -w net.ipv4.conf.ntkv1_eth1.arp_announce=2
    ip netns exec ntkv1 ip link set ntkv1_eth1 up
    ip netns exec ntkv1 ip address add 169.254.42.4 dev ntkv1_eth1
  • nodo 𝛾
  • ip link add dev ntkv1_eth1 link eth1 type macvlan
    ip netns add ntkv1
    ip link set dev ntkv1_eth1 netns ntkv1
    ip netns exec ntkv1 ip link set dev ntkv1_eth1 address 3A:01:4E:AF:4C:2A
    ip netns exec ntkv1 sysctl -w net.ipv4.conf.ntkv1_eth1.arp_ignore=1
    ip netns exec ntkv1 sysctl -w net.ipv4.conf.ntkv1_eth1.arp_announce=2
    ip netns exec ntkv1 ip link set ntkv1_eth1 up
    ip netns exec ntkv1 ip address add 169.254.24.198 dev ntkv1_eth1
  • nodo 𝜀
  • ip link add dev ntkv1_eth1 link eth1 type macvlan
    ip netns add ntkv1
    ip link set dev ntkv1_eth1 netns ntkv1
    ip netns exec ntkv1 ip link set dev ntkv1_eth1 address AE:57:CE:3B:9F:45
    ip netns exec ntkv1 sysctl -w net.ipv4.conf.ntkv1_eth1.arp_ignore=1
    ip netns exec ntkv1 sysctl -w net.ipv4.conf.ntkv1_eth1.arp_announce=2
    ip netns exec ntkv1 ip link set ntkv1_eth1 up
    ip netns exec ntkv1 ip address add 169.254.241.153 dev ntkv1_eth1

Ogni nodo in 𝜑 crea una sua nuova identità, che si assegna a caso un nuovo identificativo, che userà l'interfaccia di rete e il network namespace con cui il nodo gestiva il suo precedente indirizzo in 𝜑. Nel dettaglio:

  • Il nodo 𝛽i(1,2) crea 𝛽i(1,2),N che gestirà "ntkv0_eth1" nel network namespace "ntkv0".

  • Il nodo 𝛾 crea 𝛾N che gestirà "eth1" nel network namespace default.

  • Il nodo 𝜀 crea 𝜀N che gestirà "eth1" nel network namespace default.

Queste nuove identità formano un gruppo che chiamiamo 𝜑N.

Le vecchie identità ora gestiranno indirizzi di connettività ai livelli da 2 a 2, virtuali al livello 1. Per indicare ciò, da ora in poi le chiamiamo 𝛽i(1,2),i(2,2), 𝛾i(2,2) e 𝜀i(2,2) e chiamiamo il gruppo 𝜑i(2,2). Queste useranno la pseudo-interfaccia di rete creata adesso nel relativo network namespace. Nel dettaglio:

  • Il nodo 𝛽i(1,2),i(2,2) gestirà "ntkv1_eth1" nel network namespace "ntkv1".

  • Il nodo 𝛾i(2,2) gestirà "ntkv1_eth1" nel network namespace "ntkv1".

  • Il nodo 𝜀i(2,2) gestirà "ntkv1_eth1" nel network namespace "ntkv1".

Ogni nodo in 𝜑, per tutti i suoi archi crea un duplicato che sarà di 𝜑N. Poi modifica gli archi vecchi, quelli che rimangono in 𝜑i(2,2). Per gli archi che aveva con altri nodi in 𝜑 ora l'arco in 𝜑i(2,2) collega la pseudo-interfaccia nuova nell'uno e nell'altro nodo, mentre per gli archi che aveva con altri nodi che non appartengono a 𝜑 ora l'arco in 𝜑i(2,2) collega la pseudo-interfaccia nuova nell'uno con la vecchia interfaccia nell'altro. Nel dettaglio:

  • L'arco 𝜀N-𝛽B è il duplicato del vecchio arco 𝜀-𝛽B. Questo collega la "eth1" del nodo 𝜀 con la "eth1" del nodo 𝛽.

  • L'arco 𝜀i(2,2)-𝛽B è il vecchio arco 𝜀-𝛽B che viene modificato. Ora esso collega la "ntkv1_eth1" del nodo 𝜀 con la "eth1" del nodo 𝛽.

  • L'arco 𝜀N-𝛽i(1,2),N è il duplicato del vecchio arco 𝜀-𝛽i(1,2). Questo collega la "eth1" del nodo 𝜀 con la "ntkv0_eth1" del nodo 𝛽.

  • L'arco 𝜀i(2,2)-𝛽i(1,2),i(2,2) è il vecchio arco 𝜀-𝛽i(1,2) che viene modificato. Ora esso collega la "ntkv1_eth1" del nodo 𝜀 con la "ntkv1_eth1" del nodo 𝛽.

  • ...

Visualiziamo la rete nel seguente disegno. Come prima, gli elementi rossi sono quelli nuovi, i violetti sono quelli modificati; gli archi tratteggiati collegano a nodi che non fanno ancora parte della rete.

grafo9.adraw

Ora illustriamo i comandi che vengono dati ai nodi per realizzare queste operazioni. Va considerato che ogni nodo esterno a 𝜑 che vede una modifica realizzata su un suo vecchio arco (cambia l'indirizzo IP link-local al suo estremo che è in 𝜑) deve anche apportare la relativa variazione alle rotte che aveva memorizzato in precedenza e che usavano quell'arco come gateway.

Diamo questi comandi ai nodi:

  • nodo 𝛽
  • # come 𝛽B
    ip route add 169.254.241.153 dev eth1 src 169.254.96.141
    ip route add 169.254.24.198 dev eth1 src 169.254.96.141
    ip route change 10.0.0.4/30 src 10.0.0.3 via 169.254.24.198 dev eth1
    # come 𝛽i12,N
    # come 𝛽i12,i22
    ip netns exec ntkv1 ip route add 169.254.241.153 dev ntkv1_eth1 src 169.254.42.4
    ip netns exec ntkv1 ip route add 169.254.24.198 dev ntkv1_eth1 src 169.254.42.4
    ip netns exec ntkv1 ip route add unreachable 10.0.0.0/29
    ip netns exec ntkv1 ip route add unreachable 10.0.2.0/30
    ip netns exec ntkv1 ip route add unreachable 10.0.1.0/31
  • nodo 𝛾
  • # come 𝛾N
    # come 𝛾i22
    ip netns exec ntkv1 ip route add 169.254.96.141 dev ntkv1_eth1 src 169.254.24.198
    ip netns exec ntkv1 ip route add 169.254.42.4 dev ntkv1_eth1 src 169.254.24.198
    ip netns exec ntkv1 ip route add 169.254.253.216 dev ntkv1_eth1 src 169.254.24.198
    ip netns exec ntkv1 ip route add unreachable 10.0.0.0/29
    ip netns exec ntkv1 ip route add unreachable 10.0.2.0/30
    ip netns exec ntkv1 ip route add unreachable 10.0.1.0/31
  • nodo 𝛿
  • ip route add 169.254.24.198 dev eth1 src 169.254.253.216
    ip route change 10.0.0.0/30 via 169.254.24.198 dev eth1 src 10.0.0.5
    ip route change 10.0.0.6/31 via 169.254.24.198 dev eth1 src 10.0.0.5
    ip route change 10.0.2.2/31 via 169.254.24.198 dev eth1 src 10.0.2.1
  • nodo 𝜀
  • # come 𝜀N
    # come 𝜀i22
    ip netns exec ntkv1 ip route add 169.254.96.141 dev ntkv1_eth1 src 169.254.241.153
    ip netns exec ntkv1 ip route add 169.254.42.4 dev ntkv1_eth1 src 169.254.241.153
    ip netns exec ntkv1 ip route add 169.254.109.22 dev ntkv1_eth1 src 169.254.241.153
    ip netns exec ntkv1 ip route add unreachable 10.0.0.0/29
    ip netns exec ntkv1 ip route add unreachable 10.0.2.0/30
    ip netns exec ntkv1 ip route add unreachable 10.0.1.0/31
  • nodo 𝜆
  • ip route add 169.254.241.153 dev eth1 src 169.254.109.22

I nodi in 𝜑i(2,2), quindi in riferimento alla loro identità che mantiene l'indirizzo di connettività nel network namespace "ntkv1", trasformano il loro precedente indirizzo [X, 1, 1] in [X, 2, 1] che è di connettività ai livelli da 2 a 2. Nel dettaglio:

  • Il nodo 𝛽i(1,2),i(2,2) trasforma il suo indirizzo da [2, 1, 1] a [2, 2, 1]. Poiché era in precedenza un nodo di connettività ai livelli da 1 a 2, diventa un nodo di connettività ai livelli da 1 a 2.

  • Il nodo 𝛾i(2,2) trasforma il suo indirizzo da [0, 1, 1] a [0, 2, 1]. Diventa un nodo di connettività ai livelli da 2 a 2.

  • Il nodo 𝜀i(2,2) trasforma il suo indirizzo da [1, 1, 1] a [1, 2, 1]. Diventa un nodo di connettività ai livelli da 2 a 2.

Riguardando la regola generale descritta nel passo 3 sulle operazioni da fare con gli indirizzi e le rotte, poiché il g-nodo 𝜑 diventa di connettività ai livelli da 2 a 2 e quindi virtuale al livello 1, i nodi in esso fanno queste operazioni:

  • Vengono copiati nel network namespace ntkv1 gli indirizzi interni ai propri g-nodi di livello minore di 2, cioè quelli in 10.0.1.X.
  • Le rotte verso nodi contenuti nel nostro g-nodo di livello 1:
    • Quelle espresse con indirizzi interni al g-nodo di livello 1 vanno mantenute nel network namespace vecchio e copiate nel network namespace ntkv1. Inoltre, essendo nel network namespace ntkv1, se usano come gateway un nodo in 𝜑 devono usare il nuovo indirizzo IP link-local del gateway in 𝜑i(2,2).

    • Quelle espresse con indirizzi globali o con indirizzi interni ai livelli superiori, vanno rimosse dal network namespace vecchio.
  • Le rotte verso g-nodi di livello k (quindi contenuti nel nostro g-nodo di livello k + 1), con k ≥ 1, sia quelle espresse con indirizzi globali che quelle espresse con indirizzi interni ai vari livelli, vanno spostate dal network namespace vecchio nel network namespace ntkv1, ma senza avere un source preferito. Inoltre, essendo nel network namespace ntkv1, se usano come gateway un nodo in 𝜑 devono usare il nuovo indirizzo IP link-local del gateway in 𝜑i(2,2).

  • Vengono rimossi l'indirizzo globale e gli indirizzi interni ai propri g-nodi di livello maggiore o uguale a 2 dal network namespace vecchio. Vi restano quindi quelli in 10.0.1.X.

Quindi diamo questi comandi:

  • nodo 𝛽
  • ip netns exec ntkv1 ip route add 10.0.1.0/32 via 169.254.24.198 dev ntkv1_eth1
    ip netns exec ntkv1 ip route add 10.0.1.1/32 via 169.254.241.153 dev ntkv1_eth1
    ip netns exec ntkv0 ip route del 10.0.0.6/32 via 169.254.94.223 dev ntkv0_eth1
    ip netns exec ntkv0 ip route del 10.0.0.7/32 via 169.254.163.36 dev ntkv0_eth1
    ip netns exec ntkv0 ip route del 10.0.2.2/32 via 169.254.94.223 dev ntkv0_eth1
    ip netns exec ntkv0 ip route del 10.0.2.3/32 via 169.254.163.36 dev ntkv0_eth1
    ip netns exec ntkv1 ip route add 10.0.0.0/30 via 169.254.24.198 dev ntkv1_eth1
    ip netns exec ntkv0 ip route del 10.0.0.0/30 via 169.254.94.223 dev ntkv0_eth1
    ip netns exec ntkv1 ip route add 10.0.0.4/31 via 169.254.24.198 dev ntkv1_eth1
    ip netns exec ntkv0 ip route del 10.0.0.4/31 via 169.254.94.223 dev ntkv0_eth1
    ip netns exec ntkv1 ip route add 10.0.2.0/31 via 169.254.24.198 dev ntkv1_eth1
    ip netns exec ntkv0 ip route del 10.0.2.0/31 via 169.254.94.223 dev ntkv0_eth1
  • nodo 𝛾
  • ip netns exec ntkv1 ip address add 10.0.1.0 dev ntkv1_eth1
    ip netns exec ntkv1 ip route add 10.0.1.1/32 via 169.254.42.4 dev ntkv1_eth1 src 10.0.1.0
    ip route del 10.0.0.7/32 via 169.254.27.218 dev eth1 src 10.0.0.6
    ip route del 10.0.2.3/32 via 169.254.27.218 dev eth1 src 10.0.2.2
    ip netns exec ntkv1 ip route add 10.0.0.0/30 via 169.254.96.141 dev ntkv1_eth1
    ip route del 10.0.0.0/30 via 169.254.96.141 dev eth1 src 10.0.0.6
    ip netns exec ntkv1 ip route add 10.0.0.4/31 via 169.254.253.216 dev ntkv1_eth1
    ip route del 10.0.0.4/31 via 169.254.253.216 dev eth1 src 10.0.0.6
    ip netns exec ntkv1 ip route add 10.0.2.0/31 via 169.254.253.216 dev ntkv1_eth1
    ip route del 10.0.2.0/31 via 169.254.253.216 dev eth1 src 10.0.2.2
    ip address del 10.0.0.6/32 dev eth1
    ip address del 10.0.2.2/32 dev eth1
  • nodo 𝜀
  • ip netns exec ntkv1 ip address add 10.0.1.1 dev ntkv1_eth1
    ip netns exec ntkv1 ip route add 10.0.1.0/32 via 169.254.42.4 dev ntkv1_eth1 src 10.0.1.1
    ip route del 10.0.0.6/32 via 169.254.27.218 dev eth1 src 10.0.0.7
    ip route del 10.0.2.2/32 via 169.254.27.218 dev eth1 src 10.0.2.3
    ip netns exec ntkv1 ip route add 10.0.0.0/30 via 169.254.96.141 dev ntkv1_eth1
    ip route del 10.0.0.0/30 via 169.254.96.141 dev eth1 src 10.0.0.7
    ip netns exec ntkv1 ip route add 10.0.0.4/31 via 169.254.42.4 dev ntkv1_eth1
    ip route del 10.0.0.4/31 via 169.254.27.218 dev eth1 src 10.0.0.7
    ip netns exec ntkv1 ip route add 10.0.2.0/31 via 169.254.42.4 dev ntkv1_eth1
    ip route del 10.0.2.0/31 via 169.254.27.218 dev eth1 src 10.0.2.3
    ip address del 10.0.0.7/32 dev eth1
    ip address del 10.0.2.3/32 dev eth1

Vediamo ora le comunicazioni del g-nodo 𝜑 agli altri g-nodi. Ogni border-nodo di 𝜑 trasmette un ETP ai suoi vicini che non appartengono a 𝜑. In questo ETP comunica che non è più possibile raggiungere tramite lui l'indirizzo [1, 1]; e che ora è possibile raggiungere tramite lui l'indirizzo [2, 1].

Questo ETP viene recepito solo dai nodi del g-nodo di livello 2, trattandosi di due percorsi verso g-nodi di livello 1, cioè solo dai nodi 𝛿 e 𝜇. Inoltre la comunicazione relativa all'indirizzo virtuale [2, 1] viene recepita ma non comporta alcun comando.

Quindi diamo questi comandi ai nodi:

  • nodo 𝛿
  • ip route del 10.0.0.6/31 via 169.254.24.198 dev eth1 src 10.0.0.5
    ip route del 10.0.2.2/31 via 169.254.24.198 dev eth1 src 10.0.2.1
  • nodo 𝜇
  • ip route del 10.0.0.6/31 via 169.254.253.216 dev eth1 src 10.0.0.4
    ip route del 10.0.2.2/31 via 169.254.253.216 dev eth1 src 10.0.2.0

Dopo tutti questi comandi, il g-nodo 𝜑 non è in grado di comunicare con gli altri g-nodi della rete, ma è in grado di inoltrare i pacchetti. Quindi la rete rimane connessa: ad esempio, il nodo 𝛼 è in grado di comunicare con il nodo 𝜇 usando il suo indirizzo globale.

Inoltre, all'interno del g-nodo 𝜑 i singoli nodi (vale a dire 𝜀 e 𝛾) possono comunicare tra loro usando i loro indirizzi IP interni al g-nodo di livello 1. E le connessioni che erano state aperte tra 𝜀 e 𝛾 (sempre con gli indirizzi IP interni) prima di queste operazioni sono tuttora funzionanti.

Proseguiamo con il passo 8.

Netsukuku/ita/docs/ModuloQSPN/Esempio1/Step7 (last edited 2016-07-27 10:29:36 by lukisi)