|
Size: 4511
Comment:
|
Size: 10631
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| 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. | 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. |
| Line 10: | Line 10: |
| Assegnamo un indirizzo link-local al nodo 𝜀: * 𝜀 = 169.254.163.36 e aggiungiamo una rotta ai diretti vicini per l'arco 𝛽𝜀. |
Il nuovo nodo si assegna questo indirizzo link-local sull'interfaccia "eth1": * ''IP(''𝜀'',eth1)'' = 169.254.163.36 Si aggiunge questo arco all'elenco: * 𝛽-𝜀 |
| Line 17: | Line 19: |
| ip r add 169.254.163.36 dev eth1 src 169.254.96.141 | ip route add 169.254.163.36 dev eth1 src 169.254.96.141 |
| Line 21: | Line 23: |
| ip l set eth1 up ip a add 169.254.163.36 dev eth1 ip r add 169.254.96.141 dev eth1 src 169.254.163.36 |
ip link set eth1 up ip address add 169.254.163.36 dev eth1 ip route add 169.254.96.141 dev eth1 src 169.254.163.36 |
| Line 32: | Line 34: |
| Il nodo 𝛽 trasforma il suo precedente indirizzo ''reale'' ''globale'' [1, 1, 1], in un indirizzo ''interno'' ai livelli da 1 a 2, cambiando il suo identificativo al livello 0 nel primo identificativo ''virtuale'' libero. Quindi diventa [2, 1, 1], che è ''virtuale'' al livello 0. | Il nodo 𝛽, per ognuna delle interfacce di rete gestite, costruisce una pseudo-interfaccia (nel nostro caso su "eth1" costruiamo "ntkv0_eth1") e su essa si assegna un nuovo indirizzo link-local. Inoltre crea un nuovo network namespace (nel nostro caso "ntkv0"). * ''IP(''𝛽'',ntkv0_eth1)'' = 169.254.27.218 |
| Line 34: | Line 37: |
| Per indicare che questo nodo è ''interno'' ai livelli da 1 a 2 lo chiamiamo da ora in poi 𝛽~-,,i(1,2),,-~. Per indicare che è ''virtuale'' disegnamo un cerchio vuoto. | Diamo questi comandi: * nodo 𝛽 . {{{ ip link add dev ntkv0_eth1 link eth1 type macvlan ip netns add ntkv0 ip link set dev ntkv0_eth1 netns ntkv0 ip netns exec ntkv0 ip link set dev ntkv0_eth1 address E6:2D:52:EE:AF:D1 ip netns exec ntkv0 sysctl -w net.ipv4.conf.ntkv0_eth1.arp_ignore=1 ip netns exec ntkv0 sysctl -w net.ipv4.conf.ntkv0_eth1.arp_announce=2 ip netns exec ntkv0 ip link set ntkv0_eth1 up ip netns exec ntkv0 ip address add 169.254.27.218 dev ntkv0_eth1 }}} Il nodo 𝛽 crea una sua nuova identità, un nodo completamente nuovo, che si assegna a caso un nuovo identificativo, chiamiamolo 𝛽~-,,B,,-~. Questa userà l'interfaccia di rete precedente nel network namespace originale. La vecchia identità di 𝛽 ora gestirà un indirizzo ''di connettività'' ai livelli da 1 a 2, che è ''virtuale'' al livello 0. Per indicare ciò, da ora in poi la chiamiamo 𝛽~-,,i(1,2),,-~ e la disegnamo come un cerchio vuoto. Questa userà la pseudo-interfaccia di rete creata adesso nel relativo network namespace. Il nodo 𝛽 per tutti i suoi archi, cioè 𝛽-𝛾 e 𝛽-𝛼 e 𝛽-𝜀, crea un duplicato, cioè 𝛽~-,,B,,-~-𝛾 e 𝛽~-,,B,,-~-𝛼 e 𝛽~-,,B,,-~-𝜀. Il nodo 𝛽 comunica questa duplicazione ai nodi 𝛾 e 𝛼 e 𝜀, indicando anche la sua nuova identità e i dati della sua nuova pseudo-interfaccia. Così i nodi 𝛾 e 𝛼 e 𝜀 ora sanno che: * I loro archi con 𝛽 (che ora nel grafo è indicato come 𝛽~-,,i(1,2),,-~) hanno al loro estremo una interfaccia di rete che ha come indirizzo IP link-local il 169.254.27.218 e come indirizzo MAC E6:2D:52:EE:AF:D1. * I nuovi archi con 𝛽~-,,B,,-~ hanno al loro estremo una interfaccia di rete che ha come indirizzo IP link-local e come indirizzo MAC quelli che prima erano di 𝛽. * Il monitoraggio dell'arco va ora fatto solo sull'arco con 𝛽~-,,B,,-~. I risultati delle misurazioni si applicano anche all'arco con 𝛽~-,,i(1,2),,-~. * Le comunicazioni del demone ''ntkd'' con il vicino 𝛽~-,,i(1,2),,-~ vanno anche esse fatte per il tramite dell'arco con 𝛽~-,,B,,-~, utilizzando l'identificativo di 𝛽~-,,i(1,2),,-~ perché il nodo 𝛽 distingua l'identità a cui ogni comunicazione è indirizzata. Questo passaggio è importante: infatti pur essendoci ora in 𝛽 due distinti network namespace, il demone ''ntkd'' è unico ed è in esecuzione sul network namespace originale gestito da 𝛽~-,,B,,-~. |
| Line 38: | Line 62: |
| Questo è a tutti gli effetti lo stesso nodo di prima. Ad esso si associa la mappa dei percorsi finora appresi da 𝛽 e il set di archi e il fingerprint che aveva prima. In particolare, il fatto che gli archi sono gli stessi che aveva prima, significa che l'indirizzo link-local 169.254.96.141 dell'interfaccia di rete di 𝛽 è ora di 𝛽~-,,i(1,2),,-~. | Nel disegno abbiamo evidenziato in rosso gli elementi nuovi e in violetto quelli modificati. 𝛽~-,,B,,-~ è la nuova identità di 𝛽, anche se essa gestisce ora il network namespace default con i vecchi indirizzi IP link-local e indirizzi MAC. I suoi archi sono quelli risultati dalla duplicazione. 𝛽~-,,i(1,2),,-~ è la vecchia identità di 𝛽, anche se essa gestisce ora il nuovo network namespace temporaneo con i nuovi indirizzi IP link-local e indirizzi MAC. I suoi archi sono quelli che esistevano prima, ma con gli indirizzi IP link-local e MAC modificati. |
| Line 40: | Line 64: |
| Siccome l'indirizzo ''reale'' viene rimosso e il nodo detiene ora un indirizzo ''virtuale'' a livello 0, dobbiamo rimuovere l'indirizzo nella classe 10.0.0.0/8 dal nodo. ~-'''Nota:''' Se si adottano anche gli indirizzi interni ai g-nodi, e si generalizza dicendo che l'indirizzo è ''virtuale'' al livello ''i'', dovremmo aggiungere che vengono rimossi l'indirizzo globale e gli indirizzi interni ai propri g-nodi di livello maggiore di ''i'', ma non quelli interni ai propri g-nodi di livello minore o uguale a ''i''.-~ | I nodi 𝛾 e 𝛼, siccome i loro vecchi archi hanno cambiato l'indirizzo IP link-local al loro estremo, oltre ad aggiungere la rotta con il nuovo indirizzo IP link-local, cambiano le rotte che avevano memorizzato in precedenza e che usavano 𝛽 come gateway. |
| Line 42: | Line 66: |
| Per rimuovere un proprio indirizzo, prima vanno cambiate le rotte nella classe 10.0.0.0/8 che lo usavano come source preferito, "src", di modo da non avere più affatto un source preferito. Tali rotte infatti non serviranno più per i pacchetti originati dal nodo, ma sono valide per i pacchetti inoltrati. Per il momento il nodo non ha nessun indirizzo valido nella classe 10.0.0.0/8. | Diamo questi comandi ai nodi: * nodo 𝛽 . {{{ ip netns exec ntkv0 ip route add 169.254.69.30 dev ntkv0_eth1 src 169.254.27.218 ip netns exec ntkv0 ip route add 169.254.94.223 dev ntkv0_eth1 src 169.254.27.218 ip netns exec ntkv0 ip route add 169.254.163.36 dev ntkv0_eth1 src 169.254.27.218 ip netns exec ntkv0 ip route add unreachable 10.0.0.0/29 ip netns exec ntkv0 ip route add unreachable 10.0.2.0/30 ip netns exec ntkv0 ip route add unreachable 10.0.1.0/31 }}} * nodo 𝛼 . {{{ ip route add 169.254.27.218 dev eth1 src 169.254.69.30 ip route change 10.0.0.4/30 src 10.0.0.2 via 169.254.27.218 dev eth1 }}} * nodo 𝛾 . {{{ ip route add 169.254.27.218 dev eth1 src 169.254.94.223 ip route change 10.0.0.0/30 src 10.0.0.6 via 169.254.27.218 dev eth1 ip route change 10.0.0.7/32 src 10.0.0.6 via 169.254.27.218 dev eth1 ip route change 10.0.2.3/32 src 10.0.2.2 via 169.254.27.218 dev eth1 ip route change 10.0.1.1/32 src 10.0.1.0 via 169.254.27.218 dev eth1 }}} * nodo 𝜀 . {{{ ip route add 169.254.27.218 dev eth1 src 169.254.163.36 }}} Il nodo 𝛽, o meglio la sua identità 𝛽~-,,i(1,2),,-~, trasforma il suo precedente indirizzo ''reale'' ''definitivo'' [1, 1, 1], in un indirizzo ''di connettività'' ai livelli da 1 a 2, cambiando il suo identificativo al livello 0 nel primo identificativo ''virtuale'' libero nel g-nodo di livello 1 [1, 1], cioè 2. Quindi diventa [2, 1, 1], che è ''virtuale'' al livello 0. Questo è a tutti gli effetti lo stesso nodo di prima. Ad esso si associa la mappa dei percorsi finora appresi da 𝛽 e il set di archi e il fingerprint che aveva prima. Ma le informazioni di routing ad esso associate (i suoi indirizzi e le sue rotte) sono ora di pertinenza del network namespace ntkv0. Siccome l'indirizzo ''reale'' viene rimosso e il nodo detiene ora un indirizzo ''virtuale'' a livello 0, dobbiamo rimuovere l'indirizzo nella classe 10.0.0.0/24 dal nodo. Siccome adottiamo anche gli indirizzi ''interni'' ai g-nodi, dobbiamo rimuovere anche gli indirizzi in 10.0.1.0/24 e 10.0.2.0/24. Vediamo in generale le operazioni da fare quando l'indirizzo ''definitivo'' ''reale'' diventa ''di connettività'' ai livelli da ''i'' a ''j'' e quindi ''virtuale'' al livello ''i'' - 1. * Vengono copiati nel network namespace ntkv0 gli indirizzi interni ai propri g-nodi di livello minore di ''i''. * Le rotte verso g-nodi di livello ''k'' (quindi contenuti nel nostro g-nodo di livello ''k'' + 1), con ''k'' < ''i'' - 1: * Quelle espresse con indirizzi globali vanno rimosse dal network namespace default. * Quelle espresse con indirizzi ''interni'' al g-nodo di livello ''k'' + 1 vanno mantenute nel network namespace default e copiate nel network namespace ntkv0. * Le rotte verso g-nodi di livello ''k'' (quindi contenuti nel nostro g-nodo di livello ''k'' + 1), con ''k'' ≥ ''i'' - 1, sia quelle espresse con indirizzi globali che quelle espresse con indirizzi ''interni'' al g-nodo di livello ''k'' + 1, vanno spostate dal network namespace default nel network namespace ntkv0, ma senza avere un source preferito. * Vengono rimossi l'indirizzo globale e gli indirizzi interni ai propri g-nodi di livello maggiore o uguale a ''i'' dal network namespace default. |
| Line 45: | Line 109: |
| * nodo 𝛽~-,,i(1,2),,-~ | * nodo 𝛽 |
| Line 47: | Line 111: |
| ip r change 10.0.0.0/30 via 169.254.69.30 dev eth1 ip r change 10.0.0.4/31 via 169.254.94.223 dev eth1 ip r change 10.0.0.6/32 via 169.254.94.223 dev eth1 ip a del 10.0.0.7/32 dev eth1 |
ip netns exec ntkv0 ip route add 10.0.0.0/30 via 169.254.69.30 dev ntkv0_eth1 ip route del 10.0.0.0/30 via 169.254.69.30 dev eth1 src 10.0.0.7 ip netns exec ntkv0 ip route add 10.0.0.4/31 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.0.4/31 via 169.254.94.223 dev eth1 src 10.0.0.7 ip netns exec ntkv0 ip route add 10.0.0.6/32 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.0.6/32 via 169.254.94.223 dev eth1 src 10.0.0.7 ip netns exec ntkv0 ip route add 10.0.2.0/31 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.2.0/31 via 169.254.94.223 dev eth1 src 10.0.2.3 ip netns exec ntkv0 ip route add 10.0.2.2/32 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.2.2/32 via 169.254.94.223 dev eth1 src 10.0.2.3 ip netns exec ntkv0 ip route add 10.0.1.0/32 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.1.0/32 via 169.254.94.223 dev eth1 src 10.0.1.1 ip address del 10.0.0.7/32 dev eth1 ip address del 10.0.2.3/32 dev eth1 ip address del 10.0.1.1/32 dev eth1 |
| Line 60: | Line 135: |
| ip r del 10.0.0.7/32 src 10.0.0.6 via 169.254.96.141 dev eth1 | ip route del 10.0.0.7/32 src 10.0.0.6 via 169.254.27.218 dev eth1 ip route del 10.0.2.3/32 src 10.0.2.2 via 169.254.27.218 dev eth1 ip route del 10.0.1.1/32 src 10.0.1.0 via 169.254.27.218 dev eth1 |
| Line 65: | Line 142: |
| * Il nodo 𝛼 sa di poter raggiungere il g-nodo [1] passando per il vicino 𝛽~-,,i(1,2),,-~. * Il nodo 𝛾 sa di poter raggiungere il g-nodo [0] passando per il vicino 𝛽~-,,i(1,2),,-~. |
* Il nodo 𝛼 sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛼-𝛽~-,,i(1,2),,-~. * Il nodo 𝛾 sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛾-𝛽~-,,i(1,2),,-~. |
Modulo QSPN - Esempio di uso degli indirizzi virtuali
Passo 3
In questo passo simuliamo l'ingresso di un nuovo nodo che forza la migrazione di 𝛽 in g1(𝛼), 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.
Il nuovo nodo si assegna questo indirizzo link-local sull'interfaccia "eth1":
IP(𝜀,eth1) = 169.254.163.36
Si aggiunge questo arco all'elenco:
- 𝛽-𝜀
Diamo questi comandi ai nodi:
- nodo 𝛽
ip route add 169.254.163.36 dev eth1 src 169.254.96.141
- nodo 𝜀
ip link set eth1 up ip address add 169.254.163.36 dev eth1 ip route add 169.254.96.141 dev eth1 src 169.254.163.36
Al livello più alto la rete è satura, non si può costituire un nuovo g-nodo di livello 2. Il nodo 𝜀 può fare ingresso solo in g2(𝛽) poiché il suo unico vicino è 𝛽. Ma questo è saturo. Anche g1(𝛽) è saturo. Supponiamo che decida di entrare in g1(𝛽) = [1, 1]. Come soluzione si sceglie di far migrare 𝛽 in g1(𝛼) = [1, 0], ma che 𝛽 resti come virtuale in [1, 1].
I due g-nodi interessati dalla migrazione di 𝛽 sono stati evidenziati nel disegno e contrassegnati con le lettere A e B.
Si noti che il livello più alto in cui i due g-nodi A e B differiscono è 2.
Il nodo 𝛽, per ognuna delle interfacce di rete gestite, costruisce una pseudo-interfaccia (nel nostro caso su "eth1" costruiamo "ntkv0_eth1") e su essa si assegna un nuovo indirizzo link-local. Inoltre crea un nuovo network namespace (nel nostro caso "ntkv0").
IP(𝛽,ntkv0_eth1) = 169.254.27.218
Diamo questi comandi:
- nodo 𝛽
ip link add dev ntkv0_eth1 link eth1 type macvlan ip netns add ntkv0 ip link set dev ntkv0_eth1 netns ntkv0 ip netns exec ntkv0 ip link set dev ntkv0_eth1 address E6:2D:52:EE:AF:D1 ip netns exec ntkv0 sysctl -w net.ipv4.conf.ntkv0_eth1.arp_ignore=1 ip netns exec ntkv0 sysctl -w net.ipv4.conf.ntkv0_eth1.arp_announce=2 ip netns exec ntkv0 ip link set ntkv0_eth1 up ip netns exec ntkv0 ip address add 169.254.27.218 dev ntkv0_eth1
Il nodo 𝛽 crea una sua nuova identità, un nodo completamente nuovo, che si assegna a caso un nuovo identificativo, chiamiamolo 𝛽B. Questa userà l'interfaccia di rete precedente nel network namespace originale.
La vecchia identità di 𝛽 ora gestirà un indirizzo di connettività ai livelli da 1 a 2, che è virtuale al livello 0. Per indicare ciò, da ora in poi la chiamiamo 𝛽i(1,2) e la disegnamo come un cerchio vuoto. Questa userà la pseudo-interfaccia di rete creata adesso nel relativo network namespace.
Il nodo 𝛽 per tutti i suoi archi, cioè 𝛽-𝛾 e 𝛽-𝛼 e 𝛽-𝜀, crea un duplicato, cioè 𝛽B-𝛾 e 𝛽B-𝛼 e 𝛽B-𝜀. Il nodo 𝛽 comunica questa duplicazione ai nodi 𝛾 e 𝛼 e 𝜀, indicando anche la sua nuova identità e i dati della sua nuova pseudo-interfaccia. Così i nodi 𝛾 e 𝛼 e 𝜀 ora sanno che:
I loro archi con 𝛽 (che ora nel grafo è indicato come 𝛽i(1,2)) hanno al loro estremo una interfaccia di rete che ha come indirizzo IP link-local il 169.254.27.218 e come indirizzo MAC E6:2D:52:EE:AF:D1.
I nuovi archi con 𝛽B hanno al loro estremo una interfaccia di rete che ha come indirizzo IP link-local e come indirizzo MAC quelli che prima erano di 𝛽.
Il monitoraggio dell'arco va ora fatto solo sull'arco con 𝛽B. I risultati delle misurazioni si applicano anche all'arco con 𝛽i(1,2).
Le comunicazioni del demone ntkd con il vicino 𝛽i(1,2) vanno anche esse fatte per il tramite dell'arco con 𝛽B, utilizzando l'identificativo di 𝛽i(1,2) perché il nodo 𝛽 distingua l'identità a cui ogni comunicazione è indirizzata. Questo passaggio è importante: infatti pur essendoci ora in 𝛽 due distinti network namespace, il demone ntkd è unico ed è in esecuzione sul network namespace originale gestito da 𝛽B.
Nel disegno abbiamo evidenziato in rosso gli elementi nuovi e in violetto quelli modificati. 𝛽B è la nuova identità di 𝛽, anche se essa gestisce ora il network namespace default con i vecchi indirizzi IP link-local e indirizzi MAC. I suoi archi sono quelli risultati dalla duplicazione. 𝛽i(1,2) è la vecchia identità di 𝛽, anche se essa gestisce ora il nuovo network namespace temporaneo con i nuovi indirizzi IP link-local e indirizzi MAC. I suoi archi sono quelli che esistevano prima, ma con gli indirizzi IP link-local e MAC modificati.
I nodi 𝛾 e 𝛼, siccome i loro vecchi archi hanno cambiato l'indirizzo IP link-local al loro estremo, oltre ad aggiungere la rotta con il nuovo indirizzo IP link-local, cambiano le rotte che avevano memorizzato in precedenza e che usavano 𝛽 come gateway.
Diamo questi comandi ai nodi:
- nodo 𝛽
ip netns exec ntkv0 ip route add 169.254.69.30 dev ntkv0_eth1 src 169.254.27.218 ip netns exec ntkv0 ip route add 169.254.94.223 dev ntkv0_eth1 src 169.254.27.218 ip netns exec ntkv0 ip route add 169.254.163.36 dev ntkv0_eth1 src 169.254.27.218 ip netns exec ntkv0 ip route add unreachable 10.0.0.0/29 ip netns exec ntkv0 ip route add unreachable 10.0.2.0/30 ip netns exec ntkv0 ip route add unreachable 10.0.1.0/31
- nodo 𝛼
ip route add 169.254.27.218 dev eth1 src 169.254.69.30 ip route change 10.0.0.4/30 src 10.0.0.2 via 169.254.27.218 dev eth1
- nodo 𝛾
ip route add 169.254.27.218 dev eth1 src 169.254.94.223 ip route change 10.0.0.0/30 src 10.0.0.6 via 169.254.27.218 dev eth1 ip route change 10.0.0.7/32 src 10.0.0.6 via 169.254.27.218 dev eth1 ip route change 10.0.2.3/32 src 10.0.2.2 via 169.254.27.218 dev eth1 ip route change 10.0.1.1/32 src 10.0.1.0 via 169.254.27.218 dev eth1
- nodo 𝜀
ip route add 169.254.27.218 dev eth1 src 169.254.163.36
Il nodo 𝛽, o meglio la sua identità 𝛽i(1,2), trasforma il suo precedente indirizzo reale definitivo [1, 1, 1], in un indirizzo di connettività ai livelli da 1 a 2, cambiando il suo identificativo al livello 0 nel primo identificativo virtuale libero nel g-nodo di livello 1 [1, 1], cioè 2. Quindi diventa [2, 1, 1], che è virtuale al livello 0.
Questo è a tutti gli effetti lo stesso nodo di prima. Ad esso si associa la mappa dei percorsi finora appresi da 𝛽 e il set di archi e il fingerprint che aveva prima. Ma le informazioni di routing ad esso associate (i suoi indirizzi e le sue rotte) sono ora di pertinenza del network namespace ntkv0.
Siccome l'indirizzo reale viene rimosso e il nodo detiene ora un indirizzo virtuale a livello 0, dobbiamo rimuovere l'indirizzo nella classe 10.0.0.0/24 dal nodo. Siccome adottiamo anche gli indirizzi interni ai g-nodi, dobbiamo rimuovere anche gli indirizzi in 10.0.1.0/24 e 10.0.2.0/24.
Vediamo in generale le operazioni da fare quando l'indirizzo definitivo reale diventa di connettività ai livelli da i a j e quindi virtuale al livello i - 1.
Vengono copiati nel network namespace ntkv0 gli indirizzi interni ai propri g-nodi di livello minore di i.
Le rotte verso g-nodi di livello k (quindi contenuti nel nostro g-nodo di livello k + 1), con k < i - 1:
- Quelle espresse con indirizzi globali vanno rimosse dal network namespace default.
Quelle espresse con indirizzi interni al g-nodo di livello k + 1 vanno mantenute nel network namespace default e copiate nel network namespace ntkv0.
Le rotte verso g-nodi di livello k (quindi contenuti nel nostro g-nodo di livello k + 1), con k ≥ i - 1, sia quelle espresse con indirizzi globali che quelle espresse con indirizzi interni al g-nodo di livello k + 1, vanno spostate dal network namespace default nel network namespace ntkv0, ma senza avere un source preferito.
Vengono rimossi l'indirizzo globale e gli indirizzi interni ai propri g-nodi di livello maggiore o uguale a i dal network namespace default.
Quindi diamo questi comandi:
- nodo 𝛽
ip netns exec ntkv0 ip route add 10.0.0.0/30 via 169.254.69.30 dev ntkv0_eth1 ip route del 10.0.0.0/30 via 169.254.69.30 dev eth1 src 10.0.0.7 ip netns exec ntkv0 ip route add 10.0.0.4/31 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.0.4/31 via 169.254.94.223 dev eth1 src 10.0.0.7 ip netns exec ntkv0 ip route add 10.0.0.6/32 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.0.6/32 via 169.254.94.223 dev eth1 src 10.0.0.7 ip netns exec ntkv0 ip route add 10.0.2.0/31 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.2.0/31 via 169.254.94.223 dev eth1 src 10.0.2.3 ip netns exec ntkv0 ip route add 10.0.2.2/32 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.2.2/32 via 169.254.94.223 dev eth1 src 10.0.2.3 ip netns exec ntkv0 ip route add 10.0.1.0/32 via 169.254.94.223 dev ntkv0_eth1 ip route del 10.0.1.0/32 via 169.254.94.223 dev eth1 src 10.0.1.1 ip address del 10.0.0.7/32 dev eth1 ip address del 10.0.2.3/32 dev eth1 ip address del 10.0.1.1/32 dev eth1
Il nodo 𝛽i(1,2) comunica via ETP ai suoi vicini 𝛼 e 𝛾 che non è più possibile raggiungere tramite lui l'indirizzo [1, 1, 1]; e che ora è possibile raggiungere tramite lui l'indirizzo [2, 1, 1].
Questo ETP viene recepito solo dai nodi del g-nodo di livello 1, trattandosi di due percorsi verso singoli nodi, cioè solo dal nodo 𝛾. Inoltre la comunicazione relativa all'indirizzo virtuale [2, 1, 1] viene recepita dal nodo 𝛾 ma non comporta alcun comando.
Quindi diamo questi comandi:
- nodo 𝛾
ip route del 10.0.0.7/32 src 10.0.0.6 via 169.254.27.218 dev eth1 ip route del 10.0.2.3/32 src 10.0.2.2 via 169.254.27.218 dev eth1 ip route del 10.0.1.1/32 src 10.0.1.0 via 169.254.27.218 dev eth1
I percorsi che 𝛽 aveva pubblicizzati valgono ora per 𝛽i(1,2). Non c'è bisogno che 𝛽i(1,2) li trasmetta di nuovo. Questo significa che:
Il nodo 𝛼 sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛼-𝛽i(1,2).
Il nodo 𝛾 sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛾-𝛽i(1,2).
Proseguiamo con il passo 4.