Virtual Connect bruger en todelt hovedbygning, hvor dirigering- og GRE-kontrolfly leveres af én enhed, og IPS-ec-kontrolflyet leveres af en anden.

Når Virtual Connect-forbindelsen er fuldført , oprettes to GRE over IPS-ec-tunneler mellem kundens virksomhedsnetværk og Cisco's datacentre for dedikeret forekomst. En til hvert redundant datacenter i den respektive region. Yderligere netværkselementer, der kræves til peering, udveksles af partneren eller kunden til Cisco via aktiveringsformularen Control Hub Virtual Connect.

Figur 1 viser et eksempel på installationsmodellen for virtuel tilslutning til valgmuligheden 2-koncentrator på kundesiden.

Virtual Connect – VPN er et hub-design, hvor kundens hub-websteder er forbundet til DC1 og DC2 af datacentre for dedikeret forekomst inden for et bestemt område.

To Hub-steder anbefales for bedre redundans, men One Hub-sted med to tunneler er også en understøttet udrulningsmodel.

Båndbredden pr. tunnel er begrænset til 250 Mbps.

Kundens eksterne websteder inden for samme område skal oprette forbindelse tilbage til Hub-webstedet/webstederne via kundens WAN, og det er ikke Ciscos ansvar for denne forbindelse.

Partnere forventes at arbejde tæt sammen med kunderne, så det sikres, at der vælges den mest optimale vej for serviceområdet "Virtual Connect".

Figur 2 viser peering-regioner for dedikeret forekomst af cloud-forbindelse.

Routing for tilføjelsesprogrammet Virtual Connect implementeres ved hjælp af ekstern BGP (eBGP) mellem dedikeret forekomst og kundens lokale udstyr (CPE). Cisco vil annoncere deres respektive netværk for hvert redundant DC i en region til kundens CPE, og CPE er påkrævet for at annoncere en standardrute til Cisco.

• Cisco vedligeholder og tildeler

  • IP-adresse til tunnelgrænseflade (overgangslink til distribution) Cisco tildeler fra et udpeget delt adresseområde (ikke offentligt distribuerbart)

  • Destinationsadresse for tunneltransport (Ciscos side)

  • Private autonome systemnumre (ASN'er) til konfiguration af BGP-distribution

    • Cisco tildeler fra det angivne private anvendelsesområde: 64512 til 65534

• eBGP, der bruges til at udveksle ruter mellem dedikeret forekomst og CPE

  • Cisco opdeler det tildelte /24-netværk i 2/25 et for hvert DC i det respektive område

  • I Virtual Connect annonceres hvert /25-netværk tilbage til CPE af Cisco via de respektive punkt-til-punkt VPN-tunneler (overgangslink)

  • CPE skal konfigureres med de relevante eBGP-naboer. Hvis der bruges én CPE, bruges to eBGP-naboer, der peger på hver fjerntunnel. Hvis der bruges to CPE, vil hver CPE have en eBGP-nabo, der ponerer til den enkelte fjerntunnel for CPE.

  • Cisco-siden af hver GRE-tunnel (tunnelgrænseflade-IP) konfigureres som BGP-naboen på CPE

  • CPE er påkrævet for at annoncere en standardrute over hver af tunnellerne

  • CPE er ansvarlig for omfordeling efter behov af de lærde ruter i cutomers virksomhedsnetværk.

• Under betingelse af, at forbindelsen ikke mislykkes, vil en enkelt CPE have to aktive/aktive tunneler. For to CPE-knudepunkter vil hver CPE have én aktiv tunnel, og begge CPE-knudepunkter skal være aktive og passere trafik. Under et ikke-fejlslagne scenarie skal trafikken opdeles i to tunneler, der går til de korrekte /25-destinationer, hvis en af tunnelen går ned, kan den resterende tunnel bære trafikken for begge. Under et sådant fejlscenarie, når /25-netværket er nede, bruges /24-netværket som en backup-rute. Cisco sender kundetrafik via sin interne WAN til det DC, der mistede forbindelsen.

Forhandlingerne om IP sec-tunnelen omfatter to faser, IKE v2-fasen og IP-sec-fasen. Hvis forhandlingerne om IKE v2-fasen ikke afsluttes, vil der ikke blive indledt en anden IP-sek-fase. Først skal du udstede kommandoen "vis crypto ikev2 sa" (på Cisco-udstyr) eller lignende kommando på tredjepartsudstyret for at kontrollere, om IKEV2-sessionen er aktiv. Hvis IKE v2-sessionen ikke er aktiv, kan de potentielle årsager være:

• Interessant trafik udløser ikke IP sec-tunnelen.

• IP-sek-tunneladgangslisten er forkert konfigureret.

• Der er ingen forbindelse mellem kunden og IP-sek-tunnelslutpunkt-IP for dedikeret forekomst.

• IKE v2-sessionsparametrene matcher ikke mellem siden dedikeret forekomst og kundesiden.

• En firewall blokerer IKE v2 UDP-pakkerne.

Kontrollér først IP-sec-logfilerne for alle meddelelser, der viser status for IKE v2-tunnelforhandlingerne. Logfilerne kan angive, hvor der er et problem med IKE v2-forhandlingerne. Manglende logføringsmeddelelser kan også indikere, at IKE v2-sessionen ikke aktiveres.

Nogle almindelige fejl i IKE v2-forhandlingerne er:

• Indstillingerne for IKE v2 på CPE-siden stemmer ikke overens med Cisco-siden. Kontrollér de nævnte indstillinger igen:

  • Kontroller, at IKE-versionen er version 2.

  • Kontrollér, at krypterings- og godkendelsesparametrene stemmer overens med den forventede kryptering på siden Dedikeret forekomst.

    Når "GCM"-krypteringen er i brug, håndterer GCM-protokollen godkendelsen og indstiller godkendelsesparameteren til NULL.

  • Bekræft indstillingen for levetid.

  • Bekræft Diffie Hellman modulus-gruppen.

  • Bekræft indstillingerne for pseudo-tilfældig funktion.

• Adgangslisten for krypteringskortet er ikke indstillet til:

  • Tillad GRE (local_tunnel_transport_ip) 255.255.255.255.255 (remote_tunnel_transport_ip) 255.255.255" (eller tilsvarende kommando)

    Adgangslisten skal være specifik for "GRE"-protokollen, og "IP"-protokollen fungerer ikke.

Hvis logmeddelelserne ikke viser nogen forhandlingsaktivitet for IKEV2-fasen, kan det være nødvendigt med en pakkeløsning.

Siden dedikeret forekomst begynder muligvis ikke altid IKEV2-udvekslingen og kan nogle gange forvente, at kunde CPE-siden er initiativtageren. Kontrollér CPE-sidekonfigurationen for følgende forudsætninger for start af IKE v2-sessioner: Kontrollér for en IP-sec-krypto-adgangsliste for GRE-trafik (protokol 50) fra CPE-tunneltransport-IP til den dedikerede forekomst-tunnel-transport-IP. Sørg for, at GRE-tunnelgrænsefladen er aktiveret for GRE-keepalives, hvis udstyret ikke understøtter GRE-keepalives, underrettes Cisco, fordi GRE-keepalives vil blive aktiveret på siden Dedikeret forekomst som standard. Sørg for, at BGP er aktiveret og konfigureret med naboadressen for tunnelen til dedikeret forekomst.

Når den er konfigureret korrekt, starter følgende IP sec-tunnelen og første fase IKE v2-forhandling:

• GRE keepalives fra CPE-side GRE-tunnelgrænsefladen til GRE-tunnelgrænsefladen for dedikeret forekomst-side GRE-tunnel.

• BGP-naboens TCP-session fra CPE-side BGP-naboen til den dedikerede forekomst-side BGP-nabo.

• Ping fra CPE-sidetunnelens IP-adresse til den dedikerede forekomst-sidetunnelens IP-adresse.

  Ping kan ikke være tunnel transport IP til tunnel transport IP, det skal være tunnel IP til tunnel IP.

Hvis der er behov for en pakkestørrelse til IKEV2-trafikken, skal du indstille filteret til UDP og enten port 500 (når ingen NAT-enhed er midt i IP-sek-slutpunkterne) eller port 4500 (når en NAT-enhed er placeret midt i IP-sek-slutpunkterne).

Kontrollér, at IKEV2 UDP-pakker med port 500 eller 4500 sendes og modtages til og fra DI IP-sec-IP-adressen.

Datacenteret for dedikeret forekomst starter muligvis ikke altid den første IKE v2-pakke. Kravet er, at CPE-enheden er i stand til at starte den første IKEV2-pakke mod siden Dedikeret forekomst. Hvis den lokale firewall tillader det, skal du også forsøge at ping til den eksterne IP-sek-adresse. Hvis ping ikke lykkes fra lokal til ekstern IP-sek-adresse, skal du udføre en sporingsrute for at hjælpe og bestemme, hvor pakken skal kasseres. Nogle firewalls og internetudstyr tillader muligvis ikke sporingsrute.

Kontrollér, at IP sec første fase (dvs. IKEV2-sikkerhedstilknytning) er aktiv, før der foretages fejlfinding af IP sec anden fase. Udfør en "vis krypto ikev2 sa" eller tilsvarende kommando for at bekræfte IKE v2-sessionen. Kontrollér, at IKE v2-sessionen har været oppe i mere end et par sekunder, og at den ikke springer ud. Sessionsoptiden vises som sessionen "Aktiv tid" eller tilsvarende i output.

Når IKE v2-sessionen bekræfter at være oppe og aktiv, skal du undersøge IPsek-sessionen. Som med IKE v2-sessionen skal du udføre en "vis krypto ipsec sa" eller tilsvarende kommando for at bekræfte IP-sessionen. Både IKE v2-sessionen og IP sec-sessionen skal være aktiv, før GRE-tunnelen etableres. Hvis IP-sek-sessionen ikke vises som aktiv, skal du kontrollere IP-sek-logfilerne for fejlmeddelelser eller forhandlingsfejl.

Nogle af de mere almindelige problemer, der kan opstå under IP-sec-forhandlingerne, er:

Indstillingerne på CPE-siden stemmer ikke overens med siden Dedikeret forekomst. Kontrollér indstillingerne igen:

• Kontrollér, at parametrene for kryptering og godkendelse stemmer overens med indstillingerne på siden Dedikeret forekomst.

• Bekræft indstillingerne for Perfekt viderestilling af hemmeligholdelse, og at matchindstillingerne på siden Dedikeret forekomst.

• Bekræft livstidsindstillingerne.

• Kontrollér, at IP-sek er konfigureret i tunneltilstand.

• Bekræft kilde- og destinations-IP-sek-adresser.

Når IP-sec- og IKEV2-sessioner bekræftes som op og aktive, kan GRE-tunnelens keepalive-pakker flyde mellem den dedikerede forekomst og CPE-tunnelslutpunkter. Hvis tunnelgrænsefladen ikke viser status, er nogle almindelige problemer:

• Tunnelgrænsefladetransport-VRF matcher ikke VRF'ens VRF for loopback-grænsefladen (hvis der bruges VRF-konfiguration på tunnelgrænsefladen).

  Hvis VRF-konfigurationen ikke bruges på tunnelgrænsefladen, kan denne kontrol ignoreres.

• Keepalives er ikke aktiveret på CPE-sidetunnelgrænsefladen

  Hvis keepalives ikke understøttes på CPE-udstyret, skal Cisco underrettes, så standardkeepaliverne på siden Dedikeret forekomst også deaktiveres. Hvis keepaliverne understøttes, skal du kontrollere, at keepaliverne er aktiveret.

• Masken eller IP-adressen for tunnelgrænsefladen er ikke korrekt og svarer ikke til de forventede værdier for dedikeret forekomst.

• Kilde- eller destinationstunneltransportadressen er ikke korrekt og stemmer ikke overens med de forventede værdier for dedikeret forekomst.

• En firewall blokerer GRE-pakker fra sendt ind i IP sec-tunnelen eller modtaget fra IP sec-tunnelen (GRE-tunnelen transporteres over IP sec-tunnelen)

En ping-test skal kontrollere, at den lokale tunnelgrænseflade er oppe, og at forbindelsen er god til den eksterne tunnelgrænseflade. Udfør ping-kontrollen fra tunnel-IP (ikke transport-IP) til den eksterne tunnel-IP.

Krypteringsadgangslisten for den IP sec-tunnel, der transporterer GRE-tunneltrafikken, tillader kun GRE-pakker at krydse. Som følge heraf vil pings ikke fungere fra tunneltransport-IP til fjerntransport-IP.

Ping-kontrollen resulterer i en GRE-pakke, der genereres fra kildetunneltransport-IP til destinationstunneltransport-IP, mens nyttelasten af GRE-pakken (den indvendige IP) vil være kilde- og destinationstunnelens IP.

Hvis ping-testen ikke lykkes, og de foregående elementer bekræftes, kan det være nødvendigt med en pakkeoptagelse for at sikre, at icmp-ping resulterer i en GRE-pakke, som derefter indlejres i en IP-sec-pakke og derefter sendes fra kilde-IP-sec-adressen til destinations-IP-sec-adressen. Tællere på GRE-tunnelgrænsefladen og IP sec-sessionstællerne kan også hjælpe med at vise. Hvis afsendelses- og modtagelsespakkerne stiger.

Ud over pingetrafikken skal fangsten også vise keepalive GRE-pakker, selv under inaktiv trafik. Hvis BGP er konfigureret, skal BGP keepalive-pakker også sendes som GRE-pakker indkapslet i IPSEC-pakker samt over VPN.

På siden Dedikeret forekomst er to funktioner aktiveret til dynamisk at justere MTU for store pakkestørrelser. GRE-tunnelen tilføjer flere overskrifter til de IP-pakker, der flyder gennem VPN-sessionen. IP sec-tunnelen tilføjer de ekstra overskrifter oven for GRE-overskrifterne vil yderligere reducere den største MTU, der er tilladt over tunnelen.

GRE-tunnelen justerer MSS-funktionen, og GRE-tunnelstien i MTU-registreringsfunktionen er aktiveret på siden Dedikeret forekomst. Konfigurer "ip tcp adjustment-mss 1350" eller tilsvarende kommando samt "tunnelsti\u0002mtu-discovery" eller tilsvarende kommando på kundesiden for at hjælpe med den dynamiske justering af MTU af trafik gennem VPN-tunnelen.