Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

VeloCloud Gateway (VCG) Purpose & Resiliency (71374)

Last Updated: 9/5/2019Categories: InformationalTotal Views: 28892Language:
JapaneseEnglish

47 like this article

Subscribe to get an email
newsletter with new updates

47 people found this helpful Please provide article feedback:

Purpose

This article explains about the VeloCloud Gateway functionality and Resiliency.

Resolution

For Edge’s running Release 3.2.x or earlier, there are three VeloCloud Gateway's assigned to each Edge in an Enterprise—Primary, Secondary, and Super Gateway. An Edge using Release 3.3.0 or later will have four VCG's assigned to it as a result of the addition of a second, redundant Super Gateway. There may be additional VCG’s assigned depending on whether the Edge is also connected to a Non-VeloCloud site or using a Cloud Security Service (e.g. Zscaler).

Primary VCG : All Cloud (internet) traffic will use this VCG. If the Primary VCG goes down, Cloud traffic would be sent Direct to the Cloud from the Edge WAN link. Once the Primary VCG is back up, existing flows would continue to go direct to ensure these existing flows remain intact. Any new flow would travel via the Primary VCG. If there are two Edges in the Enterprise that are connected to the same Primary Gateway, then that VCG would be used for site-to-site VPN traffic as well.

Secondary VCG:This VCG is only used for VPN traffic when the Primary VCG goes down and only if it is a common gateway between Edges. Once the Primary VCG is back up, existing flows will continue to go via the Secondary Gateway to ensure these existing flows remain intact. Any new VPN flow would use the Primary VCG.

Super VCG: Depending on the Edge release (mentioned above) an Edge has either one or two Super Gateways. All the Edges which do not have a common Primary or Secondary Gateway will use the Super Gateway for Edge-to-Edge communication.

The VeloCloud Orchestrator assigns the Gateways to the Edge when it comes up based on the location of the Edge. By default, the location of the Edge is determined by the WAN IP address when the Edge comes up. The Orchestrator queries the MaxMind database to get the location and then calculates and assigns the closest Gateway for the Edge. You may change the assignment of VCG by manually editing the address for an Edge from Configure → Edge Overview → Contact & Location. If you change the location of the Edge to something that results in different Gateways being assigned, the VeloCloud service will tear down all existing tunnels using the current VCG's and establish tunnels with the new VCG's assigned.

Example: There are 5 Edges in the Enterprise, 2 located in New York, 1 in Mumbai, and 2 in Frankfurt.

New York Edges: The Primary VeloCloud Gateway will be the closest Gateway to the Edge and is used for sending Cloud/Internet traffic. Most likely this Gateway would be hosted in, or close to the New York region. Depending on the precise location of both New York Edges, they would likely have the same Primary and Secondary Gateway. As a result, these two Edges would have redundancy between each other, because if the Primary VCG goes
down they can still use the Secondary Gateway for VPN traffic. They would use the Super Gateway for VPN traffic to the Mumbai and Frankfurt Edges.

Mumbai Edge: Primary VCG would be the closest to this location with the Secondary VCG being the second closest to the Mumbai location.
Frankfurt Edges: Primary VCG will be the Gateway closest to their location.Both Edges would most likely have the same Primary and Secondary Gateways given they are in the same city.
Super Gateway(s): The Super Gateway(s) assignments are calculated by the Orchestrator based on the location of all Edges in the enterprise.

Routing:

For resiliency purposes, VeloCloud SD-WAN Edges connect to multiple VeloCloud Gateways—each of which functions as a route reflector. To be truly resilient, a single Gateway going down must not affect user traffic when alternate VeloCloud Gateways are available.

If an Edge using Release 3.2.0 (and earlier) loses contact with a Gateway, there may be a route flush and re-advertisement with a resulting significant impact to ongoing user traffic where large route tables and/or dynamic routing are configured.

From Release 3.2.1 onwards, an Edge losing connectivity to a VeloCloud Gateway marks routes as stale and triggers a timer to remove those routes after 60 seconds if the Gateway is still not connected. When the 60 second timer expires:

● If the Gateway is still down, routes are removed for this Gateway.
● If all Gateways are down, the routes are retained, and the timer is restarted.
● If the Gateway reconnects with the Edge, the Edge removes any stale routes no longer present on
the Gateway.

This offers full protection against any momentary loss of connectivity to any single Gateway, as well as ensuring that traffic between Edges is not impacted even if all Gateways are down for a prolonged period.

Example Topology:
Let's consider a Hub and Spoke scenario. Both the Hub and Spoke Edge have a Public and a Private link. Branch-to-Hub is configured, so both sites have two direct tunnels between them. There are no paths/tunnels from the Private link to any of the VeloCloud Gateways. Only the Public link has paths/tunnels to all the VeloCloud Gateways.

Case#1:
If the Public link on the Spoke goes down then the site will lose all the connectivity to all VCG's. However, we still have a Stable path between HUB and Spoke on the Private link. To offer full protection, VPN traffic between these sites will not be impacted because routes will not be revoked and will continue to use the Private path. If Internet Backhaul is configured on the Spoke via Business Policy, the internet traffic can use this Private path to go the HUB and then to the Internet. Any new routes added/deleted will not be advertised/removed by/from Spoke as there is no connectivity to any of the VCG's. If you want to have reachability to the VCG's from a Private link, you can enable SD-WAN Service Reachable under Device tab --> WAN Overlay.

Case#2:
If the path from the Public link on the Spoke goes down for one VCG only, then routes from that VCG will be revoked. In other words, the Gateway that no longer has a path to the Spoke will remove the routes to this Spoke from all other sites that are connected to it once the 60 seconds timer has expired. Once the Gateway is reconnected, the Edge will remove any stale routes no longer present on the Gateway."

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
JapaneseEnglish

Attachments

Additional Resources

KB
•
vApp テンプレートから vApp をデプロイすると、「ハブの「リソース」が仮想マシンのホスト アフィニティ ルールに違反しています (Hub "Resources" violates VM host affinity rule)」というエラーが表示される (71366)

KB
•
将磁盘添加到 vCloud Director for Service Providers 中的虚拟机时出现错误“未设置 StoragePlacementSpec 所需属性 podSelectionSpec” (71365)

KB
•
K8S 服务创建停滞，一直处于等待服务 IP 状态，并出现错误“超过负载平衡器服务上的最大池数 (Exceed maximum number of pools on the Load balancer service)” (71372)

KB
•
对文件 /opt/vmware/vcloud-director/data/transfer 解压存档失败：cpio：chown (71340)

KB
•
尝试通过 api 删除计算机前缀时出现错误“400 错误请求 (400 bad request)” (71344)

Results 1-5 of 5

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

Related Versions:

VMware SD-WAN by VeloCloud

Take Our Survey

Support Assistant