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 <ziopr...@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 _______________________________________________ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless