Retrospection
Starting with the previous VMware Cloud Director (VCD) release (10.5), the Border Gateway Protocol (BGP) feature of the platform has begun to change.
The BGP configuration was initially available to service providers and tenants via the Edge Gateway UI. The main reason for that was to ensure that the VCD integration with VMware NSX (NSX-T) remained similar to the VMware NSX Data Center for vSphere (NSX-V). The BGP configuration on the Edge Gateway modified the upstream Tier-0 Gateway, and this functionality was only available when the upstream Tier-0 Gateway was dedicated to the Edge Gateway.
VCD 10.4.1 replaced an NSX Tier-0 Gateway import with the Provider Gateway concept. Unlike the VCD Tier-0 Gateway, which can be dedicated to a specific Edge, the Provider Gateway can be dedicated to an organization, making it private. This, with the introduction of IP Spaces, made it possible to connect more than one Edge Gateway to a single Private Provider Gateway.
So, with the introduction of the Provider Gateway and IP Spaces, VCD now has a suitable location to display BGP configuration. It is crucial to transfer the BGP configuration to the Provider Gateway UI and make it apparent that any modifications to BGP will impact all connected downstream Edge Gateways.
Feature Overview
VCD 10.5.1 allows the BGP configuration to be a shared responsibility between the provider and his tenants altogether. The provider has the exclusive rights to configure the initial BGP peering with the datacenter physical routers for core infrastructure configuration (like internet access). Depending on the provider’s intentions, these configurations can stay hidden for the tenant. However, the provider can outsource the responsibility of modifying the BGP configuration to the tenant.
The provider has the option to grant partial rights to the BGP stack. For example, to allow the tenant to configure BGP filter prefixes without necessarily having access to the BGP neighbors’ settings. In this way, the provider can precisely control which parts of the BGP configuration suite are visible and owned by the tenant.
The BGP configuration is available for the Provider Gateway, regardless of ownership (Public or Private), taking into account the following notable distinctions:
- The Public Provider Gateway BGP configuration is not exposed in the tenant portal.
- The BGP configurations on the Private Provider Gateways are exposed on both the provider and tenant portals, according to the tenant role rights and organization rights bundle.
- VCD provides a workflow to auto-generate the Private Provider Gateway BGP configurations. Currently, this is a provider privilege only.
- VCD provides tenants’ rights management with the respect of configuring BGP via a new entity – BGP Permissions Groups
Public Provider Gateway
For the Public Provider Gateway, the BGP configuration is a manual process available only from the provider portal. VCD exposed all general BGP configuration parameters, as well as BFD and Rute Filtering configurations. In the case of an existing BGP configuration for the backing Tier-0 Gateway, VCD pulls and visualizes that information.
VCD also displays summarized information about the status of all BGP connections.
Private Provider Gateway
Provider perspective
When the Provider Gateway is private to an Organization, along with the manual BGP configuration, VCD also provides a wizard for auto-generating the configuration. At present, only the provider has the capability to generate the BGP configuration automatically.
When triggered, the wizard configures the BGP neighbor with the respective IP Prefix List, Route Map, and Inbound and Outbound route Filters to advertise only the necessary IP Prefixes. The wizard gathers the required information from the Provider Gateway IP Space’ internal and external scope definition to correctly generate the previously mentioned IP Prefix Lists and Route Maps.
The provider can also rerun the BGP configuration wizard, per IP Space Uplink, multiple times and update the corresponding BGP components based on any change in the internal/external scope metadata of an IP Space. Any existing IP Prefix Lists and Route Maps from previous auto-configuration or manual editions will be updated with the current IP Space internal/external scope. If a new neighbor IP address is also provided, this will also update that neighbor with the generated components for route filters/permission groups.
To learn more about VMware Cloud Director IP Spaces, check my blog, How to customize IP Spaces’ IP allocation with Terraform
BGP Permission Groups
The Private Gateway BGP configuration process enables providers to quickly and reliably generate Permission Groups that logically set BGP configurations and provide tenant-level permissions. These Permission Groups are aligned with specific Provider Gateway Uplinks, such as “Internet” or “MPLS”. The provider can delegate control and responsibility for specific BGP components (BGP Neighbors, IP Prefix Lists, Community List, Route Maps) to Organizations using the Permission Group. BGP components can be assigned to and removed from the BGP Permission Group to grant or restrict access.
This provides granular control over BGP configurations and enhances security by limiting tenants’ access to critical BGP configurations, like the BGP Neighbor parameter, for instance.
The permissions for each BGP component that the provider can assign are:
- Provider Only
- Tenant Manage
- Tenant View
The provider can also create a BGP Permission Group manually beforehand and then utilize this group when using the BGP auto-configuration wizard for a particular Provider Gateway IP Space Uplink.
If a BGP Permission Group is not used for a particular Provider Gateway Uplink, all BGP configurations are generated with “Provider Only” permission.
Tenant perspective
After the provider has created the initial BGP configuration and based on the BGP Permission Group tenant-level permission, the Organization Admins have the capability to view or edit BGP configuration parameters.
For instance, the tenant might want to add additional IP subnets to the IP Prefix Lists or create his own Community List entries. Another example will be, in the case of Active/Active Tier-0 Gateway, influencing the inbound routing path by manipulating the Rroute Map using BGP AS Path, prepending or changing the outbound path utilizing BGP Local Preference.
The tenant cannot modify the configuration if only “Tenant View” permission is provided for a particular BGP component.
Suppose the provider wants critical BGP configurations not exposed to the tenant. In that case, he can select “Provider Only” permissions for the respective BGP component, for example, the BGP Neighbor configuration.
Note that the tenant BGP configuration feature is only available on a Private (organization-owned) Provider Gateway. This ensures that any changes the tenant might make concerning the BGP configuration will not affect other tenants.
In Summary
VMware Cloud Director 10.5.1 empowers both providers and tenants with enhanced process automation, control, and visibility for configuring the Brother Gateway Protocol. This eliminates the need to perform BGP configurations in VMware NSX, thereby improving the infrastructure network administration and management.
Moreover, service providers can now delegate specific BGP components for management to their tenants, ensuring governance and providing greater flexibility over the BGP configuration. These enhancements result in more streamlined and effective network administration by both the provider and the tenants.
Keep yourself informed about the latest features and improvements of VMware Cloud Director.
- VMware Cloud Director 10.5.1 is now GA
- VMware Cloud Director 10.5.1 adopts NSX Projects
- What’s New in LBaaS with VMware Cloud Director 10.5.1
Remain up-to-date by regularly checking this blog for the latest updates. You can also connect with us on Slack, Facebook, Twitter, and LinkedIn.
Stay tuned for new demo videos and enablement on YouTube, especially our Feature Fridays series.
