Considerazioni generali

Tutti i prefissi di una VPC e tutte le sottoreti di una rete classica si collegheranno al gateway di transito, quindi è importante che non si sovrappongano. Quando si creano i VPC destinati a connettersi a un transit gateway, assicurarsi di creare i VPC con prefissi VPC non sovrapposti.

• IBM Cloud Transit Gateway supporta il provisioning dei gateway di transito nelle regioni elencate in IBM Cloud Transit Gateway locations.
• Crea il tuo transit gateway in un'ubicazione che abbia senso per il tuo carico di lavoro. Ad esempio, se stai connettendo due VPC nella regione us-south (Dallas) e un VPC nella regione eu-de (Francoforte), la creazione del tuo gateway nella regione us-south sarebbe la più efficiente per il tuo carico di lavoro.
• Non è possibile collegare una VPC di accesso classica direttamente a un gateway di transito. Per connettere le risorse classiche, utilizza la connessione all'infrastruttura classica IBM Cloud e quindi tutte le risorse nel tuo VPC di accesso classico vengono connesse automaticamente.
• Un transit gateway richiede almeno due connessioni prima che il traffico di rete possa fluire sul transit gateway. I gateway di transito che hanno meno di due connessioni per 45 giorni o più sono soggetti a recupero (sospesi, quindi eliminati dopo 30 giorni).
• Puoi connettere un VPC, un Direct Linko un'infrastruttura classica a più gateway locali e a un singolo gateway globale.
• I gateway di transito e le relative connessioni possono impiegare diversi minuti dopo il provisioning prima che siano disponibili.
• Essere descrittivi quando si denominano le connessioni Transit Gateway. Quando ci si connette alle risorse tra account, è necessario specificare un nome connessione. Quando ci si connette alle risorse nello stesso account del gateway di transito, il nome VPC o la parola 'classic' è la selezione predefinita e può essere modificata.
• IBM Cloud Transit Gateway è un'applicazione a più tenant, dove una singola istanza del software e la sua infrastruttura di supporto, serve più clienti. Di conseguenza, è importante monitorare l'utilizzo della larghezza di banda. Se si utilizza una larghezza di banda eccessiva, l'istanza del gateway di transito potrebbe essere sospesa. Se si sospetta che questo sia il caso, controllare lo stato di connessione dell'istanza di transit gateway per verificare se si trova in uno stato Suspended. In tal caso, contattare il supporto per ripristinarlo.
• Le seguenti ASN sono bloccate sulle connessioni Transit Gateway Generic Routing Encapsulation (GRE) e Direct Link. Evitare di utilizzare queste ASN sulle applicazioni in modo che non vengano incluse negli instradamenti pubblicizzati nel percorso AS. L'inclusione di queste ASN impedisce alle reti di funzionare correttamente.

0, 13884, 36351, 64512, 64513, 65100, 65200-65234, 65402-65433, 65500, 65516, 65519, 65521, 65531 e 4201065000-4201065999

Considerazioni sull'ECMP

• Quando si pianifica l'implementazione dell'ECMP (Equal-Cost Multi-Path), è importante tenere presente che la larghezza di banda non varia in modo lineare con il numero di collegamenti diretti. Ad esempio, se si collegano due collegamenti diretti da 10 GB a un gateway di transito compatibile con ECMP, non si ottiene una larghezza di banda di 20 GB; si ottiene una larghezza di banda superiore a 10 GB, ma inferiore a 20 GB. Questo perché l'ECMP funziona a livello di flusso o di sorgente; ciò significa che, se il traffico proviene da un unico endpoint, è probabile che privilegi un unico collegamento, anziché entrambi. Per ottenere un throughput più equilibrato, si raccomanda di convogliare il traffico da più fonti, in quanto ciò consente di distribuire il carico in modo più uniforme tra i collegamenti diretti disponibili.

• Limitazione: ECMP non funziona per i collegamenti diretti su un singolo router. È invece supportato da più router con collegamenti diretti, purché questi router pubblicizzino lo stesso prefisso.

• Limitazione nota: I nuovi gateway di transito supportano l'ECMP a 4 vie, ma i gateway esistenti non possono utilizzare questa funzione a meno che non si apra un caso di assistenza.

  Se non volete che la funzione ECMP sia abilitata sui vostri gateway di transito, potete aprire un caso di assistenza per essere aggiunti a una denylist, che disabiliterà questa funzione sui vostri gateway.

Considerazioni sui prezzi

Lo stimatore dei costi di IBM Cloud, situato nella pagina di provisioning di Transit Gateway, non è in grado di interpretare i tipi di connessione di rete. Per ottenere una stima dei costi affidabile, inserisci il numero stimato di gateway di transito e connessioni. Tieni presente che se crei un GRE ridondante, ogni tunnel è una connessione individuale che conta rispetto al tuo limite di connessione.

Considerazioni sulla connessione dell'infrastruttura classica

• Per utilizzare un gateway di transito per collegare i tuoi VPC alla tua infrastruttura classica IBM Cloud, devi abilitare il tuo account classico per VRF (virtual routing and forwarding) e collegarlo al tuo account IBM Cloud. Per informazioni sull'abilitazione del tuo account per VRF, vedi Abilitazione di VRF e degli endpoint del servizio.

• Quando connetti un VPC e l'infrastruttura classica ad un gateway di transito, tutti i prefissi nel VPC diventano visibili al VRF dell'infrastruttura classica, che utilizza gli indirizzi IP nello spazio 10.0.0.0/8. Per garantire la connettività con l'infrastruttura classica, non utilizzare nelle VPC prefissi che si sovrappongano ai blocchi 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15 e 10.254.0.0/16. Inoltre, non utilizzare gli indirizzi dalle tue sottoreti dell'infrastruttura classica. Per visualizzare un elenco delle sottoreti dell'infrastruttura classica, consulta la sezione " Visualizza tutte le sottoreti ".

• Le istanze del server virtuale classico possono avere sia un'interfaccia di rete privata (eth0) che pubblica (eth1). Attualmente, le tabelle di instradamento per queste interfacce puntano il gateway predefinito all'interfaccia pubblica (eth1). Potresti dover aggiungere voci di instradamento per instradare le sottoreti da altri VPC tramite l'interfaccia privata.

• Tutte le tue reti dell'infrastruttura classica IBM Cloud tra MZR sono accessibili tramite questa connessione, indipendentemente dall'ubicazione del transit gateway o dal tipo di instradamento specificato.

• Le risorse dell'infrastruttura classica ubicate in questi data center si collegano tramite un gateway di transito alle risorse VPC.

• Quando l'infrastruttura classica è collegata a un gateway di transito, essa include anche eventuali VPC Classic Access associate all'account, poiché le sottoreti di tali VPC sono associate al VRF dell'infrastruttura classica. Questo è l'unico modo per connettere un gateway di transito a un VPC di accesso classico: connettendo l'intera infrastruttura classica al gateway di transito (invece dei VPC di accesso classico specifici).

• Le connessioni classiche che risiedono nello stesso data center non sono in grado di comunicare tra loro se si trovano in una regione diversa rispetto al gateway di transito.

Considerazioni sul filtraggio dei prefissi

• I filtri di prefisso sono supportati per tutti i tipi di connessione di Transit Gateway, ad eccezione delle connessioni tunnel GRE legacy. Per le connessioni GRE, il filtraggio dei prefissi è supportato per entrambi i tipi di connessione GRE ridondante e GRE non vincolata.
• Per le connessioni non-GRE, il proprietario della rete può aggiungere filtri di prefisso. Per le connessioni GRE, solo il proprietario di Transit Gateway può aggiungere o modificare i filtri di prefisso, un aspetto importante per le connessioni cross-account.
• Per le connessioni tra account, solo il proprietario dell'account della rispettiva connessione può modificare i filtri di prefisso. Gli altri account possono visualizzare la connessione, ma non possono modificare i filtri.
• Non è possibile filtrare i prefissi in arrivo da un altro account.
• Per le connessioni GRE e gateway VPN ridondanti, i filtri di prefisso possono essere configurati solo sulla connessione di primo livello. Le singole gallerie sotto queste connessioni non supportano filtri di prefisso separati; qualsiasi filtro applicato al livello superiore verrà applicato a tutte le gallerie associate.
• I filtri di prefisso nell'elenco vengono elaborati in sequenza. È possibile modificare l'ordine in qualsiasi momento.
• Se si seleziona Richiedi connessione a una rete di un altro account come opzione di connessione, non è possibile impostare filtri di prefisso perché non si è il proprietario della rete per quella connessione. I filtri di prefisso devono essere configurati nell'account che possiede la rete. Per le connessioni GRE, solo il proprietario di Transit Gateway può impostare i filtri di prefisso durante la creazione della connessione.
• Le maschere di sottorete dei filtri di prefisso sono specifiche. Ad esempio, una regola definita come 10.10.20.0/24 non corrisponde alla sottorete 10.10.20.0/28 o a qualsiasi altro prefisso di sottorete.
• Rivedere i limiti di servizio del prefisso per i gateway di transito.

Considerazioni sulla connessione GRE (Generic Routing Encapsulation)

Esaminare le considerazioni riportate di seguito per la particolare connessione GRE.

Considerazione sulla connessione Direct Link

Puoi creare connessioni Direct Link a un gateway di transito per consentire alle reti in loco di connettersi ad altre reti in IBM Cloud. Dopo che il link diretto si connette al gateway di transito, la rete in loco riceve l'accesso a tutte le altre connessioni del gateway di transito. Allo stesso modo, tutte le altre reti connesse al gateway di transito hanno accesso alla rete in loco. Le connessioni Direct Link seguono lo stesso processo per le connessioni incrociate fisiche o virtuali dell'offerta Direct Link standard. Dopo che la connessione è stata eliminata da un transit gateway, il transit gateway funziona come se non fosse mai stato connesso a un collegamento diretto.

Le stesse considerazioni sulla subnet di rete per le connessioni gateway di transito si applicano anche alle connessioni Direct Link. Per garantire la connettività, nella rete collegata a Direct Link non utilizzare prefissi che si sovrappongono ad altre connessioni.

Considerazioni sulla connessione Power Virtual Server

Puoi connettere un'istanza Power Virtual Server a un transit gateway. Ciò ti consente di collegare direttamente il Power Virtual Server a un gateway di transito downstream. Una volta che l' Power Virtual Server e è stato collegato al gateway di transito, l'istanza del servizio Power Virtual Server avrà accesso a tutte le risorse e a tutti i servizi a valle del gateway di transito. Allo stesso modo, tutte le reti a valle collegate al gateway di transito hanno accesso all'istanza di Power Virtual Server.

Le connessioni Power Virtual Server possono utilizzare l'instradamento locale o globale. Tuttavia, solo le istanze Power Virtual Server nella stessa regione del gateway di transito possono utilizzare l'instradamento locale. Inoltre, un'istanza Power Virtual Server può essere connessa più gateway di transito con instradamento locale, ma solo un gateway di transito con instradamento globale. I servizi downstream rispetterà la preferenza di instradamento in base al tipo di transit gateway.

Le stesse considerazioni sulla subnet di rete per le connessioni gateway di transito si applicano anche alle connessioni Power Virtual Server. Per garantire la connettività, nella vostra istanza di Power Virtual Server non utilizzate prefissi che si sovrappongono ad altre connessioni. Si noti che Transit Gateway fornisce un filtro dei prefissi per limitare i prefissi esposti, nonché un rapporto sulla tabella di routing per vedere eventuali sovrapposizioni dopo la creazione della connessione.

Considerazioni sulla connessione al gateway VPN

È possibile creare connessioni gateway VPN a un gateway di transito per consentire alle reti on-premise o esterne di connettersi con altre reti in IBM Cloud. Il gateway VPN funge da spoke all'interno dell'architettura del gateway di transito, consentendo un peering efficiente tra più reti e riducendo la complessità del tunnel. Questo progetto utilizza il routing dinamico con eBGP su tunnel GRE ridondanti per fornire una connettività scalabile e resiliente.

• Ogni connessione al gateway VPN prevede automaticamente quattro tunnel GRE ridondanti tra il gateway VPN e il gateway di transito. IBM gestisce questi tunnel, con le sessioni eBGP che vi passano sopra per il routing dinamico. La connettività in sede utilizza eBGP su tunnel IPsec per una comunicazione sicura. Mentre è possibile creare, eliminare e rinominare le connessioni gateway VPN, non è possibile modificare o rimuovere i singoli tunnel GRE.

• I prezzi si basano sul costo di 4 tunnel GRE per connessione più i costi del traffico dati.

• Per impostazione predefinita, le connessioni dei gateway VPN sono limitate a 4 per gateway di transito e a 2 per zona.

• Le connessioni gateway VPN non supportano il filtraggio dei prefissi. L'utente è responsabile della gestione del filtraggio delle rotte sul proprio lato della sessione BGP.

• È possibile creare connessioni VPN dinamiche o statiche in qualsiasi momento. Le connessioni statiche funzionano con o senza l'aggiunta di un gateway di transito. Le connessioni dinamiche richiedono che il gateway VPN sia collegato a un gateway di transito prima che il traffico possa fluire.

• Dopo che un gateway VPN è stato collegato a un gateway di transito, l'ASN locale non può essere modificato.

• Per configurare una VPN come backup di una connessione Direct Link, è necessario assicurarsi che le rotte di Direct Link siano preferite. A tal fine, è possibile sfruttare meccanismi come l'AS Path prepending o il MED (Multi-Exit Discriminator) sul dispositivo on-premises.

• Quando si crea una connessione gateway VPN, è necessario definire un blocco CIDR per gli indirizzi IP del tunnel GRE. Si consiglia di utilizzare un intervallo di indirizzi privati RFC 1918, in quanto non richiede un percorso delegato-VPC aggiuntivo. Il blocco CIDR deve essere minimo /27 e non deve sovrapporsi ad altri CIDR di connessione configurati sul gateway di transito.

  Se si assegna un CIDR a un gateway VPN che non rientra negli intervalli IP privati standard (10.0.0.0/8, 172.16.0.0/12, o 192.168.0.0/16), è necessario aggiungere manualmente delle rotte nella tabella di routing VPC (nella stessa zona del gateway VPN) per consentire un flusso di traffico corretto. Hai due opzioni:

  • Aggiungere una singola rotta con la destinazione impostata sul CIDR completo assegnato alla VPN (ad esempio, 100.31.128.0/18) e l'azione impostata su Delegate-VPC.
  • Aggiungere quattro rotte separate, ciascuna rivolta all'IP del gateway locale di ciascun tunnel VPN (ad esempio, 100.31.128.1/32) con l'azione impostata su Delegate-VPC.

  La prima opzione è più semplice, mentre la seconda offre un controllo più granulare del routing, che potrebbe essere preferito in progetti di rete avanzati o per la risoluzione dei problemi.

Considerazioni su VPC

• IBM Cloud VPC consente l'utilizzo dello spazio di indirizzo RFC-1918 e IANA - registrato IPv4, privatamente all'interno del tuo VPC, con alcune eccezioni negli intervalli di scopo speciale IANA e seleziona gli intervalli assegnati ai servizi IBM Cloud. Quando utilizzi gli intervalli registrati IANA all'interno della tua azienda e all'interno dei VPC insieme a IBM Cloud Transit Gateway, le rotte personalizzate devono essere installate in ciascuna zona. Per ulteriori informazioni, vedi Considerazioni sull'instradamento per le assegnazioni IP registrate IANA.

• È possibile creare un singolo gateway di transito o più gateway di transito per interconnettere più di un VPC IBM Cloud. Puoi anche connettere la tua infrastruttura classica IBM Cloud a un gateway di transito per fornire una comunicazione senza interruzioni con le risorse dell'infrastruttura classica. Per ulteriori informazioni, fare riferimento a Interconnessione di VPC.

• Bare Metal in VPC non è supportato.

Considerazioni sull'instradamento

• Tutte le connessioni a un transit gateway sono connesse tra loro, quindi considera attentamente tutte le risorse che vuoi interconnettere prima di decidere se l'instradamento locale o globale è giusto per ogni gateway.

  Il traffico proveniente da entrambe le opzioni di routing non lascia la rete privata IBM Cloud ed è ottimizzato per le prestazioni.

• Se intendi utilizzare il tuo gateway per connettere i VPC nella stessa regione multizona (MZR), utilizza l'instradamento locale per fornire la connettività a tutte le risorse accessibili all'interno dello stesso MZR; ad esempio, us-south (Dallas).

  

• Se si prevede di utilizzare i gateway di transito per connettere i VPC localmente e tra MZR differenti, utilizzare i gateway locali per i VPC nello stesso MZR e un gateway globale per i VPC tra MZR. Puoi utilizzare anche l'esempio che segue uno scenario HA (Highly Available). Tutti i dati nei VPC A e B possono essere replicati nei VPC C e D. Se c'è un problema nella regione degli Stati Uniti Sud, i collegamenti si reindirizzano verso gli Stati Uniti Est.

  ![Routing globaleRouting](/images/2-aboutLocalAndGlobalRoutingExample.png "e " caption-side="bottom"} di "){: caption="di routing locale e globale

  Indipendentemente dal tipo di routing specificato, IBM Cloud Transit Gateway può connettersi alle reti infrastrutturali classiche situate in qualsiasi MZR. Per ottenere ciò, aggiungere semplicemente la connessione classica al gateway di transito.

• È possibile modificare il tipo di instradamento di un gateway dopo che è stato eseguito il provisioning. Tuttavia, per cambiare il tipo di instradamento da Globale a Locale, bisogna prima rimuovere tutte le connessioni globali (cioè le connessioni a risorse che non si trovano nella stessa posizione del gateway). Si noti che le connessioni all'infrastruttura classica IBM Cloud sono sempre considerate Locali.

• Quando si passa dal routing locale a quello globale, vengono addebitati i costi relativi a tutte le connessioni globali associate. Non vi è alcun impatto sul traffico di rete quando il tipo di instradamento viene modificato.

Considerazioni sui report di instradamento

• Il percorso AS visualizzato in un rapporto di rotta fornisce una prospettiva di una singola zona. Se l'origine o la destinazione si trovano in zone diverse, la lunghezza del percorso può variare. Ad esempio, si considerino due collegamenti diretti: uno in DAL10 e l'altro in DAL12, che pubblicizzano entrambi la stessa lunghezza di percorso AS verso un gateway di transito basato su DAL e connesso a un ambiente VPC o classico. Quando si chiama da un'istanza di server virtuale DAL10:

  • È preferibile il collegamento diretto DAL10.
  • Per le connessioni provenienti da DAL12, è preferibile il collegamento diretto DAL12.
  • Nel caso di DAL13, si otterrebbe un instradamento ECMP, supponendo che il gateway sia predisposto per questo, oppure si utilizzerebbe un singolo collegamento diretto. Tuttavia, durante un reset BGP, potrebbe passare all'altro collegamento diretto.

• Gli instradamenti sovrapposti sono un problema comune durante la configurazione di un gateway di transito. Se gli instradamenti da due o più connessioni si sovrappongono, il traffico potrebbe non essere instradato come previsto. Per ulteriori informazioni, consultare Addressing route conflicts.

• Dopo che una nuova connessione virtuale (VPC, infrastruttura classica o Direct Link) raggiunge lo stato Attivo, concedi 5 minuti perché le rotte vengano apprese dal tuo transit gateway. La generazione di un report di instradamento prima che tutti gli instradamenti vengano appresi risulta in un report di instradamento parziale.

• Se una connessione espone un instradamento di 0.0.0.0/0, tale instradamento viene ignorato quando si calcolano prefissi sovrapposti.

• È disponibile un solo report per gateway alla volta. Se si genera un nuovo report, il vecchio report viene eliminato.

• I report di instradamento meno recenti potrebbero non essere precisi dopo l'aggiunta o la rimozione di una connessione. Di conseguenza, se si aggiornano gli instradamenti all'interno di tali connessioni, si consiglia di creare un nuovo report di instradamento.

• Se una o più rotte sono negate dai filtri di prefisso, tali rotte non appaiono nel rapporto sulle rotte.

Limiti del servizio

Tenere presente i seguenti limiti di servizio quando si usa IBM Cloud Transit Gateway.

È possibile aprire un caso di assistenza su IBM se si desidera ampliare i limiti del servizio.