01-30-2014 12:51 PM
We're running CSS version 7.50, where the back-end servers r NOT directly connected to it, so used the destination service to NAT them to the VIP, as in the following:
group PAD-CAT-PROD
vip address 10.2.10.15
add destination service pad-cat-prod-1
add destination service pad-cat-prod-2
active
When we setup sniffers on the switch where the back-end servers are patched into, we were expecting to see the connections to these servers coming from the 10.2.10.15 VIP, however, instead, we're seeing connections to these back-end servers coming from the CSS's loopback address, 10.123.12.9.
Anybode has seen this type of behavior on a CSS?
Thanks.
_ greg
01-30-2014 01:07 PM
Hi Greg,
Have you added the same services under the appropriate content rule? Your group configuration looks good and it should not use any other IP than the one which you have defined in group configuration unless it is a bug. Just ensure that the configuration is not missing or conflicting. Some important point listing here from user guide:
1)The destination service must be active and must be added to a content rule for it to perform destination source address NATing for the source group.
2)You can use services with duplicate addresses among destination services because the actual service is chosen through content rule selection.
3)You cannot use a service with the same name in other source groups or use the source service list within the same source group.
Regards,
Kanwal
01-30-2014 01:39 PM
hey Kawval, thanks for your response.
Yea, I'checked to make sure the content rule is the correct one..
owner PAD-INTRANET-CAT-PROD
content PAD-CAT-PROD
vip address 10.2.10.15
add service pad-cat-prod-1
add service pad-cat-prod-2
advanced-balance sticky-srcip
sticky-inact-timeout 25
active
The odd thing is this is not a new config and from the sniffer trace, it's looking OK as far as the 3 WHS, etc...
So, did the sh flows command and saw the following:
css1# sh flows | grep 155.108.160.153
10.216.210.49 49011 10.2.10.15 3335 15.10.16.15 TCP 1/1 1/1
15.10.16.15 3335 10.2.10.15 36893 10.216.210.49 TCP 1/1 1/1
15.10.16.15 443 10.123.12.9 11534 0.0.0.0 TCP 1/2 Ipv4
the first 2 lines are looking OK - the client 10.216.210.49 hits the VIP 10.2.10.15 that forwards it to the back-end server
15.10.16.15. Then the server responds back to the VIP, that sends it back to the client. The odd thing is the server is listening on port 443, which is the third line, but it reponds to the loopback address 10.123.12.9....hmmm...
_greg..
01-30-2014 01:40 PM
correction, the sh flows command was as per the following:
css1# sh flows | grep 15.10.16.15
_greg
01-30-2014 02:04 PM
Hi Greg,
But third line destination port is not what client or CSS sent to the server at first place, i mean the source port i see are different.
Do you think there is a bad route on server or something? Even the interface is different too.I don't see any problem with configuration though and as you said it was working before. What has changed? Happening with both the servers or just one server? In sniffer trace what is the source IP you see CSS used to forward the traffic to server?
Regards,
Kanwal
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