Una panoramica sul mondo della Sicurezza Informatica, del Networking, della Virtualizzazione e non solo. Blog particolarmente indicato per i reparti IT che comunque alterna articoli scritti per specialisti con articoli formulati con linguaggio semplice e comprensibile a tutti.

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

mercoledì 1 marzo 2017

Case Study: Quando il WISP ti fa saltare la Spanning Tree Topology

Lo Spanning Tree Protocol, con le sue varianti (RapidSTP), consente di raggiungere tipicamente due obiettivi:

  • La ridondanza dei collegamenti tra più switch (ma non solo)
  • La risoluzione di fenomeni di Broadcast Storm (comunemente chiamati loop)


Come funziona


Il funzionamento del protocollo RSTP è bene approfondirlo un attimo, seppur brevemente e semplificando alcuni concetti, così da entrare nel vivo del Case Study.

Immaginiamo di avere questa banale topologia di rete, ovvero uno switch di centro stella e due switch (A e B) secondari chiusi ad anello tra di loro.



E' subito evidente che, per prima cosa, in assenza del protocollo RSTP abilitato, la rete collasserebbe in un loop tale da renderla del tutto inutilizzabile. Il protocollo RSTP per sua natura impone il forward dei frame sulla porta solo dopo essersi accertato che non si tratta di un percorso ridondante. Quindi nella nostra architettura, della bretella A-B lo switch B blocca la porta mettendola in uno stato di non inoltro del traffico tradizionale (ma di inoltro delle BPDU, ovvero del traffico generato dall'RSTP degli switch stessi e necessario a trasferirsi informazioni circa la topologia di rete).

Altrettanto evidente è che l'interruzione di un qualsiasi percorso tra A e Root oppure tra B e Root, causerà (dopo un tempo minimo di convergenza) un cambio di topologia che vedrà protagonista la riattivazione completa della porta originariamente bloccata da B.


Ora immaginiamo uno scenario più articolato, ma che sostanzialmente è assimilabile a quello precedente:




Poniamo quindi il caso che le tratte nere siano in Fibra Ottica e le tratte rosse siano in Rame. Per sua natura, la Fibra Ottica ha una priorità superiore a quella in Rame, pertanto ogni switch intento a capire quale porta ridondante spegnere, tenderà a privilegiare la Fibra Ottica.

Tutto questo identifica, in maniera sommaria, una topologia di rete. Ad onor del vero ci sarebbe da parlare per ore su come gli switch eleggono una topologia e su come stabiliscono (in assenza di indicazioni specifiche) chi è il Root Switch e la gerarchia che ne deriva.

A noi, per non annoiarci in dettagli tecnici degni del miglior studente CCNA, interessa solo un principio: lo Spanning Tree abilitato per prevenire i loop, può essere lasciato di default. Ma lo Spanning Tree con percorsi ridondanti va configurato correttamente per non ritrovarsi con percorsi erroneamente lunghi oppure con lo switch dello scantinato come Root Switch a capo di tutta la topologia.

Questa configurazione si fa forzando l'autorevolezza di un apparato che deve imporsi su tutti gli altri.



Case Study


Poniamo il caso di avere un WISP che ci eroga connettività tramite un bridge radio (Layer 2, occhio, non Layer 3 come un router di un operatore tradizionale). Il bridge, ovviamente, fa passare le BPDU che lavorano a Livello 2 della pila ISO/OSI. Se siete particolarmente sfortunati ed il WISP ha impostato il Priority a 0 su uno dei suoi switch nella sua infrastruttura, esso si imporrà su tutto il nostro sistema in LAN forzando un cambio di topologia di rete che farà saltare ogni percorso minuziosamente studiato su carta.

L'aspetto più insidioso è che questo tipo di fenomeno spesso è apparentemente invisibile e si traduce in rallentamenti e micro-disconnessioni che, ad una prima e superficiale osservazione, possono essere sottovalutati o attribuiti "al solito server lento".



Soluzione


I log sono nostri amici: una volta identificato il problema disabilitare lo Spanning Tree sulle porte direttamente connesse ai gateway. E siccome non costa nulla, diciamo che è buona norma farlo sempre. 

Del resto, è del tutto sconsigliato creare una rete con percorsi ridondati senza controllare nei giorni successivi lo stato delle porte RSTP per capire se realmente il traffico sta facendo il percorso da noi voluto.



Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.