I feel so lame to have this doubt, so there is the question : Why do I not have connectivity ?
The case is simple, I have configured the topology and have connectivity between each PC and respective gateway.
The problem is when I tried to ping a device in another network like PC1 to PC0 the next event occur
- PC1 broadcast arp to know MAC gateway of R0
- R0 reply arp to PC1
- PC1 send icmp packet R0
- R0 broadcast arp to know MAC of PC0
- PC0 don't reply because "The ARP request's sender IP address is in a different network than the receiving port."
So I want to know why PC0 don't reply? this is a base functionality of ARP?
Obviously I've configured 2 static route (one on each router) to route packets to another network on the same interface.
on R1 : ip route 192.168.1.0 255.255.255.0 FastEthernet0/0
on R0 : ip route 172.16.200.0 255.255.255.0 FastEthernet0/0
Many thanks for an answer!
========================= (EDIT) UPDATE / ANSWER ================================
After I read the RFC I understand why this is doesn't work. Well it's simple, ARP hasn't been develop/design to respond (reply) to a request coming from a another network. In this case, I force the forwarding (through the static route) to a network where the router doesn't belong. In some documentation, they said this protocol is between Layer 2 and Layer 3 (layer2.5 LOL), but in fact he never across Layer3 it only send information about Layer3 in a frame. So when a device receive a ARP request from another network, he process the frame (it's her IP in the frame to translate) and see the ARP request sender IP in another network discard automatically the frame. To do a arp request in another network we need a device Layer3 to work as a ARP Proxy, he simply relay the arp's request and reply, obviously have connection on each network. It's a weird design and somewhat stupid but interessant to learn more about ARP / LAN's. I want to say thank you to people who respond and try to help.
Best Answer
If you have a router in the middle, you're working across broadcast domains. ARP/Layer-2 communication is done explicitly between mac-addresses.
What happens in typical situation:
PC 1 (ip X.X.X.X, mac XX:XX:XX:XX:XX:XX) wants to connect to PC 2 (ip Y.Y.Y.Y, mac YY:YY:YY:YY:YY:YY) PC 1 notices that IP Y.Y.Y.Y is not "locally route-able" so it sends the packet to the router (ip Z.Z.Z.Z, mac ZZ:ZZ:ZZ:ZZ:ZZ:ZZ)
At this point, the packet leaving PC1 looks like this src ip = X.X.X.X src mac = XX:XX:XX:XX:XX:XX, dst ip = Y.Y.Y.Y, dst mac = ZZ:ZZ:ZZ:ZZ:ZZ:ZZ
the switch "switches" the packet to the router (because it already knows what port ZZ:ZZ:ZZ:ZZ:ZZ:ZZ is plugged into) the router knows that the IP Y.Y.Y.Y is on it's other interface, and routes the packet to PC2 accordingly.
at this point, the packet leaving the router looks like this: src ip = X.X.X.X src mac = ZZ:ZZ:ZZ:ZZ:ZZ:ZZ, dst ip = Y.Y.Y.Y, dst mac = YY:YY:YY:YY:YY:YY
PC2 accepts packets on it's mac address... and also notes that the IP is destined for itself... and then does whatever with the packet.
At no point in time did PC1 know the mac address. There is no direct way to know the mac address of devices that aren't in the same broadcast domain... because the "physical address" (or mac) is only used to talk locally to locally connected devices.