Cisco – Can we have same IP addresses of PCs connected to a switch port with different VLAN Ids

The switch will fully load the incoming frames of data, from the two sending systems, into its buffer(s). I'm not sure how it determines which frame would be first in the queue for subsequent forwarding; but it's probably based on initial receive time of the beginning of the frame. Then the switch works through the transmit buffer queue sending the frames out one-by-one onto the destination port/segment.

There's no issue with frames "running into each other." The real issue is can the ultimate port/segment accept the frames fast enough. (And, of course, can the switch process its buffer/queues fast enough.)

Let me start by saying proxy ARP is at best a sloppy solution. They only time I found it useful as a feature is when I was dealing with devices on the network that could not utilize classless netmasks or couldn't set a default route.

Yes, it can "cover" many client configuration or bad design problems, but it doesn't fix those problems. It also doesn't "cover" all of them and it can make troubleshooting issues more difficult.

Getting back to your question, the most likely reason this isn't working is that your client's aren't ARPing. My guess is that you have given them what is often considered a "standard" network mask of /24. In your example, there is likely no solution to get proxy ARP to work as clients should not accept a network mask less than /8 so your client will never think the destination is on the local network and send out an ARP request.

Why? A client uses it's IP address and network mask to determine if a destination is on the local network or not. If it is on the local network, the client checks it's ARP table for any entries for the destination and if one doesn't exist, will send out an ARP request to get this information. This is where the router with proxy ARP enabled can respond, but if there is no ARP request then the router cannot provide a proxy ARP response.

If the destination is not on the local network, then the client will check it's routing table to see where to forward the traffic. This is typically your default gateway.

Now, with the IP addresses you used, when the client checked the destination against it's IP/mask, it would find the destination is not on the local network. Going to the routing table, it won't have a specific entry for the destination network (clients won't by default) and no default route/gateway. It will then fail with a "no route to host" type of message.