You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In the Deployment guides, there's a section where readers are asked to fill in the Routes for AVI Static Routes. Currently, the static route prefix input is 0.0.0.0/0 for 3 next hop gateways. Is there a reasoning for these to be set?
For AVI Enterprise, this shouldn't be needed since there's an Auto-gateway that is ticked automatically in each VirtualService. This allows Service Engines to know how to route response traffic back to a caller using the MAC address instead of IP - unless the "Prefer Static Routes over directly connected networks" is ticked in the Cloud configuration.
For AVI Essentials, static routes in AVI are needed, since Auto-gateway is not available. The static routes are assessed on a top to bottom basis. So if the first entry has a prefix 0.0.0.0/0, all subsequent entries will be ignored, since the destination for a packet already matches 0.0.0.0/0. In a single Frontend network routable in from and out to the internet, it is sufficient to have a single static route prefix: 0.0.0.0/0 and next-hop: <frontend default gateway-ip>
This has caused some pain in the field for people who have set these 3, where they found that 're-ordering' the static routes work in one scenario but not the other. I have documented this internally at Central, which serves as a temporary holding place for docs to review before being pushed out to respective public sites on VMware.
After the networks are configured, set the default routes for all VIP/Data networks. Click Routing. Create and add default routes for following networks. Change the gateway subnet to match your network configuration:
Expected behavior
If the deployment guide assumes, AVI Enterprise, we shouldn't need to set the static route (unless there was a reason). Otherwise, AVI Essentials require the static routes to be set.
The text was updated successfully, but these errors were encountered:
Describe the bug
In the Deployment guides, there's a section where readers are asked to fill in the Routes for AVI Static Routes. Currently, the static route prefix input is 0.0.0.0/0 for 3 next hop gateways. Is there a reasoning for these to be set?
For AVI Enterprise, this shouldn't be needed since there's an
Auto-gateway
that is ticked automatically in each VirtualService. This allows Service Engines to know how to route response traffic back to a caller using the MAC address instead of IP - unless the "Prefer Static Routes over directly connected networks" is ticked in the Cloud configuration.For AVI Essentials, static routes in AVI are needed, since Auto-gateway is not available. The static routes are assessed on a top to bottom basis. So if the first entry has a prefix 0.0.0.0/0, all subsequent entries will be ignored, since the destination for a packet already matches 0.0.0.0/0. In a single Frontend network routable in from and out to the internet, it is sufficient to have a single static route
prefix: 0.0.0.0/0
andnext-hop: <frontend default gateway-ip>
This has caused some pain in the field for people who have set these 3, where they found that 're-ordering' the static routes work in one scenario but not the other. I have documented this internally at
Central
, which serves as a temporary holding place for docs to review before being pushed out to respective public sites on VMware.https://central.eng.vmware.com/how-to-guides/avi/tips-integrating-avi-with-tkg/#setting-up-avi-essentials-with-tkg
To Reproduce
Example:
See:
https://github.com/vmware-tanzu-labs/tanzu-validated-solutions/blob/main/src/deployment-guides/tko-on-vsphere-vds.md
with step text reading:
Expected behavior
If the deployment guide assumes, AVI Enterprise, we shouldn't need to set the static route (unless there was a reason). Otherwise, AVI Essentials require the static routes to be set.
The text was updated successfully, but these errors were encountered: