In this deployment, BGP is used for peering with ACI fabric and to exchange the virtual service routes. This deployment is mostly applicable for setups with no vCenter deployed or has no vCenter integration with NSX Advanced Load Balancer Controller.
In vCenter no-access cloud, the Controller has no access to vCenter resources. In vCenter read access cloud, the Controller will integrate with vCenter, but the Controller can only read the vCenter resources and not write or create any Service Engines or resources. In both cases, you need to manually deploy Service Engines.
For more information on VMware no-access or read access, see Installing NSX Advanced Load Balancer in VMware vSphere Environments.
To support BGP peering between the SEs hosted on vCenter and ACI fabric the SEs should be connected to the ACI fabric and configured as an external routed device in APIC. Then, APIC will consider it as an L3Out device.
BGP Peering
For configuring BGP L3Out on Cisco APIC, please refer to the APIC configuration section in NSX Advanced Load Balancer Deployment for North-South Traffic.
To configure BGP on NSX Advanced Load Balancer Controller:
Navigate to .
Select the cloud in which BGP peering is configured.
Under BGP Peering, enter the peer IP, AS numbers, and other parameters.
For configuring BGP L3Out on Cisco APIC, please refer to the APIC configuration section in NSX Advanced Load Balancer Deployment for North-South Traffic.
To configure BGP on the NSX Advanced Load Balancer Controller:
Navigate to .
Select the cloud in which BGP peering is configured.
Under BGP Peering, enter the peer IP,AS numbers, and other parameters.
For detailed information, see BGP Support for Scaling Virtual Services.
Virtual Service Provisioning
After configuring BGP peering, proceed with creating virtual services.
To create virtual services:
In NSX Advanced Load Balancer Controller, click Creating Virtual Service (Advanced)option.
Enter all virtual service parameters, such as the name, IP address, pool, etc.
Click Next and navigate to the Advanced tab.
Enable Advertise VIP via BGP option.
After the virtual service is created, the NSX Advanced Load Balancer SE will start publishing the routes to ACI fabric.
You can check the BGP peering status and advertised routes in APIC. Alternatively, to check BGP peering and neighbor status on NSX Advanced Load Balancer, login to the SE CLI and run the commands shown below under the quagga router. See How to Access and Use Quagga Shell using NSX Advanced Load Balancer CLI for reference.
10-128-3-198> show ip bgp
BGP table version is 0, local router ID is 2.103.143.46
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 15.15.15.5/32 0.0.0.0 0 32768 i
*> 16.16.16.0/24 17.17.17.1 0 0 500 670 ?
Total number of prefixes 2
10-128-3-198> show ip bgp summary BGP router identifier 2.103.143.46, local AS number 600 RIB entries 3, using 336 bytes of memory Peers 1, using 4568 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 17.17.17.1 4 500 19369 19373 0 0 0 01w6d10h 1 Total number of neighbors 1
You can verify the virtual service routes in ACI fabric. The sample below is the output of the virtual service route learned by a border leaf in ACI fabric:
leaf-1# show bgp ipv4 unicast vrf VMware-NO-Access-Demo:vmware-no-vrf BGP routing table information for VRF VMware-NO-Access-Demo:vmware-no-vrf, address family IPv4 Unicast BGP table version is 12, local router ID is 4.4.4.4 Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist, I-injected Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath, & - backup Network Next Hop Metric LocPrf Weight Path *>r4.4.4.4/32 0.0.0.0 0 100 32768 ? *>e15.15.15.5/32 17.17.17.2 0 0 500 600 *>r16.16.16.0/24 0.0.0.0 0 100 32768 ? *>r17.17.17.0/24 0.0.0.0 0 100 32768 ?
