We've got a CSS running software 8.1 and we're performing source NAT on IP addresses in our back-end networks to a IP addresses on a front-end network.
Essentially each IP on the back-end is transleted to a single IP address on the front-end (customer side) network, for example:
service Service_Example1 ip address 10.0.0.1 active
group NAT-Example1 vip address 192.168.100.100 add service Service_Example1 flow-timeout-multiplier 1350 active
The problem we're experiencing is that the CSS upon performing source NAT for connections outbound from the back-end, it also randomizes the source TCP port for the outgoing packet which poses a problem with an application which expects the TCP source port to be within a very tight range.
Restricting the port-map range for the NAT also doesn't help as it will still randomize the TCP source port but just to a smaller range.
I know that the source port randomization can be disabled for UDP flows but can this be done for TCP and if so, how?
Instructs the CSS to perform Network Address Translation (NAT) only on the source IP addresses and not on the source ports of UDP traffic hitting a particular source group. This option does not affect TCP flows.
For applications with high-numbered assigned ports (for example, SIP and WAP), we recommend that you preserve those port numbers by configuring destination services in source groups. Destination services cause the CSS to NAT the client source ports, but not the destination ports.
Note If you disable flows for a UDP port using the flow-state table and configure the portmap disable command in a source group, traffic for that port that matches on the source group does not successfully traverse the CSS.
The CSS maintains but ignores any base-port or number-of ports (see the options above) values configured in the source group. If you later reenable port mapping for that source group, any configured base-port or number-of ports values will take effect. The default behavior for a configured source group is to NAT both the source IP address and the source port for port numbers greater than 1023.
There is no possibility to disable it for TCP.
We need to source nat the port to guarantee that the server response comes back on the same module/CPU and the internal packet allocation algorithm is based on src and dst ports.µ
Yes, I realised I had forgotten the last part and updated my initial comment.
This does not apply to TCP and therefore there is no solution for TCP.
This behavior is required because the CSS is modular and all modules participate to packet processing.
The traffic is assigned to the modules based on a hash of the src and dst port.
Since one module needs to process inbound and outbound traffic of a single connection, we need to guarantee that the hash of the nated traffic does come back to the same module...so we change the src port since normally the src port should not matter for an application.
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...