ddesmidt's Posts

Connection Mirror: NSX-Edge-LB doesn't support connection mirror (only persistence mirror). In other words, in the unlikely case of Edge failure (or ESXi failure) clients accessing the VIP will have to re-establish new connections. Note: The backend server persistence is synched between NSX-Edge-LB active/standby so in case of persistence configured, clients new connections will go to the same backend servers used previously. Loose Initiation/Close Initiation: NSX-Edge-LB doesn't support Loose Initiation/Close Initiation But do you really have: . Loose: Need on the load balancer to load balance new sessions even in case the first packet seen is NOT TCP SYN (what TCP application do you have not doing a proper TCP SYN handshake?) . Close: Need on the load balancer to flush LB sessions after seeing the first TCP FIN packet (instead of the full FIN handshake)? FastL4 If your definition of K5 FastL4 is: "load balancer with higher performance for applications that don't require HTTP/HTTPS load balancing" Then I agree NSX-Edge-LB has also that with Acceleration Enabled. Dimitri

DLB will currently stay as Tech Preview and no commitment on its production. The missing pieces are the API/UI. As you can see in the configuration steps, we're currently using a "hack". I would be interested to hear from your use case (what application do you like to load balance with DLB - where are the clients / servers - traffic type and volume - etc). Thanks, Dimitri

With: SSL Passthrough, the Edge does NOT terminate Client SSL session           So NSX Edge LB can DOES NOT see the HTTPS request in clear and do actions like add XFF header. End-to-End SSL the Edge does terminate Client SSL session (Edge needs the web site certificate obviously to terminate the SSL)           So NSX Edge LB DOES see the HTTPS request in clear and can do actions like add XFF header. Dimitri

X-Forwarded-For HTTP hearder (XFF) is inserted for:   1. HTTP VIP   2.  HTTPS VIP if the NSX LB terminates the Client HTTPS (not SSL passthrough). Note: This means you must have the application SSL certificate imported in NSX Edge. If you have XFF enabled in the Application Profile for case1 or case2, the XFF HTTP header will be added to the request to the server. And this whatever if you have configured your pool in transparent mode (no SNAT) or non-transparent mode (SNAT). Dimitri

You can take a capture directly on your NSX Edge doing the LB. Lots of information in the NSX Troubleshooting Guide. Below is is an quick example: 1. Capture all traffic on the Edge Interface vNIC_1 for host 10.0.1.11 (backend server) Note: You can use any tcpdump filter (using "_" instead of space " "). PowerNSX-Edge01-0> debug packet capture interface vNic_1 host_10.0.1.11 Packet capture has started on interface vNic_1. To stop the capture, invoke 'no debug packet capture interface vNic_1'. 2. Stop the capture PowerNSX-Edge01-0> no debug packet capture interface vNic_1 3. List all the captured files saved on the Edge PowerNSX-Edge01-0> debug show files total 9.0K -rw------- 1 8.4K Jan  3 18:29 tcpdump_vNic_1.0 4. Copy the file to your laptop and use Wireshark to look at it PowerNSX-Edge01-0> debug copy scp root@20.20.20.199: tcpdump_vNic_1.0 Dimitri

I don't dully understand the text below. Can you send a ppt or Visio diagram with the IP@ of everything (client, Edge, DLR, pool servers, etc), the default gw / route of everything, and the specific other config of elements in a detailed way (like NAT on the Edge). Then it will be easier to reply. Dimitri

Looks like the issue here, is more related to the Edge-HA (than LB). Can you validate the Edge#1 and Edge#2 are well "active-standby" when everything is working fine (in CLI: show service highavailability). Then unplug the ESX hosting the Edge#1 and validate everything is working fine "...-active". If there is any issue there, the usual errors are: . Edge must have at least an interface configured as "Internal" for the HA to work . ESX2 (hosting the Edge#2) VXLAN-transport interface can not talk to the other ESXi VXLAN transport interface (try ping ++netstack=vxlan x.x.x.x [-d -s 1570]). . Assuming the Edge uplink interface is on a VLAN, ESX2 (hosting the Edge#2) doesn't have the port group well configured for Edge uplink Thanks, Dimitri

There is no certificate management in the NSX solution currently. In other words, you're in charge of importing the new certificate and update the Application Profile to link it to the new imported certificate. Dimitri

You'll need:   . to turn on promiscuous mode on the vCenter port group where is connected the ToR interface-VLAN (since the VM-ToR will send packets from other sce-mac@ than its mac@)   . to have the ToR vendors bits in VM form factor with HW VTEP support) After that, you're good to go Note: Obviously don't test perf since you'll have "promiscuous mode" enabled. Dimitri

What tool did you use to generate the CSR? And then what tool do you use to import the cert received? If you use NSX-Edge to generate the CSR, the steps are: 1. Generate a CSR and copy the "BEGIN CERTIFICATE REQUEST" (the private key is securely stored on the Edge and can't be exported for security reasons) 2. Give that to your Certificate Authority to get a signed certificate 3. Import the certificate (highlight the CSR + go on "Action - Import Certificate" 4. That's it, now you have your cert available on the Edge that can be used for an Application Profile If you use an external tool to generate the CSR, the steps are: 1. Generate a CSR from the tool (and save the private key) 2. Get your certificate from your Certificate Authority 3. Import the cert + key on NSX Note: If you have a chain of Certificate Authority, import the cert as mentioned previously. Dimitri

What you need is: your server cert your intermediate cert your root cert (and obviously your server key) The way you enter the cert chain in the Edge under "certificate contents" is: -----BEGIN CERTIFICATE----- Server cert -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Intermediate cert -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Root cert -----END CERTIFICATE----- Thanks, Dimitri

When a LB VIP is created, an "internal DNAT" rule in created under NAT (you can see it with the description "loadBalancer"). This happens regardless if the VIP is: in transparent mode (no SNAT with pool = transparent) in non-transparent mode (SNAT with pool = non-transparent) The SNAT in case of non-transparent mode is NOT done via "Edge-NAT" but directly within the "Edge-LB". That's why you don't see it under "Edge-NAT" Dimitri

I tried the same thing as you did with "VIP with sce-iP persistence with no expiration time" Step0: both servers UP NSX-edge-3-0> show service loadbalancer pool Pool-Web01-http ----------------------------------------------------------------------- Loadbalancer Pool Statistics: POOL Pool-Web01-http |  LB METHOD round-robin |  LB PROTOCOL L7 |  Transparent enabled |  SESSION (cur, max, total) = (0, 1, 7) |  BYTES in = (1197), out = (1911)   +->POOL MEMBER: Pool-Web01-http/web01, STATUS: UP   |  |  HEALTH MONITOR = BUILT-IN, default_http_monitor:L7OK   |  |  |  LAST STATE CHANGE: 2015-09-25 06:51:49   |  |  SESSION (cur, max, total) = (0, 1, 5)   |  |  BYTES in = (855), out = (1365)   +->POOL MEMBER: Pool-Web01-http/web02, STATUS: UP   |  |  HEALTH MONITOR = BUILT-IN, default_http_monitor:L7OK   |  |  |  LAST STATE CHANGE: 2015-09-25 06:51:49   |  |  SESSION (cur, max, total) = (0, 1, 1)   |  |  BYTES in = (129), out = (225) Step1: I access the VIP from client 20.20.20.1 and I'm redirected to server2 (test.php is a specific page displaying the server IP@) vyatta@vyatta:~$ curl http://20.20.20.2/test.php The Client IP@ is: 20.20.20.1<br> The Server IP@ is: 10.1.1.12 I validate also the persistence table for the Client (20.20.20.1) NSX-edge-3-0> show service loadbalancer table ipv4_ip_table_Pool-Web01-http ----------------------------------------------------------------------- L7 Loadbalancer Sticky Table [ipv4_ip_table_Pool-Web01-http] Status: # table: ipv4_ip_table_Pool-Web01-http, type: ip, size:1048576, used:1 0x341154e94d8: key=20.20.20.1 use=0 exp=223550 server_id=2 conn_cnt=0 conn_rate(60000)=0 conn_cur=0 sess_cnt=0 sess_rate(60000)=0 http_req_cnt=0 http_req_rate(60000)=0 And I check there client (20.20.20.1) does not have any more its TCP connection to the VIP (so when the client will re-connect to the VIP, that will be with a new TCP session) NSX-edge-3-0> show service loadbalancer session l7 ----------------------------------------------------------------------- L7 Loadbalancer Current Sessions: 0x341154e3310: proto=unix_stream src=unix:1 fe=GLOBAL be=<NONE> srv=<none> ts=09 age=0s calls=2 rq[f=c08200h,i=0,an=00h,rx=20s,wx=,ax=] rp[f=008000h,i=0,an=00h,rx=,wx=,ax=] s0=[7,8h,fd=1,ex=] s1=[7,0h,fd=-1,ex=] exp=20s Step2: I stop Apache on Server2 root@Web02:~# service apache2 stop And I validate the Edge detected Server2 DOWN NSX-edge-3-0> show service loadbalancer pool Pool-Web01-http ----------------------------------------------------------------------- Loadbalancer Pool Statistics: POOL Pool-Web01-http |  LB METHOD round-robin |  LB PROTOCOL L7 |  Transparent enabled |  SESSION (cur, max, total) = (0, 1, 7) |  BYTES in = (1197), out = (1911)   +->POOL MEMBER: Pool-Web01-http/web01, STATUS: UP   |  |  HEALTH MONITOR = BUILT-IN, default_http_monitor:L7OK   |  |  |  LAST STATE CHANGE: 2015-09-25 06:51:49   |  |  SESSION (cur, max, total) = (0, 1, 5)   |  |  BYTES in = (855), out = (1365)   +->POOL MEMBER: Pool-Web01-http/web02, STATUS: DOWN   |  |  HEALTH MONITOR = BUILT-IN, default_http_monitor:L4CON   |  |  |  LAST STATE CHANGE: 2015-09-25 07:08:32   |  |  |  FAILURE DETAIL: Connection refused   |  |  SESSION (cur, max, total) = (0, 1, 2)   |  |  BYTES in = (342), out = (546) I can also validate the persistence entry is still there using Server02 NSX-edge-3-0> show service loadbalancer table ipv4_ip_table_Pool-Web01-http ----------------------------------------------------------------------- L7 Loadbalancer Sticky Table [ipv4_ip_table_Pool-Web01-http] Status: # table: ipv4_ip_table_Pool-Web01-http, type: ip, size:1048576, used:1 0x341154e94d8: key=20.20.20.1 use=0 exp=183452 server_id=2 conn_cnt=0 conn_rate(60000)=0 conn_cur=0 sess_cnt=0 sess_rate(60000)=0 http_req_cnt=0 http_req_rate(60000)=0 Step4: I access the VIP from client 20.20.20.1 and I'm redirected now to server1 (test.php is a specific page displaying the server IP@) vyatta@vyatta:~$ curl http://20.20.20.2/test.php The Client IP@ is: 20.20.20.1<br> The Server IP@ is: 10.1.1.11 I validate also the persistence table for the Client (20.20.20.1) NSX-edge-3-0> show service loadbalancer table ipv4_ip_table_Pool-Web01-http ----------------------------------------------------------------------- L7 Loadbalancer Sticky Table [ipv4_ip_table_Pool-Web01-http] Status: # table: ipv4_ip_table_Pool-Web01-http, type: ip, size:1048576, used:1 0x341154e94d8: key=20.20.20.1 use=0 exp=288973 server_id=1 conn_cnt=0 conn_rate(60000)=0 conn_cur=0 sess_cnt=0 sess_rate(60000)=0 http_req_cnt=0 http_req_rate(60000)=0 Conclusion: I'm using the latest NSX-v build (6.2.0), but I don't think this would be different in older releases. The only explanation I can think of is, you're using a browser and the TCP connection of your browser pointing to the VIP (and then load balanced to the server) is NOT closed by your browser. In that case when the server becomes DOWN, the Edge LB still forward packets in that TCP session to the server DOWN. The reason is, the load balancer could NOT forward it to the other server since the other server did not see the beginning of that TCP session. However new TCP session from that client would go to the new server and the persistence table would be updated accordingly (as show above in the very detailed steps). Dimitri