Nel 2013 presentavo un particolare caso critico che poteva causare un isolamento completo di un datacenter. 11 anni dopo la situazione è la medesima.

Proviamo a fare qualche riflessione

Riflessioni aperte

Complessità: la complessità aumenta, ci sono molti più strati software di una volta e sicuramente la complessità causa incomprensione, design errati o, meglio, con alcuni “blindspot” non previsti e particolarmente distruttivi. Ormai la parola “complessità” è diventata un mantra, ma, lasciatemelo dire, ce la siamo cercata.

Semplificazione: paradossalmente è l’opposto del mantra precedente, ed è stato il leitmotiv che ha portato l’introduzione di una serie di tecnologie per abilitare “cose” che in precedenza erano considerate errate. Per chi lo ricorda lo STP è nato così. Per semplificare processi, renderli più agili e veloci sono state introdotte una serie di strati software che hanno portato al punto precedente.

Dispositivi ibridi: grazie ai due mantra precedenti sono nati dei dispositivi che si comportano in parte come host, in parte come switch. Nelle slide, in particolare, mi riferisco a dispositivi embedded negli chassis blade. Sempre nelle slide raccontavo di un corner case su HP, ma quello scenario è tutt’ora valido anche per altri vendor.

Lo scenario

Vediamo quindi lo scenario oggetto della discussione.

Lo scenario prevede una rete datacenter che può essere implementata in modalità legacy o tramite fabric. A questa rete sono collegati chassis blade con i dispositivi ibridi sopracitati. Sulle lame sono generalmente in esecuzione sistemi di virtualizzazione, ma non è strettamente necessario. Se, per qualche motivo, una lama crea un loop L2, in assenza di protezioni il loop si propaga sulla fabric e su tutti i dispositivi e chassis connessi.

Nei 3 casi che ho vissuto dal 2013 ad oggi, generalmente la fabric è in grado di gestire il traffico, gli switch ibridi no. Se gli switch ibridi trasportano, come è probabile, FCoE, il danno è ovviamente maggiore.

Generalmente le best practice impongono di configurare meccanismi di protezione sulla fabric, e qui nasce il problema.

Come spiegato nelle slide, se una lama o una VM creano un loop reale o apparente, attivano il meccanismo di protezione della fabric che spegne la porta da cui arriva il loop. Tuttavia il meccanismo di failover del virtualizzatore o degli switch ibridi spostano la causa del loop su una diversa interfaccia che viene anch’essa spenta per proteggere la fabric. In pochi minuti o secondi l’intero chassis blade viene isolato e con esso l’intero workload.

Il problema è che, come network engineer, siamo portati a proteggere “la fabric”, senza renderci conto che la fabric in realtà si estende agli switch ibridi e agli switch virtuali del virtualizzatore. La complessità porta a parcellizzare l’infrastruttura relegandola a tema diversi: la fabric è competenza del team di rete, i blade e la virtualizzazione del team computing. Secondo questa logica il team di rete protegge il suo perimetro secondo il suo punto di vista, che non è completo.

La soluzione dovrebbe essere quella di inserire meccanismi di protezione da loop sul bordo della fabric, considerandola nel suo complesso, in modo da isolare la singola VM (o il singolo server) che causa il loop, e non, nel nostro caso, l’intero chassis blade.

note finali

Alcune note finali:

• Il meccanismo di loop prevention lo deve fare lo switch di accesso più vicino possibile alla potenziale causa del loop (che possono essere VM o anche server).
• Il meccanismo di loop prevention deve prevedere una sorta di probe. Non tutti i loop sono identificabili tramite BPDU guard.
• Lo scenario descritto può avvenire anche a causa di virtualizzatori installati su server rack e non blade.
• Ad oggi ho osservato solo errori umani / bug, ma se dovessi pianificare un DOS efficace, ci farei un pensiero.
• Non possiamo prevenire il 100% dei problemi, possiamo solo migliorare la nostra capacità nell’identificare e reagire velocemente ad essi.

Riferimenti

• Designing an Hybrid Data Center Infrastructure