Alta disponibilità nel campus: FHRP, StackWise Virtual ed ECMP

Perché l’alta disponibilità è una scelta di design, non un accessorio

Nel campus enterprise il layer di distribution è il punto in cui si concentrano i single point of failure: è qui che risiedono i default gateway degli host, i confini fra Layer 2 e Layer 3 e la convergenza fra dominio di broadcast e dominio di routing. Il progettista ENSLD deve garantire che il guasto di un uplink, di una supervisor o di un intero switch non produca blackhole né tempi di convergenza percepibili dall’utente. Le tre leve principali sono il First-Hop Redundancy Protocol (FHRP), la device virtualization (StackWise Virtual / VSS) e il routing ECMP su link routed.

FHRP a confronto: HSRP, VRRP, GLBP

Tutti risolvono lo stesso problema — dare agli host un gateway virtuale sempre raggiungibile — ma con trade-off diversi.

HSRP e VRRP sono active/standby: un solo gateway inoltra traffico, l’altro resta in attesa. Per bilanciare il carico su HSRP/VRRP serve creare più gruppi e distribuire le VLAN. GLBP è l’unico che bilancia nativamente il traffico degli host su più forwarder tramite un solo indirizzo virtuale, rispondendo alle ARP con MAC diversi (round-robin, weighted, host-dependent). Scegli VRRP quando serve interoperabilità multi-vendor; GLBP quando vuoi sfruttare entrambi gli uplink senza segmentare le VLAN a mano; HSRP resta il default storico negli ambienti all-Cisco. In tutti i casi configura il preempt e, soprattutto, l’interface tracking (o object tracking su IP SLA): senza tracking il gateway attivo mantiene la priorità anche con l’uplink verso il core caduto, creando un blackhole.

StackWise Virtual / VSS: eliminare STP e i blocking link

Il limite strutturale del design FHRP classico è che, sotto, resta Spanning Tree. Con due switch di distribution fisicamente distinti, STP mette in blocking metà degli uplink di accesso per prevenire i loop: metà banda è sprecata e la convergenza dipende dai timer STP/RSTP.

StackWise Virtual (SWV) sui Catalyst 9000 e VSS sulle piattaforme precedenti fondono due chassis in un unico switch logico con un solo control plane. Le conseguenze di design sono decisive:

• L’access switch vede un solo vicino logico e può aggregare i due uplink fisici in un MEC (Multichassis EtherChannel). Non ci sono più link in blocking: STP resta attivo solo come rete di sicurezza, ma nessuna porta viene bloccata.
• Il gateway diventa unico e sempre attivo sul dispositivo virtuale: l’FHRP non è più strettamente necessario nel distribution virtualizzato, perché non esistono due default gateway concorrenti da coordinare.
• La convergenza non dipende più da STP ma dal ripristino dell’EtherChannel (sub-secondo), con StackWise Virtual Link (SVL) per lo stato di sincronizzazione e Dual-Active Detection (DAD) per evitare lo split-brain in caso di caduta dell’SVL.

ECMP e link routed per la convergenza sub-secondo

Dove il distribution è collegato al core (o in un routed access design), la scelta migliore è portare il Layer 3 il più vicino possibile all’edge. Con link point-to-point routed e un IGP come OSPF o EIGRP, si ottiene ECMP (Equal-Cost Multi-Path): più percorsi a costo uguale installati contemporaneamente in RIB/FIB, con load balancing per-flow e failover che non attende STP ma la riconvergenza dell’IGP. Con tuning appropriato (interfacce point-to-point, hello aggressivi o BFD) si raggiungono convergenze sub-secondo. Il vantaggio ulteriore: nessun dominio di broadcast esteso, nessun STP fra distribution e core, dominio di guasto ridotto.

Trappole tipiche d’esame

• Gateway FHRP attivo ≠ STP root → in un design L2 classico il gateway HSRP/VRRP attivo deve coincidere con la STP root bridge della stessa VLAN, altrimenti il traffico attraversa l’inter-switch link in modo subottimale. La risposta “giusta” spesso è: StackWise Virtual/VSS elimina il problema alla radice unificando il control plane, così l’allineamento manuale non serve più.
• FHRP senza tracking → scenario con uplink verso il core caduto ma gateway ancora “active”: manca l’interface/object tracking con decremento di priorità. Non è un problema di FHRP ma di configurazione del tracking + preempt.
• Link in blocking nonostante due uplink → se STP blocca metà banda, la soluzione di design è MEC/EtherChannel su StackWise Virtual, non aumentare i gruppi HSRP.
• Serve load balancing nativo sui gateway → la risposta è GLBP, non “più gruppi HSRP”; ma se serve interoperabilità multi-vendor, GLBP è escluso e si va su VRRP.
• SVL down = split-brain → senza Dual-Active Detection i due chassis credono entrambi di essere attivi. La feature richiesta è DAD (fast-hello o ePAgP), non un secondo FHRP.