Risolvere i problemi

Utilizza la seguente guida per risolvere i problemi comuni relativi al router Cloud:

Per ulteriore assistenza, consulta la seguente documentazione:

Problemi di configurazione

Impossibile stabilire la sessione BGP

Verifica che le impostazioni del router BGP on-premise e le impostazioni del router Cloud siano corrette. Per informazioni dettagliate, visualizza i log del router Cloud.

Se stai creando un tunnel Cloud VPN, controlla che lo stato del tunnel sia ESTABLISHED. Se non è possibile, consulta la pagina Risoluzione dei problemi di Cloud VPN.

Indirizzi IP per le sessioni BGP

Gli indirizzi IP che puoi utilizzare per una sessione BGP dipendono dal prodotto di connettività di rete che utilizzi. Per informazioni dettagliate, consulta Indirizzi IP BGP.

Valore non valido per il campo resource.bgp.asn

Potresti visualizzare il seguente errore:

"Valore non valido per il campo resource.bgp.asn: ######. ASN locale è in conflitto con l'ASN peer specificato da un router nella stessa area geografica e nella stessa rete.&brt;

Il router Cloud sta tentando di stabilire una sessione BGP con un dispositivo on-premise con lo stesso ASN del router Cloud. Per risolvere il problema, modifica l'ASN del dispositivo o del router Cloud.

iBGP tra router Cloud in una singola area geografica non funziona

Anche se puoi creare due router Cloud con lo stesso ASN, iBGP non è supportato.

Problemi relativi al router Cloud

I reset BGP che hanno origine da Google Cloud vengono visualizzati sul tuo router

Le attività del router Cloud sono processi software nel piano di controllo di Google Cloud, di cui normalmente viene eseguita la migrazione da macchina a macchina. Durante tali migrazioni, il router Cloud potrebbe essere inattivo per periodi fino a 60 secondi. Le normali migrazioni non comportano il calo del traffico.

Il router Cloud non si trova nel percorso dati e non agisce come switch di livello 3, ma come gestore per la programmazione delle route. Il routing viene effettivamente gestito dal collegamento VLAN o dal tunnel Cloud VPN.

NOTIFICATION_RECEIVED messaggio viene visualizzato nei log del router Cloud

Un messaggio NOTIFICATION_RECEIVED compare nei log del router Cloud quando quest'ultimo ha ricevuto un messaggio NOTIFICATION dal peer BGP. Il messaggio NOTIFICATION indica al router Cloud di interrompere la sessione BGP.

Quando il router Cloud riceve un messaggio NOTIFICATION dal peer BGP, il router Cloud chiude la connessione BGP con quel peer e rimuove tutte le route apprese.

Il peer BGP può inviare messaggi NOTIFICATION per diversi motivi. Ad esempio, il peer potrebbe inviare un messaggio "Sospendi il timer scaduto".

CONFIG_DISABLED messaggio viene visualizzato nei log del router Cloud

Un messaggio CONFIG_DISABLED indica che il router Cloud ha intenzionalmente interrotto la sessione BGP. Con l'arresto della sessione BGP, il router Cloud tenta di comunicare immediatamente uno stato di errore al peer.

Questo messaggio può essere visualizzato per uno dei seguenti motivi:

  • Un utente ha disattivato la sessione BGP utilizzando l'API Cloud Router, Google Cloud Console o l'interfaccia a riga di comando di Google Cloud. Consulta Disattivazione o rimozione delle sessioni BGP.
  • Per una sessione BGP configurata per Cloud VPN, il tunnel VPN associato alla sessione BGP non ha stabilito un'IKE e un'associazione di sicurezza secondaria (SA). Per risolvere i problemi di connettività VPN, consulta l'articolo Risoluzione dei problemi di Cloud VPN.
  • Per una sessione BGP configurata per Cloud Interconnect, il collegamento VLAN non è configurato o è in uno stato di disattivazione. Per risolvere ulteriormente il problema, consulta la sezione relativa alla risoluzione dei problemi nella documentazione di Cloud Interconnect.
  • Per una sessione BGP abilitata per BFD, il timer di rilevamento del controllo BFD su router Cloud è scaduto. In questo caso, la sessione BGP viene interrotta. Per ulteriori informazioni sugli stati delle sessioni BFD, vedi Messaggi diagnostici e stati delle sessioni BFD.

Il router on-premise riscontra un flap BGP

I flap BGP possono essere causati da vari problemi, tra cui la manutenzione software e il riavvio automatico delle attività del router Cloud.

Per informazioni dettagliate sugli eventi di manutenzione completati, consulta la sezione Individuare gli eventi di manutenzione del router. Per informazioni dettagliate su altri eventi del router Cloud, vedi Visualizzazione di log e metriche del router Cloud.

Un evento di manutenzione del router Cloud non indica un problema se il router on-premise è configurato come segue:

  • Il router on-premise può elaborare notifiche di riavvio graceful.
  • Il timer di attesa del router on-premise è impostato su almeno 60 secondi.

Per una panoramica completa delle impostazioni del timer, consulta la sezione Gestire i timer BGP.

Per informazioni sul monitoraggio della connettività, vedi Verificare la connettività tra il router on-premise e il router Cloud.

Problemi di autenticazione

Le seguenti sezioni descrivono i problemi che possono verificarsi con l'autenticazione MD5, disponibile in anteprima.

Lo stato del peer BGP è MD5_AUTH_INTERNAL_PROBLEM

A volte lo stato di un peer BGP include i seguenti valori:

  • md5AuthEnabled: true
  • statusReason: MD5_AUTH_INTERNAL_PROBLEM

Il primo valore indica che l'autenticazione MD5 è stata configurata correttamente. Tuttavia, il secondo valore, statusReason, MD5_AUTH_INTERNAL_PROBLEM, indica che un errore interno ha impedito al router Cloud di configurare l'autenticazione MD5. Per questo motivo, lo stato della sessione BGP è DOWN. In questo caso, non devi fare nulla. Il router Cloud tenta di recuperare e ripristinare la sessione.

Per informazioni su come controllare lo stato del peer, consulta Controllare lo stato di autenticazione.

Router Cloud e peer utilizzano chiavi MD5 diverse

Quando configuri l'autenticazione MD5, il router Cloud e il relativo router peer devono utilizzare la stessa chiave di autenticazione segreta. In caso di mancata corrispondenza, i due router non possono comunicare. Se ritieni che ci sia una mancata corrispondenza, una soluzione è aggiornare la chiave utilizzata dal router Cloud. Per informazioni su come apportare questa modifica, consulta la sezione Aggiornare la chiave di autenticazione.

Se non sai se c'è stata una mancata corrispondenza tra la chiave, cerca le soluzioni per la risoluzione dei problemi nella documentazione del router peer. Molti router hanno log che registrano se c'è una mancata corrispondenza con la chiave.

Problemi di elaborazione dei percorsi

Le route on-premise senza valore MED hanno la priorità

Se il router Cloud riceve una route on-premise in cui non è presente un valore MED, segue il comportamento descritto nel documento RFC 4271. Il router Cloud tratta la route con la massima priorità presumendo il valore MED più basso possibile (0).

Non puoi inviare e apprendere i valori MED tramite una connessione Partner Interconnect di livello 3

Se utilizzi una connessione Partner Interconnect in cui un provider di servizi di livello 3 gestisce BGP per conto tuo, il router Cloud non può imparare i valori MED dal router on-premise o inviare valori MED a quel router. Questo perché i valori MED non possono passare attraverso sistemi autonomi. Con questo tipo di connessione, non puoi impostare le priorità di route per le route pubblicizzate da router Cloud al tuo router on-premise. Inoltre, non puoi impostare le priorità di route per le route pubblicizzate dal router on-premise alla rete VPC.

Alcuni prefissi IP on-premise non sono disponibili

Se alcuni prefissi IP on-premise non sono disponibili, controlla le quote e i limiti o controlla gli intervalli di subnet che si sovrappongono.

Controlla le quote e i limiti

Verifica che i router Cloud non abbiano superato i limiti previsti per le route apprese. Per visualizzare il numero di route apprese per un router Cloud, visualizza il suo stato.

Per informazioni sui limiti, sui messaggi di log correlati e sulle metriche, nonché su come risolvere i problemi, consulta la tabella seguente.

Limiti Consulenza
Informazioni sui limiti

Esistono due limiti per i percorsi appresi. Questi limiti non definiscono direttamente un numero massimo di route apprese. ma definiscono il numero massimo di prefissi di destinazione univoci.

  • Il numero massimo di destinazioni univoche per route apprese che può essere applicato a subnet in una determinata area geografica da tutti i router Cloud nella stessa area geografica
  • Il numero massimo di destinazioni univoche per route apprese che può essere applicato a subnet in una determinata area geografica dai router Cloud di aree geografiche diverse

Il primo limite è rilevante indipendentemente dalla modalità di routing dinamico utilizzato dalla rete VPC. Il secondo limite ha senso solo se la rete VPC utilizza la modalità di routing dinamico globale. Per maggiori dettagli sui limiti del router Cloud, vedi Limiti.
Log Se riscontri uno di questi limiti, vedrai un messaggio limit-exceeded in Cloud Logging. Per informazioni su come creare una query avanzata per visualizzare questo messaggio, consulta la relativa query nella documentazione di logging relativa al router Cloud.
Metriche

Puoi anche utilizzare le seguenti metriche per comprendere i limiti e l'utilizzo attuali. Queste metriche sono precedute dal simbolo router.googleapis.com/dynamic_routes/learned_routes/:

  • used_unique_destinations

    Numero di destinazioni univoche attualmente utilizzate in questa rete VPC. Se il routing dinamico globale è abilitato, questa metrica mostra l'utilizzo globale e a livello di area geografica.

  • unique_destinations_limit

    Numero di destinazioni univoche per cui è consentita la pubblicità in questa rete VPC. Se il routing dinamico globale è abilitato, questa metrica mostra sia i limiti globali sia quelli a livello di area geografica.

  • any_dropped_unique_destinations

    Indica se in questa rete VPC sono state eliminate destinazioni a causa del superamento di uno o entrambi i limiti di quota della route.

Queste metriche sono disponibili tramite la risorsa monitorata gce_network_region. Per ulteriori informazioni sulle metriche del router Cloud e su come visualizzarle, consulta la sezione Metriche in Visualizzazione di log e metriche.
Risolvere i problemi

Per risolvere i problemi relativi ai limiti di percorso, puoi procedere come segue. Nei casi in cui il numero di route supera i limiti di una certa quantità, è consigliabile eseguire entrambe le operazioni:

  • Configura i tuoi router on-premise per aggregare le route che esporti in modo da pubblicizzare meno destinazioni (CIDR).
  • Contatta l'assistenza. L'assistenza può aiutarti a reimpostare i router Cloud, se necessario, o per aumentare i limiti.

Verifica gli intervalli di subnet che si sovrappongono

Assicurati che gli intervalli di indirizzi IP per una subnet VPC non si sovrappongano completamente agli annunci di route dalla tua rete on-premise. La sovrapposizione degli intervalli IP può causare l'eliminazione delle route. Questo vale anche per le route statiche personalizzate che si sovrappongono a una route dinamica rilevata da un router Cloud. I prefissi ricevuti dai router Cloud vengono ignorati (non vengono create route dinamiche personalizzate) nei seguenti scenari:

  • Quando il prefisso appreso corrisponde esattamente a un intervallo di indirizzi IP principali o secondari di una subnet nella rete VPC.
  • Quando il prefisso appreso corrisponde esattamente alla destinazione di una route statica personalizzata nella tua rete VPC.
  • Quando il prefisso appreso è più specifico (ha una subnet mask più lunga) rispetto a un intervallo di indirizzi IP principali o secondari di una subnet nella rete VPC.
  • Quando il prefisso appreso è più specifico (con una subnet mask più lunga) rispetto alla destinazione di una route statica personalizzata nella tua rete VPC.

Per ulteriori informazioni, consulta la sezione Applicabilità e ordine delle route nella panoramica delle route VPC.

Le route apprese da una rete on-premise non si propagano ad altre reti VPC

Un singolo router Cloud non può pubblicizzare nuovamente le route apprese da un peer BGP ad altri peer BGP, incluso ai router Cloud in altre reti VPC.

Ad esempio, nella seguente topologia hub e spoke, il router Cloud non può supportare la pubblicità di route tra più reti VPC.

Hub e spoke del router Cloud.
Hub e spoke del router Cloud (fai clic per ingrandire)

Per esaminare i consigli relativi alle topologie di rete in Google Cloud, consulta Best practice e architetture di riferimento per la progettazione di VPC.

Inoltre, per creare e gestire le topologie hub e spoke in Google Cloud, puoi utilizzare il Network Connectivity Center.

I prefissi non vengono importati nelle sessioni BGP (pre-ordine del percorso AS)

La presospensione del percorso AS non è pertinente per il piano di controllo e la rete VPC. La lunghezza del percorso di AS viene considerata all'interno di ciascuna attività software del router Cloud come descritto negli scenari seguenti.

Se una singola attività software del router Cloud apprende la stessa destinazione da due o più sessioni BGP:

  • L'attività software sceglie una sessione BGP dell'hop successivo con la lunghezza del percorso AS più breve.
  • L'attività software invia le informazioni su destinazione, hop successivo e MED al piano di controllo del router Cloud.
  • Il piano di controllo utilizza le informazioni per creare una o più route candidato. La priorità di base di ogni candidato è impostata sul MED ricevuto.

Se due o più attività software del router Cloud apprendono la stessa destinazione da due o più sessioni BGP:

  • Ogni attività software seleziona una sessione BGP dell'hop successivo con la lunghezza del percorso AS più breve.
  • Ogni attività software invia informazioni su destinazione, hop successivo e MED al piano di controllo del router Cloud.
  • Il piano di controllo utilizza le informazioni per creare due o più route candidati. La priorità di base di ogni candidato è impostata sul MED ricevuto.

Il piano di controllo del router Cloud installa quindi una o più route dinamiche personalizzate nella rete VPC, in base alla modalità di routing dinamico della rete VPC. In modalità di routing dinamico globale, la priorità di ogni route dinamica personalizzata viene regolata in aree geografiche diverse da quelle del router Cloud. Per informazioni dettagliate su come Google Cloud seleziona un percorso, consulta la sezione Ordine di routing nella documentazione dei VPC.

In una VM con più NIC, ogni NIC riceve route diverse

Questo è il comportamento previsto. Devi configurare ogni controller di interfaccia di rete (NIC) per una VM multi-NIC in una rete VPC univoca. Ogni router Cloud crea route dinamiche personalizzate in un'unica rete VPC. Pertanto, le route apprese da un router Cloud sono applicabili solo a un'interfaccia di rete di una VM multi-NIC. I pacchetti inviati da un'interfaccia di rete VM utilizzano solo le route applicabili alla rete VPC per tale interfaccia.

Il traffico viene indirizzato in modo asimmetrico

Il traffico viene instradato in modo asimmetrico quando il traffico in entrata e in uscita utilizza percorsi diversi. Ad esempio, potresti avere due tunnel Cloud VPN. Il traffico in uscita dalla rete VPC potrebbe utilizzare il primo tunnel, mentre quello nella rete VPC potrebbe utilizzare il secondo tunnel.

Il routing asimmetrico si verifica quando il percorso preferito pubblicizzato dal router on-premise e dal router Cloud non si allinea. Per il traffico in entrata nella tua rete VPC, utilizza il router Cloud per configurare le priorità dei percorsi pubblicizzati. Per ulteriori informazioni, consulta la sezione Percorsi dinamici personalizzati appresi.

Consulta la documentazione del dispositivo per scoprire come funziona la selezione del percorso migliore di BGP, perché possono essere interessati da altri attributi, come l'ID router o l'ASN origine. Ad esempio, consulta le seguenti risorse:

Per il traffico in uscita dalla rete VPC, controlla le preferenze locali del router o i valori MED del router on-premise.

Il percorso predefinito (0.0.0.0/0 o ::/0) invia il traffico al gateway Internet

Quando crei una rete VPC, Google Cloud crea automaticamente una route predefinita con priorità pari a 1000 il cui hop successivo è il gateway Internet predefinito.

Le route con un hop successivo del gateway Internet predefinito possono essere utilizzate solo da VM che soddisfano i requisiti di accesso a Internet.

L'utilizzo delle route con un hop successivo del gateway Internet predefinito è necessario anche per accedere alle API e ai servizi Google, ad esempio per l'accesso privato Google.

I seguenti esempi descrivono situazioni che possono causare il blocco del traffico su Internet o verso API e servizi Google:

  • Se elimini la route predefinita creata automaticamente (la route con un passaggio successivo del gateway Internet predefinito).
  • Se sostituisci il percorso predefinito creato automaticamente, l'hop successivo del percorso di sostituzione sarà diverso dal gateway Internet predefinito.
  • Se un router Cloud impara una route con destinazione 0.0.0.0/0 o ::/0 che ha una priorità superiore rispetto alla route predefinita creata automaticamente.

L'hop successivo non è chiaro

Per scoprire come funziona l'algoritmo di selezione dei percorsi di Google Cloud, consulta la sezione Applicabilità e ordine nella documentazione relativa ai percorsi dei VPC.

Il traffico IPv6 non viene instradato

Il supporto del router Cloud per IPv6 è in anteprima.

Se hai difficoltà a connetterti a host IPv6, procedi nel seguente modo:

  1. Verifica che le route IPv4 siano pubblicizzate correttamente. Se le route IPv4 non vengono pubblicizzate, esegui le procedure di risoluzione dei problemi generali elencate in questo documento.
  2. Controlla le regole firewall per assicurarti di consentire il traffico IPv6 tra la tua rete VPC e la tua rete on-premise.
  3. Verifica che non siano presenti intervalli di subnet IPv6 sovrapposti nella tua rete VPC e nella tua rete on-premise. Consulta Controllare gli intervalli di subnet sovrapposti.
  4. Determina se hai superato eventuali quote e limiti per i percorsi appresi. Se hai superato la quota per le route apprese, i prefissi IPv6 vengono eliminati prima dei prefissi IPv4. Vedi Controllare le quote e i limiti.
  5. Verifica che tutti i componenti che richiedono la configurazione IPv6 siano stati configurati correttamente.
    • La subnet VPC è configurata in modo da utilizzare il tipo di stack IPV4_IPV6.
    • La subnet VPC è--ipv6-access-typeimpostata su INTERNAL.
    • Le VM di Compute Engine nella subnet sono configurate con indirizzi IPv6.
    • Il gateway VPN ad alta disponibilità è configurato per utilizzare il tipo di stack IPV4_IPV6.
    • Il peer BGP è abilitato per utilizzare IPv6 e gli indirizzi hop successivi IPv6 corretti sono configurati per la sessione BGP.

Passaggi successivi

  • Per ulteriore supporto, consulta la pagina Assistenza.