01-11-2005 11:44 PM
Hello,
I have an applications which connects to a VIP defined as 140.168.172.200 on ports 5555 5565 5575 5585 and 5595. The service associated with this VIP in the content rule is defined as follows
service av-testeai-01
ip address 140.168.170.53
protocol tcp
port 5595
keepalive type tcp
active
Why does the VIP always forward through only on 5595 irrespective of the original port (eg 5565 etc) - Is it because of the manner in which the service is defined. I tried defining a range of ports but could not get the switch to accept the config, see below.
svjmebdc002(config-service[av-testeai-01])# port 5500 range 5599
%% Invalid mapping of rule to service port ranges
01-12-2005 06:41 AM
Hi,
Can you please clarify your configuration? Do you have five (5) VIPs configured, one for each port (5555, 5565, 5575, 5585 and 5595)?
When you say that only port 5595 is forwarded, are you referring to traffic from the client to the CSS, or from the CSS to the backend server?
With regards to the command syntax, the 'port X range Y' command expects 'Y' to be a numeric count of how many ports to increment, not the max port in the range. So for instance, if you wanted to allow ports 5555 through 5595, the command would be:
port 5555 range 41
~Zach
01-12-2005 01:57 PM
Hello Zach,
Only a single VIP has been configured for the host on port 5595. When I say its only forwarding to port 5595 this refers to connections between the CSS and the backend server.
I have also tried what you suggested around specifying the range and using a 'Y' value to represent a numeric count to the upper limit of the port range also causes the same error message.
Regards
Mark
01-12-2005 02:21 PM
Mark,
I am unable to reproduce the problem you are having. Can you please post the configuration from the VIP in question?
In addition, please reference the post from Gilles regarding the expected behavior of your configuration.
Thanks,
Zach
01-12-2005 06:54 AM
if you specify the port udner the service definition it forces the CSS to change the destination port to this one when sending traffic to the real server.
You should either remove the port from the service definition so the CSS will not change the destination port used by the client.
Or you should create a service for every port you need and use those services with appropriate content rule.
If you don't need any port translation, you should use the first solution with a layer3 content rule [no port as well].
Regards,
Gilles.
01-12-2005 04:16 PM
Hello Gilles,
I have tried the approach you suggested however when I removed the port statement the service went into a 'down' state.
I managed to get around this by modifying the keepalive statement to use one of the ports the server listens on i.e. keepalive port 5595
However the customer repors the issues has not been resolved.
01-12-2005 07:45 PM
Hello Gilles,
I have to make a retraction, by removing the port statement from the service configuration it stopped PAT translating everything to port 5595. Instead if a client connection is received by the VIP on say port 5585 then it is forwarded to the appropriate server on port 5585.
However it was necessary to add two keepalive statements 'keepalive type tcp' and 'keepalive port 5595', so the CSS was able to determine if the service was available on the server configured within the service configuration - otherwise the CSS saw the service as down.
The customer is now happy - thank you very much for you assistance.
01-12-2005 03:53 PM
Thank-you Zach
Please find attached the configuration for our two content switches, note the the issue we are experiencing is for the av-testeai-01 and av-testeai-02 services (though I assume we will see the same issue for the production services as well).
I will also address Gilles' post as well
01-12-2005 07:54 PM
Thanks for the configuration, that helped to clarify things. I was able to reproduce the error you are seeing. The CSS is objecting to having two (2) services configured with dissimilar port ranges. To make the change you want, you will need to remove the services from the content rule, suspend the services, change the port designations, activate the services, then add them back to the content rule.
**OR**
Do as Gilles recommended. :) The reason the service 'died' when you removed the 'port XXXX' designation, is because if no port is specified with the 'port X' command, the keepalive defaults to port 80. So if the real servers aren't listening on port 80, they will appear down to the CSS. You can change the keepalive port used with the command 'keepalive port X'.
Hope this helps!
~Zach
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide