{"id":4603,"date":"2019-08-28T17:45:30","date_gmt":"2019-08-28T13:45:30","guid":{"rendered":"https:\/\/rakhesh.com\/?p=4603"},"modified":"2020-03-05T15:11:30","modified_gmt":"2020-03-05T11:11:30","slug":"exchange-2016-nsx-edge-load-balancing","status":"publish","type":"post","link":"https:\/\/rakhesh.com\/exchange\/exchange-2016-nsx-edge-load-balancing\/","title":{"rendered":"Exchange 2016 & NSX Edge load balancing"},"content":{"rendered":"

This is going to be a quick and dirty post with not much details. Sorry. Spent some time figuring this out today and I wanted to put it here as a reference for anyone else.\u00a0<\/p>\n

At work we needed to setup two Exchange 2016 servers behind an NSX Edge load balancer. We wanted to capture the source IP too so this meant we had to use the load balancer in transparent mode. A colleague had set it up already but the Exchange servers weren’t seeing the source IP so I took a look to see what was missing. I had to make two changes primarily to get it working.\u00a0<\/p>\n

First<\/strong>: the Edge had two interfaces assigned to it. One for HA, another that connected to the backend servers. The VIP for the Edge was also in the second subnet. (This needn’t always be the case. I think a usual scenario is for the VIP to be on a different subnet so YMMV). For the Edge to pass on the source IP to the Exchange servers I knew I had to set it up in a transparent mode<\/strong>. This means the Edge passes<\/em> on any packets it gets off to the appropriate backend server. It does not change the IP in the packet to be itself, so the backend server see the correct source IP. The problem with this though is that the backend server will then send this packet to its default router and from there to the source IP … which we don’t want. We want the source to only see the Edge VIP always and this means we need the return traffic to come back to the Edge, and the Edge will do a NAT to change the backend server IP to be the VIP.\u00a0<\/p>\n

(This blog post<\/a>\u00a0might be a good starting point to read more on the above).<\/p>\n

For an Edge to be setup in this fashion we have to set the Edge as the default gateway for the backend servers. (Which is straight-forward – just change the default gateway in the server OS). But for the Edge to then act also as a router for the backend servers we have to tell it that such and such IP is on an internal network and it is ok to do routing on that. In our case the HA network had been set as of type Internal, but the network that was connecting to the backend servers was incorrectly set as Uplink. I changed its type to Internal. This is important as this is what tells the Edge that it can now route any traffic coming to the IP addresses defined on that interface.\u00a0<\/p>\n

\"\"<\/p>\n

This done, I went to the two backend servers and changed their default gateway to be the IP defined on the above Internal interface (vNIC0 in my case). I tested connectivity and also did a trace route to confirm it is going via the Edge. Great!<\/p>\n

Second<\/strong>: By default an Edge load balancer is in L7 mode.\u00a0When in L7 mode the Edge doesn\u2019t forward on the packets it receives. It initiates a new connection to the Exchange servers, so the source IP is itself and defeats what we are trying to do. L7 mode is useful if we are doing any L7 manipulation such as SSL termination, cookie based persistence, URL rewriting, header insertion, etc. We are not doing anything like that here so I changed the mode to L4. This is done by enabling acceleration.\u00a0<\/p>\n

\"\"<\/p>\n

Did the same in the virtual server too (this option is only available after enabling it in the above section).<\/p>\n

\"\"<\/p>\n

Lastly, I enabled transparent mode on the pool.<\/p>\n

\"\"<\/p>\n

That’s all!<\/p>\n","protected":false},"excerpt":{"rendered":"

This is going to be a quick and dirty post with not much details. Sorry. Spent some time figuring this out today and I wanted to put it here as a reference for anyone else.\u00a0 At work we needed to setup two Exchange 2016 servers behind an NSX Edge load balancer. We wanted to capture … Continue reading Exchange 2016 & NSX Edge load balancing<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[86,183],"tags":[521,660],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/4603"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=4603"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/4603\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=4603"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=4603"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=4603"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}