Nella pagina Facebook di AreaNetworking.it è stata inserita la foto che vedete qui a fianco, chiedendo a voi networkers cosa potesse essere.
Con questo articolo, voglio spiegare di cosa si tratta. In sostanza, é una soluzione pratica ad un problema che si presenta in varie circostanze: vi è mai capitato di non poter accedere ad un apparato tramite un determinato indirizzo, poichè la porta fisica di attestazione di quell’indirizzo risulta down? Capiamo brevemente perchè succede e come aggirare il problema.
Un breve esempio: border router
Consideriamo un semplicissimo router di frontiera, costituito da una punto a punto con l’ISP , 192.1.2.0/30, e una classe assegnata 1.1.1.0/29: se l’interfaccia fisica su cui poggia la classe assegnata (1.1.1.1) è down, dall’esterno quell’indirizzo non sarà raggiungile.
Vediamo l’esempio con un ping inviato dall’esterno:
# ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. From 192.1.2.1 icmp_seq=1 Time to live exceeded From 192.1.2.1 icmp_seq=2 Time to live exceeded From 192.1.2.1 icmp_seq=3 Time to live exceeded From 192.1.2.1 icmp_seq=4 Time to live exceeded From 192.1.2.1 icmp_seq=5 Time to live exceeded From 192.1.2.1 icmp_seq=6 Time to live exceeded From 192.1.2.1 icmp_seq=7 Time to live exceeded From 192.1.2.1 icmp_seq=8 Time to live exceeded From 192.1.2.1 icmp_seq=9 Time to live exceeded ^C --- 1.1.1.1 ping statistics --- 9 packets transmitted, 0 received, +9 errors, 100% packet loss, time 8009ms
TTL exceeded è una risposta interessante, perchè proprio questo risultato al ping? Proviamo anche un traceroute:
# traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets // alcuni hop fino all'ISP del mio border router 11 192-1-2-2-isp.net (192.1.2.2) 62.798 ms 60.424 ms 62.396 ms 12 192-1-2-1-isp.net (192.1.2.1) 62.706 ms 62.108 ms 61.744 ms 13 192-1-2-2-isp.net (192.1.2.2) 67.866 ms 65.754 ms 67.314 ms 14 192-1-2-1-isp.net (192.1.2.1) 67.751 ms 67.478 ms 67.286 ms 15 192-1-2-2-isp.net (192.1.2.2) 71.699 ms 72.995 ms 73.901 ms 16 192-1-2-1-isp.net (192.1.2.1) 177.307 ms 177.012 ms 177.578 ms 17 192-1-2-2-isp.net (192.1.2.2) 78.612 ms 77.994 ms 77.908 ms 18 192-1-2-1-isp.net (192.1.2.1) 109.525 ms 78.944 ms 80.213 ms 19 192-1-2-2-isp.net (192.1.2.2) 84.991 ms 83.710 ms 85.765 ms 20 192-1-2-1-isp.net (192.1.2.1) 83.953 ms 84.678 ms 86.832 ms 21 192-1-2-2-isp.net (192.1.2.2) 89.130 ms 90.348 ms 91.180 ms 22 192-1-2-1-isp.net (192.1.2.1) 90.811 ms 92.646 ms 92.308 ms 23 192-1-2-2-isp.net (192.1.2.2) 96.871 ms 96.896 ms 94.969 ms 24 192-1-2-1-isp.net (192.1.2.1) 97.341 ms 96.990 ms 96.980 ms 25 192-1-2-2-isp.net (192.1.2.2) 101.299 ms 101.900 ms 102.543 ms 26 192-1-2-1-isp.net (192.1.2.1) 101.009 ms 107.004 ms 101.364 ms 27 192-1-2-2-isp.net (192.1.2.2) 107.978 ms 106.719 ms 108.827 ms 28 192-1-2-1-isp.net (192.1.2.1) 107.126 ms 108.889 ms 107.377 ms 29 192-1-2-2-isp.net (192.1.2.2) 114.639 ms 114.593 ms 114.134 ms 30 192-1-2-1-isp.net (192.1.2.1) 114.698 ms 113.341 ms 111.249 ms
Ora il TTL exceeded diventa più chiaro: il nostro border e l’altro router del provider, che sta sullo stesso segmento /30, si rimpallano il ping finchè, appunto, il TTL dei nostri pacchetti si esaurisce e scade. Cosa spinge il nostro border a rimpallarsi i pacchetti? Andiamo a vedere la routing table:
Border#sh ip route Gateway of last resort is 192.1.2.1 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 192.1.2.1 192.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 192.1.2.0/30 is directly connected, Serial0/0/0.1 L 192.1.2.2/32 is directly connected, Serial0/0/0.1
La 1.1.1.0/29, essendo attestata su una interfaccia down, non viene installata nella routing table: quando il router riceve un pacchetto per 1.1.1.1 lo inoltra usando la default route, innescando il loop descritto in precedenza e facendo scadere il TTL del nostro pacchetto ICMP.
Workaround
Come risolvere? Semplice, basta mandare up l’interfaccia interna, però se non abbiamo nessun altro device nei paraggi il problema diventa serio… ma si aggira, con una ethernet loopback. Si tratta semplicemente di connettere i pin riceventi con quelli trasmissivi, sul medesimo jack RJ45: nello specifico, andremo a connettere i pin (1,3) e (2,6), nel caso di gigabit ethernet dovremo aggiungere anche (4,7) e (5,8), il tutto mantenendo il “dentino” di plastica verso il basso.
Basta un plug RJ45 nuovo, una pinza crimpatrice e 10-15 cm di cavo ethernet: tagliandolo sulle due estremità, basta sfilare due coppie ed isolando 4 fili possiamo creare la piedinatura sopra descritta. Crimpato il jack in questo modo e inseritolo nella nostra ethernet, l’interfaccia andrà up traendoci d’impaccio. Vediamolo con uno schema riassuntivo:
Considerazioni
Questa è solo una misura temporanea e come tale dovrebbe essere usata in emergenza, non come un elemento su cui basare le nostre soluzioni. Esistono alcune alternative a quanto esposto, questo è solo un elenco parziale:
- usare delle interfacce logiche loopback, per definizione sempre up, dove attestare gli ip da raggiungere
- sugli alcuni switch, è possibile mettere gli ip su una interfaccia vlan e separare la condizione di up fisico da quella di up logico tramite le keyword
switchport autostate exclude
- su altri apparati (e.g. Junos) l’interfaccia fisica è configurabile come loopback (always up)
# edit interfaces ge-0/0/0 # set loopback # commit
