ACE30: Connectivity between IP subnets on the same VLAN
We have a subnet setup on the ACE as follows:
interface vlan 300
description CALLISTA Environment
ip address 2001:388:608c:8b8::fffd/64
peer ip address 2001:388:608c:8b8::fffc/64
ipv6 nd ra interval 30
ipv6 nd prefix 2001:388:608c:8b8::/64
ip address 188.8.131.52 255.255.255.192
ip dhcp relay server 184.108.40.206
ip dhcp relay server 220.127.116.11
alias 18.104.22.168 255.255.255.192
peer ip address 22.214.171.124 255.255.255.192
ip address 126.96.36.199 255.255.255.224 secondary
alias 188.8.131.52 255.255.255.224 secondary
peer ip address 184.108.40.206 255.255.255.224 secondary
access-group input ALLOW
access-group input ALLOWv6
access-group output ALLOW
access-group output ALLOWv6
nat-pool 1 172.16.25.231 172.16.25.231 netmask 255.255.255.255 pat
There is the primary subnet 220.127.116.11/26 and the secondary IP subnet 18.104.22.168/27
The nat-pool is configured to allow server initiated connections to their frontend VIP when necessary.
We are noticing that when a server on the 22.214.171.124/27 subnet needs to communicate with a server on 126.96.36.199/26, albeit on the same VLAN, the destination server sees connections with a source IP of 172.16.25.231, which is the NAT address. Is this expected behavior, where connections between IP subnets, albeit on the same VLAN are NATed?
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...