cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1133
Views
0
Helpful
4
Replies

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

axfalk
Level 1
Level 1

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   

4 Replies 4

Kanwaljeet Singh
Cisco Employee
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

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

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

css1# sh flows | grep  15.10.16.15

_greg

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: