ultimamente ho dovuto configurare una coppia di router 2900 connessi tra di loro mediante tunnel GRE + IPsec.
L'interfaccia gi0/2 di entrambi i router è quella su cui sono attestati i client delle rispettive LAN, mentre le interfacce gi0/1 di entrambi sono direttamente collegate ai router WAN che fungono da "trasporto" per il tunnel GRE + IPsec. Poichè la mia intenzione sarebbe quella di abilitare la PMTUD sulle interfacce tun di entrambi i router (per consentire l'autonegoziazione della MTU), ho fatto in modo che i router coinvolti fossero in grado di inoltrare i messaggi ICMP unreachable df (type 3 code 4, per essere più precisi). Ho quindi deciso di testare il tutto ponendomi nel caso più semplice: abilitare i messaggi ICMP unreachable sull'interfaccia LAN di un router e provare ad inoltrare una serie di pacchetti ICMP con il bit DF a 1 da un client direttamente attestato su di essa (per "direttamente" intendo senza switch o altri dispositivi L2 in mezzo), puntando proprio all'IP dell'interfaccia LAN del router.
Alcune info:
1) L'IP del client è 192.168.1.12 mentre l'IP dell'interfaccia LAN del router è 192.168.1.61;
2) la MTU dell'interfaccia eth del PC client è pari a 1500 byte;
3) sull'interfaccia eth gi0/2 (LAN) del router a cui era collegato il client ho artificiosamente abbassato la MTU nativa (1500 byte) portandola a 1476 byte (ip mtu 1476);
4) sempre sulla eth gi0/2 (LAN) dello stesso router ho abilitato l'invio dei messaggi ICMP unreachable digitando il comando "ip unreachable";
5) ho abilitato il debug dell'ICMP (debug ip icmp) per appurare che i pacchetti in oggetto venissero effettivamente generati ed inoltrati;
6) sul router ho disabilitato a livello globale l'ICMP unreachable rate limit (no ip icmp rate-limit unreachable). So che tale configurazione è KO per quanto riguarda la sicurezza, ma essa è stata impiegata solo durante i test e su dei sistemi non ancora in produzione;
7) sul router non esistevano ACL di alcun genere;
le IOS che ho utilizzato per i test sono, rispettivamente, la 15.2(4)M3 e la 15.5(1)T. Ho utilizzato due versioni differenti di IOS per scongiurare eventuali bachi a livello di SO del router;9) il "display filter" utilizzato su Wireshark è semplicemente "icmp".
Test svolti
Come test ho semplicemente pingato l'interfaccia LAN del router (quella su cui avevo ridotto la MTU):
C:\Users\nightfly>ping 192.168.1.61 -l 1473 -f
ricevendo come risposta "Richiesta scaduta" anzichè "E' necessario frammentare il pacchetto ma DF è attivo" (sniffando il traffico con Wireshark ero in grado di vedere solo le echo request e nessun tipo di risposta da parte del router). Ovviamente, riducendo il payload del pacchetto ICMP (flag -l) e portandolo a 1448 byte ho ricevuto ICMP echo reply (come c'era da aspettarsi, poichè 1448 byte è l'ultimo valore utile - al payload di 1448 byte vanno sommati 20 byte di intestazione IP e 8 byte di intestazione ICMP, per un totale di 1476 byte che è la MTU dell'interfaccia LAN, dimensione oltre la quale si ha frammentazione).
Inoltre, sempre mediante Wireshark, mi sono accorto che il router era in grado di inoltrare correttamente altre tipologie di messaggi ICMP unreachable, quali host unreachable e port unreachable, ma non i DF.
Guardando l'output del "debug ip icmp" ho notato che le risposte venivano correttamente generate:
Codice: Seleziona tutto
*Dec 17 07:40:26.735: ICMP: echo reply sent, src 192.168.1.61, dst 192.168.1.12, topology BASE, dscp 0 topoid 0
*Dec 17 07:40:26.735: ICMP: dst (192.168.1.12): frag. needed and DF set
*Dec 17 07:40:31.727: ICMP: echo reply sent, src 192.168.1.61, dst 192.168.1.12, topology BASE, dscp 0 topoid 0
*Dec 17 07:40:31.727: ICMP: dst (192.168.1.12): frag. needed and DF set
*Dec 17 07:40:36.735: ICMP: echo reply sent, src 192.168.1.61, dst 192.168.1.12, topology BASE, dscp 0 topoid 0
*Dec 17 07:40:36.735: ICMP: dst (192.168.1.12): frag. needed and DF setApparentemente sembra che si tratti di un baco, ma consultando la buglist della Cisco non vi è alcuna segnalazione di questo tipo (per entrambe le IOS utilizzate, le quali presentano entrambe tale anomalia).
Qualcuno di voi ci è già passato prima? Sapreste dirmi se si tratta di un baco?
Grazie
PS: so che potrei settare il tcp adjust-mss sull'interfaccia LAN, utilizzando una dimensione pari a 1436 byte (1476 MTU nativa dell'interfaccia tunnel GRE - 20 byte di intestazione IP - 20 byte di intestazione TCP), ma preferirei optare per la PMTUD.
