Molti elementi contribuiscono a rendere fruibili i servizi su una qualsiasi rete. La ridondanza nella topologia e la resilienza nella configurazione sono fondamentali. I protocolli di routing vengono utilizzati per gestire tale ridondanza e il failover per fare un backup dei path di traffico in caso di errori nell’active path. Affinché tutto questo funzioni senza interruzioni, è necessario che l’ambiente rimanga il più possibile stabile e non sia soggetto a fluttuazioni. IP Fabric può aiutarvi ad analizzare la stabilità del protocollo di routing e a individuare i problemi.
Il BGP peering
Come sappiamo, la stabilità dei peer BGP può causare problemi di prestazione sulle grandi reti. Eventi come i link failure possono attivare sequenze di aggiornamenti sui path della rete, portando a:
- forwarding loop temporanei nei prefissi interessati dalla convergenza;
- picchi di consumo della banda, dovuti all’aumento dell’attività di comunicazione tra i nodi di rete;
- maggiore utilizzo della CPU nei nodi di rete, dovuto alla necessità di elaborare grandi quantità di dati in costante evoluzione.
Ad esempio, si pensi che la routing table di Internet ha raggiunto una dimensione tale da non convergere mai completamente. Questo è un sintomo del churn (numero di aggiornamenti e ritiri), causato dai link event di collegamento interno e tra gli AS che ovviamente si verificano di continuo!
Di norma il BGP è utilizzato in azienda per connettere reti gestite da organizzazioni diverse, o parti separate di una stessa organizzazione. Ne consegue che, una volta stabilite, le connessioni devono rimanere tali. Le fluttuazioni in tale connettività possono avere conseguenze di ampia portata, vale quindi la pena tenere traccia della stabilità del peering.
Ma come possiamo misurarne la stabilità?
Si può affrontare questo problema concentrandosi su due elementi. Per ogni relazione di BGP peering nella rete cerchiamo di rispondere a queste due domande:
- in che stato si trova il peering? È completamente stabile? E se è così…
- da quanto tempo la relazione tra peer si trova in uno status stabile? Questo potrebbe essere un indicatore della regolarità del suo funzionamento.
Processo manuale
Per verificarlo manualmente un Network Analyst dovrebbe:
- accedere a ciascun router, switch di Layer 3 e firewall nella rete;
- utilizzare i giusti comandi CLI del vendor e stabilire se le sessioni del BGP sono configurate;
- controllare lo status di ogni peer BGP sul nodo;
- registrare i risultati su un foglio di calcolo;
- consegnare i dettagli a un ingegnere più esperto affinché li analizzi.
Oppure si possono annotare gli script e sviluppare gli strumenti idonei per automatizzare il processo, in modo da poter ripetere i controlli a intervalli regolari.
Fatelo fare ad IP Fabric
IP Fabric analizza la configurazione e lo stato operativo dei dispositivi nella rete e li registra nel proprio database in modalità vendor-agnostic. Successivamente, esegue oltre 120 standard validation checks e presenta i risultati sulla dashboard del prodotto. Ciò include l’identificazione dei peer BGP tra piattaforme e vendor, nonché il controllo delle relazioni per la durata della creazione del peering…
… e per lo stato attuale:
Sulla dashboard, cliccando sui peer con uno status attivo, si visualizza una tabella dei dettagli per tali peer, tutti a portata di mano.
In tale tabella, si clicca sulla posizione del sito per visualizzare la topologia con il peer in questione dalla documentazione “live”:
Successivamente ci si concentra sulla topologia del BGP, disabilitando tutti gli altri protocolli e abilitando il controllo BGP Compliance per la Intent Verification.
Si nota che la piattaforma ha evidenziato il problema L64R7. Selezionando il router in questione, IP Fabric presenta le informazioni sul peer che crea conflitto con L64R4. L’implicazione qui è che L64R4 non è stato configurato per fare da peer con L64R7.
Dalle frecce nel diagramma appare evidente che il peering è configurato in una direzione e non in quella opposta. Dalla tabella, pare non assegnato un indirizzo IP al peer. Ispezionando i router, L64R7 risulta a posto
ma il peering su L64R4 è disabilitato:
In questo modo, IP Fabric ci ha permesso di affrontare il problema e giungere alla soluzione, molto più rapidamente che con l’azione manuale di estrazione e analisi dei dati.
Referenze:
- “BGP in 2019 – BGP Churn” di Geoff Huston, APNIC Blog.
- “RFC4271 – A Border Gateway Protocol (BGP-4)” di Yakov Rekhter, Tony Li, Susan Hares, IETF.
- “Routing Protocol Visualisation” di Milan Zapletal, IP Fabric.
Se desiderate vedere con i vostri occhi come IP Fabric può aiutarvi a gestire la vostra rete più efficacemente, contattateci visitando il nostro sito www.ipfabric.io.
