[Ninux-Wireless] Problema design policy routing Ninux

Saverio Proto zioproto a gmail.com
Ven 22 Mar 2013 23:07:21 CET


Fixed, testato sulle mie antenne:
https://github.com/zioproto/SDK.UBNT.v5.5/commit/36c5304b68732833f38f6f7eaeabd8acfab87929

prima di fare una nuova build di Sburratone mi date feedback ?

Saverio



Il 20 marzo 2013 13:44, Saverio Proto <zioproto a gmail.com> ha scritto:
> 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



Maggiori informazioni sulla lista Wireless