Grazie Saverio, proverò a passare a BIRD, vediamo se si rivela più adatto alle mie capacità (limitate).
Ciao, Marco Il giorno 27 aprile 2018 13:02, Saverio Proto <ziopr...@gmail.com> ha scritto: > Quagga ed olsrd sono programmi userspace. > > Visto che sono implementazioni di protocolli di routing, dopo aver > computato quali "route" sono necessarie, devono scrivere le "route" > nel network stack del kernel di linux. E' solo quando sono state > inserite li, che le ruote funzionano. > > Ora l'architettura in questo caso e' fatta in modo che solo Quagga > scrive nella tabella di routing del kernel. Olsrd computa le "route" > ma non le scrive nel kernel, le passa a quagga che poi si occupa di > inserire le rotte nella tabella di routing nel kernel. > > Come tu dici, si potrebbe avere una architettura diversa, dove olsrd > scrive in una tabella di routing riservata, e quagga lo stesso. Ma poi > come fai ad usare le informazioni divise in due tabelle separate ? > Quello che ti serve e' una tabella unica con tutte le route. > > ciao, > > Saverio > > Il 26 aprile 2018 15:02, Marco Tarquini <marco.tarqu...@gmail.com> ha > scritto: > > Ok, proviamo ad aggirare la questione per come l'ho posta. > > > > Nella guida VPN Isole si legge, a proposito di quagga (terzo punto, file > > zebra.conf) > > > > "Quagga prende le rotte apprese dal peer e dall'istanza locale di OLSR e > le > > scrive nella tabella di routing del kernel " > > > > Perché è necessario scriverle nella tabella del kernel? Essendo iproute2 > > multi-table, che cosa comporta che queste rotte siano o meno nella > tabella > > di routing del kernel? > > > > So che è un po' ingenuo, ma visto che al momento non riesco a > perfezionare > > questo passaggio, vorrei capire, con l'aiuto da parte di qualcuno > esperto di > > BGP ed OLSR (che io da neo-iscritto sicuramente proprio non sono), se sia > > possibile implementare dei workaround o anche ometterlo. > > > > Grazie dell'attenzione e della pazienza e buona giornata a tutti. > > Marco > > > > > > Il giorno 25 aprile 2018 13:21, Marco Tarquini <marco.tarqu...@gmail.com> > ha > > scritto: > >> > >> Si Saverio, > >> > >> grazie per avermi spiegato in maniera corretta quello che alla meno > peggio > >> avevo "intuito" ri-editando il file tinc-up > >> C'è un modo per avere l'interfaccia tap "permanente", per non avere le > mie > >> tavole di routing cambiare a seconda se la VPN sia su o giù? > >> > >> Se posso chiedere un ulteriore aiuto alla ml, il file zebra.conf della > >> guida, a differenza di quagga.conf mi è di difficile traduzione per la > CLI > >> dell'Edgerouter, perché la sintassi non è esattamente sovrapponibile. > >> > >> C'è qualcuno qui (forse la persona che risponde al nick clauz? O > Massullo > >> se ha degli Edgerouter a disposizione?) che mi può fornire qualche > >> spiegazione, o indirizzare a qualche documento al riguardo? > >> > >> Grazie ancora, buona giornata ed auguri a tutti. > >> > >> Un cordiale saluto, > >> Marco > >> > >> Il giorno 25 aprile 2018 11:37, Saverio Proto <ziopr...@gmail.com> ha > >> scritto: > >>> > >>> La rete 10.150.254.0/24 e' la rete utilizzata per la VPN Tinc. Ogni > >>> router BGP vede questa rete come direttamente connessa, in quanto ha > >>> una interfaccia tap che ha un IP di questa rete. Non servono rotte > >>> statiche perche' ogni altro router BGP e' quindi raggiungibile tramite > >>> una rete direttamente connessa. > >>> Spero di averti risposto. > >>> > >>> saluti, > >>> > >>> Saverio > >>> > >>> Il 24 aprile 2018 17:54, Marco Tarquini <marco.tarqu...@gmail.com> ha > >>> scritto: > >>> > Forse mi rispondo da solo... > >>> > > >>> > Il giorno 24 aprile 2018 11:47, Marco Tarquini > >>> > <marco.tarqu...@gmail.com> ha > >>> > scritto: > >>> >> > >>> >> > >>> >> Non conoscendo tinc (mai sentito in vita mia prima della guida), non > >>> >> so > >>> >> che interfaccia mi ritrovo su quando lo attivo con lo script > >>> >> "tinc-up", e > >>> >> che IP avrò su questa interfaccia. > >>> >> > >>> > > >>> > ...se io leggessi (DOH!) quello che copio ed incollo dentro putty, > >>> > avrei > >>> > visto che l'IP del tunnel tinc è quello che ci metto io, cioè lo > stesso > >>> > del > >>> > bgpd.conf, giusto? > >>> > E quindi che per fare il peer non servirà nessuna route statica tra > >>> > update > >>> > source ed endpoint locale, in quanto hanno lo stesso IP? > >>> > > >>> > Mi sono risposto + o - correttamente oppure ho preso una cantonata? > >>> > > >>> > Grazie in anticipo di eventuali commenti. > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Wireless mailing list > >>> > Wireless@ml.ninux.org > >>> > http://ml.ninux.org/mailman/listinfo/wireless > >>> > > >>> _______________________________________________ > >>> Wireless mailing list > >>> Wireless@ml.ninux.org > >>> http://ml.ninux.org/mailman/listinfo/wireless > >> > >> > > > > > > _______________________________________________ > > Wireless mailing list > > Wireless@ml.ninux.org > > http://ml.ninux.org/mailman/listinfo/wireless > > > _______________________________________________ > Wireless mailing list > Wireless@ml.ninux.org > http://ml.ninux.org/mailman/listinfo/wireless >
_______________________________________________ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
