cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
692
Views
1
Helpful
5
Replies

Weird CSS forwarding Issue

m.magnani
Level 1
Level 1

Hi all.

I am having some weird forwarding issue using a pair of 11503 CSS (Box-to-box redundancy).

Here is my L3 network topology:

Internet

|

-----------

| CP FW-1 |

-----------

|

|

-----------

|6500-Sup720|

-----------

|

|

-----------

| CSS 11503 |

-----------

|

|

------------

|

Client

I have drawn only one device because redundancy is achieved via HSRP on 6500, Active/Standby on CSS.

Moreover, L2 connectivity is provided by 2 4507 (CSS are connected 1 x 4500 on different vlans), connected to the 6500 via gigabit fiber connections.

A LDAP server is located on the internet and when the client tries to issue an LDAP query, it could take up to 2 minutes to have the reply back (20 seconds in the best cases). If I move the L3 on the 4500 or the 6500, the request takes form 1 to 2 seconds to complete.

We have tried both CSS, both 4500, both 6500, different clients with the same results. We upgraded the WebNS to the latest release (7.50.004). We changed physical cables, physical ports on CSS and switches, moved clients on other vlans on CSS, 4500 and 6500 and the results are always the same.

Neither errors on CSS interfaces, nor on 4500 interfaces, nor on 6500 interfaces.

I captured traffic via snoop on the Sun Client, and also with monitoring session on catalyst 4500, and when the CSS is routing, I can see lots of duplicate acks, tcp out of sequence, retransmissions which disappear when routing is performed by 6500 or 4500.

I was wondering if there is anything connected to the L3 1500 bytes size of every frames (the query produces an output of about 600k). We are at the L3 MTU limit... We also tried with ftp, but in that case everything was fine also with CSS. It looks like there something ldap related at least. The ldap query is a normal query, tcp port 389. The command come and go very well, the actual data transfer produces all the crappy tcp output (retransmission, lost segments ecc...).

I am very confused, CSS is not balancing, it's only forwarding traffic.

Sorry for my long post, any help will be really appreciated!

Regards

Massimo Magnani.

5 Replies 5

pradeepde
Level 5
Level 5

From your statements i understand that you want to know how to load balance using CSS. Content rules are where the CSS's load balancing features are customized, virtual IP address are defined, and where the actual servers (called services) are bound to that virtual IP address. Content rules allow you to specify load balancing types, sticky methods, port specific Virtual IP addresses, and a host of other features Refer to the following URL to understand how CSS load balancing works and how CSS load balancing can be configured.

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_configuration_example09186a008009438d.shtml

Gilles Dufour
Cisco Employee
Cisco Employee

Massimo,

can we have the configs and traces ?

That would help understand the problem.

Gilles.

Sorry I couldn't attach the files due to one error on the interface. I'll try again now.

Thank you

Massimo

Hi Massimo,

I can't see any kind of stickiness under LDAP content. This way CSS sends every packet to different LDAP server. Try to stick session to source IP.

Lubomir

Massimo,

the config alone is not every usefull.

We'll need a sniffer trace captured in front of the CSS and showing the complete LDAP session when there is a delay and when there is no delay.

Thanks,

Gilles.

Review Cisco Networking for a $25 gift card