Eseguire la migrazione a un nuovo circuito ExpressRoute

Se si vuole passare da un circuito ExpressRoute a un altro, è possibile farlo senza problemi con un'interruzione minima del servizio. Questo documento illustra la procedura per eseguire la migrazione del traffico di produzione senza causare gravi interruzioni o rischi. Questo metodo si applica sia che si effettui la migrazione verso una nuova località di peering sia che si rimanga nella stessa località di peering.

Se il circuito ExpressRoute è fornito tramite un provider di servizi Layer 3, creare il nuovo circuito nella propria 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 se si dispone del 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 una posizione di peering diversa del circuito A. Il processo di migrazione è costituito dai passaggi seguenti:

1. 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.

2. Blocca il flusso del traffico di produzione sul circuito B: impedisci a qualsiasi traffico di usare il circuito B fino a quando non viene testato completamente e convalidato.

3. 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.

4. Commutare il traffico: reindirizzare il traffico dal circuito A al circuito B e bloccare il traffico attraverso il circuito A.

5. Rimuovere il circuito A: rimuovere il circuito A dalla rete e rilasciarne le risorse.

Distribuire un nuovo circuito in modo isolato

Per una sostituzione simile che preservi il livello di resilienza del circuito esistente, seleziona l'opzione Resilienza Standard e segui i passaggi indicati nella guida Crea un circuito con ExpressRoute per creare il tuo nuovo circuito ExpressRoute (Circuito B) nella posizione di peering desiderata. La resilienza standard è una configurazione a sito singolo e non è raccomandata per carichi di lavoro aziendali o mission-critical. Se stai migrando un carico di lavoro di questo tipo, valuta invece High o Maximum Resiliency. Per altre informazioni, vedere Progettare e architettare Azure ExpressRoute per garantire la resilienza. Seguire quindi la procedura descritta in Configurare il peering per il circuito ExpressRoute per configurare i tipi di peering necessari: privato e Microsoft.

Per impedire che il traffico di produzione del peering privato utilizzi il circuito B prima che venga testato e convalidato, non collegare al circuito B un gateway di rete virtuale con una distribuzione di produzione. Analogamente, per evitare che il traffico di produzione del peering Microsoft utilizzi il circuito B, non associare un filtro di routing al circuito B.

Bloccare il flusso del traffico di produzione sul circuito appena creato

Impedire l'annuncio di rotte attraverso uno o più nuovi peering sui 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

Utilizzare i criteri di esportazione/importazione per filtrare le route annunciate e ricevute sulla nuova sessione di peering sui 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

Per collegare il nuovo circuito al gateway di una rete virtuale di test e verificare la connettività di peering privato, seguire la procedura descritta in Connettere una rete virtuale a un circuito ExpressRoute. Dopo aver connesso le reti virtuali al circuito, controllare la tabella di routing del peering privato per assicurarsi che lo spazio di indirizzi della rete virtuale sia incluso nella tabella. L'esempio seguente mostra una tabella di routing del peering privato di un circuito ExpressRoute nel portale di gestione di Azure:

Il diagramma seguente illustra una macchina virtuale di test in una rete virtuale di test e un dispositivo di test locale usato per verificare la connettività tramite il peering privato di ExpressRoute.

Modificare la configurazione della mappa di route o dei criteri per filtrare le route annunciate e consentire l'indirizzo IP specifico del dispositivo di test locale. Analogamente, consenti lo spazio di indirizzi della rete virtuale di test in 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 di Microsoft richiede un'attenta pianificazione per evitare di avere ripercussioni sul traffico di produzione. Per garantire un processo uniforme, seguire questa procedura:

1. Usa prefissi distinti: configurare il peering Microsoft per il circuito B con prefissi diversi da quelli usati per il circuito A per evitare conflitti di routing. Per indicazioni, vedere creazione del peering Microsoft.
2. Filtri di route separati: collegare il peering Microsoft del circuito B a un filtro di route diverso rispetto al circuito A. Seguire la procedura descritta nella configurazione dei filtri di route per il peering Microsoft.
3. Evitate route comuni: assicuratevi che i filtri delle route per entrambi i circuiti non condividano route comuni, per evitare il routing asimmetrico. A tale scopo, è possibile:
   • Selezione di un servizio o di un'area di Azure per il test del circuito B non usato dal traffico di produzione del circuito A.
   • Ridurre al minimo la sovrapposizione tra i due filtri di route e consentire solo endpoint pubblici di test specifici tramite il circuito B.

Dopo aver collegato un filtro di route, controllare le route annunciate e ricevute tramite il peering BGP nel dispositivo CE. Modifica la configurazione della route-map o del criterio Junos per filtrare le route annunciate, consentendo solo i prefissi on-premises del peering Microsoft e gli indirizzi IP specifici degli endpoint pubblici Microsoft selezionati per i test.

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, iniziare con i test di connettività di base, ad esempio traceroute dall'ambiente locale, per garantire che le richieste passino su endpoint ExpressRoute. Oltre agli endpoint ExpressRoute, i messaggi ICMP vengono eliminati tramite la rete Microsoft. Inoltre, testare la connettività a livello di applicazione. Ad esempio, se si dispone di una macchina virtuale di Azure con un indirizzo IP pubblico che esegue un server Web, provare ad accedere all'indirizzo IP pubblico del server Web dalla rete locale tramite la connessione ExpressRoute. Ciò conferma che il traffico complesso, ad esempio le richieste HTTP, può raggiungere i servizi di Azure.

Peering privato

1. Disconnettere il circuito B da qualsiasi gateway di rete virtuale di test.
2. Rimuovere eventuali eccezioni apportate ai criteri Cisco route-maps o Junos.
3. Connettere il circuito B al gateway di rete virtuale di produzione seguendo la procedura descritta in Connettere una rete virtuale a un circuito ExpressRoute.
4. Assicurarsi che il circuito B sia pronto per annunciare tutte le route attualmente annunciate sul circuito A. Verificare che le interfacce del circuito B siano associate alla VRF o all'istanza di routing appropriata.
5. Rimuovere le route-map o le policy dalle interfacce del circuito B e applicarle alle interfacce del circuito A per bloccare gli annunci di route sul circuito A, instradando il traffico sul circuito B.
6. Verificare il flusso del traffico sul circuito B. Se la verifica non riesce, ripristinare le modifiche e ripristinare il flusso di traffico al circuito A.
7. Se la verifica ha esito positivo, eliminare il circuito A.

Peering Microsoft

1. Rimuovere Circuit B da qualsiasi filtro di route Azure di test.
2. Rimuovere eventuali eccezioni applicate alle route-map o alla policy.
3. Assicurarsi che le interfacce del circuito B siano associate alla VRF o all'istanza di routing appropriata.
4. Convalidare e confermare i prefissi annunciati tramite il peering Microsoft.
5. Associare il peering Microsoft del circuito B al filtro di routing di Azure attualmente associato al circuito A.
6. Rimuovere le route-map o i criteri di esportazione/importazione dalle interfacce del circuito B e applicarli alle interfacce del circuito A per bloccare gli annunci di route tramite il circuito A, deviando il traffico sul circuito B.
7. Verificare il flusso del traffico sul circuito B. Se la verifica non riesce, ripristinare le modifiche e ripristinare il flusso di traffico al circuito A.
8. Se la verifica 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.