Considerazioni sulla pianificazione

Dynamic Route Server per VPC è una funzionalità in versione beta disponibile a scopo di valutazione e test per alcuni clienti selezionati. L'accesso è limitato agli account presenti nell'elenco delle autorizzazioni.

Prima di creare un server di instradamento dinamico, è opportuno esaminare le considerazioni relative alla pianificazione, i requisiti di configurazione e le altre linee guida applicabili.

Considerazioni generali

Prima di creare un server di instradamento dinamico, prendere in considerazione le seguenti indicazioni generali:

  • Un server di instradamento dinamico è un servizio di instradamento e non inoltra il traffico dati. Appena, apprende le rotte dai peer tramite BGP e aggiunge le rotte alle tabelle di routing della VPC in base alle politiche definite.
  • Un'istanza di server di instradamento dinamico viene creata all'interno di una singola VPC e gestisce le rotte solo per quella VPC.
  • Quando si crea un'istanza di server di instradamento dinamico, è necessario specificare almeno un membro e non più di tre (uno per zona). Per garantire un'elevata disponibilità, utilizzare un nodo per ogni zona di disponibilità.
  • Tutti i membri di un'istanza di server di instradamento dinamico devono utilizzare lo stesso ASN locale.
  • Una volta creata un'istanza del server di routing dinamico, questa deve raggiungere uno stato stabile del ciclo di vita prima di poter configurare peer, gruppi di peer o criteri di routing.

Considerazioni relative alle interfacce di rete virtuali

Quando si seleziona un'interfaccia di rete virtuale (VNI) per un'istanza di server di instradamento dinamico, tenere presenti le seguenti considerazioni:

  • Ogni nodo del server di instradamento dinamico richiede un VNI che è necessario creare in anticipo.
  • Tutti i VNI devono appartenere allo stesso VPC dell'istanza del server di instradamento dinamico.
  • Ogni VNI deve disporre di un indirizzo IP privato riservato e di uno o più gruppi di sicurezza che consentano il traffico BGP.
  • Un VNI esistente che si utilizza per un membro deve soddisfare i seguenti requisiti:
    • Si trova nello stesso account del server di routing dinamico e non è associato ad alcun altro target.
    • Lo spoofing dell'IP non è consentito, il NAT a livello di infrastruttura è abilitato e il filtraggio dello stato del protocollo non è disabilitato.
    • Non dispone di alcun IP flottante, né di IP secondari riservati, né di alcun altro IP oltre al proprio IP primario.
  • Per garantire un'elevata disponibilità, selezionare VNI situate in zone di disponibilità diverse.
  • Un VNI associato a un'istanza di server di instradamento dinamico non può essere eliminato finché non viene disassociato dal server di instradamento dinamico.
  • Le sottoreti associate ai VNI devono disporre di una capacità IP sufficiente per gli indirizzi IP riservati e per le operazioni in corso.

Considerazioni su BGP, BFD e ASN

Prima di creare un'istanza di server di instradamento dinamico, prendere in considerazione i seguenti aspetti relativi al BGP:

  • Un server di instradamento dinamico utilizza il protocollo eBGP per scambiare percorsi con i peer, quali router, firewall o gateway di transito.
  • Quando si crea un'istanza di server di instradamento dinamico, è necessario specificare un ASN locale.
  • Ogni peer deve essere configurato con un ASN di peer diverso dall'ASN locale.
  • I valori ASN 0, 13884, 36351, 64512, 64513, 65100, 65200-65234, 65402-65433, 65500, 65516, 65519, 65521, 65531 e 4201065000-4201065999 sono riservati e non possono essere utilizzati come ASN locali o di pari.
  • Se è presente un conflitto di ASN, le sessioni BGP non vengono stabilite finché la configurazione dell'ASN non viene corretta.
  • È possibile abilitare il Bidirectional Forwarding Detection (BFD) sui gruppi di peer per accelerare il rilevamento dei guasti e la rimozione delle rotte.
  • Gli appliance Dynamic Route Server stabiliscono sessioni BGP utilizzando il multihop. Per utilizzare il Bidirectional Forwarding Detection (BFD) con le sessioni BGP, configurare il BGP multihop sia sull'appliance del server di instradamento dinamico che sul dispositivo peer. Assicurarsi che la configurazione BGP del dispositivo peer supporti il multihop per abilitare il rilevamento dei guasti BFD.

Transit Gateway considerazioni sull'integrazione

Quando si integra un server di instradamento dinamico con IBM Cloud® Transit Gateway, tenere presenti le seguenti considerazioni:

  • È possibile creare una connessione al gateway di transito verso un server di instradamento dinamico sia al momento della creazione del gateway di transito, sia aggiungendo una connessione di rete a un gateway di transito esistente.
  • Un'istanza di server di instradamento dinamico può essere collegata a un solo gateway di transito.
  • Una connessione al gateway di transito utilizza tunnel GRE (Generic Routing Encapsulation) ridondanti con protocollo eBGP tra un gateway di transito e i membri del server di instradamento dinamico.
  • Se si specifica un CIDR per gli indirizzi IP del tunnel GRE, questo deve essere di almeno /27 e non deve sovrapporsi a nessuna sottorete VPC né ai CIDR dei tunnel dei gateway di transito esistenti.
  • Se non viene specificato alcun CIDR, viene utilizzato un intervallo CIDR predefinito.
  • Quando un server di instradamento dinamico è connesso a un gateway di transito, le rotte apprese dal gateway di transito possono essere diffuse ad altri peer solo se consentito dalle politiche del server di instradamento dinamico.

Per stabilire la connettività tra Transit Gateway e gli appliance del server di instradamento dinamico, configurare le ACL di rete (NACL) in modo da consentire il traffico GRE (protocollo IP 47). Inoltre, configurare le regole del gruppo di sicurezza (SG) per consentire il traffico BGP (porta TCP 179) e il traffico GRE (protocollo IP 47) tra Transit Gateway e gli appliance del server di instradamento dinamico.

Considerazioni relative alla tabella di instradamento e alle politiche

Prima di configurare le politiche relative ai server di instradamento dinamico, esaminare le seguenti considerazioni relative all'instradamento:

  • È possibile utilizzare le politiche tra peer per riflettere le rotte apprese tra i peer, pubblicizzare i prefissi degli indirizzi VPC ai peer, aggiungere le rotte apprese alle tabelle di routing VPC e pubblicizzare rotte statiche personalizzate.
  • Un server di instradamento dinamico aggiorna le tabelle di instradamento personalizzate della VPC in base alle politiche di instradamento definite dall'utente.
  • Le rotte vengono aggiunte solo alle tabelle di routing a cui si fa esplicito riferimento nelle politiche delle tabelle di routing della VPC.
  • Se si superano i limiti della tabella di instradamento, l'aggiunta di una rotta potrebbe non andare a buon fine. Per ulteriori informazioni, consultare le quote relative alle tabelle di instradamento e alle rotte. In questo caso, potrebbe essere necessario richiedere un aumento della quota.
  • Quando si configura una politica della tabella di routing VPC, configurare i gruppi di peer per un server di routing dinamico in modo che i peer appartenenti a gruppi diversi non pubblicizzino la stessa destinazione. Pubblicizzare la stessa destinazione a diversi gruppi di pari può causare incongruenze nei percorsi appresi.

Considerazioni relative all'alta disponibilità e alla resilienza

Esaminare le seguenti considerazioni relative alla disponibilità:

  • Per garantire la tolleranza ai guasti a livello di zona, implementare un nodo del server di instradamento dinamico per ogni zona di disponibilità.
  • Ogni membro stabilisce sessioni BGP indipendenti con i propri peer.
  • Se un nodo non è più operativo, il server di instradamento dinamico rimuove automaticamente le rotte interessate e le reinserisce passando per i nodi operativi.
  • Il monitoraggio dello stato si basa sullo stato della sessione BGP e sullo stato del BFD (se abilitato).

Considerazioni sulla sicurezza

Esaminare le seguenti considerazioni relative alla sicurezza:

  • I dispositivi server di instradamento dinamico sono gestiti da IBM Cloud e funzionano in VPC isolate gestite dal servizio.
  • La comunicazione tra i componenti del server di instradamento dinamico e i servizi IBM Cloud avviene tramite una rete privata e endpoint privati virtuali.
  • I gruppi di sicurezza associati ai VNI devono consentire il traffico BGP ( TCP, porta 179) e qualsiasi altro traffico specifico per i peer necessario per il controllo dell'instradamento.
  • Tutte le modifiche dinamiche alla configurazione del server di routing e tutti gli eventi relativi al ciclo di vita vengono registrati tramite IBM Cloud® Activity Tracker. Per ulteriori informazioni, consultare le sezioni " Stato e descrizioni del server di instradamento dinamico ", " Eventi del server di instradamento dinamico " e " Registrazione degli eventi del server di instradamento dinamico ".

Considerazioni operative

Esaminare le seguenti considerazioni operative:

  • Non è possibile eliminare un'istanza di server di instradamento dinamico se esistono ancora gruppi di peer o criteri che dipendono da tale istanza.
  • Per eliminare un'istanza di server di instradamento dinamico, è necessario innanzitutto rimuovere tutte le politiche, eliminare tutti i gruppi di peer e scollegare il server di instradamento dinamico da eventuali gateway di transito.
  • Le modifiche alla configurazione, come l'aggiunta di peer, gruppi di peer o criteri, non interrompono i flussi di traffico esistenti.
  • Le modifiche al percorso vengono propagate immediatamente alle tabelle di routing della VPC, in base alla policy e allo stato di integrità.