Ottimizzare il routing in ExpressRoute

In presenza di più circuiti ExpressRoute sono disponibili più percorsi per connettersi a Microsoft. Il routing può quindi risultare non ottimale, ovvero è possibile che il traffico usi un percorso più lungo per raggiungere Microsoft e da Microsoft la rete del cliente. Più lungo è il percorso di rete, maggiore sarà la latenza La latenza ha un impatto diretto sulle prestazioni dell'applicazione e sull'esperienza utente. Questo articolo descrive il problema e spiega come ottimizzare il routing con tecnologie di routing standard.

Selezione del percorso per il peering Microsoft e pubblico

Quando si usa il peering Microsoft o il peering pubblico, è importante assicurarsi che il traffico passi attraverso il percorso desiderato se sono disponibili uno o più circuiti ExpressRoute. È anche necessario assicurarsi che i percorsi per Internet usino Internet Exchange (IX) o un provider di servizi Internet (ISP, Internet Service Provider). BGP usa un algoritmo di selezione del percorso migliore in base a molti fattori, tra cui la corrispondenza del prefisso più lungo (LPM). Per assicurarsi che il traffico destinato ad Azure tramite peering Microsoft o peering pubblico attraversi il percorso ExpressRoute, è necessario implementare l'attributo Preferenza locale. Questa impostazione garantisce che il percorso sia sempre preferito in ExpressRoute.

Nota

La preferenza locale predefinita è in genere 100. Le preferenze locali più elevate risultano maggiormente preferite.

Si consideri il seguente scenario di esempio:

Nell'esempio precedente, per preferire i percorsi di ExpressRoute, configurare preferenza locale come indicato di seguito.

Configurazione di Cisco IOS-XE dal punto di vista di R1:

• R1(config)#route-map prefer-ExR permit 10

• R1(config-route-map)#set local-preference 150

• R1(config)#router BGP 345

• R1(config-router)#neighbor 1.1.1.2 remote-as 12076

• R1(config-router)#neighbor 1.1.1.2 activate

• R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in

Configurazione di Junos dal punto di vista di R1:

• user@R1# set protocols bgp group ibgp type internal
• user@R1# set protocols bgp group ibgp local-preference 150

Routing non ottimale dal cliente a Microsoft

Per esaminare il problema di routing si userà un esempio. Si supponga di avere due sedi negli Stati Uniti: una a Los Angeles e una a New York. Gli uffici sono connessi tramite una rete WAN (Wide Area Network), che può essere la propria rete backbone o la VPN IP del provider di servizi. di avere due circuiti ExpressRoute, uno negli Stati Uniti occidentali e uno negli Stati Uniti orientali. Entrambi sono connessi anche alla rete WAN. Naturalmente, per la connessione alla rete Microsoft esistono due percorsi.

Si supponga ora di avere una distribuzione di Azure, ad esempio il Servizio app di Azure, negli Stati Uniti occidentali e negli Stati Uniti orientali. Si intende connettere gli utenti di Los Angeles all'area Stati Uniti occidentali di Azure e gli utenti di New York all'area Stati Uniti orientali di Azure. Il motivo di questa configurazione è dovuto al fatto che l'amministratore del servizio annuncia che gli utenti di ogni ufficio accedono ai servizi di Azure nelle vicinanze per un'esperienza ottimale. Il piano funziona correttamente per gli utenti della costa orientale, ma non per quelli della costa occidentale.

La causa del problema è dovuta al fatto che in ogni circuito ExpressRoute viene annunciato in locale sia il prefisso 23.100.0.0/16 dell'area Stati Uniti orientali di Azure che il prefisso 13.100.0.0/16 dell'area Stati Uniti occidentali di Azure. Se non si conosce l'area di provenienza di un prefisso, non si potrà differenziarne la gestione. Ritenendo che entrambi i prefissi siano più vicini agli Stati Uniti orientali rispetto agli Stati Uniti occidentali, la rete WAN potrebbe indirizzare gli utenti di entrambi gli uffici al circuito ExpressRoute negli Stati Uniti orientali. Molti utenti nell'ufficio di Los Angeles hanno di conseguenza un'esperienza insoddisfacente.

Soluzione: usare BGP Community

Per ottimizzare il routing per gli utenti di entrambi gli uffici, è necessario sapere quale prefisso proviene da Azure negli Stati Uniti occidentali e quale da Azure negli Stati Uniti orientali. Queste informazioni vengono codificate con i valori di BGP Community. È stato assegnato un valore di BGP Community univoco per ogni area di Azure, ad esempio 12076:51004 per gli Stati Uniti orientali e 12076:51006 per gli Stati Uniti occidentali. Dopo aver appreso da quale area di Azure proviene ogni prefisso, si può scegliere il circuito ExpressRoute da configurare come preferito. Poiché si usa BGP per lo scambio di informazioni di routing, è possibile usare il valore di BGP relativo alla preferenza locale per determinare il routing.

In questo esempio è possibile assegnare un valore di preferenza locale 13.100.0.0/16 più alto negli Stati Uniti occidentali di quello negli Stati Uniti orientali e, in modo analogo, un valore di preferenza locale 23.100.0.0/16 più alto negli Stati Uniti orientali rispetto a quello negli Stati Uniti occidentali. Questa configurazione garantisce che, quando sono disponibili entrambi i percorsi per connettersi a Microsoft, gli utenti di Los Angeles usino il circuito ExpressRoute negli Stati Uniti occidentali per connettersi ad Azure negli Stati Uniti occidentali, mentre gli utenti di New York usino il circuito ExpressRoute negli Stati Uniti orientali per connettersi ad Azure negli Stati Uniti orientali. Il routing è ottimizzato su entrambi i lati.

Nota

La stessa tecnica, con la preferenza locale, può essere applicata al routing dal cliente alla rete virtuale di Azure quando si usa il peering privato. Microsoft non contrassegna i valori della community BGP per i prefissi annunciati da Azure alla rete. Dato che si sa quale distribuzione della rete virtuale è vicina a un determinato ufficio, è tuttavia possibile configurare i router di conseguenza in modo che venga preferito un circuito ExpressRoute rispetto a un altro.

Routing non ottimale da Microsoft al cliente

In questo esempio sono disponibili connessioni da Microsoft che richiedono un percorso più lungo per raggiungere la rete. In questo caso, si usano i server di Exchange in locale ed Exchange Online in un ambiente ibrido. Gli uffici sono connessi a una rete WAN. Si annunciano a Microsoft i prefissi dei server locali in entrambi gli uffici tramite due circuiti ExpressRoute.

Nel caso, ad esempio, di migrazione delle cassette postali, Exchange Online avvia le connessioni ai server locali. La connessione all'ufficio di Los Angeles viene instradata al circuito ExpressRoute negli Stati Uniti orientali, attraversando l'intero continente prima di ritornare alla costa occidentale. La causa di questo problema è simile a quella del primo. Senza indicazioni, la rete Microsoft non può stabilire quale prefisso locale è più vicino agli Stati Uniti orientali e quale agli Stati Uniti occidentali. Può quindi accadere che venga scelga il percorso errato per l'ufficio di Los Angeles.

Soluzione: anteporre AS PATH

Esistono due soluzioni al problema. La prima consiste semplicemente nell'annunciare il prefisso locale 177.2.0.0/31 per l'ufficio di Los Angeles nel circuito ExpressRoute negli Stati Uniti occidentali. Si annuncia quindi il prefisso locale per l'ufficio di New York, 177.2.0.2/31, nel circuito ExpressRoute negli Stati Uniti orientali. Di conseguenza, Microsoft avrà un solo percorso per connettersi a ogni ufficio. Non esistono ambiguità e il routing risulta ottimizzato. Con questa progettazione è necessario considerare la strategia di failover. Se il percorso di Microsoft tramite ExpressRoute diventa inattivo, è necessario assicurarsi che Exchange Online possa comunque connettersi ai server locali.

La seconda soluzione consiste nel continuare ad annunciare entrambi i prefissi in entrambi i circuiti ExpressRoute e, inoltre, indicare qual è il prefisso vicino a un determinato ufficio. Poiché è supportata l'anteposizione di AS PATH in BGP, si può configurare AS PATH nel prefisso per determinare il routing. In questo esempio è possibile aumentare il valore di AS PATH per 172.2.0.0/31 negli Stati Uniti orientali in modo da preferire il circuito ExpressRoute negli Stati Uniti occidentali per il traffico destinato a questo prefisso. Allo stesso modo si può estendere il valore di AS PATH per 172.2.0.2/31 negli Stati Uniti occidentali, in modo che venga preferito il circuito ExpressRoute negli Stati Uniti orientali. Il routing è ottimizzato per entrambi gli uffici. Con questa progettazione, se un circuito ExpressRoute viene interrotto, Exchange Online può comunque raggiungere il cliente tramite un altro circuito ExpressRoute e la rete WAN.

Importante

I numeri AS privati vengono rimossi in AS PATH per i prefissi ricevuti nel peering Microsoft quando si esegue il peering usando un numero AS privato. È necessario eseguire il peering con un numero AS pubblico e aggiungere numeri AS pubblici in AS PATH per influenzare il routing per il peering Microsoft.

Nota

Anche se gli esempi illustrati qui si riferiscono ai peer Microsoft e pubblici, le stesse funzionalità sono supportate per il peer privato. L'anteposizione di AS PATH funziona poi in un singolo circuito ExpressRoute, per determinare la selezione dei percorsi primari e secondari.

Routing non ottimale tra reti virtuali

Con ExpressRoute, è possibile abilitare la comunicazione da rete virtuale a rete virtuale collegando le reti virtuali a un circuito ExpressRoute. Se vengono collegate a più circuiti ExpressRoute, il routing tra le reti virtuali può risultare non ottimale. Di seguito è riportato un esempio. di avere due circuiti ExpressRoute, uno negli Stati Uniti occidentali e uno negli Stati Uniti orientali. In ogni area sono presenti due reti virtuali, in una sono distribuiti i server Web e nell'altra i server applicazioni. A scopo di ridondanza, si collegano le due reti virtuali di ogni area sia al circuito ExpressRoute locale che al circuito ExpressRoute remoto. Come si può notare nel diagramma seguente, da ogni rete virtuale sono presenti due percorsi per l'altra rete virtuale. Le reti virtuali non rilevano quale circuito ExpressRoute è locale e quale è invece remoto. Poiché il routing ECMP (Equal-Cost-Multi-Path) viene usato per il bilanciamento del carico del traffico tra reti virtuali, alcuni flussi di traffico seguono il percorso più lungo e vengono instradati sul circuito ExpressRoute remoto.

Soluzione: assegnare un peso elevato alla connessione locale

La soluzione è semplice. Dato che la posizione delle reti virtuali e dei circuiti è nota, è possibile indicare il percorso che dovrà essere preferito da ogni rete virtuale. Per questo esempio, in particolare, si assegna alla connessione locale un peso superiore rispetto alla connessione remota (vedere l'esempio di configurazione qui). Quando una rete virtuale riceve un prefisso dell'altra rete virtuale su più connessioni, per l'invio del traffico destinato a tale prefisso preferisce la connessione con il peso più elevato.

Nota

Per determinare il routing dalla rete virtuale alla rete locale, se si hanno più circuiti ExpressRoute, è anche possibile configurare il peso di una connessione anziché anteporre AS PATH applicando la tecnica descritta nel secondo scenario. Per ogni prefisso, per decidere come inviare il traffico verrà sempre esaminato il peso della connessione prima della lunghezza di AS PATH.

Passaggi successivi

• Informazioni sulla progettazione di ExpressRoute per la disponibilità elevata.
• Informazioni sulla progettazione di ExpressRoute per il ripristino di emergenza.