Introduksjon

Virtual Connect bruker en dual tier headend-arkitektur, der ruting- og GRE-kontrollplanene leveres av én enhet og IPSec-kontrollplanet leveres av en annen.

Etter fullføring av 'Virtual Connect'-tilkoblingen, vil to GRE over IPSec-tunneler bli opprettet mellom kundens bedriftsnettverk og Dedicated Instance Ciscos datasentre. En til hvert redundant datasenter innenfor den respektive regionen. Som nevnt i forutsetningene, vil et /24-nettverk kreves fra partneren eller kunden som skal brukes til å konfigurere Virtual Connect. Ytterligere nettverkselementer som kreves for peering, utveksles av partneren eller kunden til Cisco via aktiveringsskjemaet for Control Hub Virtual Connect.

Figur 1 viser et eksempel på Virtual Connect-implementeringsmodellen for 2-konsentratoralternativet på kundesiden.

Virtual Connect - VPN er en Hub-design, der kundens Hub-sider er koblet til DC1 og DC2 til Dedicated Instances datasentre innenfor en bestemt region.

To Hub-steder anbefales for bedre redundans, men One Hub-nettsted med to tunneler er også en støttet distribusjonsmodell.

Båndbredden per tunnel er begrenset til 250 Mbps.

Kundens eksterne nettsteder innenfor samme region må koble seg tilbake til Hub-nettstedet(e) over kundens WAN, og det er ikke Ciscos ansvar for denne tilkoblingen.

Partnere forventes å jobbe tett med kundene for å sikre at den mest optimale veien velges for tjenesteregionen 'Virtual Connect'.

Figur 2 viser peering-regionene for dedikerte forekomster av skytilkobling.

Ruting for Virtual Connect-tillegget implementeres ved hjelp av ekstern BGP (eBGP) mellom Dedikert Instance og Customer Premise Equipment (CPE). Cisco vil annonsere deres respektive nettverk for hver redundant DC innenfor en region til kundens CPE og CPE er pålagt å annonsere en standardrute til Cisco.

• Cisco vedlikeholder og tildeler

  • Tunnelgrensesnitt IP-adressering (transient link for ruting) Cisco tildeler fra et angitt delt adresseområde (ikke offentlig rutebar)

  • Destinasjonsadresse for tunneltransport (Ciscos side)

  • Private autonome systemnumre (ASN) for kunde BGP-rutingskonfigurasjon

    • Cisco tildeler fra det angitte området for privat bruk: 64512 til 65534

• eBGP brukes til å utveksle ruter mellom Dedicated Instance og CPE

  • Cisco vil dele det tilordnede /24-nettverket i 2/25 én for hver DC i den respektive regionen

  • I Virtual Connect annonseres hvert /25-nettverk tilbake til CPE av Cisco over de respektive punkt-til-punkt VPN-tunnelene (transient link)

  • CPE må konfigureres med de riktige eBGP-naboene. Hvis du bruker én CPE, vil to eBGP-naboer bli brukt, en som peker til hver ekstern tunnel. Hvis du bruker to CPE, vil hver CPE ha en eBGP-nabo som peker til den enkelt eksterne tunnelen for CPE.

  • Cisco-siden av hver GRE-tunnel (tunnelgrensesnitt IP) er konfigurert som BGP-nabo på CPE

  • CPE er påkrevd for å annonsere en standardrute over hver av tunnelene

  • CPE er ansvarlig for å omfordele, etter behov, de lærte rutene innenfor kundens bedriftsnettverk.

• Under feiltilstand i forbindelse med feil, vil en enkelt CPE ha to aktive/aktive tunneler. For to CPE-noder vil hver CPE ha én aktiv tunnel og begge CPE-nodene skal være aktive og passerende trafikk. Under ikke-feil scenario må trafikken dele seg i to tunneler som går til riktige /25 destinasjoner, hvis en av tunnelen går ned, kan den gjenværende tunnelen bære trafikken for begge. Under et slikt feilscenario, når /25-nettverket er nede, brukes /24-nettverket som en backuprute. Cisco vil sende kundetrafikk via sitt interne WAN mot DC som mistet tilkoblingen.