I may need help tracing the packet beyond the L3Out. Here is what I have so far
Site-A VM can ping Site-B VM
Site-B VM can't ping Site-A VM
For the record, other servers in Site-B are fine and are working normally. This is specifically for new endpoints in a new BD/EPG.
Both are multi-site ACI endpoints in different vCenter VMM domains (immediate resolution) on separate Fabric Interconnects so two datacenters. The EPGs aren't stretched and therefore have L3Outs on their BDs.
To rule out contracts, I unenforced the policy control at the VRF level.
To rule out local L2 and run apic# show endpoints ip x.x.x.x it learns MAC/IP from vmm domain via the vPC policy.
I ran LF# show ip route bgp vrf all | egrep x.x.x.x (remote endpoint net ID) and it contains the source network out a tunnel TEP. I don't know how to trace the packet after that.
I also successfully ran LF103# iping -V tn:vrf -S <ip address> <ip address> (src bd gateway > dst host). It pings fine. Meaning the BD gateway in Site-B can ping the Site-A host. I think that's what I was testing anyways.
The BDs are using Hardware Proxy but I did a constant ping from the source VMs but not the destination and arp glean is turned off of the BD. Does that mean I need to ping the source host from the remote endpoint to wake it up in the case of a silent host?
That's as far as my experience takes me atm. Can someone help me use a more methodical process for tracking down where the problem lies? Again, just trying to get new endpoints in a new EPG/BD in Site-B to ping endpoints in Site-A.
