Come posso influenzare il percorso del traffico di rete della mia connessione Direct Connect all'on-premise su più circuiti?

Breve descrizione

È possibile utilizzare più circuiti Direct Connect in diverse regioni AWS per aumentare la larghezza di banda e la disponibilità elevata. A seconda della distribuzione dei circuiti tra le regioni, puoi influenzare il traffico Direct Connect pubblicizzando i tag della community Border Gateway Protocol (BGP) con prefissi on-premise.

Le normali configurazioni per più connessioni Direct Connect includono:

• Interfacce virtuali private create sulle connessioni Direct Connect collegate agli stessi gateway virtuali privati (VGW) nella stessa regione.
• Interfacce virtuali private create sulle connessioni Direct Connect collegate allo stesso Direct Connect Gateway (DXGW) e associate a più VGW in qualsiasi regione.
• Interfacce virtuali di transito create sulle connessioni Direct Connect collegate allo stesso DXGW e associate a più gateway di transito in qualsiasi regione.

Risoluzione

Segui queste istruzioni per influenzare il percorso del traffico di rete della connessione Direct Connect in base al caso d'uso.

Comportamento di default per le interfacce virtuali private e di transito e come influenzarle

Per influenzare il comportamento di default, è una best practice utilizzare la prependenza del percorso Autonomous System (AS) e i seguenti tag della community BGP delle preferenze locali:

• 7224:7100 – Bassa preferenza
• 7224:7200 – Media preferenza
• 7224:7300 – Alta preferenza

I tag della community BGP delle preferenze locali vengono valutati in ordine dalla preferenza più bassa alla più alta (dove si preferisce la preferenza più alta). Per ogni prefisso pubblicizzato in una sessione BGP, puoi applicare un tag della community per indicare la priorità del percorso associato per il traffico di ritorno.

Per ulteriori informazioni, consulta Come posso utilizzare le community BGP per influenzare il percorso di routing preferito sui collegamenti Direct Connect da AWS alla mia rete?

Scenario 1

Hai una connessione Direct Connect (DX1) nella regione us-east-1 e una seconda connessione (DX2) nella regione eu-west-1. Un'interfaccia virtuale privata (VIF) viene creata su DX1 e DX2 con lo stesso prefisso pubblicizzato dai dispositivi on-premise. DX1 e DX2 VIF sono collegati con un DXGW associato a tre VGW nelle regioni us-east-1, eu-west-1 e ap-southeast-1.

Se pubblicizzi il tag BGP 7224:7300 su VIF su DX1, il traffico proveniente da Amazon Virtual Private Cloud (Amazon VPC) nella regione us-east-1 rimane invariato. Il traffico proveniente dalle regioni eu-west-1 e ap-southeast-1 preferisce DX1 perché la stessa preferenza di regione viene sovrascritta dalla community BGP.

Se pubblicizzi il tag BGP 7224:7300 su VIF su DX1 e DX2, il traffico proveniente da tutti i VPC Amazon in diverse regioni viene bilanciato dal carico su DX1 e DX2. Questo perché la stessa preferenza di regione viene sovrascritta dalla community BGP.

Se pubblicizzi il tag BGP 7224:7300 su entrambi i file VIF con AS che precede DX1, il traffico proveniente da tutti gli Amazon VPC in tutte le regioni preferisce DX2. Questo perché le preferenze di regione vengono sovrascritte come uguali. Quindi, AWS esegue la convalida sulla lunghezza del percorso AS rilevando che il prefisso del percorso per DX2 è più breve di DX1.

Se pubblicizzi solo un AS che precede VIF su DX1 senza tag della community BGP, il traffico proveniente dagli Amazon VPC nelle regioni us-east-1 e eu-west-1 rimane invariato. Il traffico proveniente dalla regione ap-southeast-1 preferisce DX2. Questo perché la preferenza della regione ha una priorità più alta rispetto alla lunghezza del percorso AS.

Scenario 2

Esistono connessioni Direct Connect DX1 e DX2 nella regione us-east-1 con interfacce virtuali private che utilizzano lo stesso prefisso pubblicizzato dai dispositivi on-premise. Le interfacce virtuali private sono collegate con il DXGW associato a tre VGW nelle regioni us-east-1 ed eu-west-1.

Se pubblicizzi il tag BGP 7224:7300 sulla VIF su DX1, il traffico proveniente dalle regioni us-east-1 e eu-west-1 preferisce DX1 perché la stessa preferenza di regione viene sovrascritta dalla community BGP.

Se pubblicizzi il tag BGP 7224:7300 su entrambi i file VIF su DX1 e DX2, il traffico proveniente da VPC in regioni diverse rimane invariato. Questo perché la preferenza di regione viene sovrascritta dal tag della community BGP per il bilanciamento del carico.

Se pubblicizzi il tag BGP 7224:7300 su entrambi i file VIF con AS che precede DX1, il traffico dagli Amazon VPC in tutte le regioni preferisce DX2. Questo perché la preferenza di regione viene sovrascritta come uguale. Quindi, AWS esegue la convalida sulla lunghezza del percorso AS rilevando che il prefisso del percorso per DX2 è più breve di DX1.

Se pubblicizzi un AS che precede VIF su DX1 senza tag della community BGP, il traffico proveniente dagli Amazon VPC nelle regioni us-east-1 e eu-west-1 preferisce DX2. Questo perché le regioni us-east-1 e eu-west-1 hanno la stessa preferenza di regione e un percorso AS più breve per DX2.

Scenario 1 e Scenario 2

Se pubblicizzi prefissi on-premise senza influenzare i fattori, il comportamento di default del traffico in uscita è il seguente:

• Il traffico proveniente da Amazon VPC nella regione us-east-1 viene preferito per DX1 perché si trova nella stessa regione. Il traffico proveniente da Amazon VPC nella regione eu-west-1 viene preferito per DX2 perché si trova nella stessa regione. Poiché ap-southeast-1 è una regione remota, il traffico proveniente da Amazon VPC è bilanciato dal carico tra DX1 e DX2.
• Il traffico proveniente da Amazon VPC nella regione us-east-1 viene bilanciato dal carico tra DX1 e DX2 perché si trova nella stessa regione. Il traffico proveniente da Amazon VPC nella regione eu-west-1 viene bilanciato dal carico tra DX1 e DX2.

Comportamento di default per le interfacce virtuali pubbliche e come influenzarlo

Nel seguente scenario, vi sono due connessioni Direct Connect nella stessa regione che utilizzano la stessa interfaccia virtuale pubblica e il prefisso pubblicizzati dai dispositivi on-premise.

Il traffico in uscita dalla direzione AWS è bilanciato dal carico tra i file VIF pubblici senza influenzare i fattori. Per influenzare il comportamento di default, è una best practice utilizzare la prependenza Autonomous System (AS) con un ASN pubblico. Se è possibile utilizzare solo un ASN privato, è una best practice pubblicizzare prefissi più specifici dall'interfaccia utente virtuale pubblica preferita, in modo che la corrispondenza più lunga del prefisso determini il percorso di routing.

Scenari di routing asimmetrici comuni per interfacce virtuali pubbliche

È possibile utilizzare i seguenti prefissi BGP con Direct Connect:

• 7224:9100 — Regione AWS locale
• 7224:9200 — Tutte le regioni AWS di un continente
• 7224:9300 — Globale (tutte le regioni AWS pubbliche)

Per ulteriori informazioni, consulta le community BGP coinvolte.

Nel seguente scenario, si dispone di una connessione Direct Connect nella regione us-east-1 con un'interfaccia virtuale pubblica. Stai pubblicizzando lo stesso prefisso pubblico on-premise con il tag community 7224:9100 sulla connessione Direct Connect e sul fornitore di servizi Internet locale.

Se accedi a un bucket Amazon Simple Storage Service (Amazon S3) nella regione us-east-1, il traffico in entrata e in uscita avviene tramite la connessione Direct Connect.

Se stai accedendo a un bucket Amazon S3 nella regione eu-west-1, il traffico in entrata avviene tramite la connessione Direct Connect e il traffico in uscita è sul fornitore di servizi Internet locale. Questo perché il prefisso non viene propagato alla regione eu-west-1 causando un routing asimmetrico.

Se stai accedendo a un bucket Amazon S3 nella regione us-east-1 e il traffico in entrata è da on-premise utilizza il fornitore di servizi Internet locale, si verifica un routing asimmetrico. Questo perché AWS preferisce inviare traffico in uscita tramite la connessione Direct Connect anziché il fornitore di servizi Internet locale quando vengono ricevuti gli stessi prefissi.

Informazioni correlate

Configurare connessioni ridondanti con AWS Direct Connect

Come posso impostare una connessione Direct Connect come attiva/attiva o attiva/passiva ad AWS da un'interfaccia virtuale pubblica? 

Tipi di interfaccia virtuale di AWS Direct Connect

---