[Ninux-Wireless] Problema design policy routing Ninux

[Saverio Proto]

Ciao,

grazie a Lorenzo che ha messo in campo a Viterbo l'archiettura con il
policy routing abbiamo trovato un problema di design:

premesse, non centrano nulla le network a blackhole come si pensava al
principio del troubleshooting.

su un nodo con policy routing troviamo questa situazione:

XM.v5.5.sdk# ip rule show
0:      from all lookup local
4:      from all to 10.0.0.0/8 lookup 111
4:      from all to 172.16.0.0/12 lookup 111
4:      from all to 192.168.0.0/16 lookup 111
4:      from all to 176.62.53.0/24 lookup 111
4:      from 176.62.53.0/24 lookup 111
5:      from all lookup main
6:      from all lookup 112

111 è la tabella delle rotte OLSR e 112 è la tabella della default via OLSR

XM.v5.5.sdk# ip route show table local
broadcast 10.183.1.255 dev eth0  proto kernel  scope link  src 10.183.1.11
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
local 172.16.183.2 dev ath0  proto kernel  scope host  src 172.16.183.2
local 10.183.1.11 dev eth0  proto kernel  scope host  src 10.183.1.11
broadcast 172.16.0.0 dev ath0  proto kernel  scope link  src 172.16.183.2
broadcast 10.183.1.0 dev eth0  proto kernel  scope link  src 10.183.1.11
broadcast 172.16.255.255 dev ath0  proto kernel  scope link  src 172.16.183.2
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
XM.v5.5.sdk#

XM.v5.5.sdk# ip route show table main
blackhole 176.62.53.0/24
10.183.1.0/24 dev eth0  proto kernel  scope link  src 10.183.1.11
172.16.0.0/16 dev ath0  proto kernel  scope link  src 172.16.183.2
blackhole 192.168.0.0/16
blackhole 172.16.0.0/12
blackhole 10.0.0.0/8
XM.v5.5.sdk#

Nell'esempio di casa mia la LAN è 10.183.1.0/24
Lo sbaglio sta nel pensare che la route per la rete locale
10.183.1.0/24 si trova nella tabella "local" che è la prima che viene
esaminata.

In "local" ci sta la route per 10.183.1.255 (broadcast) ma non la
route per gli host locali, che sta invece nella tabella "main":
10.183.1.0/24 dev eth0  proto kernel  scope link  src 10.183.1.11

Ora succede che visto che girava in OLSR come HNA 10.110.0.0/18
(annunciata dal concentratore VPN quando Viterbo non parlava OLSR)
questa network anche se meno specifica delle varie LAN /24 che usano a
Viterbo (esempio 10.110.1.0/24) veniva sempre preferita alla network
locale su eth0.

Si poteva risolvere un due modi, o con una network aggiunta a mano
nella table local:
ip route add 10.110.1.0/24 dev eth0 table local

oppure togliendo di mezzo l'HNA dell'aggregato /18.

abbiamo testato tutti e due i workaround e funzionano.

resta da risolvere in modo elegante il problema perché adesso
basterebbe un annuncio HNA di un grande aggregato come 10.0.0.0/8 per
interrompere la connettività dei nodi con la propria LAN se contenuta
in quell'aggregato.

vi ricordo che la tabella "main" contiene la rotta di default che
viene inserita opzionalmente a mano dall'utente nell'interfaccia web,
e quindi deve essere valutata per forza dopo la table 111.

a mio avviso ci sono due strade. O facciamo in modo che non c'è MAI
una default nella main, e quindi la possiamo valutare per prima della
111, altrimenti dobbiamo fare una nuova tabella con le network locali
da valutare prima della 111.

se qualcuno vuole fare una patch per sburratone che risolve il
problema il codice è su github.

ciao,

Saverio