|
Size: 5440
Comment:
|
Size: 5552
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 33: | Line 33: |
| * 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,,-~. |
* 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,,-~-𝛼. |
| Line 48: | Line 48: |
| * Il nodo 𝛽~-,,i(1,2),,-~ sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛽~-,,i(1,2),,-~-𝛾. | |
| Line 49: | Line 50: |
| Sono due conoscenze nuove, ma che non cambiano il miglior percorso verso quelle destinazioni per 𝛼 e 𝛾. Quindi nessun comando verrà dato. | Sono conoscenze nuove, ma che non cambiano il miglior percorso verso quelle destinazioni per quei nodi. Quindi nessun comando verrà dato. |
| Line 72: | Line 73: |
| 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 change 10.0.0.0/30 via 169.254.94.223 dev ntkv0_eth1 |
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 g1(𝛼). 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.
Il nodo 𝛽i(1,2) sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛽i(1,2)-𝛾.
Sono conoscenze nuove, ma che non cambiano il miglior percorso verso quelle destinazioni per quei nodi. 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 change 10.0.0.0/30 via 169.254.94.223 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.