Ability to communicate between two routers

[Christopher_Escalante]

Is router R1 able to ping router R3 ? We assume that all devices have only basic configuration.

[balaji.bandi]

If R2 doing routing here, any ACL they should able to reach each other ?

R1 i would expect same as R3 ip route towards gateway, example ip route 20.0.20.2 255.255.255.255 10.0.10.1

[Richard Burts]

There are interesting differences in configuration of the static routes. R1 has a host specific static route which specifies the outbound interface but not a next hop address. R3 has a static default route which specifies a next hop address. This could work if R2 has enabled proxy arp and will not work if R2 has not enabled proxy arp.

While it might work configuration of a static route which specifies an outbound Ethernet interface without specifying a next hop is not recommended. It might work but it will make the router work much harder.

[Georg Pauwen]

Hello,

I just lab tested this, it won't work. You need either one of the below routes on R1:

ip route 20.0.20.0 255.255.255.0 GigabitEthernet0/0

ip route 20.0.20.2 255.255.255.255 10.0.10.1

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0

[Joseph W. Doherty]

@Georg Pauwen, just to confirm, you're saying the non-host routes with an interface next hop work, but the host route requires a next hop IP?

If so, curious!

Like @Richard Burts, I would expect the host route, with interface, to work too.

BTW, Rick also mentions using an interface for a next hop causes the router to "work much harder".  In this specific example, it wouldn't but it can!  So, he's 100% right to advise against that usage.

If you use an interface for next hop, router builds ARP entry for every remote IP.  With a next hop address, if only builds an entry for the network prefix.  So, with the former, if you pinged both 20.0.20.1 and 20.0.20.2, two would be required, but with the latter one entry would cover both.  This can be a major issue when using a global default route, like the one on R3, but again, using the interface as a next hop.

[Georg Pauwen]

@Richard Burts 

-->  just to confirm, you're saying the non-host routes with an interface next hop work, but the host route requires a next hop IP?

Indeed, that was the result of my testing.

[Richard Burts]

@Georg Pauwen I am surprised at the results of your test. Given the environment described in the original post, this is what I would expect to happen:

- R1 attempts to ping 20.0.20.2 (interface address of R3) but does not have a mac address to use as the destination mac in the IP packet.

- R1 sends an arp request for address 20.0.20.2.

- R2 receives the arp request, recognizes that it can get to that address, assuming that proxy arp is enabled R2 should send an arp response with R2 mac address.

- R1 now has a mac address associated with the destination IP and forwards the ping request to R2.

- R2 forwards the ping request to R3.

- R3 receives the ping request and generates a ping response with 10.0.10.2 as the destination address.

- using its default route R3 sends the ping response to R2.

- R2 receives the ping response and forwards it to R1.

But you are saying that this is not what happens. I could understand the failure if proxy arp is not enabled on R2.

If proxy arp is not enabled on R2 then I would expect that this suggested route would not work

ip route 20.0.20.0 255.255.255.0 GigabitEthernet0/0

But your post suggests that it does work.

So we have 2 very similar routes

ip route 20.0.20.2 255.255.255.255 GigabitEthernet0/0

ip route 20.0.20.0 255.255.255.0 GigabitEthernet0/0

And your test result is that one does work while the other does not? I am puzzled about this.

[Joseph W. Doherty]

Again, like @Richard Burts, and for the reasons he notes, still find it curious the host route doesn't work (again when the non-host routes, with interface only next hop do).

I wondering if there's some bug in the platform @Georg Pauwen used.

Without getting into full debugging mode, such as watching packets being sent out by R1 and R2, Georg you might also quickly try:

ip route 20.0.20.2 255.255.255.254 GigabitEthernet0/0

ip route 20.0.20.2 255.255.255.252 GigabitEthernet0/0

ip route 20.0.20.0 255.255.255.252 GigabitEthernet0/0

Georg from what you've found so far, would expect the above to work too.