IP for Fun: Funzionalità avanzate di ip

5. Funzionalità avanzate di ip

Nei paragrafi precedenti ho spesso parlato di tabelle di routing al plurale, e non si tratta di un errore: nei kernel 2.2.x e 2.4.x si hanno infatti a disposizione più tabelle di routing.

Di default, infatti, sono presenti 3 tabelle di routing: la tabella main, la tabella local e la tabella cache.

La tabella main contiene la tabella principale, quella che, per intenderci, viene modificata inconsciamente dal comando ``route'' e che viene modificata in caso non venga indicata esplicitamente un'altra tabella. La tabella cache tiene una cache (come il nome lascia intuire :) dei route utilizzati di recente mentre la tabella local contiene tutti gli indirizzi locali (normalmente gli indirizzi di tutte le interfacce, quelli di broadcast e quelli di multicast). Per vedere il contenuto di una tabella specifica è necessario dare il comando ``ip route show table nometabella''.

Per vedere il contenuto di tutte le tabelle, potete utilizzare come ``nometabella'' la parola ``all'', che vi dovrebbe dare un output simile a:


192.168.200.0/24 dev eth0  proto kernel  scope link  src 192.168.200.1 
127.0.0.0/8 dev lo  scope link 
default via 192.168.200.3 dev eth0 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.200.255 dev eth0  table local  proto kernel  scope link  src 192.168.200.1 
local 192.168.200.1 dev eth0  table local  proto kernel  scope host  src 192.168.200.1 
broadcast 192.168.200.0 dev eth0  table local  proto kernel  scope link  src 192.168.200.1 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1

In questa schermata manca il collegamento seriale (nel frattempo è stato disattivato) e mancano le righe (entry) sugli indirizzi di multicast.

Ancora una volta però, iniziamo ad analizzare la prima riga. In questa riga vediamo che possiamo raggiungere la rete 192.168.200.0/24 attraverso l'interfaccia eth0, vediamo che il protocollo utilizzato per gestire questo indirizzo è quello del kernel, vediamo che lo scope è impostato a link e infine vediamo che l'indirizzo ip sorgente da usare è 192.168.0.1.

Per quanto riguarda il protocollo, questo indica come è stato inserito il route. Nel nostro caso, ``kernel'' indica che il route è stato automaticamente inserito quando abbiamo attivato l'interfaccia (con ip link set eth0 up). Altri possibili valori sarebbero potuti essere:

``static'', ad indicare che un amministratore ha voluto inserire manualmente il valore e che non deve essere automaticamente modificato
``boot'' che è stato inserito sempre dal kernel utilizzando protocolli come il dhcp od il bootp
``redirect'' che è stato inserito per via di un messaggio ICMP che ci indicava un percorso migliore per raggiungere una determinata destinazione

Il parametro ``scope'' è invece normalmente impostato a ``link'' per tutti gli host direttamente raggiungibili (per cui non c'è bisogno di passare per un gateway) e quindi per gli indirizzi di broadcast, mentre ``host'' è usato per tutti gli altri indirizzi nella tabella di local (notate che 127.0.0.0/8 in questo caso non è considerato un indirizzo di broadcast).

Infine, il parametro src indica quale indirizzo ip deve essere utilizzato come sorgente per mandare pacchettini agli altri computer connessi alla rete indicata. Tutti questi parametri possono essere modificati manualmente sempre utilizzando il comando ip route.

Per esempio, è possibile aggiungere un route statico dando un comando simile a:


  # ip route add 172.163.54.12 via 192.168.200.3 proto static

Notate inoltre che in alcune righe viene mostrato il parametro ``table''. Questo è seguito dal nome della tabella in cui si trova il route. Quando però il nome della tabella viene omesso, come nelle prime tre righe, il route deve essere considerato parte della tabella ``main'', quella cioè di default.

Prima di andare oltre, è necessario aggiungere qualche piccola informazione su come il kernel faccia ad individuare il route ``corretto'' da utilizzare (perchè, per esempio, non manda sempre tutti i pacchetti al route di default, ovvero 0.0.0.0/0?). Quando un pacchetto deve essere inviato, il kernel cerca tra tutte le righe nella tabella di routing quelle che indicano un destinatario che potrebbe andare bene. Volendo raggiungere 192.168.0.1, potrebbe quindi scegliere per esempio tre righe come 192.168.0.0/24, 192.168.0.0/16 o 0.0.0.0/0 (default). In caso di ambiguità come queste, sceglierebbe quindi la riga che verifica un numero di bit maggiori (in questo caso, 192.168.0.0/24). Infine, se dovessero rimanere ancora ambiguità, sceglierebbe il route inserito per primo o, se sono stati inseriti dei costi, quello con il costo minore.

Vediamo quindi di fare un esempio. Immaginiamo di avere due interfacce collegate ad una stessa rete. Beh, essendo collegate ad una stessa rete, avranno due indirizzi molto simili, ad esempio 192.168.200.1 ed 192.168.200.2, ed avranno due route molto simili indicati nella tabella di routing, per esempio:


192.168.200.0/24 dev inf0  proto kernel  scope link  src 192.168.200.1 
192.168.200.0/24 dev inf1  proto kernel  scope link  src 192.168.200.2

dove per ``inf'' è intesa una interfaccia di rete qualsiasi. In questo caso il kernel sceglierebbe probabilmente il primo route, pur non avendo alcun valido motivo per non utilizzare il secondo. Se invece inf0 fosse molto più lenta della seconda interfaccia, si potrebbero associare dei costi a queste interfacce in modo da far utilizzare al kernel sempre inf1 (potrebbe essere il caso, per esempio, di un collegamento di backup via modem isdn o di qualcosa di simile), con qualcosa del tipo:


ip route flush dev inf0
ip route flush dev inf1

ip route add 192.168.200.0/24 dev inf0 preference 10
ip route add 192.168.200.0/24 dev inf1 preference 1

Dove i primi due comandi eliminerebbero tutti i route relativi ad inf0 ed inf1, mentre gli altri comandi creerebbero rispettivamente un route via inf0 con preferenza a 10 (metric) ed un route tramite inf1 con preferenza pari ad 1.

Attenzione però che la preferenza deve essere intesa come un ``costo'': il kernel sceglierà infatti il route con preferenza minore.

E' possibile fare anche bilanciamento del carico su più connessioni, ma fino a qualche versione del kernel fa, utilizzando il sistema di bilanciamento standard, non era possibile utilizzare molte funzioni di NAT (Network Address Translation) e vi conviene quindi cercare documentazione specifica in proposito (magari guardando anche ciò che riguarda il ``bonding'').

Avanti Indietro Indice