Modulo QSPN - Esempio di uso degli indirizzi virtuali

Passo 4

In questo passo assegnamo alla nuova identità di 𝛽, 𝛽_B, un indirizzo definitivo nel g-nodo g₁(𝛼). Per l'esattezza gli assegnamo l'indirizzo virtuale [2, 1, 0].

Nel disegno seguente gli archi di 𝛽_B con 𝛼 e 𝛾 non sono più tratteggiati in quanto 𝛽_B fa ora parte della rete.

Riassumiamo l'elenco di tutti gli archi ora esistenti coi relativi indirizzi IP link-local:

𝛼-𝛽_B
169.254.69.30-169.254.96.141
𝛼-𝛽_i(1,2)
169.254.69.30-169.254.27.218
𝛾-𝛽_B
169.254.94.223-169.254.96.141
𝛾-𝛽_i(1,2)
169.254.94.223-169.254.27.218
𝜀-𝛽_B
169.254.163.36-169.254.96.141
𝜀-𝛽_i(1,2)
169.254.163.36-169.254.27.218
𝛾-𝛿
169.254.94.223-169.254.253.216
𝛿-𝜇
169.254.253.216-169.254.119.176

Non ci sono, comunque, da fare nuove assegnazioni di indirizzi né di rotte verso nodi vicini.

Poiché il nuovo indirizzo definitivo di 𝛽_B è virtuale al livello 0, la sua assegnazione non comporta un comando di assegnazione di indirizzo IP globale nella rete per il nodo 𝛽, né di un indirizzo interno al livello 2, né di un indirizzo interno al livello 1.

Ora il nodo 𝛽_B chiede un ETP completo ai vicini tramite i suoi archi e li processa con questo nuovo indirizzo. Grazie ad essi:

Il nodo 𝛽_B sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛾-𝛽_B.
Il nodo 𝛽_B sa di poter raggiungere il nodo [0, 1, 0] passando per l'arco 𝛼-𝛽_B.

Quindi diamo questi comandi:

nodo 𝛽

ip route add 10.0.0.4/30 via 169.254.94.223 dev eth1
ip route add 10.0.0.2/32 via 169.254.69.30 dev eth1
ip route add 10.0.2.2/32 via 169.254.69.30 dev eth1
ip route add 10.0.1.0/32 via 169.254.69.30 dev eth1

Il nodo 𝛽_B avendo ora completato il suo bootstrap, comunica via ETP ai suoi vicini 𝛼 e 𝛾 tutti i percorsi che conosce. Quindi ora:

Il nodo 𝛼 sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛼-𝛽_B.
Il nodo 𝛾 sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛾-𝛽_B.

Sono due conoscenze nuove, ma che non cambiano il miglior percorso verso quelle destinazioni per 𝛼 e 𝛾. Quindi nessun comando verrà dato.

Inoltre ora:

Il nodo 𝛼 sa di poter raggiungere il nodo [2, 1, 0] passando per l'arco 𝛼-𝛽_B.

Anche questa è una conoscenza nuova, ma l'indirizzo di destinazione è virtuale. Quindi nessun comando verrà dato.

Ora che il nodo 𝛽_B ha trasmesso i suoi primi ETP ai diretti vicini 𝛼 e 𝛾, dopo aver atteso qualche istante per permettere la loro processazione da parte di 𝛼 e 𝛾, il nodo 𝛽_i(1,2) rimuove i suoi archi con nodi che non appartengono al suo g-nodo di livello 2. Si ricordi infatti che il livello più alto in cui i due g-nodi A e B differiscono è 2. Quindi 𝛽_i(1,2) rimuove il suo arco con il nodo 𝛼.

Questo fa si che il nodo 𝛼 non può più raggiungere il g-nodo [1] passando per l'arco 𝛼-𝛽_i(1,2). Però abbiamo detto prima che aveva appreso di poterlo fare passando per l'arco 𝛼-𝛽_B.

Va quindi cambiata, dal nodo 𝛼, la rotta verso 10.0.0.4/30, sostituendo il gateway 𝛽_i(1,2) con 𝛽_B. Va poi rimossa, dal nodo 𝛼, la sua rotta verso 𝛽_i(1,2).

Va poi rimossa, dal nodo 𝛽, la rotta di 𝛽_i(1,2) verso 𝛼, e vanno rimosse o cambiate le rotte che eventualmente si appoggiavano su tale arco.

Quindi diamo questi comandi:

nodo 𝛼

ip route change 10.0.0.4/30 src 10.0.0.2 via 169.254.96.141 dev eth1
ip route del 169.254.27.218 dev eth1 src 169.254.69.30

nodo 𝛽

ip netns exec ntkv0 ip route del 10.0.0.0/30 via 169.254.69.30 dev ntkv0_eth1
ip netns exec ntkv0 ip route del 169.254.69.30 dev ntkv0_eth1 src 169.254.27.218

Ora il nodo 𝛽_B, avendo rimosso un suo arco, comunica le variazioni apportate alla sua mappa tramite un ETP agli altri vicini. Quindi il nodo 𝛾, al ricevere tale ETP, sa che non può più raggiungere il g-nodo [0] passando per l'arco 𝛾-𝛽_i(1,2). Però abbiamo detto prima che aveva appreso di poterlo fare passando per l'arco 𝛾-𝛽_B. Va quindi cambiata, dal nodo 𝛾, la rotta verso 10.0.0.0/30, sostituendo il gateway 𝛽_i(1,2) con 𝛽_B.

Quindi diamo questi comandi:

nodo 𝛾

ip route change 10.0.0.0/30 src 10.0.0.6 via 169.254.96.141 dev eth1

Riassumiamo l'elenco degli archi ora presenti e il grafo che descrive la rete.

𝛼-𝛽_B
𝛾-𝛽_B
𝜀-𝛽_B
𝛾-𝛽_i(1,2)
𝛾-𝛿
𝛿-𝜇
𝜀-𝛽_i(1,2)

Temporaneamente, il nodo 𝛽 non è in grado di comunicare con gli altri nodi della rete in quanto ha solo indirizzi virtuali al livello 0. Nonostante questo, il nodo è perfettamente in grado di inoltrare pacchetti provenienti da altri nodi e destinati ad altri nodi nella rete. Quindi sebbene 𝛽 sia un nodo punto di articolazione, il grafo resta connesso.

Proseguiamo con il passo 5.