Eseguire la migrazione a un nuovo circuito ExpressRoute
Se si vuole passare da un circuito ExpressRoute a un altro, è consigliabile farlo senza problemi con un'interruzione minima del servizio. Questo documento consente di seguire la procedura per eseguire la migrazione del traffico di produzione senza causare gravi interruzioni o rischi. È possibile usare questo metodo se si passa a una posizione di peering nuova o uguale.
Se il circuito ExpressRoute è disponibile tramite un provider di servizi di livello 3, creare il nuovo circuito nella sottoscrizione nel portale di Azure. Collaborare con il provider di servizi per passare facilmente il traffico al nuovo circuito. Dopo che il provider di servizi ha effettuato il deprovisioning del circuito precedente, eliminarlo dal portale di Azure.
Il resto dell'articolo si applica all'utente se si ha il circuito ExpressRoute tramite un provider di servizi di livello 2 o porte dirette ExpressRoute.
Passaggi per la migrazione senza problemi del circuito ExpressRoute
Il diagramma precedente illustra il processo di migrazione da un circuito ExpressRoute esistente, denominato Circuito A, a un nuovo circuito ExpressRoute, denominato Circuito B. Il circuito B può trovarsi nello stesso percorso o in un percorso di peering diverso del circuito A. Il processo di migrazione è costituito dai passaggi seguenti:
Distribuire il circuito B individualmente: mentre il traffico continua a fluire sul circuito A, distribuire un nuovo circuito B senza influire sull'ambiente di produzione.
Bloccare il flusso del traffico di produzione sul circuito B: impedire l'uso del circuito B fino a quando non viene testato e convalidato completamente.
Completare e convalidare la connettività end-to-end del circuito B: assicurarsi che il circuito B possa stabilire e mantenere una connessione stabile e sicura con tutti gli endpoint necessari.
Passare al traffico: reindirizzare il flusso del traffico dal circuito A al circuito B e bloccare il flusso del traffico sul circuito A.
Rimuovere il circuito A: rimuovere il circuito A dalla rete e rilasciarne le risorse.
Distribuire un nuovo circuito individualmente
Seguire la procedura descritta in Creare un circuito con ExpressRoute per creare il nuovo circuito ExpressRoute (Circuito B) nel percorso di peering desiderato. Seguire quindi la procedura descritta in Esercitazione: Configurare il peering per il circuito ExpressRoute per configurare i tipi di peering necessari: privato e Microsoft.
Per impedire al traffico di produzione di peering privato di usare il circuito B prima di testarlo e convalidarlo, non collegare il gateway di rete virtuale con distribuzione di produzione al circuito B. Analogamente, per evitare che il traffico di produzione del peering Microsoft utilizzi il circuito B, non associare un filtro di route al circuito B.
Bloccare il flusso del traffico di produzione sul circuito appena creato
Impedire l'annuncio di route sui nuovi peering nei dispositivi CE.
Per Cisco IOS, è possibile usare un oggetto route-map e un oggetto prefix-list per filtrare le route annunciate tramite un peering BGP. Nell'esempio seguente viene illustrato come creare e applicare un oggetto route-map e un oggetto prefix-list a questo scopo:
route-map BLOCK ADVERTISEMENTS deny 10
match ip address prefix-list BLOCK-ALL-PREFIXES
ip prefix-list BLOCK-ALL-PREFIXES seq 10 deny 0.0.0.0/0 le 32
router bgp <your_AS_number>
neighbor <neighbor_IP_address> route-map BLOCK-ADVERTISEMENTS out
neighbor <neighbor_IP_address> route-map BLOCK-ADVERTISEMENTS in
Usare i criteri di esportazione/importazione per filtrare le route annunciate e ricevute nei nuovi peering nei dispositivi Junos. L'esempio seguente illustra come configurare i criteri di esportazione/importazione per questo scopo:
user@router>show configuration policy-options policy-statement BLOCK-ALL-ROUTES
term reject-all {
the reject;
}
protocols {
bgp {
group <your_group_name> {
neighbor <neighbor_IP_address> {
export [ BLOCK-ALL-ROUTES ];
import [ BLOCK-ALL-ROUTES ];
}
}
}
}
Convalidare la connettività end-to-end del circuito appena creato
Peering privato
Seguire la procedura descritta in Connettere una rete virtuale a un circuito ExpressRoute per collegare il nuovo circuito al gateway di una rete virtuale di test e verificare la connettività del peering privato. Dopo aver collegato le reti virtuali al circuito, esaminare la tabella di route del peering privato del circuito e verificare che lo spazio indirizzi della rete virtuale sia incluso nella tabella. L'esempio seguente mostra una tabella di route del peering privato di un circuito ExpressRoute nel portale di gestione di Azure:
Il diagramma seguente illustra una macchina virtuale di test configurata in una rete virtuale di test e un dispositivo di test situato in locale per verificare la connettività tramite il peering privato di ExpressRoute.
Modificare la configurazione dei criteri o la route-map applicata per filtrare le route annunciate e consentire l'indirizzo IP specifico del dispositivo di test dall'ambiente locale. Analogamente, consentire lo spazio indirizzi della rete virtuale di test da Azure.
route-map BLOCK ADVERTISEMENTS permit 5
match ip address prefix-list PERMIT-ROUTE
route-map BLOCK ADVERTISEMENTS deny 10
match ip address prefix-list BLOCK-ALL-PREFIXES
ip prefix-list PERMIT-ROUTE seq 10 permit 10.17.1.0/24
ip prefix-list PERMIT-ROUTE seq 20 permit 10.1.18.10/32
ip prefix-list BLOCK-ALL-PREFIXES seq 10 deny 0.0.0.0/0 le 32
Per consentire prefissi IP specifici per i dispositivi di test in Junos, configurare un elenco di prefissi. Configurare quindi i criteri di importazione/esportazione BGP per consentire questi prefissi e rifiutare tutto il resto.
user@router>show configuration policy-options policy-statement BLOCK-ADVERTISEMENTS
term PERMIT-ROUTES {
from {
prefix-list PERMIT-ROUTE;
}
then accept;
}
term reject-all {
then reject;
}
user@router>show configuration policy-options prefix-list PERMIT-ROUTE
10.1.18.10/32;
10.17.1.0/24;
Verificare la connettività end-to-end tramite il peering privato. Ad esempio, è possibile effettuare il ping della macchina virtuale di test in Azure dal dispositivo di test locale e controllare i risultati. Per una convalida dettagliata, vedere Verifica della connettività ExpressRoute.
Peering Microsoft
La verifica del peering Microsoft richiede un'attenta pianificazione per evitare qualsiasi effetto sul traffico di produzione. È necessario usare prefissi distinti per il peering Microsoft del circuito B diversi da quelli usati per il circuito A, per evitare conflitti di routing tra i due circuiti. È inoltre necessario collegare il peering Microsoft del Circuito B a un filtro di route separato rispetto a quello collegato al circuito A, seguendo la procedura descritta in configurazione dei filtri di route per il peering Microsoft. Inoltre, è necessario assicurarsi che i filtri di route per entrambi i circuiti non abbiano route comuni annunciate alla rete locale, per evitare il routing asimmetrico tra il circuito A e il circuito B. A tale scopo, è possibile:
- selezionare un servizio o un'area di Azure per il test del circuito B non usato dal traffico di produzione sul circuito A o
- ridurre al minimo la sovrapposizione tra i due filtri di route e consentire solo endpoint pubblici di test più specifici ricevuti tramite il circuito B
Dopo aver collegato un filtro di route, è necessario controllare le route annunciate e ricevute tramite il peering BGP nel dispositivo CE. Per filtrare le route annunciate e consentire solo i prefissi locali del peering Microsoft e l'indirizzo IP specifico degli endpoint pubblici Microsoft selezionati per il test, è necessario modificare la configurazione dei criteri Junos o la route-map applicata.
Per testare la connettività agli endpoint di Microsoft 365, seguire la procedura descritta in Implementazione di ExpressRoute per Microsoft 365 - Compilare le procedure di test. Per gli endpoint pubblici di Azure, è possibile iniziare con test di connettività di base, ad esempio traceroute dall'ambiente locale e verificare che la richiesta esegua endpoint ExpressRoute. Oltre agli endpoint ExpressRoute, i messaggi ICMP vengono eliminati sulla rete Microsoft. È anche possibile testare la connettività a livello di applicazione, oltre ai test di ping di base. Ad esempio, se si dispone di una macchina virtuale di Azure con indirizzo IP pubblico di Azure che esegue un server Web, è possibile provare ad accedere all'indirizzo IP pubblico del server Web dalla rete locale tramite la connessione ExpressRoute. Ciò consente di verificare che il traffico più complesso, ad esempio le richieste HTTP, possa raggiungere i servizi di Azure.
Passare al traffico di produzione
Peering privato
- Disconnettere il circuito B da qualsiasi gateway di rete virtuale di test a cui è stato connesso.
- Rimuovere eventuali eccezioni apportate ai criteri Cisco Junos o mappe di route (route-map).
- Seguire la procedura descritta in Connettere una rete virtuale a un circuito ExpressRoute e connettere il circuito B ai gateway di rete virtuale di produzione.
- In CE assicurarsi di essere pronti per annunciare tutte le route attualmente annunciate sul circuito A, sul circuito B quando si rimuovono la route-map o i criteri applicati alle interfacce del circuito B in CE. Ciò include anche la garanzia che le interfacce del circuito B siano associate a VRF o all'istanza di routing appropriata, se presente.
- Rimuovere le mappe di route (route-map) o i criteri nelle interfacce del Circuito B. Applicare le route-map o i criteri alle interfacce del Circuito A per bloccare l'annuncio della route sul circuito A. Questo cambierà il flusso del traffico sul circuito B.
- Verificare il flusso del traffico sul circuito B. Se la verifica ha esito negativo, annullare l'associazione route-map o firewall eseguita nel passaggio precedente e ripristinare il flusso del traffico sul circuito A.
- Se la verifica del flusso di traffico sul circuito B ha esito positivo, eliminare il circuito A.
Peering Microsoft
- Rimuovere il circuito B da qualsiasi filtro di route di Azure di test a cui è stato collegato.
- Rimuovere tutte le eccezioni apportate alle mappe di route (route-map) o ai criteri.
- In CE assicurarsi che l'interfaccia del circuito B sia associata all'istanza di routing o VRF appropriata.
- Convalidare e confermare il prefisso annunciato sul peering Microsoft.
- Associare il peering Microsoft del circuito B al filtro di route di Azure attualmente associato al circuito A.
- Rimuovere i criteri relativi a esportazione/importazione o mappe di route (route-map) nelle interfacce circuito B. Applicare i criteri relativi a esportazione/importazione o mappe di route (route-map) sulle interfacce del circuito A per bloccare l'annuncio di route sul circuito A. Questo cambierà il flusso del traffico sul circuito B.
- Verificare il flusso del traffico sul circuito B. Se la verifica ha esito negativo, annullare l'associazione criteri o route-map eseguita nel passaggio precedente e ripristinare il flusso del traffico sul circuito A.
- Se la verifica del flusso di traffico sul circuito B ha esito positivo, eliminare il circuito A.
Passaggio successivo
Per altre informazioni sulla configurazione del router, vedere Esempi di configurazione del router per configurare e gestire il routing.