A proposito dell'autore

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

Post correlati

  • GianPaolo Boarina

    E’ possibile anche disattivare il keepalive sull’interfaccia ethernet del router così va in stato up/up col cavo disconnesso.

  • In realtà oggi ho provato su un 3750 giga e su un 3560 fast: quello giga non si schioda, come se il plug non venisse inserito; il 3560 invece va up ma poi devia in errdisable per il problema che hai indicato. Anche disabilitando globalmente l’errdisable comunque continuo ad avere problemi sulla porta che è POE, genera errori e flappa. A te rimane up/up la porta? Per inciso uno Huawei S3300 e un HP 2524 tirano su la porta senza battere ciglio…

  • Luigi Cristiani

    Esatto GianPaolo, come ho suggerito anche io su Linkedin. Non sempre però è possibile utilizzarlo, vedi ad esempio sui “routerini” con switch integrato (tipo 877), in quel caso non funziona, purtroppo – almeno a me capita così! :-)

  • Alex

    Prova int gig o fa power inline never

  • AndyB

    Giusto, nella maggiorparte dei router e switch cisco di fascia media e alta, l’error disable interviene per default se i pacchetti di keepalive generati da una porta rientrano sulla stessa porta.

Close
Entra in contatto con altri professionisti ICT, seguici su Facebook e Twitter: