About Me

My Photo
TsooRad is a blog for John Weber. John is a Lync Server MVP (2010-2014). My day job is titled "Principal Consulting Engineer" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.

2014/03/07

Kemp 7.0.12a Two Arm bug

Update: 14 March 2014

According to Derek Kiely (Kemp), the fix will be in a 7.0-14 firmware release due out this month (see his comment below).

 

The Issue

Working in my lab making sure I know what I am doing with a two-arm Kemp LoadMaster configuration.  Here is what I am attempting to setup:

image

I am using a Kemp VM100 (firmware 7.0.12a) with content rules to redirect 443 traffic to various target virtual servers.  Specifically, the LM has one leg in 10.10.10.0./24 and one leg in 1.1.1.0/24.  HTTPS comes into a Virtual Service on one single IP (10.10.10.58) and uses various rules to redirect traffic to either a 10.10.10.0/24 network host or a 1.1.1.0/24 network host.

According to the super-helpful folks at Kemp support, there is a bug in Kemp firmware 7.0.12a that results in abysmal failure on this setup.  Apparently, the traffic is landing on the 10.10.10.58 service correctly, and heading off to the underlying real server correctly, but it is arriving at the 1.1.1.73 (my Lync WAS test case) as a 10.10.10.58 source when it should be showing up as a 1.1.1.x source. 

But what do I do NOW?

The fix is to put a static route into the target real server.  Here is my LyncWAS server (1.1.1.73) route table with the fix in place. If you are curious, the command is (from an elevated CMD):

Route add –p 10.10.10.58/32 1.1.1.5

This identifies the traffic from the virtual service on the LM and send responses back to the LM on 1.1.1.5 which knows what to do with the traffic.

image

Why does this work? 

Well, the traffic shows up on the LyncWAS (1.1.1.73) but appears to be originating from the KempLB but from the 10.10.10.58 address (which is correct from one point of view).  But the 1.1.1.73 server thinks that to get to the 10.10.10.0 network, it needs to talk out its’ default route of 1.1.1.2.  And your connection fails because the real server is sending responses out the wrong gateway.  By adding the static route for the expected source IP, and pointing it to the KempLB, we now have a coherent route for the traffic.  A bit clunky for now, but it works.

My thanks to Kemp Tech support for identifying this issue.  Kemp is providing a fix in the next release which is due out shortly.

YMMV

2 comments:

Derek Kiely said...

Issue has been resolved. Version 7.0-14 is due for release this month.

Derek Kiely said...

Hi John, this issue has been resolved and will be fixed in 7.0-14 that is due for release this month.