Virtual Connect bruger en headend-arkitektur med to niveauer, hvor routing- og GRE-kontrol planerne leveres af en enhed, og IPsec-kontrolplanet leveres af en anden.

Når Virtual Connec t-forbindelsen er afsluttet, oprettes to GRE over IPsec-tunneler mellem kundens virksomhedsnetværk og Ciscos datacentre med dedikeret instans. Én til hvert redundant datacenter inden for den respektive region. Yderligere netværkselementer, der kræves til peering, udveksles af partneren eller kunden til Cisco via aktiveringsformularen Control Hub Virtual Connect.

Nedenstående figur viser eksemplet på den virtuelle forbindelsesimplementeringsmodel for 2-koncentratorindstillingen på kundesiden.

Virtual Connect - VPN er et hub-design, hvor kundens hub-websteder er forbundet til DC1 og DC2 i Dedicated Instances datacentre inden for en bestemt region.

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

Partnere forventes at arbejde tæt sammen med kunderne for at sikre, at den mest optimale vej vælges til Virtual Connect- serviceområdet.

Nedenstående figur viser peeringsområderne for cloudforbindelse med dedikerede instanser.

Routing for Virtual Connect-tilføjelsen implementeres ved hjælp af ekstern BGP (eBGP) mellem Dedicated Instance og Customer Premise Equipment (CPE). Cisco vil annoncere deres respektive netværk for hver redundant DC inden for en region til kundens CPE, og CPE er forpligtet til at annoncere en standardrute til Cisco.

• Cisco vedligeholder og tildeler

  • Tunnelgrænseflade IP-adressering (transient link til routing) Cisco tildeler fra et udpeget delt adresseområde (ikke-offentligt routbart)

  • Adresse til tunneltransport (Ciscos side)

  • Private autonome systemnumre (ASN'er) til kundens BGP-routingkonfiguration

    • Cisco tildeler fra det udpegede område til privat brug: 64512 til 65534

• EBGP bruges til at udveksle ruter mellem Dedicated Instance og CPE

  • Cisco opdeler det tildelte /24-netværk i 2/25 et for hver DC i den respektive region

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

  • CPE skal konfigureres med de relevante EBgP-naboer. Hvis du bruger en CPE, bruges to eBgP-naboer, hvoraf en peger på hver fjerntunnel. Hvis du bruger to CPE, vil hver CPE have en eBgP-nabo, der peger på den enkelte fjerntunnel til CPE.

  • Cisco-siden af hver GRE-tunnel (tunnelgrænseflade IP) er konfigureret som BGP-nabo på CPE

  • CPE er forpligtet til at annoncere en standardrute over hver af tunnelerne

  • CPE er ansvarlig for omfordeling, efter behov, de indlærte ruter inden for kundens virksomhedsnetværk.

• Hvis forbindelsen ikke svigter, vil en enkelt CPE have to aktive/aktive tunneler. For to CPE-noder vil hver CPE have en aktiv tunnel, og begge CPE-noder skal være aktive og passere trafik. I tilfælde af ikke-svigt scenarie skal trafikken deles i to tunneler, der går til de korrekte /25 destinationer, hvis en af tunnelerne går ned, kan den resterende tunnel bære trafikken for begge. Under et sådant fejlscenario, når /25-netværket er nede, bruges /24-netværket som en backup-rute. Cisco sender kundetrafik via sit interne WAN til DC, der mistede forbindelsen.

IPsec-tunnelforhandlingen involverer to faser, IKEv2-fasen og IPsec-fasen. Hvis IKEv2-faseforhandlingen ikke fuldføres, er der ingen igangsættelse af en anden IPsec-fase. Udsted først kommandoen „vis crypto ikev2 sa“ (på Cisco-udstyr) eller lignende kommando på tredjepartsudstyret for at kontrollere, om IKEv2-sessionen er aktiv. Hvis IKEv2-sessionen ikke er aktiv, kan de potentielle årsager være:

• Interessant trafik udløser ikke IPsec-tunnelen.

• IPsec-tunneladgangslisten er forkert konfigureret.

• Der er ingen forbindelse mellem kunden og IPsec-tunnelslutpunkts-IP-adressen for dedikeret instans.

• IKEv2-sessionsparametrene stemmer ikke overens mellem siden Dedikeret Instans og kundesiden.

• En firewall blokerer IKEv2 UDP-pakkerne.

Kontroller først IPsec-logfilerne for meddelelser, der viser forløbet af IKEv2-tunnelforhandlingen. Logfilerne kan indikere, hvor der er et problem med IKEv2-forhandlingen. Manglende logningsmeddelelser kan også indikere, at IKEv2-sessionen ikke aktiveres.

Nogle almindelige fejl med IKEv2-forhandlingen er:

• Indstillingerne for IKEv2 på CPE-siden stemmer ikke overens med Cisco-siden, kontroller de nævnte indstillinger igen:

  • Kontroller, at IKE-versionen er version 2.

  • Kontroller, 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.

  • Kontroller levetidsindstillingen.

  • Bekræft Diffie Hellman-modulusgruppen.

  • Bekræft indstillingerne for Pseudo Random Function.

• Adgangslisten for kryptokortet er ikke indstillet til:

  • Tilladelse GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (eller tilsvarende kommando)

    Adgangslisten skal være specifikt til „GRE“ -protokollen, og „IP“ -protokollen fungerer ikke.

Hvis logmeddelelserne ikke viser nogen forhandlingsaktivitet for IKEv2-fasen, kan en pakkeindsamling være nødvendig.

Når den er konfigureret korrekt, starter følgende IPsec-tunnelen og IKEv2-forhandlingen i første fase:

• GRE holder fra GRE-tunnelgrænsefladen på CPE-siden til GRE-tunnelgrænsefladen på dedikeret instans.

• BGP-nabo-TCP-session fra CPE-siden BGP-nabo til BGP-nabo på Dedikeret Instance side.

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

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

Hvis der er brug for en pakkesporing til IKEv2-trafikken, skal du indstille filteret for UDP og enten port 500 (når der ikke er nogen NAT-enhed midt i IPsec-slutpunkterne) eller port 4500 (når en NAT-enhed indsættes midt i IPsec-slutpunkterne).

Kontroller, at IKEv2 UDP-pakker med port 500 eller 4500 sendes og modtages til og fra DI IPsec-IP-adressen.

Kontroller, at IPsecs første fase (dvs. IKEv2-sikkerhedstilknytningen) er aktiv, før du foretager fejlfinding i anden fase af IPsec. Udfør en „show crypto ikev2 sa“ eller tilsvarende kommando for at bekræfte IKEv2-sessionen. I output skal du kontrollere, at IKEv2-sessionen har været oppe i mere end et par sekunder, og at den ikke hopper. Sessionens oppetid vises som sessionen „Aktiv tid“ eller tilsvarende i output.

Når IKEv2-sessionen er bekræftet som aktiv, skal du undersøge IPsec-sessionen. Som med IKEv2-sessionen skal du udføre en „show crypto ipsec sa“ eller tilsvarende kommando for at bekræfte IPsec-sessionen. Både IKEv2-sessionen og IPsec-sessionen skal være aktive, før GRE-tunnelen etableres. Hvis IPsec-sessionen ikke vises som aktiv, skal du kontrollere IPsec-logfilerne for fejlmeddelelser eller forhandlingsfejl.

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

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

• Kontroller, at krypterings- og godkendelsesparametrene stemmer overens med indstillingerne på siden Dedikeret forekomst.

• Kontroller indstillingerne for Perfect Forward Secrecy, og at indstillingerne matcher på siden Dedikeret forekomst.

• Kontroller levetidsindstillingerne.

• Kontroller, at IPsec er konfigureret i tunneltilstand.

• Bekræft kilde- og destinations-IPsec-adresserne.

Når IPsec- og IKEv2-sessionerne verificeres som oppe og aktive, kan GRE-tunnelens keepalive-pakker flyde mellem Dedicated Instance og CPE-tunnelslutpunkterne. Hvis tunnelgrænsefladen ikke viser status, er nogle almindelige problemer:

• VRF for tunnelgrænsefladetransport svarer ikke til VRF'en for loopback-grænsefladen (hvis VRF-konfiguration anvendes 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å standard keepalives på siden med dedikeret forekomst også er deaktiveret.

  Hvis keepalives understøttes, skal du kontrollere, at keepalives er aktiveret.

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

• Kilde- eller destinationstunneltransportadressen er ikke korrekt og svarer ikke til de forventede værdier for dedikeret instans.

• En firewall blokerer GRE-pakker fra at blive sendt ind i IPsec-tunnelen eller modtaget fra IPsec-tunnelen (GRE-tunnelen transporteres over IPsec-tunnelen)

En ping-test skal kontrollere, at den lokale tunnelgrænseflade er oppe, og forbindelsen er god til fjerntunnelgrænsefladen. Udfør ping-kontrollen fra tunnelens IP (ikke transport-IP) til fjerntunnelens 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 emner verificeres, kan det være nødvendigt med en pakkeoptagelse for at sikre, at icmp-ping resulterer i en GRE-pakke, som derefter indkapsles i en IPsec-pakke og derefter sendes fra kilde-IPsec-adressen til destinationens IPsec-adresse. Tællere på GRE-tunnelgrænsefladen og IPsec-sessionstællerne kan også hjælpe med at vise. hvis send- og modtagepakkerne øges.

Ud over ping-trafikken skal optagelsen også vise keepalive GRE-pakker selv under inaktiv trafik. Endelig, hvis BGP er konfigureret, skal BGP keepalive-pakker også sendes som GRE-pakker indkapslet i IPSEC-pakker såvel over VPN.

På siden Dedicated Instance er to funktioner aktiveret til dynamisk at justere MTU til store pakkestørrelser. GRE-tunnelen tilføjer flere overskrifter til IP-pakkerne, der strømmer gennem VPN-sessionen. IPsec-tunnelen tilføjer de ekstra overskrifter oven på GRE-overskrifterne, hvilket yderligere reducerer den største tilladte MTU over tunnelen.

GRE-tunnelen justerer MSS-funktionen, og GRE-tunnelbanen i MTU-opdagelsesfunktionen er aktiveret på siden Dedicated Instance. Konfigurer „ip tcp just-mss 1350" eller tilsvarende kommando samt „tunnel path\ u0002mtu-discovery“ eller tilsvarende kommando på kundesiden for at hjælpe med den dynamiske justering af MTU af trafik gennem VPN-tunnelen.