Re: [Ninux-Wireless] Digest di Wireless, Volume 50, Numero 27
Ciao a tutti, sono Gabriel di ninux Firenze. Sono a Roma per qualche giorno per Codemotion e Romecup e volevo venire alla riunione settimanale al fusolab. Qualcuno potrebbe dirmi l'ora a cui inizia e un modo per arrivarci da termini? ( se qualcuno passasse in zona accetterei volentieri pure un passaggio) Ruspondete direttamente per pvt, che con il digest non so quando mi arriva la mail Gabriel wireless-requ...@ml.ninux.org ha scritto: Invia le richieste di iscrizione alla lista Wireless all'indirizzo wireless@ml.ninux.org Per iscriverti o cancellarti attraverso il web, visita http://ml.ninux.org/mailman/listinfo/wireless oppure, via email, manda un messaggio con oggetto `help' all'indirizzo wireless-requ...@ml.ninux.org Puoi contattare la persona che gestisce la lista all'indirizzo wireless-ow...@ml.ninux.org Se rispondi a questo messaggio, per favore edita la linea dell'oggetto in modo che sia più utile di un semplice Re: Contenuti del digest della lista Wireless... Argomenti del Giorno: 1. Problema design policy routing Ninux (Saverio Proto) 2. Re: olsr mdns plugin chiacchierone? (Alessio Caiazza) 3. [blog] Reverse FAQ: Cosa non siamo (geegeek) 4. [blog] Reverse FAQ: Cosa non siamo-old (geegeek) 5. [blog] (geegeek) 6. [blog] Reverse FAQ: Cosa non siamo (geegeek) -- Message: 1 Date: Wed, 20 Mar 2013 13:44:52 +0100 From: Saverio Proto ziopr...@gmail.com Subject: [Ninux-Wireless] Problema design policy routing Ninux To: wireless wireless@ml.ninux.org, nodi-r...@ml.ninux.org Message-ID: capmmg8uylnc_nflaihjgmw5izop5iq3auwclo0y3npa0mlf...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 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
Re: [Ninux-Wireless] Digest di Wireless, Volume 50, Numero 27
Da termini ci sta la linea giardinetti che si ferma davanti il fusolab. Il giorno 21/mar/2013 10:26, Gabriel Unname gabr...@autistici.org ha scritto: Ciao a tutti, sono Gabriel di ninux Firenze. Sono a Roma per qualche giorno per Codemotion e Romecup e volevo venire alla riunione settimanale al fusolab. Qualcuno potrebbe dirmi l'ora a cui inizia e un modo per arrivarci da termini? ( se qualcuno passasse in zona accetterei volentieri pure un passaggio) Ruspondete direttamente per pvt, che con il digest non so quando mi arriva la mail Gabriel wireless-requ...@ml.ninux.org ha scritto: Invia le richieste di iscrizione alla lista Wireless all'indirizzo wireless@ml.ninux.org Per iscriverti o cancellarti attraverso il web, visita http://ml.ninux.org/mailman/listinfo/wireless oppure, via email, manda un messaggio con oggetto `help' all'indirizzo wireless-requ...@ml.ninux.org Puoi contattare la persona che gestisce la lista all'indirizzo wireless-ow...@ml.ninux.org Se rispondi a questo messaggio, per favore edita la linea dell'oggetto in modo che sia più utile di un semplice Re: Contenuti del digest della lista Wireless... Argomenti del Giorno: 1. Problema design policy routing Ninux (Saverio Proto) 2. Re: olsr mdns plugin chiacchierone? (Alessio Caiazza) 3. [blog] Reverse FAQ: Cosa non siamo (geegeek) 4. [blog] Reverse FAQ: Cosa non siamo-old (geegeek) 5. [blog] (geegeek) 6. [blog] Reverse FAQ: Cosa non siamo (geegeek) -- Message: 1 Date: Wed, 20 Mar 2013 13:44:52 +0100 From: Saverio Proto ziopr...@gmail.com Subject: [Ninux-Wireless] Problema design policy routing Ninux To: wireless wireless@ml.ninux.org, nodi-r...@ml.ninux.org Message-ID: capmmg8uylnc_nflaihjgmw5izop5iq3auwclo0y3npa0mlf...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 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
