Hi I am pretty new to the Content switches. I have a portal running in a unix cluster. it has 2 similar instances each for http and https, running on different ports. i have to load balance the http trafic between ins-1-http:5001, ins-2-http:6001 for http and ins-1-https:5002, ins-2-https:6002 for https. all the instances are pointing to the same ip address only. Please see the attached file for the network diagram and configureation. it seems like the back end connection with the server is not happening and I am not getting any response back from the server.Please correct me if i did some thing wrong in the configuration at any level.
Thanks for the help. i have 2 more questions. after i have the css working perfectly, the application guys are asking for the source address, which is the IP of the actual client who is requesting the service; to be seen in their application. right now their application sees the vip address of the css only. is it possible to configure the CSS to meet their requirement?
Q2: can i add more interfaces to VLAN5, if I add more interfaces, will the traffic pass through all of them or any additional configuration is requried?
we cannot change the gateway in the servers. The current setup is fine, the only requirement is to pass the Ip address of the requesting host. is there any work around to make it possible keeping the current configuration?
It is a requirement for the traffic to flow back thru the CSS. The reason why this is happening is because of the source NATing, without that you will have an asymmetric flow.
In a one-arm setup the group is what is currently used, anyway you can have the workaround of using the CSS as default gateway of the servers and disable ICMP redirects.
I do not think that there is anything else to change the behavior, with your current design and if the gateway change is not a possibility, well you will not be able to see real client's IP reaching the servers.
This is actually the issue,
Client sends a SYN with source IP 18.104.22.168 destined to the VIP.
Without NAT the CSS will send the SYN to the server with source IP 22.214.171.124
The server will see the SYN coming from 126.96.36.199 and will answer the SYN/ACK to that IP which will bypass the CSS.
The client gets a SYN/ACK from 188.8.131.52 but it did send a SYN to 184.108.40.206, so the packet is dropped.
So, it is "must" that the frames flow back thru the Load Balancer.
There are other balancers (such the CSM) that support bypassing the LB on the way back by implementing DSR (Direct Server Return), but this is not a possibility on the CSS.
The unmanaged mode is also known as Network only switching, which is introduced in Brazos release. It adds the flexibility for customer to use only network automation for service appliance.
If a device is configured a...
Usually, we can access ESXi Shell by pressing Alt+F1 from ESXi DCUI (Direct Console User Interface).
But on HyperFlex system, it just shows black window.
This is expected behavior because HyperFlex redirects ESXi Shell output to SoL...
Configuring an Export Policy Using the GUI
This procedure explains how to configure an Export policy using the APIC GUI. Follow these steps to trigger a backup of your data:
On the menu bar, choose Admi...