De optie Virtual Connect helpt om hun privénetwerk veilig via internet uit te breiden met behulp van point-to-point IP VPN -tunnels.
Inleiding
Virtual Connect is een extra add-on onoptie voor Cloud Connectivity to Dedicated Instance for Webex Calling (Dedicated Instance). Met Virtual Connect kunnen klanten hun privénetwerk veilig uitbreiden via internet met behulp van punt-naar-punt IP VPN -tunnels. Met deze verbindingsoptie kunt u snel een privénetwerkverbinding tot stand brengen door gebruik te maken van de bestaande Customer Premise Equipment (CPE) en internetverbinding.
Cisco host, beheert en verzekert redundante IP VPN -tunnels en de vereiste internettoegang in de datacenterregio('s) van Cisco's Dedicated Instance waar de service vereist is. Evenzo is de beheerder verantwoordelijk voor de bijbehorende CPE- en internetservices die vereist zijn voor het tot stand brengen van Virtual Connect.
Elke Virtual Connect-order in een bepaalde toegewezen instantieregio bevat twee GRE-tunnels (generic Routing Encapsulation) die worden beschermd door IPSec -codering (GRE via IPSec), één naar elk Cisco-datacenter in de geselecteerde regio.
Virtual Connect heeft een bandbreedtelimiet van 250 Mbps per tunnel en wordt aanbevolen voor kleinere implementaties. Aangezien er twee punt-naar-punt- VPN -tunnels worden gebruikt, moet al het verkeer naar de cloud via de CPE van het kopstation van de klant gaan. Daarom is het mogelijk niet geschikt als er veel externe sites zijn. Voor andere alternatieve peeringopties raadpleegt u Cloudconnectiviteit .
 |
Voordat u het peeringverzoek voor Virtual Connect indient, moet u ervoor zorgen dat de toegewezen exemplaarservice in die respectieve regio is geactiveerd. |
Voorwaarden
De vereisten voor het tot stand brengen van Virtual Connect zijn onder meer:
Klant biedt
Internetverbinding met voldoende beschikbare bandbreedte om de implementatie te ondersteunen
Openbaar IP-adres(sen) voor twee IPSec -tunnels
GRE-transport- IP -adressen aan de kant van de klant voor de twee GRE-tunnels
Partner en klant
Werk samen om de bandbreedtevereisten te evalueren
Zorg ervoor dat netwerkapparaat(en) Border Gateway Protocol (BGP)-routering en een GRE over IPSec tunnelontwerp ondersteunen
Partner of klant biedt
Netwerkteam met kennis van site-to-site VPN -tunneltechnologieën
Netwerkteam met kennis van BGP, eBGP en algemene routeringsprincipes
Cisco
Door Cisco toegewezen privé-autonome systeemnummers (ASN's) en tijdelijke IP -adressering voor GRE-tunnelinterfaces
Cisco heeft een openbaar maar niet via internet routeerbaar klasse C (/24) netwerk toegewezen voor cloudadressering van een specifiek exemplaar
|
Als een klant slechts één CPE-apparaat heeft, zijn de twee tunnels naar de datacenters van Cisco (DC1 en DC2) in elke regio afkomstig van dat CPE-apparaat. De klant heeft ook een optie voor 2 CPE-apparaten, waarna elk CPE-apparaat verbinding moet maken met slechts één tunnel naar Cisco's datacenters (DC1 en DC2) in elke regio. Extra redundantie kan worden bereikt door elke tunnel te beëindigen op een afzonderlijke fysieke locatie/locatie binnen de infrastructuur van de klant. |
Technische details
Implementatiemodel
Virtual Connect maakt gebruik van een dual-tier headend-architectuur, waarbij de routerings- en GRE-besturingsvlakken worden geleverd door het ene apparaat en het IPSec -besturingsvlak wordt geleverd door een ander apparaat.
Na voltooiing van de Virtuele verbinding connectiviteit, worden er twee GRE over IPSec -tunnels gemaakt tussen het bedrijfsnetwerk van de klant en de datacenters van Cisco voor toegewezen instanties. Eén voor elk redundant datacenter binnen de respectieve regio. Aanvullende netwerkelementen die nodig zijn voor de peering, worden door de partner of klant uitgewisseld met Cisco via het activeringsformulier van Control Hub Virtual Connect.
Afbeelding 1 toont een voorbeeld van het Virtual Connect implementatiemodel voor de optie met 2 concentrators aan de kant van de klant.
Virtuele verbinding - VPN is een hub-ontwerp, waarbij de hubsites van de klant zijn verbonden met DC1 en DC2 van de datacenters van een toegewezen exemplaar binnen een bepaalde regio.
Twee hubsites worden aanbevolen voor betere redundantie, maar één hubsite met twee tunnels is ook een ondersteund implementatiemodel.
|
De bandbreedte per tunnel is beperkt tot 250 Mbps. |
 |
De externe sites van de klant binnen dezelfde regio moeten opnieuw verbinding maken met de hubsite(s) via het WAN van de klant. Cisco is niet verantwoordelijk voor die verbinding. |
Van partners wordt verwacht dat ze nauw samenwerken met de klanten om ervoor te zorgen dat het meest optimale pad wordt gekozen voor de serviceregio 'Virtual Connect'.
In afbeelding 2 ziet u de peeringregio's voor cloudconnectiviteit voor specifieke instanties.
Routing
Routering voor de add-on Virtual Connect wordt geïmplementeerd met behulp van externe BGP (eBGP) tussen een toegewezen exemplaar en de Customer Premise Equipment (CPE). Cisco adverteert hun respectieve netwerk voor elke redundante DC binnen een regio aan de CPE van de klant en de CPE moet een standaardroute naar Cisco adverteren.
Cisco onderhoudt en wijst toe
Tunnelinterface IP -adressering (tijdelijke koppeling voor routering) Cisco wijst toe vanuit een aangewezen gedeelde adresruimte (niet-openbaar routeerbaar)
Bestemmingsadres voor tunneltransport (zijde van Cisco)
Privé-autonome systeemnummers (ASN's) voor de BGP-routeringsconfiguratie van de klant
Cisco wijst het volgende toe uit het opgegeven bereik voor privégebruik: 64512 tot en met 65534
eBGP gebruikt om routes uit te wisselen tussen toegewezen exemplaar en CPE
Cisco splitst het toegewezen /24-netwerk in 2/25 één voor elke DC in de respectieve regio
In Virtual Connect wordt elk /25-netwerk terug geadverteerd naar CPE door Cisco via de respectieve punt-naar-punt VPN -tunnels (tijdelijke koppeling)
CPE moet worden geconfigureerd met de juiste eBGP-buren. Als u één CPE gebruikt, worden er twee eBGP-buren gebruikt, waarbij één naar elke externe tunnel wijst. Als u twee CPE's gebruikt, heeft elke CPE één eBGP-buur die naar de enkele externe tunnel voor de CPE verwijst.
Cisco -zijde van elke GRE-tunnel (tunnelinterface IP) is geconfigureerd als de BGP-buur op de CPE
CPE is vereist om een standaardroute over elk van de tunnels te adverteren
CPE is verantwoordelijk voor het zo nodig herdistribueren van de geleerde routes binnen het bedrijfsnetwerk van de klant.
Bij een niet-failure verbindingsfout heeft één CPE twee actieve/actieve tunnels. Voor twee CPE-knooppunten heeft elke CPE één actieve tunnel en beide CPE-knooppunten moeten actief zijn en verkeer doorgeven. In het scenario zonder storing moet het verkeer worden opgesplitst in twee tunnels die naar de juiste /25-bestemmingen gaan. Als een van de tunnels uitvalt, kan de resterende tunnel het verkeer voor beide vervoeren. In een dergelijk storingsscenario wordt het /24-netwerk gebruikt als een back-uproute wanneer het /25-netwerk niet beschikbaar is. Cisco stuurt klantverkeer via het interne WAN naar de DC die de verbinding heeft verbroken.
Verbindingsproces
| 1 | |
| 2 | |
| 3 | |
| 4 |
Stap 1: CCW-bestelling
Virtual Connect is een add-on voor een toegewezen exemplaar in CCW.
| 1 | Navigeer naar de CCW-bestelsite en klik vervolgens op Aanmelden om u aan te melden bij de site: |
||
| 2 | Schatting maken. |
||
| 3 | Voeg 'A-FLEX-3'-SKU toe. |
||
| 4 | Selecteer Opties bewerken. |
||
| 5 | Selecteer Opties en invoegtoepassingen op het tabblad Abonnement dat wordt weergegeven. |
||
| 6 | Schakel onder Aanvullende invoegtoepassingen het selectievakje naast 'Virtual Connect voor toegewezen exemplaar' in. De SKU-naam is 'A-FLEX-DI-VC'. |
||
| 7 | Voer het aantal en het aantal regio's in waarin Virtual Connect vereist is.
|
||
| 8 | Als u tevreden bent met uw selecties, klikt u op Verifiëren en opslaan in de rechterbovenhoek van de pagina. |
||
| 9 | Klik op Opslaan en doorgaan om uw bestelling te voltooien. Uw voltooide bestelling wordt nu weergegeven in het bestelraster. |
Stap 2: Activering van Virtual Connect in Control Hub
| 1 | Aanmelden bij Control Hubhttps://admin.webex.com/login . |
||||||||
| 2 | In de Services sectie, navigeer naar Bellen > Toegewezen instantie > Cloudconnectiviteit . |
||||||||
| 3 | Op de Virtual Connect-kaart wordt het gekochte aantal Virtual Connect weergegeven. De beheerder kan nu klikken op Activeren om de activering van Virtual Connect te starten. 
|
||||||||
| 4 | Als u op de klikt Activeren knop, Virtuele verbinding activeren Het formulier wordt weergegeven zodat de beheerder de technische details van Virtual Connect kan verstrekken die nodig zijn voor de peeringconfiguraties aan de kant van Cisco.
|
||||||||
| 5 | Klik op de Activeren zodra alle verplichte velden zijn ingevuld. |
||||||||
| 6 | Nadat het activeringsformulier voor Virtual Connect is ingevuld voor een bepaalde regio, kan de klant het activeringsformulier exporteren vanuit Control Hub, Bellen > Toegewezen exemplaar > tabblad Cloudverbinding en op Instellingen exporteren klikken. 
|
Stap 3: Cisco voert netwerkconfiguratie uit
| 1 | Zodra het formulier Virtual Connect-activering is ingevuld, wordt de status bijgewerkt naar: Actieve activering in Bellen > Toegewezen exemplaar > Cloud Connectivity Virtual Connect-kaart. |
| 2 | Cisco voltooit de vereiste configuraties op de zijapparatuur van Cisco binnen 5 werkdagen . Na succesvolle voltooiing 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-configuraties voor de IP VPN -verbinding zijn voltooid op basis van de invoer die door de klant is verstrekt. Maar van de klantbeheerder wordt verwacht dat hij zijn kant van de configuraties op de CPE's voltooit en de verbindingsroutes test voor de Virtual Connect-tunnel om online te zijn. Als er problemen optreden tijdens de configuratie of verbinding, kan de klant contact opnemen met Cisco TAC voor hulp. |
Probleemoplossing
Eerste fase IPsec (IKEv2-onderhandeling) Problemen oplossen en valideren
De IPsec-tunnelonderhandeling omvat twee fasen: de IKEv2-fase en de IPsec-fase. Als de onderhandeling van de IKEv2-fase niet wordt voltooid, wordt er geen tweede IPsec-fase gestart. Geef eerst de opdracht "show crypto ikev2 sa" (op Cisco -apparatuur) of een vergelijkbare opdracht op de apparatuur van derden om te controleren of de IKEv2-sessie actief is. Als de IKEv2-sessie niet actief is, kunnen de volgende redenen zijn:
Interessant verkeer activeert de IPsec-tunnel niet.
De toegangslijst voor de IPsec-tunnel is onjuist geconfigureerd.
Er is geen verbinding tussen de klant en het IPsec - tunneleindpunt - IP van het toegewezen exemplaar .
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. Als er geen logboekberichten zijn, kan dit er ook op wijzen dat de IKEv2-sessie niet wordt geactiveerd.
De instellingen voor de IKEv2 aan de CPE-zijde komen niet overeen met de Cisco -zijde. Controleer de genoemde instellingen opnieuw:
Controleer of de IKE-versie versie 2 is.
Controleer of de parameters voor versleuteling en verificatie overeenkomen met de verwachte versleuteling aan de kant van het toegewezen exemplaar.
Wanneer de 'GCM'-codering in gebruik is, verwerkt het GCM-protocol de verificatie en stelt u de verificatieparameter in op NULL.
Controleer de instelling voor de levensduur.
Controleer de Diffie Hellman-modulusgroep.
Controleer de instellingen voor de pseudo-willekeurige functie.
De toegangslijst voor de cryptokaart is niet ingesteld op:
GRE toestaan (local_tunnel_transport_ip ) 255.255.255.255 (remote_tunnel_transport_ip ) 255.255.255.255" (of een gelijkwaardige opdracht)
De toegangslijst moet specifiek voor het 'GRE'-protocol zijn en het ' IP'-protocol werkt niet.
Als de logboekberichten geen onderhandelingsactiviteiten voor de IKEv2-fase weergeven, is mogelijk een pakketopname vereist.
|
De kant van de toegewezen instantie start mogelijk niet altijd de IKEv2-uitwisseling en kan soms verwachten dat de CPE-kant van de klant de initiator is. Controleer de configuratie aan de CPE-zijde voor de volgende vereisten voor het starten van een IKEv2-sessie:
|
Als dit correct is geconfigureerd, wordt het volgende gestart met de IPsec-tunnel en de IKEv2-onderhandeling in de eerste fase:
GRE houdt alives van de GRE-tunnelinterface aan de CPE-zijde naar de GRE-tunnelinterface aan de kant van de toegewezen instantie.
BGP-buur- TCP -sessie van de BGP-buur aan de CPE-zijde naar de BGP-buur aan de kant van het toegewezen exemplaar.
Ping vanaf het IP-adres van de CPE-tunnel naar het IP-adres IP-adres van de zijtunnel van het toegewezen exemplaar.
Ping kan niet het IP-adres van het tunneltransport naar het transport- IP van de tunnel zijn. Het moet het IP - IP IP .
Als een pakkettracering nodig is voor het IKEv2-verkeer, stelt u het filter in voor UDP en poort 500 (wanneer zich geen NAT-apparaat in het midden van de IPsec-eindpunten bevindt) of poort 4500 (wanneer een NAT-apparaat in het midden van de eindpunten).
Controleer of IKEv2 UDP -pakketten met poort 500 of 4500 worden verzonden en ontvangen van en naar het DI IPsec IP-adres.
|
Het datacenter van het toegewezen exemplaar begint mogelijk niet altijd met het eerste IKEv2-pakket. De vereiste is dat het CPE-apparaat het eerste IKEv2-pakket naar de kant van het toegewezen exemplaar kan starten. Als de lokale firewall dit toestaat, probeert u ook een ping uit te voeren naar het externe IPsec-adres. Als de ping van het lokale naar het externe IPsec-adres niet lukt, voert u een traceerroute uit om te helpen bepalen waar het pakket wordt neergezet. Sommige firewalls en internetapparatuur staan mogelijk geen traceerroute toe. |
Tweede fase IPsec (IPsec-onderhandeling) Problemen oplossen en valideren
Controleer of de eerste fase van IPsec (dat wil zeggen de IKEv2-beveiligingskoppeling) actief is voordat u problemen met de tweede fase van IPsec oplost. Voer de opdracht 'show crypto ikev2 sa' of een vergelijkbare opdracht uit om de IKEv2-sessie te verifiëren. Controleer in de uitvoer of de IKEv2-sessie al meer dan een paar seconden actief is en niet stuitert. De uptime van de sessie wordt weergegeven als de sessie 'Actieve tijd' of een equivalent daarvan in de uitvoer.
Zodra de IKEv2-sessie is geverifieerd als actief en actief, onderzoekt u de IPsec-sessie. Voer, net als bij de IKEv2-sessie, de opdracht 'show crypto ipsec sa' of een vergelijkbare 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 kunnen optreden tijdens de IPsec-onderhandelingen 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 parameters voor versleuteling en verificatie overeenkomen met de instellingen aan de kant van het toegewezen exemplaar.
Controleer of de instellingen voor Perfect Forward Secrecy overeenkomen met de instellingen aan de kant van de toegewezen instantie.
Controleer de instellingen voor de levensduur.
Controleer of de IPsec is geconfigureerd in de tunnelmodus.
Controleer de bron- en doel-IPsec-adressen.
Problemen met de tunnelinterface oplossen en valideren
Wanneer de IPsec- en IKEv2-sessies zijn geverifieerd als actief en actief, kunnen de keepalive-pakketten van de GRE-tunnel tussen het toegewezen exemplaar en de CPE-tunneleindpunten stromen. Als de status van de tunnelinterface niet wordt weergegeven, zijn enkele veelvoorkomende problemen:
De 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 op de tunnelinterface, kan deze controle worden genegeerd.
Keepalives zijn niet ingeschakeld op de CPE-zijtunnelinterface
Als keepalives niet worden ondersteund op de CPE-apparatuur, moet Cisco hiervan op de hoogte worden gebracht, zodat de standaard keepalives aan de kant van het toegewezen exemplaar ook worden uitgeschakeld.
Als keepalives worden ondersteund, controleert u of de keepalives zijn ingeschakeld.
Het masker of het IP-adres van de tunnelinterface is niet correct en komt niet overeen met de verwachte waarden van het toegewezen exemplaar.
Het transportadres van de bron- of bestemmingstunnel is niet correct en komt niet overeen met de verwachte waarden van het toegewezen exemplaar.
Een firewall blokkeert GRE-pakketten die naar de IPsec-tunnel worden verzonden of vanuit de IPsec-tunnel worden ontvangen (de GRE-tunnel wordt via de IPsec-tunnel getransporteerd)
Een ping-test moet controleren of de lokale tunnelinterface actief is en dat de verbinding met de externe tunnelinterface goed is. Voer de pingcontrole uit vanaf het tunnel- IP (niet het transport IP) naar het externe tunnel- IP.
|
De toegangslijst voor de IPsec-tunnel die het GRE-tunnelverkeer vervoert, staat alleen GRE-pakketten toe. Als gevolg hiervan werken pings niet van het IP -adres voor tunneltransport naar het IP -adres voor extern tunneltransport. |
De pingcontrole resulteert in een GRE-pakket dat wordt gegenereerd van het transport- IP van de brontunnel naar het transport- IP van de bestemmingstunnel, terwijl de payload van het GRE-pakket (het binnen- IP) het bron- en bestemmingstunnel- IP is.
Als de ping-test niet is gelukt en de voorgaande items zijn geverifieerd, is mogelijk een pakketopname vereist 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 vanaf het IPsec-bronadres naar het doel-IPsec-adres. Tellers op de GRE-tunnelinterface en de IPsec-sessietellers kunnen ook helpen om weer te geven. als de verzend- en ontvangstpakketten toenemen.
Naast het ping-verkeer moet de opname ook keepalive GRE-pakketten weergeven, zelfs tijdens inactief verkeer. Als BGP is geconfigureerd, moeten BGP-keeppakketten ook worden verzonden als GRE-pakketten die zijn ingekapseld in IPSEC-pakketten en via de VPN.
Problemen met BGP oplossen en valideren
BGP-sessies
BGP is vereist als routeringsprotocol via de VPN IPsec-tunnel. De lokale BGP-buur moet een eBGP-sessie tot stand brengen met de BGP-buur van het toegewezen exemplaar. De eBGP-buur- IP -adressen zijn hetzelfde als de IP -adressen van de lokale en externe tunnel. Zorg er eerst voor dat 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 actief is, controleert u of een ping is geslaagd tussen het lokale en het externe IP-adres van de GRE-tunnel. Als de ping is gelukt maar de BGP-sessie niet wordt gestart, onderzoekt u het BGP-logboek op fouten bij het tot stand brengen van BGP.
Enkele van de meest voorkomende problemen met BGP-onderhandeling 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 AS opnieuw.
Het lokale AS-nummer komt niet overeen met wat de kant van het toegewezen exemplaar verwacht. Controleer of het lokale AS-nummer overeenkomt met de verwachte parameters van het toegewezen exemplaar.
Een firewall verhindert dat BGP TCP -pakketten die zijn ingekapseld in GRE-pakketten, worden verzonden naar de IPsec-tunnel of worden ontvangen vanuit de IPSEC-tunnel
Het externe BGP-buur- IP komt niet overeen met het externe GRE-tunnel- IP.
BGP-route-uitwisseling
Nadat de BGP-sessie voor beide tunnels is geverifieerd, controleert u of de juiste routes worden verzonden en ontvangen vanaf de kant van het toegewezen exemplaar.
De VPN -oplossing voor toegewezen instanties verwacht dat er twee tunnels worden gemaakt vanaf de kant van de klant/partner. De eerste tunnel verwijst naar datacenter A voor toegewezen instantie en de tweede tunnel verwijst naar datacenter B voor toegewezen instantie. Beide tunnels moeten de actieve status hebben en voor de oplossing is een actieve/actieve implementatie vereist. Elk datacenter van een toegewezen exemplaar maakt de lokale /25-route en een /24-back-uproute bekend. Wanneer u de inkomende BGP-routes van een toegewezen exemplaar controleert, moet u ervoor zorgen dat de BGP-sessie die is gekoppeld aan de tunnel die naar datacenter A verwijst, de lokale route van het toegewezen exemplaar datacenter A/25 en de back-uproute /24 ontvangt. Zorg er daarnaast voor dat de tunnel die naar datacenter B van toegewezen exemplaar verwijst, de lokale route van het toegewezen exemplaar van 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 Datacenter A van toegewezen exemplaar en Datacenter B van toegewezen exemplaar.
Redundantie wordt geboden aan een datacenter voor een toegewezen exemplaar als de tunnelinterface naar dat datacenter uitvalt. Als de verbinding met datacenter A van toegewezen exemplaar wordt verbroken, wordt het verkeer doorgestuurd van datacenter B van toegewezen exemplaar naar datacenter A. In dit scenario gebruikt de tunnel naar datacenter B de route van datacenter B/25 om verkeer naar datacenter B en de tunnel te verzenden naar datacenter B gebruikt de back-up/24-route om verkeer naar datacenter A te sturen via datacenter B.
Het is belangrijk dat, wanneer beide tunnels actief zijn, de tunnel van datacenter A niet wordt gebruikt om verkeer naar datacenter B te verzenden en vice versa. Als in dit scenario verkeer wordt verzonden naar datacenter A met als bestemming datacenter B, stuurt datacenter A het verkeer door naar datacenter B en probeert datacenter B verkeer terug te sturen naar de bron via de datacenter B-tunnel. Dit leidt tot een suboptimale routering en kan ook leiden tot onderbreking van het verkeer dat firewalls doorkruist. Daarom is het belangrijk dat beide tunnels zich tijdens normaal bedrijf in een actieve/actieve configuratie bevinden.
De route 0.0.0.0/0 moet worden geadverteerd van de kant van de klant naar de kant van het datacenter van het toegewezen exemplaar. Specifiekere routes worden niet geaccepteerd door de kant van de toegewezen instantie. Zorg ervoor dat de 0.0.0.0/0-route wordt geadverteerd vanuit zowel de toegewezen instantie datacenter A-tunnel als de toegewezen instantie datacenter B-tunnel.
MTU-configuratie
Aan de kant van de toegewezen instantie zijn twee functies ingeschakeld om MTU dynamisch aan te passen voor grote pakketgroottes. De GRE-tunnel voegt meer headers toe aan de IP -pakketten die door de VPN sessie stromen. De IPsec-tunnel voegt de extra headers toe aan de GRE-headers om de grootste MTU die via de tunnel is toegestaan verder te verkleinen.
De GRE-tunnel past de MSS-functie aan en het GRE-tunnelpad in de MTU-detectiefunctie is ingeschakeld aan de kant van de toegewezen instantie. Configureer de opdracht 'ip tcp adjust-mss 1350' of een vergelijkbare opdracht en de opdracht '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 via de VPN -tunnel.
