Salve, volevo porvi una domanda su un "problema" che ha tenuto me ed i miei colleghi un po' sotto pressione nell'ultimo mese. Il problema nasce in seguito ad un'attività di riavvio di un intero ced, quando all'improvviso il trasferimento dati dai siti remoti dell'azienda in cui lavoro diventa quasi impossibile causando un susseguirsi di messaggi di errori di crc o di timeout delle connessioni verso server con cartelle condivise o servizi di service management e database. La rete che gestiamo è "appoggiata" all'mpls di fastweb (in particolare fastweb ha configurato una serie di tunnel vpn tra le varie sedi). Il nostro core è basato su cisco catalyst 4500 e cisco catalyst 3560, che si occupano del routing interno e dell'intervlan routing. All'inizio sembrava che il problema fosse causato dagli apparati che si occupano dell'encryption di tutto il traffico generato da tutte le sedi della suddetta azienda, ma non era così. Per rendere più comprensibile la topologia vi dico che: - ogni sede ha un core basato su 2 cisco catalyst (4500/3560) in hsrp - ogni sede ha 2 router cisco (2621/2821) fastweb connessi ai nostri core attraverso vlan specifiche - ogni sede ha 2 encryptor (che generano tunnell ipsec) connessi ai router fastweb attraverso una vlan specifica ed ai catalyst attraverso un'altra vlan specifica - le varie sedi sono collegate tra di loro attraverso una rete mpls fastweb con link che varia tra i 20 ed i 40Mbit - le varie sedi sono poi collegate con le sedi straniere attraverso 2 router cisco (2610XM e 3825) e 2 encryptor con un unico link, gestito da Orange Telecom, a 8Mbit
Dopo un'attenta analisi svolta da più di un esperto sembrava che il problema fosse imputabile all'errato valore dell'mtu impostato su tutti gli apparati. Tuttavia la rete in questione è in funzione da 5 anni e non è stata mai apportata alcuna modifica al suddetto valore; aggiungerò poi che nel momento in cui sono stati installati gli apparati di encryption era stato richiesto un test proprio per controllare che il processo di encryption non causasse problemi nel momento del reincapsulamento ipsec. Tali test avevano confermato che l'encryption non causava alcun problema. Gli esperti suddetti,inoltre, erano sicuri che il problema fosse proprio l'mtu che fino a quel momento era impostato a 1500 byte come standard. Per questo ci è stato richiesto di modificarlo apportando il valore a 1300 byte. Le analisi, svolte dal mio team hanno, però, constatato che il problema si presentava solo in caso di connessioni verso e da macchine windows (client e server) che erano state aggiornate con le ultime patch di sicurezza (alcune riguardanti il famoso virus conficker); inoltre le nostre analisi e ricerche conseguenti hanno mostrato che alcune patch possono modificare il valore dell'mtu, del path mtu discovery e dell'mss sui singoli client creando in qualche caso problemi nei trasferimenti dati nonchè timeout o quant'altro. Voglio aggiungere che il problema coinvolgeva solo le connessioni verso il ced mentre tutti i servizi verso l'estero o verso altri servizi funzionavano correttamente. Purtroppo ad oggi non sappiamo se il problema sia stato proprio l'mtu o un problema lato server/client (i nostri colleghi lato sala server non ci hanno mai dato alcun riscontro o analisi effettuate) visto che il giorno in cui abbiamo modificato l'mtu sugli apparati di encryption (che si occupano del routing di tutto il traffico delle diverse sedi verso i router fastweb) è stato riavviato l'intero ced (e quindi tutti i server windows). Dopo avervi spiegato un pò ciò che è successo e scusandomi della mia mail prolissa volevo chiedervi: E' possibile che il valore di default dell'mtu (1500) possa provocare un qualche problema a livello di interconnessione tra varie sedi? E' possibile pensare che il problema fosse locato lato server? A qualcuno di voi è mai capitato un problema simile? Vi ringrazio della vostra attenzione e del vostro aiuto. ciao vito _______________________________________________ http://cug.areanetworking.it [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
