Domande frequenti su AWS (FAQ)

Fai clic su una qualsiasi delle FAQ nella navigazione a destra per suggerimenti e risoluzioni.

Come posso configurare una VPN come backup per la mia connessione Direct Connect?

Voglio configurare una connessione VPN di backup per il failover con la mia connessione AWS Direct Connect. Quali sono le vostre raccomandazioni e le migliori pratiche?

Risoluzione

Per configurare la VPN hardware come un backup per la tua connessione Direct Connect:

Assicurati di utilizzare lo stesso gateway privato virtuale sia per Direct Connect che per la connessione VPN al VPC.
Se stai configurando una VPN del Border Gateway Protocol (BGP), pubblicizza lo stesso prefisso per Direct Connect e la VPN.
Se stai configurando una VPN statica, aggiungi gli stessi prefissi statici alla connessione VPN che stai annunciando con l’interfaccia virtuale Direct Connect.
Se stai annunciando gli stessi percorsi verso il VPC AWS, il percorso Direct Connect sarà sempre preferito, indipendentemente dal prepending del percorso AS.

Importante

Assicurati che Direct Connect sia la rotta preferita dal tuo lato, e non attraverso la VPN quando l’interfaccia virtuale Direct Connect è attiva, per evitare il routing asimmetrico; questo potrebbe causare la caduta del traffico. Noi preferiamo sempre una connessione Direct Connect rispetto alle rotte VPN. Per informazioni sulla priorità del percorso e sulle opzioni di routing, consulta l’argomento AWS Priorità del percorso.

Nota

Se desideri una soluzione a breve termine o a costo inferiore, prendi in considerazione la configurazione di una VPN hardware come opzione di failover per una connessione Direct Connect. Le connessioni VPN non sono progettate per fornire lo stesso livello di larghezza di banda disponibile per la maggior parte delle connessioni Direct Connect. Assicurati che il tuo caso d’uso o la tua applicazione possano tollerare una larghezza di banda inferiore se stai configurando una VPN come backup per una connessione Direct Connect.

Come posso abilitare BFD per l’utilizzo con Direct Connect?

Bidirectional Forwarding Detection (BFD) è un protocollo di rilevamento dei guasti di rete che rileva eventuali guasti di percorso tra vicini BGP direttamente connessi. Fornisce tempi rapidi di rilevamento dei guasti, che facilita un tempo di ri-convergenza più veloce per i protocolli di instradamento BGP dinamici. È indipendente dai media, dal protocollo di instradamento e dai dati.

Consigliamo di abilitare BFD quando si configurano più connessioni AWS Direct Connect o quando si configura una singola connessione AWS Direct Connect e una connessione VPN come backup per garantire un rilevamento e un failover rapidi. BFD rileva guasti di collegamento o percorso e aggiorna il routing dinamico mentre Direct Connect termina rapidamente il peering BGP in modo che possano entrare in funzione le rotte di backup. Questo garantisce che la relazione di neighbor Bidirectional Forwarding Detection (BGP) sia rapidamente interrotta invece di aspettare che falliscano 3 keep-alive con un tempo di attesa di 90 secondi.

Risoluzione

L’intervallo BFD specifica quanto spesso inviamo i pacchetti BFD, il min_rx è quanto spesso un router si aspetta di ricevere i pacchetti, e il moltiplicatore è quanti possiamo perdere prima che la relazione di neighbor BGP sia considerata inattiva.

BFD asincrono è abilitato automaticamente per ogni interfaccia virtuale Direct Connect dal lato AWS, ma non prende effetto fino a quando non è configurato sul tuo router. Il default di Direct Connect imposta l’intervallo minimo di rilevamento della vita BFD a 300 millisecondi e il moltiplicatore di rilevamento della vita BFD a 3.

Prima di utilizzare la modalità echo BFD con il tuo dispositivo di rete, devi disabilitare l’invio dei messaggi di reindirizzamento del Protocollo di Controllo dei Messaggi Internet (ICMP) con il comando no ip redirect per evitare un’elevata utilizzazione della CPU.

Come imposto una connessione Direct Connect attiva/passiva?

Quando si utilizza AWS Direct Connect per trasportare i carichi di lavoro di produzione da e verso AWS, si consiglia di utilizzare circuiti virtuali Direct Connect duali, sia da una singola porta, un paio di connessioni fisiche di porta (sia discrete che LAG/LACP) in un singolo DC, o distribuite su più località DC.

Puoi configurare quanto segue:

Due router per terminare le connessioni DX primarie e secondarie per evitare un singolo punto di fallimento del dispositivo.
Un’interfaccia virtuale privata su ciascuno dei router DX che termina verso lo stesso VPC. Protocolli di routing ad alta affidabilità (come HSRP, VRRF, GLBP, ecc.) su due router per consentire ai server locali di utilizzare più router che agiscono come un singolo router virtuale, mantenendo la connettività anche se il router primario fallisce, perché il router secondario prenderà il sopravvento e diventerà attivo, o eseguirà un protocollo di routing interno come iBGP che imparerà le rotte da Direct Connect EBGP e distribuirà i prefissi ai gateway iBGP interni.
Attivo/Passivo (failover). Una connessione gestisce il traffico, e l’altra è in standby. Se la connessione attiva diventa indisponibile, tutto il traffico viene instradato attraverso la connessione passiva. Avrai bisogno di AS path prepend le rotte su uno dei tuoi link affinché sia il link passivo. Per ulteriori informazioni, vedere Configura connessioni ridondanti con AWS Direct Connect.

L’attributo di preferenza locale identifica un punto di uscita preferito dal sistema autonomo locale (AS). Se ci sono più punti di uscita dall’AS, l’attributo di preferenza locale seleziona il punto di uscita per una rotta specifica.

Influenzare il traffico in uscita di AWS utilizzando AS Path prepending

L’algoritmo del miglior percorso BGP decide come viene selezionato il miglior percorso per un sistema autonomo. Un valore comune per determinare il miglior percorso è la lunghezza del percorso AS. Quando esistono due o più rotte per raggiungere un prefisso, il default in BGP è preferire la rotta con il percorso AS più corto.

Il router secondario pubblicizzerà un percorso AS più lungo, quindi il traffico dal VPC alla tua rete sarà sempre attraverso il router primario.

La mia interfaccia virtuale pubblica rimane nello stato “verifica”. Cosa posso fare?

Quando crei un’interfaccia virtuale pubblica e specifici gli indirizzi IP peer pubblici, richiede l’approvazione del team AWS Direct Connect (le VIF private/VXC non richiedono questa autorizzazione e sono disponibili entro pochi minuti). Prima di approvare i prefissi IP pubblici o gli ASN pubblici, il team AWS Direct Connect deve verificare la proprietà dei prefissi IP pubblici e dell’ASN BGP. Il team AWS Direct Connect verifica la proprietà confermando che il registro regionale appartiene al nome dell’organizzazione elencato nel tuo account AWS.

Risoluzione

Se lo stato dell’interfaccia virtuale pubblica è nello stato di verifica per più di 72 ore, controlla l’indirizzo email registrato sul tuo account AWS. Potresti aver ricevuto un’email dal team AWS Direct Connect se il proprietario dell’ASN BGP o una delle tue rotte pubblicate non corrisponde ai dettagli del tuo account.

Se l’ASN BGP o una rotta pubblicata non corrisponde al tuo account, puoi:

Chiedere al proprietario dell’indirizzo IP di inviare un’email a directconnect-requests@amazon.com dichiarando che autorizzano l’approvazione dei prefissi IP pubblici per l’interfaccia virtuale pubblica dxvif-xxx.

—oppure—
Chiedere al proprietario dell’indirizzo IP di presentare una lettera di autorizzazione scritta su carta intestata dell’azienda o di inviare una email autorizzando l’uso del prefisso IP pubblico per l’interfaccia virtuale pubblica dxvif-xxx con il tuo account AWS. Poi accedi all’account che possiede l’interfaccia virtuale pubblica Direct Connect, apri un caso, e allega la lettera di autorizzazione al tuo caso.

Lo stato BGP dell’interfaccia virtuale è inattivo nella console AWS. Cosa dovrei fare?

Lo stato della tua interfaccia virtuale potrebbe essere inattivo a causa di problemi di configurazione con lo OSIOpen Systems Interconnection (OSI) è un modello che caratterizza e standardizza le funzioni di comunicazione di un sistema di telecomunicazioni o di calcolo. La maggior parte dei prodotti Megaport sono di Livello 2 (o L2) con alcune delle costruzioni OSI che spingono nel Livello 3 (L3) dove vengono scambiate le informazioni di indirizzamento IP, noto come servizio L2/L3.
Livello 2 o Border Gateway Protocol (BGP)Il Border Gateway Protocol (BGP) è un protocollo di instradamento standardizzato progettato per scambiare informazioni di rotta e raggiungibilità tra sistemi autonomi (AS) su internet.
.

Configurazione OSI Livello 2

Prima di tutto, verifica che il tuo OSI livello 2 sia configurato correttamente. Verifica i seguenti dettagli:

Hai configurato il corretto ID VLAN con l’incapsulamento dot1Q sul tuo dispositivo (come un router o un switch). L’ID VLAN appare nella scheda Informazioni del Portale come servizio A-End per il tuo VXC.
La configurazione dell’indirizzo IP peer è identica sul tuo dispositivo, attraverso il Portal, e nella console AWS Direct Connect.
Tutti i dispositivi intermedi sono configurati per il tagging VLAN con l’ID VLAN appropriato, e il traffico VLAN-tagged è preservato nel punto finale AWS Direct Connect.
Il tuo dispositivo sta apprendendo l’indirizzo di controllo accesso al mezzo (MAC) del punto finale AWS Direct Connect per l’ID VLAN configurato dalla tabella del Protocollo di Risoluzione degli Indirizzi (ARP).
Il tuo dispositivo può eseguire il ping dell’IP peer Amazon che proviene dal tuo IP peer.

Configurazione BGP

Se i risultati del test OSI livello 2 sono positivi, quindi conferma la configurazione BGP sul tuo dispositivo. Verifica quanto segue:

L’ASN locale e l’ASN remoto come fornito nella scheda Informazioni del Portale come servizio A-End per il tuo VXC.
L’indirizzo IP del neighbor e la password BGP MD5 come forniti nella scheda Informazioni del Portale come servizio A-End per il tuo VXC.
Il tuo dispositivo non sta bloccando l’ingresso o l’uscita dalla porta TCP 179 (BGP) e da altre porte effimere appropriate.
Il tuo dispositivo non sta pubblicando più di 100 prefissi verso AWS tramite BGP. Per impostazione predefinita, AWS accetta solo fino a 100 prefissi utilizzando una sessione BGP su AWS Direct Connect.

Dopo aver confermato queste configurazioni, lo stato BGP della tua interfaccia virtuale dovrebbe essere attivo.