Inleiding

Virtual Connect is een aanvullende invoegoptie voor cloudverbinding met een speciaal exemplaar Webex Calling (speciaal exemplaar). Met Virtual Connect kunnen klanten hun privénetwerk veilig uitbreiden via internet met point-to-point IP VPN-gebruik. Deze verbindingsoptie levert een snelle verbinding van de privénetwerkverbinding met behulp van de bestaande CPE (Customer Premise Equipment) en internetverbinding.

Cisco host, beheert en zorgt voor redundante IP VPN-verbinding en de benodigde internettoegang in de datacenterregio(n) van het speciale exemplaar van Cisco waar de service vereist is. Op dezelfde manier is de beheerder verantwoordelijk voor de bijbehorende CPE- en internetservices, die vereist zijn voor Virtual Connect.

Elke Bestelling voor Virtual Connect in een specifieke speciale instantieregio bevat twee algemene routing-encapssniveaus (GRE) die zijn beveiligd met IPSec-codering (GRE over IPSec), een voor elk cisco-datacenter in de geselecteerde regio.

Virtual Connect heeft een bandbreedtelimiet van 250 Mbps per tunnel en wordt aanbevolen voor kleinere implementaties. Omdat twee point-to-point VPN-verbindingen worden gebruikt, moet al het verkeer naar de cloud via de klantkop cpue lopen. Daarom is het mogelijk niet geschikt voor veel externe sites. Raadpleeg Cloud Connectivity voor andere alternatieve peeringopties .

Voordat u het peering-verzoek voor Virtual Connect verzendt, moet u ervoor zorgen dat de service Dedicated Instance is geactiveerd in de betreffende regio.

Voorwaarden

De vereisten voor het tot stand brengen van Virtual Connect zijn onder andere:

  • Klant levert

    • Internetverbinding met voldoende beschikbare bandbreedte om de implementatie te ondersteunen

    • Openbaar IP-adres(sen) voor twee IPSec-adressen

    • GRE-transport-IP-adressen van klantzijde voor de twee GRE-personen

  • Partner en klant

    • Werk samen om bandbreedtevereisten te evalueren

    • Zorg voor ondersteuning van netwerkapparaat(en) BGP (Border Gateway Protocol) (BGP)-routering en een GRE via IPSec-tunnelontwerp

  • Partner of klant biedt

    • Netwerkteam met kennis van VPN-tunneltechnologieën voor site naar locatie

    • Netwerkteam met kennis van BGP, eBGP en algemene routeringsprincipes

  • Cisco

    • Cisco heeft privé automatische systeemnummers (ASN's) en tijdelijke IP-adressering voor GRE-tunnelinterfaces toegewezen

    • Cisco heeft een openbaar, maar niet internet omkeerbaar C-netwerk (/24) toegewezen voor het oplossen van speciale exemplaar cloud

Als een klant slechts 1 CPE-apparaat heeft, zijn de 2 datacenters (DC1 en DC2) in elke regio van dat CPE-apparaat. De klant heeft ook een optie voor 2 CPE-apparaten. Elk CPE-apparaat moet dan verbinding maken met 1 tunnel alleen in de richting van datacenters van Cisco (DC1 en DC2) in elke regio. Aanvullende redundantie kan worden bereikt door elke tunnel op een afzonderlijke fysieke site/locatie in de infrastructuur van de klant te beëindigen.

Technische details

Implementatiemodel

Virtual Connect maakt gebruik van een headend-architectuur van een dubbele laag, waarbij de routering en GRE-besturing door het ene apparaat worden geleverd en het IPSec-besturingsmodel door een ander apparaat wordt geleverd.

Nadat de Virtual Connect-verbinding is voltooid, wordt twee GRE over IPSec-verbinding gemaakt tussen het bedrijfsnetwerk van de klant en de datacenters van Cisco. Een voor elk redundant datacenter binnen de respectievelijke regio. Aanvullende netwerkelementen die vereist zijn voor peering, worden door de partner of klant uitgewisseld aan Cisco via het Control Hub Virtual Connect-activeringsformulier.

In afbeelding 1 ziet u een voorbeeld van het implementatiemodel voor Virtual Connect voor de twee-opties voor klanten.

Virtuele verbinding : VPN is een hub-ontwerp, waarbij de hub-sites van de klant zijn verbonden met DC1 en DC2 van de datacenters van een speciale instantie binnen een bepaalde regio.

Two Hub-sites worden aanbevolen voor een betere redundantie, maar One Hub-site met twee hub-sites is ook een ondersteund implementatiemodel.

De bandbreedte per tunnel is beperkt tot 250 Mbps.

De externe sites van de klant binnen dezelfde regio, moeten verbinding maken met de Hub-site(s) via WAN van de klant en dit is niet de verantwoordelijkheid van Cisco voor die verbinding.

Van partners wordt verwacht dat ze nauw samenwerken met hun klanten waardoor het meest optimale pad wordt gekozen voor de serviceregio 'Virtual Connect'.

In afbeelding 2 ziet u de Speciale instantie cloudverbindings peeringregio's.

Routering

Routering voor de virtual Connect-invoegkoppeling wordt geïmplementeerd met behulp van externe BGP (eBGP) tussen speciale instantie en de CPE (Customer Premise Equipment). Cisco zal hun respectievelijke netwerk voor elk redundante DC binnen een regio adverteren in de CPE van de klant en de CPE is vereist om een standaardroute naar Cisco te adverteren.

  • Cisco onderhoudt en wijst

    • Tunnel Interface IP-adressering (tijdelijke koppeling voor routering) Die Cisco toewijst vanuit een toegewezen gedeelde adresruimte (niet-openbaar omleidingsbaar)

    • Tunnel transportdeitiatieadres (aan de kant van Cisco)

    • Privé zelfstandige systeemnummers (ASN's) voor BGP-routeringsconfiguratie klant

      • Cisco wijst toe vanuit het toegewezen bereik voor privégebruik: 64512 tot en met 65534

  • eBGP gebruikt om routes uit te wisselen tussen speciale instantie en CPE

    • Cisco zal het toegewezen /24-netwerk opsplitsen in 2 /25 een voor elk DC in de respectievelijke regio

    • In Virtual Connect wordt elk /25-netwerk via de respectievelijk point-to-point VPN - (tijdelijke koppeling) geadverteerd naar CPE door Cisco

    • CPE moet worden geconfigureerd met de juiste eBGP-naburigen. Als u één CPE gebruikt, worden twee eBGP-naburigen gebruikt, een die naar elke externe tunnel wijst. Als u twee CPE gebruikt, heeft elke CPE één eBGP-naburige gebruikers die werken met de enkele externe tunnel voor de CPE.

    • Cisco-zijde van elke GRE-tunnel (tunnel interface IP) wordt geconfigureerd als de BGP-neighbor op de CPE

    • CPE is vereist om een standaardroute te adverteren over elk van de

    • CPE kan indien nodig opnieuw worden verdeeld over de geleerde routes binnen het bedrijfsnetwerk van de netwerkbeheerder.

  • Als de koppeling niet mislukt, heeft één CPE twee actieve/actieve gebruikers. Voor twee CPE-knooppunten heeft elke CPE één actieve tunnel en moeten beide CPE-knooppunten actief zijn en doorgevend verkeer. Bij een niet-storingsscenario moet het verkeer in twee delen als deze naar de juiste /25-bestemmingen gaat. Als een van de tunnel uitgaat, kan de resterende tunnel het verkeer voor beide uitvoeren. Bij een dergelijk storingsscenario wordt het /25-netwerk gebruikt als back-uproute als het /25-netwerk defect is. Cisco zal klantverkeer via de interne WAN naar de DC sturen, waardoor de verbinding is verloren.

Verbindingsproces

De volgende stappen van hoog niveau beschrijven hoe u verbinding met virtuele Connect voor een speciaal exemplaar tot stand kunt brengen.
1

Een bestelling plaatsen in Cisco CCW

2

Virtuele verbinding activeren vanuit Control Hub

3

Cisco voert een netwerkconfiguratie uit

4

Klant voert netwerkconfiguratie uit

Stap 1: CCW-bestelling

Virtual Connect is een invoeg toevoegen voor een speciaal exemplaar in CCW.

1

Navigeer naar de ccw-bestelsite en klik vervolgens op Aanmelden om u aan te melden bij de site:

https://apps.cisco.com/Commerce/guest.
2

Schatting maken.

3

Voeg 'A-FLEX-3' SKU toe.

4

Selecteer Opties bewerken.

5

Selecteer opties en invoegtoepassingen op het abonnementtabblad dat wordt weergegeven.

6

Schakel onder Aanvullende invoegtoepassingen het selectievakje naast 'Virtuele verbinding voor speciaal exemplaar' in. De SKU-naam is 'A-FLEX-DI-VC'.

7

Voer de hoeveelheid en het aantal regio's in waarvoor Virtuele verbinding is vereist.

De hoeveelheid Virtuele verbinding mag niet groter zijn dan het totale aantal regio's dat voor een speciaal exemplaar is aangeschaft. Er is ook slechts één Virtual Connect bestelling toegestaan per regio.
8

Als u tevreden bent met uw selecties, klikt u rechtsboven op de pagina op Verifiëren en opslaan.

9

Klik op Opslaan en doorgaan om uw bestelling te ronden. Uw bestelling is nu definitief bestelen appers in het bestelraster.

Stap 2: Activering van Virtual Connect in Control Hub

1

Meld u aan bij Control Hub https://admin.webex.com/login.

2

Navigeer in het gedeelte Services naar Bellen > Speciale Instacnce > Cloud Connectivity.

3

Op de Virtual Connect-kaart wordt de aangeschafte hoeveelheid Virtual Connect vermeld. De beheerder kan nu op Activeren klikken om de virtuele verbinding te activeren.

Het activeringsproces kan alleen geactiveerd worden door beheerders met de rol 'Klant volledig beheer'. Terwijl een beheerder met de rol 'Alleen-lezenbeheerder' van de klant alleen de status kan bekijken.
4

Wanneer de beheerder op de knop Activeren klikt, wordt het formulier Virtuele verbinding activeren weergegeven voor de beheerder om de technische details van Virtual Connect te verstrekken die vereist zijn voor de peeringconfiguraties aan de kant van Cisco.

Het formulier bevat ook statische informatie aan de kant van Cisco, op basis van de geselecteerde regio. Deze informatie is handig voor klantbeheerders om de CPE te configureren aan hun kant om de verbinding tot stand te laten komen.

  1. IP-adres GRE-tunneltransport: De klant moet de IP-adressen van de klant bij Tunnel Transport leveren en Cisco zal de IP-adressen dynamisch toewijzen zodra de activering is voltooid. De IPSec ACL voor Interessante verkeersinformatie moet het mogelijk maken dat lokale tunneltransport IP/32 wordt gebruikt voor het externe tunneltransport IP/32. De ACL mag ook alleen het GRE IP-protocol opgeven.

    Het door de klant verstrekte IP-adres kan privé of openbaar zijn.

  2. IPSec peers: De klant moet de IPSec Tunnel-bron-IP-adressen leveren en Cisco wijst het IP-adres van de IPSec-bestemming toe. Indien nodig wordt ook de NAT-vertaling van een intern IPSEC-tunneladres naar een openbaar adres ondersteund.

    Het door de klant verstrekte IP-adres moet openbaar zijn.

    Alle andere statische gegevens die in het activeringsscherm worden geleverd, worden de beveiligings- en coderingsnormen van Cisco gevolgd. Deze statische configuratie kan niet worden aangepast of aangepast. Voor verdere ondersteuning met betrekking tot de statische configuraties aan de kant van Cisco, moet de klant contact op met de TAC.
5

Klik op de knop Activeren als alle verplichte velden zijn ingevuld.

6

Nadat het virtuele verbindingsactiveringsformulier is voltooid voor een deelgebaseerde regio, kan de klant het activeringsformulier exporteren vanuit Control Hub, Bellen > Speciaal exemplaar > Cloud Connectivity en op Exportinstellingen klikken.

Vanwege beveiligingsredenen zijn de verificatie en het BGP-wachtwoord niet beschikbaar in het geëxporteerde document, maar kan de beheerder hetzelfde bekijken in Control Hub door op Instellingen weergeven te klikken onder Control Hub, tabblad Calling > Dedicated Instance > Cloud Connectivity.

Stap 3: Cisco voert een netwerkconfiguratie uit

1

Zodra het virtual Connect-activeringsformulier is voltooid, wordt de status bijgewerkt naar De activering die bezig is met bellen > een speciaal exemplaar > Virtual Connect-kaart van de Cloud Connectivity.

2

Cisco voltooit de vereiste configuraties op de zijapparatuur van Cisco binnen 5 werkdagen. Wanneer dit is voltooid, wordt de status bijgewerkt naar 'Geactiveerd' voor die specifieke regio in Control Hub.

Stap 4: Klant voert netwerkconfiguratie uit

De status wordt gewijzigd in 'Geactiveerd' om de klantbeheerder te informeren dat de cisco-zijde van configuraties voor de IP VPN-verbinding is voltooid op basis van de invoer van de klant. Van de klantbeheerder wordt echter verwacht dat hij of zij de configuraties van de CPU's zal voltooien en de verbindingsroutes voor de Virtual Connect-tunnel zal testen om online te zijn. Als de problemen gewoon door de configuratie of verbinding komen, kan de klant contact op nemen met het Cisco TAC voor hulp.

Problemen oplossen

IPsec First Phase (IKEv2-onderhandeling) Probleemoplossing en validatie

De IPsec-tunnelonderhandeling bestaat uit twee fasen: de IKEv2-fase en de IPsec-fase. Als de onderhandeling van de IKEv2-fase niet voltooid is, wordt er geen tweede IPsec-fase gestart. Geef eerst de opdracht 'show crypto ikev2 sa' (op Cisco-apparatuur) of een soortgelijke opdracht op de apparatuur van derden om te controleren of de IKEv2-sessie actief is. Als de IKEv2-sessie niet actief is, kunnen de mogelijke redenen zijn:

  • Interessant verkeer activeert de IPsec-tunnel niet.

  • De IPsec-tunneltoegangslijst is onjuist geconfigureerd.

  • Er is geen verbinding tussen de klant en het eindpunt-IP voor de Dedicated Instance IPsec-tunnel.

  • De IKEv2-sessieparameters komen niet overeen tussen de kant van het toegewezen exemplaar en de kant van de klant.

  • Een firewall blokkeert de IKEv2 UDP-pakketten.

Controleer eerst de IPsec-logboeken op berichten die de voortgang van de IKEv2-tunnelonderhandeling weergeven. De logboeken kunnen aangeven waar er een probleem is met de IKEv2-onderhandeling. Een gebrek aan logboekberichten kan er ook op wijzen dat de IKEv2-sessie niet wordt geactiveerd.

Enkele veelvoorkomende fouten bij de IKEv2-onderhandeling zijn:

  • De instellingen voor de IKEv2 aan de CPE-kant komen niet overeen met de Cisco-kant. Controleer de vermelde instellingen opnieuw:

    • Controleer of de IKE-versie versie 2 is.

    • Controleer of de coderings- en verificatieparameters overeenkomen met de verwachte codering aan de kant van het toegewezen exemplaar.

      Wanneer de GCM-code wordt gebruikt, verwerkt het GCM-protocol de verificatie en wordt de verificatieparameter ingesteld op NULL.

    • Controleer de instelling voor de levensduur.

    • Controleer de modulusgroep Diffie Hellman.

    • Controleer de Pseudo Random-functie-instellingen.

  • De toegangslijst voor de cryptokaart is niet ingesteld op:

    • Vergunning GRE (local_tunnel_transport_ip) 255.255.255.255 remote_tunnel_transport_ip() 255.255.255.255" (of gelijkwaardig commando)

      De toegangslijst moet specifiek voor het "GRE"-protocol zijn en het "IP"-protocol werkt niet.

Als de logboekberichten geen onderhandelingsactiviteit voor de IKEv2-fase weergeven, is mogelijk een pakketopname nodig.

De kant van het toegewezen exemplaar begint mogelijk niet altijd met de IKEv2-uitwisseling en kan soms verwachten dat de CPE-kant van de klant de initiator is.

Controleer de CPE-zijconfiguratie voor de volgende vereisten voor het starten van een IKEv2-sessie:

  • Controleer op een IPsec crypto toegangslijst voor GRE verkeer (protocol 50) van de CPE tunnel transport IP naar de Dedicated Instance tunnel transport IP.

  • Zorg ervoor dat de GRE-tunnelinterface is ingeschakeld voor GRE-keepalives. Als de apparatuur geen GRE-keepalives ondersteunt, wordt Cisco hiervan op de hoogte gesteld omdat GRE-keepalives standaard worden ingeschakeld aan de kant van het toegewezen exemplaar.

  • Zorg ervoor dat BGP is ingeschakeld en geconfigureerd met het naburige adres van de tunnel-IP van het toegewezen exemplaar.

Indien correct geconfigureerd, begint het volgende met de IPsec-tunnel en de eerste fase IKEv2-onderhandeling:

  • GRE-keepalives van de GRE-tunnelinterface van de CPE-kant naar de GRE-tunnelinterface van de kant van het toegewezen exemplaar.

  • BGP-buurman TCP-sessie van de CPE-kant BGP-buurman naar de kant BGP-buurman van het toegewezen exemplaar.

  • Ping van het IP-adres van de CPE-zijtunnel naar het IP-adres van de zijtunnel van het toegewezen exemplaar.

    Ping kan niet het tunneltransport IP naar het tunneltransport IP zijn, het moet tunnel IP naar tunnel IP zijn.

Als er een pakkettracering nodig is voor het IKEv2-verkeer, stelt u het filter in voor UDP en ofwel poort 500 (wanneer er geen NAT-apparaat in het midden van de IPsec-eindpunten staat) of poort 4500 (wanneer een NAT-apparaat in het midden van de IPsec-eindpunten wordt ingevoegd).

Controleer of IKEv2 UDP-pakketten met poort 500 of 4500 worden verzonden en ontvangen van en naar het IP-adres van DI IPsec.

Het datacenter van het toegewezen exemplaar begint mogelijk niet altijd het eerste IKEv2-pakket. De vereiste is dat het CPE-apparaat het eerste IKEv2-pakket kan initiëren naar de kant van het toegewezen exemplaar.

Als de lokale firewall dit toestaat, probeert u ook te pingen naar het externe IPsec-adres. Als het pingen niet lukt van het lokale naar het externe IPsec-adres, voert u een traceringsroute uit om te helpen en bepaalt u waar het pakket wordt verwijderd.

Sommige firewalls en internetapparatuur staan mogelijk geen traceringsroute toe.

Problemen oplossen en valideren in de tweede fase van IPsec (IPsec Negotiation)

Controleer of de eerste fase van IPsec (d.w.z. de IKEv2-beveiligingskoppeling) actief is voordat u problemen met de tweede fase van IPsec oplost. Voer een opdracht 'toon crypto ikev2 sa' of een gelijkwaardige opdracht uit om de IKEv2-sessie te verifiëren. Controleer in de uitvoer of de IKEv2-sessie langer dan een paar seconden actief is geweest en dat deze niet springt. De uptime van de sessie wordt weergegeven als de sessie 'Actieve tijd' of equivalent in de uitvoer.

Zodra de IKEv2-sessie is geverifieerd als actief, Onderzoekt u de IPsec-sessie. Voer, net als bij de IKEv2-sessie, een opdracht 'toon crypto ipsec sa' of een gelijkwaardige opdracht uit om de IPsec-sessie te verifiëren. Zowel de IKEv2-sessie als de IPsec-sessie moeten actief zijn voordat de GRE-tunnel tot stand wordt gebracht. Als de IPsec-sessie niet als actief wordt weergegeven, controleert u de IPsec-logboeken op foutberichten of onderhandelingsfouten.

Enkele van de meest voorkomende problemen die zich tijdens de IPsec-onderhandelingen kunnen voordoen zijn:

De instellingen aan de kant van de CPE komen niet overeen met de kant van het toegewezen exemplaar. Controleer de instellingen opnieuw:

  • Controleer of de coderings- en verificatieparameters overeenkomen met de instellingen aan de kant van het toegewezen exemplaar.

  • Controleer de instellingen voor Perfect Forward Secrecy en controleer of de overeenkomende instellingen aan de kant van het toegewezen exemplaar staan.

  • Controleer de instellingen voor levensduur.

  • Controleer of de IPsec is geconfigureerd in tunnelmodus.

  • Controleer de bron- en bestemmings-IPsec-adressen.

Problemen met tunnelinterface oplossen en valideren

Wanneer de IPsec- en IKEv2-sessies zijn geverifieerd als up en actief, kunnen de GRE-tunnelkeepalive-pakketten stromen tussen de eindpunten van het toegewezen exemplaar en de CPE-tunnel. Als de status van de tunnelinterface niet wordt weergegeven, zijn enkele veelvoorkomende problemen:

  • Het transport-VRF van de tunnelinterface komt niet overeen met de VRF van de loopback-interface (als VRF-configuratie wordt gebruikt op de tunnelinterface).

    Als de VRF-configuratie niet wordt gebruikt in de tunnelinterface, kan deze controle worden genegeerd.

  • Keepalives zijn niet ingeschakeld op de CPE-tunnelinterface aan de zijkant

    Als keepalives niet worden ondersteund op de CPE-apparatuur, moet Cisco een melding ontvangen zodat ook de standaard keepalives aan de kant van het toegewezen exemplaar zijn uitgeschakeld.

    Als keepalives worden ondersteund, controleert u of de keepalives zijn ingeschakeld.

  • Het masker of IP-adres van de tunnelinterface is niet correct en komt niet overeen met de verwachte waarden van het toegewezen exemplaar.

  • Het bron- of bestemmingspunnel-transportadres is niet correct en komt niet overeen met de verwachte waarden van het toegewezen exemplaar.

  • Een firewall blokkeert het verzenden van GRE-pakketten naar de IPsec-tunnel of ontvangen van de IPsec-tunnel (de GRE-tunnel wordt over de IPsec-tunnel vervoerd)

Een ping-test moet controleren of de lokale tunnelinterface goed is en of de verbinding goed is met de externe tunnelinterface. Voer de ping-controle uit vanaf de tunnel IP (niet het transport IP) naar de externe tunnel IP.

Met de crypto-toegangslijst voor de IPsec-tunnel die het GRE-tunnelverkeer vervoert, kunnen alleen GRE-pakketten worden gekruist. Hierdoor zullen pings niet werken van tunnel transport IP naar remote tunnel transport IP.

De pingcontrole resulteert in een GRE-pakket dat wordt gegenereerd van de bron tunnel transport IP naar bestemming tunnel transport IP, terwijl de payload van het GRE-pakket (de binnenste IP) de bron en bestemming tunnel IP zal zijn.

Als de pingtest niet succesvol is en de voorgaande items zijn geverifieerd, kan een pakketopname nodig zijn om ervoor te zorgen dat de icmp ping resulteert in een GRE-pakket dat vervolgens wordt ingekapseld in een IPsec-pakket en vervolgens wordt verzonden van het bron-IPsec-adres naar het bestemmings-IPsec-adres. Tellers op de GRE-tunnelinterface en de IPsec-sessietellers kunnen ook helpen om weer te geven of de pakketten verzenden en ontvangen worden verhoogd.

Naast het pingverkeer moet de opname ook keepalive GRE-pakketten tonen, zelfs bij inactief verkeer. Als ten slotte BGP is geconfigureerd, moeten BGP keepalive-pakketten ook worden verzonden als GRE-pakketten die zijn ingekapseld in IPSEC-pakketten en via de VPN.

BGP-probleemoplossing en validatie

BGP-sessies

BGP is vereist als het routeringsprotocol via de VPN IPsec-tunnel. De lokale BGP-buurman moet een eBGP-sessie organiseren met de BGP-buurman van het toegewezen exemplaar. De IP-adressen van de naburige eBGP zijn dezelfde als de IP-adressen van de lokale en externe tunnel. Controleer eerst of de BGP-sessie actief is en controleer vervolgens of de juiste routes worden ontvangen van het toegewezen exemplaar en of de juiste standaardroute naar het toegewezen exemplaar wordt verzonden.

Als de GRE-tunnel is ingeschakeld, controleert u of er een ping is uitgevoerd tussen de lokale en de externe GRE-tunnel IP. Als de ping succesvol is maar de BGP-sessie niet verschijnt, onderzoek dan het BGP-logboek voor BGP-opmaakfouten.

Enkele van de meest voorkomende problemen bij BGP-onderhandelingen zijn:

  • Het externe AS-nummer komt niet overeen met het AS-nummer dat is geconfigureerd aan de kant van het toegewezen exemplaar. Controleer de AS-configuratie van de naburige instantie opnieuw.

  • Het lokale AS-nummer komt niet overeen met wat de kant van de toegewezen instantie verwacht. Controleer of het lokale AS-nummer overeenkomt met de verwachte parameters voor toegewezen instantie.

  • Een firewall blokkeert dat BGP TCP-pakketten die zijn ingekapseld in GRE-pakketten worden verzonden naar de IPsec-tunnel of worden ontvangen van de IPSEC-tunnel

  • Het IP van de externe BGP-buurman komt niet overeen met het IP van de externe GRE-tunnel.

BGP-route-uitwisseling

Zodra de BGP-sessie voor beide tunnels is geverifieerd, controleert u of de juiste routes worden verzonden en ontvangen van de kant van het toegewezen exemplaar.

De VPN-oplossing voor toegewezen exemplaar verwacht dat er twee tunnels van de kant van de klant/partner worden gemaakt. De eerste tunnel wijst naar het Dedicated Instance-datacenter A en de tweede tunnel naar het Dedicated Instance-datacenter B. Beide tunnels moeten een actieve status hebben en de oplossing vereist een actieve/actieve implementatie. Elk datacenter van een toegewezen exemplaar adverteert de lokale /25-route en een /24-back-uproute. Wanneer u de inkomende BGP-routes controleert vanuit Dedicated Instance, controleert u of de BGP-sessie die is gekoppeld aan de tunnel die naar Dedicated Instance-datacenter A wijst, de lokale route Dedicated Instance A /25 en de back-uproute /24 ontvangt. Zorg er bovendien voor dat de tunnel die naar Dedicated Instance-datacenter B wijst, de lokale route van Dedicated Instance-datacenter B /25 en de back-uproute /24 ontvangt. Houd er rekening mee dat de /24 back-uproute dezelfde route is die wordt geadverteerd vanuit Dedicated Instance-datacenter A en Dedicated Instance-datacenter B.

Redundantie wordt geboden aan een datacenter voor een toegewezen exemplaar als de tunnelinterface naar dat datacenter uitvalt. Als de verbinding met Dedicated Instance-datacenter A wordt verbroken, wordt het verkeer van Dedicated Instance-datacenter B doorgeschakeld naar datacenter A. In dit scenario gebruikt de tunnel naar datacenter B de route datacenter B /25 om het verkeer naar datacenter B te sturen en gebruikt de tunnel naar datacenter B de route back-up /24 om het verkeer via datacenter B naar datacenter A te sturen.

Het is belangrijk dat, wanneer beide tunnels actief zijn, datacenter A-tunnel niet wordt gebruikt om verkeer naar datacenter B te sturen en omgekeerd. Als in dit scenario verkeer wordt verzonden naar datacenter A met een bestemming van datacenter B, stuurt datacenter A het verkeer door naar datacenter B en probeert datacenter B het verkeer via de tunnel van datacenter B terug naar de bron te sturen. Dit zal resulteren in een suboptimale routering en kan ook het verkeer door firewalls breken. Daarom is het belangrijk dat beide tunnels in een actieve/actieve configuratie zijn tijdens normaal bedrijf.

De 0.0.0.0/0-route moet worden geadverteerd van de kant van de klant naar de kant van het datacenter van het toegewezen exemplaar. Meer specifieke routes worden niet geaccepteerd door de kant van het toegewezen exemplaar. Zorg ervoor dat de 0.0.0.0/0-route wordt geadverteerd vanuit zowel de Dedicated Instance-datacenter A-tunnel als de Dedicated Instance-datacenter B-tunnel.

MTU-configuratie

Aan de kant van het toegewezen exemplaar zijn twee functies ingeschakeld om de MTU dynamisch aan te passen voor grote pakketformaten. De GRE-tunnel voegt meer kopteksten toe aan de IP-pakketten die door de VPN-sessie stromen. De IPsec-tunnel voegt de extra kopteksten toe boven op de GRE-kopteksten om de grootste toegestane MTU over de tunnel verder te verminderen.

De GRE-tunnel past de MSS-functie aan en het GRE-tunnelpad in de MTU-detectiefunctie is ingeschakeld aan de kant van het toegewezen exemplaar. Configureer 'ip tcp adjust-mss 1350' of een vergelijkbare opdracht en 'tunnel path\u0002mtu-discovery' of een vergelijkbare opdracht aan de kant van de klant om te helpen bij het dynamisch aanpassen van de MTU van verkeer door de VPN-tunnel.