Configurazione del Direct Link on Classic
Dopo aver stabilito la tua connettività IBM Cloud® Direct Link on Classic, puoi seguire i passaggi forniti in questo documento per configurare la tua sottorete per interagire con IBM Cloud.
In generale, per far funzionare la tua connessione Direct Link on Classic, devi eseguire alcune operazioni di configurazione della rete di base e quindi configurare BGP (Border Gateway Protocol). Durante il processo di configurazione, un tecnico IBM collabora con il cliente per abilitare la rete all'uso della funzionalità Virtual Routing Function (VRF), che è necessaria.
Configurazione della rete di base
-
Definire la rete remota che utilizza lo spazio di indirizzi privati standard RFC1918.
- Per i nuovi ambienti, lo spazio
10.0.0.0/8
. - Per gli ambienti esistenti che utilizzano il '
10.0.0.0/8
, si consiglia di ottenere una valutazione più dettagliata per garantire che non vi siano conflitti con la rete di servizi IBM Cloud o con le reti già assegnate all'account.
- Per i nuovi ambienti, lo spazio
-
Il nostro staff di IBM Cloud assegna un "
/31
o un "/30
per ogni connessione e configura un indirizzo IP di interfaccia sull'infrastruttura del router cross-connect (XCR) IBM Cloud. -
Configura l'interfaccia sul tuo CER (customer edge router) utilizzando l'indirizzo IP fornito: utilizza l'IP XCR IBM Cloud come hop successivo per qualsiasi traffico destinato a IBM Cloud.
-
Per il traffico di ritorno, IBM Cloud utilizza l'IP CER assegnato come next-hop per qualsiasi traffico destinato alla rete remota, come pubblicizzato tramite BGP.
Configurazione di BGP
Per scambiare le informazioni della rotta con il tuo ambiente, IBM Cloud richiede la configurazione di BGP. Le opzioni sono le seguenti:
-
ASN: IBM Cloud assegna un ASN privato per ogni utilizzo del cliente. In alternativa, è possibile utilizzare il proprio ASN pubblico. La tua preferenza viene richiesta al momento in cui inserisci l'ordine. L'ASN privato assegnato ti viene fornito durante il processo di implementazione.
-
VRF: Utilizzando il VRF, IBM Cloud pubblicizza le sottoreti private specifiche assegnate all'account cliente. È necessario pubblicizzare le reti remote che si desidera siano raggiungibili dalla rete privata IBM Cloud. È responsabilità del cliente gestire gli annunci da e verso la rete IBM Cloud. (Ulteriori dettagli su VRF sono inclusi nella prossima sezione.)
Le seguenti reti sono filtrate e non possono essere accettate:
10.0.0.0/14
, '10.198.0.0/15
, '10.200.0.0/14
, '169.254.0.0/16
, '224.0.0.0/4
. -
ECMP: per i clienti che scelgono di creare la ridondanza nell'ubicazione supportata, IBM Cloud supporta l'implementazione di ECMP (equal-cost multipath) per fornire il bilanciamento del carico e la ridondanza tra i due link. Questa configurazione ECMP deve essere richiesta al momento dell'ordine.
Specifiche per IBM Cloud Direct Link
Le specifiche BGP sono le seguenti:
Come indicato nella sezione precedente, BGP è obbligatorio per la gestione del tuo instradamento tramite Direct Link. Un account che ordina il Direct Link viene migrato in un ambiente VRF.
Avvertimenti per le VLAN e VRF:
- Lo spanning VLAN tra account non è consentito nell'ambiente VRF.
- Il servizio IPSEC VPN è limitato.
VRF non impedisce l'accesso SSL VPN, ma il comportamento cambia. Senza VRF, una connessione VPN è sufficiente per visualizzare tutti i server sul tuo account. Con il VRF, è possibile accedere alle risorse solo nel mercato associato alla propria VPN. Quindi, se ci si connette alla VPN DAL, è possibile connettersi solo ai server DAL.
L'ASN di IBM Cloud è 13884, per i servizi pubblico e privato.
- L'ASN predefinito per un cliente quando ordina è 64999, ma il valore predefinito può essere modificato dalla richiesta del cliente.
- Opzionalmente, può essere supportato un ASN privato a 4 byte "
4201000000
- "4294967294
. - ASN esclusi: '
0
, '13884
, '36351
, '64512
, '64513
, '65100
, '65201-65234
,65402-65433
, '65500
e ASN a 4 byte: '4201065000-4201065999
- Se si utilizza Direct Link Connect con un servizio layer-3, come una VPN IP, IBM Cloud stabilisce BGP con l'ASN del fornitore di Direct Link Connect.
Consigli, valori predefiniti e limiti:
- Il tunneling (ossia, GRE) è supportato e consigliato se la sovrapposizione IP diventa un problema.
- I timer BGP predefiniti sono '
Keepalive:30
, 'Holdtime:90
. - L'autenticazione non è abilitata per impostazione predefinita.
- BGP BFD non è abilitato per impostazione predefinita.
- Il limite massimo di prefisso ricevuto (dal cliente o provider) è 200 per VRF.
Limitazioni rigorose sulle assegnazioni IP
-
Se si utilizza la rete 10.x.x.x, non è comunque possibile creare sovrapposizioni con gli host all'interno di IBM Cloud né con la rete dei servizi IBM Cloud, che occupa '
10.0.0.0/14
, '10.198.0.0/15
e '10.200.0.0/14
. -
I seguenti intervalli non sono ammessi nel sistema federale e vengono rifiutati dai server IBM: '
169.254.0.0/16
, '224.0.0.0/4
.
Ridondanza e diversità
IBM Cloud Direct Link fornisce la diversità e i clienti sono responsabili per l'implementazione della ridondanza tramite i propri schemi BGP.
Se si seleziona ECMP per la ridondanza, entrambe le sessioni BGP devono esistere sullo stesso XCR; di conseguenza, si rinuncia alla diversità dei router e si è esposti al rischio di guasti. Ottieni la ridondanza di livello 3 ma perdi la diversità del router.
Comprendere le decisioni di inoltro BGP
IBM Cloud BGP Routing and Forward varia a seconda dell'implementazione del fornitore sul lato on-premises. Questo è fondamentale per capire come configurare le apparecchiature in sede per lavorare con Direct Link. La mancata comprensione e pianificazione può portare a comportamenti indesiderati, come percorsi di instradamento asimmetrici o scelte di instradamento non correttamente preferite. La tabella seguente è ordinata dal più importante al meno importante. Questo vale per i percorsi singoli. L'utilizzo di più percorsi modifica questo comportamento. Seguire la guida alla configurazione del router per le deviazioni da queste regole generali.
Considerazioni su BGP | Significato | Valore preferenziale |
---|---|---|
Luppolo successivo Raggiungibile | BGP non selezionerà un percorso con cui non può comunicare. | N/D |
Peso (solo Cisco) | Metrica specifica di Cisco per la preferenza di un percorso. | Valore più alto Preferito |
Locale_Pref | Metrica indipendente dal fornitore per preferire un percorso. | Valore più alto Preferito |
Percorsi iniettati localmente | Se il router origina le rotte, preferirlo a iBGP/eBGP. | N/D |
Lunghezza AS_Path | Numero di AS attraverso cui deve passare un percorso. | Valore inferiore Preferito |
Origine | Quale protocollo ha originato il percorso. | BGP interno preferito a BGP esterno |
MEDIO | Multi Exit Discriminator, che può preferire un percorso di uscita tra AS. | Si preferisce un valore più basso |
Tipo di vicino | Qual è la relazione protocollare tra due AS? | Preferire BGP interno a BGP esterno |
Metrica IGP | Qual era la metrica IGP del percorso? | Si preferisce un valore più basso |
Età del percorso | Quanti anni hanno i percorsi? | Preferire il percorso più vecchio |
Ulteriori informazioni sull'utilizzo di VRF
Tutti gli account che utilizzano una soluzione IBM Cloud Direct Link devono migrare a un VRF. Per ulteriori informazioni, vedi FAQ sulla migrazione dell'account VRF.
Utilizzando la VRF, i clienti annunciano le rotte disponibili alle proprie reti remote auto-definite. Questa configurazione non consente di utilizzare indirizzi IP autodefiniti sulla rete IBM Cloud.
La migrazione a un VRF richiede una breve finestra di interruzione (fino a 30 minuti per i grandi account con più VLAN/sedi), durante la quale le VLAN della rete di backend perdono la connettività reciproca mentre vengono trasferite al VRF.
Il VRF elimina l'opzione "VLAN Spanning" per l'account, comprese le funzionalità di VLAN spanning da account ad account, perché tutte le VLAN sono in grado di comunicare, a meno che non venga introdotto un dispositivo gateway per gestire il traffico. Il VRF limita inoltre la possibilità di utilizzare i servizi VPN IBM Cloud VPN perché non è compatibile con i servizi IBM Cloud SSL e IPsec.
Un'alternativa è di utilizzare la stessa offerta IBM Cloud Direct Link per gestire i tuoi server o di eseguire la tua propria soluzione VPN (come Vyatta) che può essere configurata con diversi tipi di VPN. Dopo aver eseguito la migrazione a una VRF, la VPN SSL normalmente funziona quando viene effettuata una connessione VPN alla stessa ubicazione del datacenter in cui la VM di calcolo è in esecuzione, ma non concede l'accesso globalmente.
Utilizzo di BYOIP e NAT con Direct Link
IBM Cloud Direct Link non offre BYOIP nella rete privata. Pertanto, il traffico con un indirizzo IP di destinazione non assegnato da IBM Cloud viene eliminato. Tuttavia, i clienti possono incapsulare il traffico tra la rete remota e la propria rete IBM Cloud che utilizza GRE, IPsec o VLAN.
Più comunemente, l'ambiente BYOIP viene implementato nello scopo di un gateway di rete (Vyatta) o una distribuzione VMWare NSX. Questa configurazione consente ai clienti di utilizzare ogni spazio IP opportuno nel lato IBM Cloud e di ritornare tramite il tunnel nella rete remota. Questa configurazione deve essere gestita e supportata dal cliente, indipendentemente da IBM Cloud. Inoltre, questa configurazione può interrompere la connettività alla rete dei servizi IBM Cloud se il cliente assegna un blocco 10.x.x.x che IBM Cloud ha in uso per i servizi.
Questa soluzione richiede inoltre che a ogni host che necessita di connettività alla rete di servizi IBM Cloud e alla rete remota vengano assegnati due indirizzi IP: uno dal blocco IBM '10.x.x.x
e uno dal blocco della rete remota.
Le rotte statiche devono essere impostate sull'host per garantire l'instradamento del traffico. Non puoi assegnare lo spazio IP direttamente sugli host (BYOIP) IBM Cloud e farlo instradare sulla rete IBM Cloud intrinsecamente. L'unico modo
per implementare questa funzionalità è come illustrato precedentemente, ma non è supportata da IBM Cloud.
In alternativa, i clienti spesso assegnano un blocco di rete remoto da utilizzare in una tabella NAT configurata sul router edge remoto. Questa configurazione consente ai clienti di limitare le modifiche necessarie a entrambe le reti, pur continuando a tradurre il traffico in uno spazio di indirizzi di rete compatibile con entrambe le reti.