I was just having some server initiated printing problem thru CSM on our 6500, which is still an open case here in this forum, and now here comes a more critical problem.
We did not experience any problem accessing the load balanced web servers using the CSM for the past 3 days that it was up, till yesterday.
Some workstations can access the SLB web servers while others cannot.
Change the ip address of the workstations which cannot access, to an unused ip address and it will work fine.
It looks like this IP addresses were blocked somewhere on the core switch or on the CSM.
Is there any way i could see what actualy happened? A day before that, a host was by mistake, configured with an ip address the same as the virtual ip. This has created a conflict on the CSM but was rectified right away.
Any help will be appreciated.
Thanks a lot.
one suggestion to see if the CSM or the switch blocked the address is to sniff the port-channel going to the CSM.
Like this you can see all traffic going in and out of the CSM.
If you don't see traffic going in for your specific address, it will mean the problem is before the CSM.
I have seen a similar situation. Users on the same subnet as the real servers could not access the servers. The problem was that the client requested the connection to the VIP and the return traffic from the server went directly to the client on the same subnet bypassing the CSS in that direction. The client was not expecting the traffic from the real server and would not associate this with the original request.
Since I couldn't talk the network administrators to move to a seperate subnet, I had to NAT the source address on the CSS for any traffic that originated on the server subnet.
This looks very similar to something I have seen
Some IP addresses cannot access the servers using the VIP when going through an IP tunnel (CSM ver 3-1-5)
the reason is ICMP unreachables sent due to the reduced MTU of the tunnel get mangled in certain circumstances and the server cannot do PMTU hence the connection stops
It happens when using any protocol any port on a vserver so a workaround is to reconfigure the vserver for TCP any this forces it into layer 4-7.
like this ;-
virtual 188.8.131.52 TCP any
hope this helps
configure the tcp any just make the rule L4 and the behavior is exactly the same [more or less] as a L3 rule.
So you will have to explain me how this would solve the PMTU discovery problem.