I am trying to understand the rationale for destination source group, where one NATs source IP addresses and source ports for flows originating from a client on the public side of the CSS.. Wouldn't those addresses be public in the first place, so why NAT them?
I understand your point, but it seems to me that using the group/destination source, the source address is translated to the VIP (on the public side) and not to the redundant-vip (on the private side).
If the server's default gateway doesn't point toward the CSS, this configuration makes it respond to the CSS on the public side. While this isn't a real problem, it's not really optimal in case the Server and the CSS are in the same private subnet. It would be better if the server can respond to the CSS on it's private side interface.
Question : is it possible to achieve this by making the CSS NAT the source address to its redundant-vip instead of its vip?
Way back when, we were told to put the CSS in the network path between back-end servers and clients.
With the source group, the CSS becomes a true NAT proxy, not just a "splicing" device. So the CSS may no longer be "between" source and destination.
I used to have my network like this
Router <-> firewall <-> CSS <-> LAN switch.
Problem was, if the CSS went down or rebooted, it was 5 minutes or so before I could pass any traffic to devices on that LAN switch. But I never had to worry about out-of-path returns as the CSS was always "between" the clients and the backend servers.
Now, I have it set up like this:
Router <-> firewall <-> LAN Switch, and the CSS hangs off of the LAN switch. When my CSS died one day and rebooted, I didn't lose connectivity with all the un-balanced servers on that LAN. All I lost was the CSS VIPs.
Thanks for the responses. I understand the underlying reasons for using the source groups. I also understand the concept behind the source groups as the servers, by and large, have private addresses assigned to them. What I am trying to clarify is why do we need to NAT the clients' already public addresses when using the destination service to a group? Am I missing something here?
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...
RBAC users like email@example.com may fail HX Connect login. At that time, "Incorrect user name or password(100005)" is shown as a failure reason.
RBAC users can login to vCenter server. So, RBAC username and passwo...