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 se si passa a una posizione di peering nuova o uguale.

Se si dispone del circuito ExpressRoute 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 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. Passare al traffico: reindirizzare il flusso del traffico dal circuito A al circuito B e bloccare il flusso del traffico sul circuito A.

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

Distribuire un nuovo circuito individualmente

Per una sostituzione uno-a-uno del circuito esistente, selezionare l'opzione Resilienza Standard e seguire i passaggi descritti nella guida Creare un circuito con ExpressRoute per creare il nuovo circuito ExpressRoute (Circuito B) nella posizione di peering desiderata. 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 al traffico di produzione di peering privato di usare il circuito B prima di testarlo e convalidarlo, non collegare un gateway di rete virtuale con distribuzione di produzione al circuito B. Analogamente, per evitare il traffico di produzione di peering Microsoft dall'uso del 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 su uno o più 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 nel nuovo 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

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 collegato le reti virtuali al circuito, controllare la tabella di route del peering privato per assicurarsi che lo spazio degli indirizzi della rete virtuale sia incluso. 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 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, 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 di influire 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 di 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. Evitare route comuni: assicurarsi che i filtri di route per entrambi i circuiti non condividono route comuni per impedire 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. Modificare la configurazione dei criteri route-map o Junos per filtrare le route annunciate, consentendo solo i prefissi locali del peering Microsoft e specifici indirizzi IP degli endpoint pubblici Microsoft selezionati per il 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 mappe di route o i criteri sulle interfacce circuito B e applicarli alle interfacce circuito A per bloccare gli annunci di route sul circuito A, passando il flusso di traffico al 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 circuito A.

Peering Microsoft

1. Rimuovere il circuito B da qualsiasi filtro di route di Azure di test.
2. Rimuovere eventuali eccezioni apportate alle mappe o ai criteri di route.
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 route di Azure attualmente associato al circuito A.
6. Rimuovere i criteri di esportazione/esportazione/importazione delle mappe di route nelle interfacce del circuito B e applicarli alle interfacce circuito A per bloccare gli annunci di route sul circuito A, passando il flusso di traffico al 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 circuito A.

Passaggio successivo

Per altre informazioni sulla configurazione del router, vedere Esempi di configurazione del router per configurare e gestire il routing.