Basically we have a running ACE context which works however we are using natting and we have some applications complaining that they can't see the source address of things. So I created a whole new context with the following config but I have the problem of when the client is on the server side network the traffic never makes it there.
ACE1/10.0.0.0_Network# sho run
access-list ALL line 8 extended permit ip any any
rserver host CE-565-1
ip address 10.0.2.83
serverfarm host Content_Engine_SF
class-map match-all Content_Engine_VIP
2 match virtual-address 10.0.18.101 any
class-map type management match-any Remote_Management
2 match protocol http any
3 match protocol icmp any
4 match protocol telnet any
5 match protocol ssh any
policy-map type management first-match rmt_mgt_policy
policy-map type loadbalance first-match Content_Engine_VIP-l7slb
policy-map multi-match int18
loadbalance vip inservice
loadbalance policy Content_Engine_VIP-l7slb
loadbalance vip icmp-reply active
access-group input ALL
interface vlan 3
ip address 10.0.3.240 255.255.254.0
interface vlan 18
description Client Side Network
ip address 10.0.18.251 255.255.255.0
service-policy input int18
ip route 0.0.0.0 0.0.0.0 10.0.18.1
if I telnet to the vip from my machine 172.16.6.222 it works fine. If I telnet from 10.0.18.30 it works fine. However when I telnet from a machine on the vlan 3 10.0.2.188 it does not work. I would have thought the mac-sticky option would work but it seems to be doing nothing. Any ideas with out using a NAT pool would be great so we can see the originating IP Address.
If you are initiating traffic from serverA to a vip that load balances to serverB in that same vlan you will have an asymmetric flow. ServerA is on the same vlan as serverB. Since both servers are in the same subnet, ServerB will ARP for serverA address and send the response directly to serverA. The traffic will never make it back to the ACE. There are a few things you can do:
1. Use NAT to ensure the return traffice makes it back to ACE.
2. Insert HTTP header with client IP address. This only works for HTTP traffic and your application must be able to recognize this header for logging.
3. Use Direct Server Return (DSR). This feature has been committed to ACE 2.0. This will require the servers to be L2 adjacent to the ACE module and you will need to configure the VIP address as a loopback address on the server. Here is CSM documentation that lists some of the limitations with DSR:
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...