About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. 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. 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:

Unknown said...

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

Unknown said...

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

test 02 Feb

this is a test it’s only a test this should be a picture