VMware Networking Community
phillbl
Enthusiast
Enthusiast
Jump to solution

f5 integration with NSX cross vcentre

hi,

we are looking at using nsx in a cross vcentre configuration with f5 load balancers.  after doing a bit of reading i found the below in a f5 design guide:

NOTE: Cross-vCenter NSX functionality does not support load balancing service insertion

has anyone out there tried doing this or does this statement make the solution of cross vcentre and f5 just not possible?  to me this would mean that if we use f5 then cross vcentre will not be possible.

we have the physical devices.

thanks

Tags (1)
1 Solution

Accepted Solutions
erikverbruggen
Hot Shot
Hot Shot
Jump to solution

No, universal objects are objects shared between vCenter Servers. A logical switch is a universal object if it's made available on multiple vCenter Servers in a cross-vCenter NSX environment. It is not supported to enable service insertion for universal objects. So if you attach a vm to a universal logic switch, you cannot enable service insertion.

In a cross-vCenter NSX environment it is supported to mix local and universal objects. If you create local NSX objects, which are local to a vCenter Server, it is supported to enable service insertion.

View solution in original post

9 Replies
erikverbruggen
Hot Shot
Hot Shot
Jump to solution

Logical Load balancer service insertion is not supported for universal objects in a cross-vCenter NSX environment. You can still use the service insertion for local objects.

The documentation states which services are available for universal synchronization in a cross-vCenter NSX environment, VMware Documentation Library.

phillbl
Enthusiast
Enthusiast
Jump to solution

thanks for the response.  from what you are saying then my understanding is that if i had two web servers running in one dc then this would be fully supported but if i had two web servers with one in each dc this would not be supported.

thanks

Reply
0 Kudos
erikverbruggen
Hot Shot
Hot Shot
Jump to solution

No, universal objects are objects shared between vCenter Servers. A logical switch is a universal object if it's made available on multiple vCenter Servers in a cross-vCenter NSX environment. It is not supported to enable service insertion for universal objects. So if you attach a vm to a universal logic switch, you cannot enable service insertion.

In a cross-vCenter NSX environment it is supported to mix local and universal objects. If you create local NSX objects, which are local to a vCenter Server, it is supported to enable service insertion.

phillbl
Enthusiast
Enthusiast
Jump to solution

thank you for the explanation.

so with that in mind i could for example have 2 web servers on a switch (local) and a app server.  The two web servers load balanced using f5 and at the back end i could have an SQL always on cluster stretched running on a universal switch?  the SQL object would require no service insertion from the f5, only the web would require this and all the other traffic from the web servers would be handled as east west traffic?

thanks

Reply
0 Kudos
lhoffer
VMware Employee
VMware Employee
Jump to solution

The only reason that this is considered unsupported for cross-vCenter use cases is because the F5 service insertion happens in an ESG, and an ESG will always belong to one, and only one, vCenter/NSX Manager.  In a cross-vCenter environment where you're using the F5 integration for service insertion (which is really just an automated way of deploying the F5-VE instance from the NSX UI), you can have the servers behind the F5-VE on either a local or universal logical switch with no issue.  The only caveat for this (which also applies to the NSX logical load balancer) is that as mentioned, each ESG instance will only ever exist in one vCenter so in a cross-vCenter environment where you want resiliency across vCenters for DR scenarios, the only way to do it is by configuring an additional ESG instance for each vCenter and leaving it disconnected until you want to fail over to that site.  This is described in more detail in the Stateful Services section starting on page 91 of the NSX-V Multi-site Options and Cross-VC NSX Design Guide

bayupw
Leadership
Leadership
Jump to solution

As mentioned by lhoffer​ above the unsupported statement is applicable when you are using cross-VC + F5 service insertion.

Service insertion is used when you are using NSX and third party (such as F5) and integrate their management and control plane for automated deployment

F5 service insertion is uses F5 BIG-IP Virtual Edition (VE) in conjuction with BIG-IQ.

You mentioned that you are using physical appliance, so I believe you are not using service insertion and this limitation/unsupported statement is not applicable in your case

In some cases, the F5 BIG-IP is bridged to the VXLAN logical switch so the VMs attached to VXLAN can be in the same layer 2 network as the physical BIG-IP so the gateway of the VMs is F5.

Please note that Layer 2 Bridging does not work with Universal Logical Switch

L2 Bridges: you cannot add a bridge to a universal logical switch

Not sure if you are referring to a same design guide, but there is a NSX F5 design guide here: NSX F5 Design Guide v1.6.pdf

Bayu Wibowo | VCIX6-DCV/NV
Author of VMware NSX Cookbook http://bit.ly/NSXCookbook
https://github.com/bayupw/PowerNSX-Scripts
https://nz.linkedin.com/in/bayupw | twitter @bayupw
phillbl
Enthusiast
Enthusiast
Jump to solution

hi,

yes you are correct, we are using physical f5 appliances. what i want to achieve is the following:

VRA installation with NSX used for Dist firewall, micro segmentation.  all of this achieved by creating blue prints and leveraging VRO to do this.

as part of the blue print i would like to be able to automate the F5 load balancing parts using VRO. 

all of the above sitting on NSX cross vcentre using UDLR.  all load balancing would be done on the physical appliance using a vip that forwards onto a web servers in NSX.

i have looked at the guide you mention but the comment is on page 17 of this one

https://f5.com/Portals/1/Premium/Architectures/RA-VMware-NSX-Design-Guide.pdf

thanks

Reply
0 Kudos
bayupw
Leadership
Leadership
Jump to solution

Hi, are you using VXLAN?

The document you have provided is more for virtual appliances BIG-IP VE & BIG-IQ and not for physical appliances.

https://f5.com/Portals/1/Premium/Architectures/RA-VMware-NSX-Design-Guide.pdf

This guide will focus on the integration of F5® BIG-IQ® Cloud and F5 BIG-IP® virtual editions (VEs) with VMware NSX network virtualization.

The other document I have provided might be more relevant for your case NSX F5 Design Guide v1.6.pdf

The topology in design guide requires SNAT.

If you require inline without SNAT, you might need to perform L2 bridging from F5 VLAN to NSX VXLAN - as mentioned previously bridging does not work on UDLR at the moment.

You would need to decide which topology you are going to use before automate the provisioning process using vRO.

Stretching network across sites with stateful services such as load balancing is normally tricky, especially on the ingress routing part

Bayu Wibowo | VCIX6-DCV/NV
Author of VMware NSX Cookbook http://bit.ly/NSXCookbook
https://github.com/bayupw/PowerNSX-Scripts
https://nz.linkedin.com/in/bayupw | twitter @bayupw
phillbl
Enthusiast
Enthusiast
Jump to solution

yes i have had a look at that design guide and as a requirement we would need to use the LB without SNAT.  We will also be using vxlan locally and was hoping to strech over to the other dc.  The hope was to be able to use load balance services that need it in each dc.

for example we would have two dc's with 2 web servers in each dc.  one set acting as active and the other 2 servers in the dr dc as fail over.  these would be on different vips and serviced by different physical load balancers.  the area that we always struggle with is SQL Always on groups because we dont use stretched vlans, the hope was to be be able to use L2 over VXLAN so in the event of a failover we could just move the db over to the other dc.  to failover to the other LB web vip we would just use DNS monitoring so that it failed over to the dr web servers.

thanks

Reply
0 Kudos