ddesmidt's Posts

When a server is marked down, new sessions will never go to that servers. That said existing sessions will still go to that server. Is it what you're experiencing? Dimitri
Modification of objects are with the HTTP method "PUT". Creation of objects are with the HTTP method "POST". I understand you try to modify an existing VIP, so you should try with the HTTP me... See more...
Modification of objects are with the HTTP method "PUT". Creation of objects are with the HTTP method "POST". I understand you try to modify an existing VIP, so you should try with the HTTP method "PUT". Can you try again? If you're still facing issue, can you send the exact URL + payload you're sending. Thanks, Dimitri
You edit your Application Profile, and you enter your cipher list in the field "Cipher". Dimitri
Larsonm aslready gave an answer. As explained, the default cipher is: AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH (takes the strongest of AES first. Then the strongest of any cipher but RC4. At last th... See more...
Larsonm aslready gave an answer. As explained, the default cipher is: AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH (takes the strongest of AES first. Then the strongest of any cipher but RC4. At last the strongest of RC4. And in any case it will accept a client with no encryption neither authentication). The syntax used to specify the supported cipher is the one from OpenSSL: https://www.openssl.org/docs/apps/ciphers.html For instance: To allow only TLSv1.2, use the cipher “!SSLv3:ALL” Note: This cipher does not allow TLSv1.0 nor TLSv1.1. Dimitri
Indeed. Thanks for the catch. Just updated the ppt with the correction. Thanks again. Dimitri
This Getting Started Guide: Offers a presentation of DLB Explain how to enable DLB + configure DLB VIP Give an example on how to demo DLB Offers a video of DLB List known limitation on the ... See more...
This Getting Started Guide: Offers a presentation of DLB Explain how to enable DLB + configure DLB VIP Give an example on how to demo DLB Offers a video of DLB List known limitation on the current DLB preview !!! Attention: DLB is a preview feature and not for production !!! Note: Document updated with NSX-v 6.2.3 latest enhancements. Dimitri
Three are multiple ways (like always in load balancers) to achieve the same thing. Here are a few examples of possible options: OPTION1: In case of servers in the primary pool are all dead, u... See more...
Three are multiple ways (like always in load balancers) to achieve the same thing. Here are a few examples of possible options: OPTION1: In case of servers in the primary pool are all dead, use servers in the secondary pool Create an Application Rule (Under "Edge – Manage /  Load Balancer / Applications Rules") # detect if pool "pool_production" is still UP acl pool_production_down nbsrv(pool_production) eq 0 # use pool "pool_sorry_server" if "pool_production" is dead use_backend pool_sorry_server if pool_production_down Apply that Application Rule to the Virtual Server (Under "Edge – Manage /  Load Balancer / Virtual Servers") OPTION2: Redirect EVERYTHING to maintenance site Create an Application Rule (Under "Edge – Manage /  Load Balancer / Applications Rules") redirect location http://maintenance.xyz.com/maintenance.htm Apply that Application Rule to the Virtual Server (Under "Edge – Manage /  Load Balancer / Virtual Servers") OPTION3: Use a specific maintenance server pool + rewrite all URL to /maintenance.php Create an Application Rule (Under "Edge – Manage /  Load Balancer / Applications Rules") # Match everything acl match_all always_true use_backend maint_pool if match_all # Rewrite all url with "/maintenance.html" reqirep ^GET\ (.*)\ HTTP/(.*)  GET\ /maintenance.php\ HTTP/\2 Apply that Application Rule to the Virtual Server (Under "Edge – Manage /  Load Balancer / Virtual Servers") Dimitri
Could it be related to some DFW rules? Can you try with allowing any traffic on DFW? Dimitri
That's the expected behavior IF your VM have IPv4 and IPv6 (most VMs have now both stacks enabled). In such case you have to configure the VM IP@ manually. Dimitri
NSX deployments can be today coupled with F5 BIG-IP appliances or Virtual Edition. Such deployment gives to NSX customers a flexible, powerful, and agile infrastructure with the richness of F5 A... See more...
NSX deployments can be today coupled with F5 BIG-IP appliances or Virtual Edition. Such deployment gives to NSX customers a flexible, powerful, and agile infrastructure with the richness of F5 ADC service. Note: F5 deployment + configuration done from F5. This design guide provides recommended practices and topologies to optimize interoperability between the NSX platform and F5 BIG-IP physical and virtual appliances.
Just for other readers: Hardware VTEP allows L2 VXLAN/VLAN connectivity. That's for the use case where you have VMs on a VXLAN logical switch (10.1.1.11/24)  and you want them L2 connected to p... See more...
Just for other readers: Hardware VTEP allows L2 VXLAN/VLAN connectivity. That's for the use case where you have VMs on a VXLAN logical switch (10.1.1.11/24)  and you want them L2 connected to physical servers on a VLAN (10.1.1.21/24). NSX offers native VXLAN/VLAN connectivity too: 1. with DLR bridging (used for Logical/Physical L2 connectivity within a DC) 2. with L2 SSL-VPN (used for Logical/Physical L2 connectivity with a remote location) NSX-v 6.2 (planed early Q3) will support Hardware VTEP. Contact your physical switch vendor to see if it will support integration with NSX-v. Important Note: HW VTEP will be incompatible with NSX Distributed Logical Router function. In other words the subnet (10.1.1.0/24) extended from Logical (VXLAN) to Physical (VXLAN) via HW VTEP won't be able use a dist L3 (only central L3). When using NSX-v 6.2 native VXLAN/VLAN bridging, you'll be able to combine VXLAN/VLAN bridging and still enjoy Dist L3 for that subnet. Dimitri
You can still have 1 Edge with many subnets. But you definitely need a route (default gateway). Dimitri
Number of subnets in 1 single Edge One single Edge can actually be connected to more than 10 networks. Indeed 1 Edge interface can be of type: "Unlink", "Internal", but also "Trunk". Using the... See more...
Number of subnets in 1 single Edge One single Edge can actually be connected to more than 10 networks. Indeed 1 Edge interface can be of type: "Unlink", "Internal", but also "Trunk". Using the type "trunk", you can create sub-interfaces and up to 200 sub-interfaces supported in 6.1.x within the same interface. Now about your question: 1 Edge LB per subnet You can definitely have the same Edge with multiple interfaces / subnets, and configure VIP in each subnet. Note: You'll need non-transparent mode (SNAT) under pool to guaranty to the server response will go back via the Edge-LB. The question I have is on your point:"Disable routing". Are you saying the Edge will not need any route to reply to the clients. In other words all the clients' requests hitting an Edge-LB VIP comes from a subnet that exists on the Edge? If the answer to that question is "yes". Then I agree. If the answer to that question is "no" (clients come from Internet for instance). Then I disagree. Dimitri
Indeed you need 6.1.3 minimum with vCenter 6.0.
There is a flag in edge configuration-> sslvpn->private networks->specific entry-> "enable TCP optimization". Disable that and you will see client ip even for TCP connections. Dimitri
In vCenter, you go under: Networking & Security NSX Edges (and edit your Edge with a double-click) Manage - Routing - Global Configuration - Edit Default Gateway Dimitri
The AppRule in the VMware documentation looks good to me. I would need to see your AppRule and a trace from your browser on the http request you send to the Edge-VIP. Note: Also validate your V... See more...
The AppRule in the VMware documentation looks good to me. I would need to see your AppRule and a trace from your browser on the http request you send to the Edge-VIP. Note: Also validate your VIP is type HTTP and not TCP to be able to use the Application Rule. Here is another example with comments that may help you: # Check if host is "app1.xyz.com" (case insensitive) acl host_app1 hdr(Host) -i app1.xyz.com # Check if host is "app2.xyz.com" (case insensitive) acl host_app2 hdr(Host) -i app2.xyz.com # Check if host is "app3*" (case insensitive) acl host_any_app3 hdr_beg(host) -i app3 # Use specific pool for each hostname use_backend pool_app1 if host_app1 use_backend pool_app2 if host_app2 use_backend pool_app3 if host_any_app3 #for everything else, use the pool defined in the Virtual Server Dimitri
This community is focused on VMware NSX product. Looks like your question is VMware workstation 11. You may want to ask your question on their community: VMware Workstation Dimitri
I tried your ACL with success. "/api*" go to api_pool. other urls go to ui_pool. In term of documentation, there are examples in our Admin Guide but not an exhaustive AppRules documentation.... See more...
I tried your ACL with success. "/api*" go to api_pool. other urls go to ui_pool. In term of documentation, there are examples in our Admin Guide but not an exhaustive AppRules documentation. The Admin Guide points to the haproxy manual since the Edge is using the haproxy "straight". Note: There would be no point of recreating something that already exists. Could you send: The config of your Edge show configuration loadbalancer The trace taken from the Edge debug packet capture interface vNic_0 host_10.0.1.6 (where "vNic_0" is the Edge interface where the VIP is listening and "10.0.1.6" is the VIP@) debug copy scp root@20.20.20.199: tcpdump_vNic_0.0 (to export the trace taken) Thanks, Dimitri
NSX Edge has no concept of 2 arm or 1 arm deployment. What NSX Edge knows is under the pool: . Transparent enabled => SNAT is configured . Transparent disabled => SNAT is not configured S... See more...
NSX Edge has no concept of 2 arm or 1 arm deployment. What NSX Edge knows is under the pool: . Transparent enabled => SNAT is configured . Transparent disabled => SNAT is not configured So when you deploy an Edge in 2 arm mode: "Client --- Edge --- servers_load_balanced" (with servers default gw = Edge) If you have Transparent enabled, it will works and the server will see the real client IP@, so the server will reply to the Client IP@ (via its default gw = Edge) If you have Transparent disabled, it will works and the server will see the Edge IP@, so the server will reply to the Edge IP@ (which will NAT to reply to the Client)