×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

seeing connection sourced out of the layer 3 int as opposed to the VIP on CSS

Unanswered Question
Jan 30th, 2014
User Badges:

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   

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Fnu Kanwaljeet Singh Thu, 01/30/2014 - 13:07
User Badges:
  • Cisco Employee,

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

axfalk Thu, 01/30/2014 - 13:39
User Badges:

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..

axfalk Thu, 01/30/2014 - 13:40
User Badges:

correction, the sh flows command was as per the following:

css1# sh flows | grep  15.10.16.15



_greg

Fnu Kanwaljeet Singh Thu, 01/30/2014 - 14:04
User Badges:
  • Cisco Employee,

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

Actions

This Discussion