Ciao a tutti, Ieri sera mi sono imbatutto in un problema non banale mentre eseguivo la migrazione del network IPv6 di accesso di Fast Labs da routing statico a routing dinamico. La topologia della nostra rete di accesso IPv6 giace completamente su network IPv4 pre-esistenti in quanto, essendo il tunnel broker un progetto gratuito, le macchine che forniscono connettività agli utenti finali sono hostate fisicamente dietro linee residenziali sparse in varie parti di Italia. La connettività delle macchine di accesso (che chiamerò miniPOP d'ora in avanti) è terminata verso la backbone tramite un link VPN layer3 (con openVPN) e verso gli utenti tramite tunnel GRE/SIT. Fino ad adesso il routing IPv6 dai miniPOP verso gli apparati di backbone (POP) era implementato, come già detto, staticamente. Dopo varie valutazioni di laboratorio ho deciso di utilizzare OSPFv3 (tramite il demone 'ospf6d' della quagga suite) per il routing dinamico, visto che il numero di sottoreti routate all'utente finale inizia ad essere abbastanza alto e la ridondanza inizia a diventare una necessità. A livello operativo ho predisposto due aree nella configurazione di OSPFv3, una riservata ai router di backbone (POP) che hanno connettività nativa fra di loro (area 0.0.0.0) e una riservata al network di accesso (area 0.0.0.1). Alcuni POP, non tutti, parlano BGP4+ verso gli upstreams e ridistribuiscono in area 0.0.0.0 la full routing table BGP IPv4 e, ovviamente, le rotte statiche/connesse intra-area (circa 860 rotte contando anche le rotte intra-area). L'idea era quella di ridistruibire la full routing table ottenuta in area 0.0.0.0 verso i miniPOP (area 0.0.0.1) e ridistribuire le rotte di area 0.0.0.1 verso i POP che parlano BGP. Fino a qui tutto bene.. I problemi sono iniziati cercando di tirare su il routing tra il primo miniPOP (situato a Bologna) con il nostro POP principale (situato a Milano). Il link esistente tra le due macchine è una VPN layer3 (tramite openVPN) e il tipo di interfaccia utilizzata è TUN (point-to-point). Da subito i due lati della adiacenza OSPFv3 sono saliti in stato 'Full/Point-to-Point' e hanno iniziato regolarmente a scambiarsi LSAs. Tuttavia, osservando le tabelle di routing di entrambi i router, ho notato che le rotte venivano scambiate, ma non installate nel kernel e che, in entrambi i casi, il demone OSPFv3 sceglieva '::' come next-hop verso le rotte imparate dal neighbor. Il problema è imputabile al fatto che, essendo TUN un'interfaccia p-t-p e non avendo broadcast, linux/BSD non aggiungono in automatico l'indirizzo link-local predisposto da OSPFv3 ad essere il next-hop. L'utilizzo di interfacce di tipo TAP, che trasportano broadcast come una qualsiasi ethernet (utilizzano proprio ethernet come link encapsulation), risolve il problema in quanto linux/BSD aggiungono in automatico l'indirizzo link-local. Tuttavia le interfacce TAP hanno qualche problema, che si verifica in maniera randomica, nel trasportare IPv6 e la sfortuna vuole che questo problema si sia verificato proprio in quel collegamento (e in qualche altro). L'unico work-around possibile che mi è venuto in mente è stato quello di aggiungere *manualmente* gli indirizzi link-local ad entrambi i VPN con risultati, in un primo momento, *ottimi*. I due routers hanno iniziato ad installare le rotte IPv6 nel kernel correttamente e i pacchetti hanno iniziato a passare nella maniera giusta. Dopo qualche minuto, però, il miniPOP ha riportato 'kernel tainted' e in poco è andato in 'kernel panic' causando il crash della macchina. Domani mi recherò a Bologna e investigherò se il crash è stato causato da OSPFv3 in se o se l'aggiunta del link-local address manuale abbia scombussolato qualcosa. Se a qualcuno viene in mente un altro work-around o una soluzione definitiva per il problema vi prego di farmi sapere e lo proverò sui link di test ancora in piedi. Grazie a tutti,
Samer -- Samer Francesco Abdel-Hafez Network Operations Coordinator, Fast Labs Group e-mail: [EMAIL PROTECTED] nic-handle: SA3083-RIPE web site: http://www.fast-labs.net _______________________________________________ Cug mailing list http://www.areanetworking.it/index_docs.php [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
