networking - Secondary IPs on DMZ machines not working

I am moving some virtual machines from my DMZ in a bladecenter over to my new cisco UCS. We are using Hyper-V, and are running Server 2012 on the old bladecenter, and Server 2012r2 on the new UCS.

We have a Cisco ASA 5515 firewall, asa version 9.1(4), that is our gateway for both LAN and DMZ traffic.

In the old bladecenter, we have a virtual machine that exists in the DMZ, with one network interface configured. On this network interface, it has a primary IP, let's say 172.10.1.10, and some additional IPs configured, 172.10.1.11, 172.10.1.12.

All of these work, and route normally, no issues.

We migrated a machine from the bladecenter to the UCS, and have trouble now with it's secondary IPs on the DMZ.

So this machine in the UCS exists in the DMZ, has one network interface configured with a primary IP, let's say 172.10.1.15, and secondary IPs 172.10.1.16, 172.10.1.17.

I can ping the primary IP (.15) from anywhere on the network. However I cannot ping (or connect in any way) to the secondary IPs (.16, .17) from anywhere except other machines in the UCS environment.

Important note:
I have a virtual machine on the UCS environment that is on my LAN. It has primary and secondary IPs that all work fine. For instance, it's primary is 192.168.1.20, and it has secondary of 192.168.1.21 and 192.168.1.22. I can hit .21 and .22 from everywhere.

The problem seems to only be with the DMZ secondary IPs in the UCS environment.

I do not think that it is a Windows/HyperV problem.

No configuration changes have been made to the ASA.

The UCS vendor is certain that it's not a problem in UCS.

Has anyone seen anything like this? Any suggestions are appreciated!

edit: added asa version

edit: if I tracert from a workstation to the primary IP, I get 1 hop, no problem. If I tracert to the secondary IP, it fails to route and I just get stars.

tracert 172.10.1.15
Tracing route to test.domain.com [172.10.1.15] over a maximum of 30 hops:
1  2 ms   1 ms   <1 ms  test.domain.com [172.10.1.15]
Trace complete.

tracert 172.10.1.16
Tracing route to test.domain.com [172.10.1.16] over a maximum of 30 hops:
1  *  *  *  Request timed out.

2  *  *  *  Request timed out.
3  *  *  *  Request timed out.
4  *  *  *  Request timed out.
5  *  *  *  Request timed out.
6  *  *  *  Request timed out.
7  *  *  *  Request timed out.
8  *  *  *  Request timed out.
9  *  *  *  Request timed out.

Edit: I can SSH into my ASA, and if I ping the DMZ machine in the bladecenter, primary and secondary IPs respond just fine. If I ping the DMZ machine in the UCS, primary IP responds, secondary IPs do not.

Edit: from the DMZ machine in the bladecenter, I cannot ping to primary or secondary DMZ IPs on systems in the UCS environment; however, I can ping FROM a DMZ machine in UCS TO a DMZ machine in the bladecenter, on primary and secondary IPs.

Edit: if I tracert from a system in the bladecenter, to a system in the UCS, I get this:

Tracing route to test.domain.com [172.10.1.15]
over a maximum of 30 hops:

  1  Server1 [172.10.1.10]  reports: Destination host unreachable.


Trace complete.

DoubleEdit: to joeqwerty's question about ARP, I do see arp entries in the ASA for at least one set of primary and secondary IPs. Looks like if I swap the primary and secondary IP addresses on a server's NIC, it builds the ARP in the firewall and then it appears to work! But shouldn't the ASA be doing ARP for those secondary IPs anyway??

Answer

Thanks to joeqwerty who helped get me pointed in the right direction.

The problem was twofold, the ASA was not correctly creating ARP entries dynamically. We got that squared away, but then found that we also had a VLAN problem.