Bdtyk

When configuring a Cisco router, a static route can be added using the following commands:

• ip route 192.0.2.128 255.255.255.128 192.0.2.48


• ip route 192.0.2.128 255.255.255.128 f0/0

If I use the second option, how does R1 know who's the next host and therefore which MAC address it should use as the destination when it wants to reach the 192.0.2.0/25 network? With a /30 network it's easy to assume that the next hop is the only remaining address in the subnet but with a larger subnet like in the example below, I don't get how this works.

The second option is something to avoid. It is acceptable for point-to-point interfaces like serial or tunnel interfaces, but on broadcast media (such as Ethernet), it is "close to illegal" to use (regardless of whether the directly attached subnet is /25, /30 or /31).

If configuring the route this way is possible at all (I seem to remember that recent IOS and IOS-XE based routers don't allow it), the router will attempt ARP resolution of the destination IP address of the packet-to-be-forwarded.

Another (Cisco) router may respond to that request, if a) it has proxy arp enabled on the given interface [1] and b) it has a route to the actual destination.

However, also any other system on that broadcast domain may respond to that ARP broadcast, and could "attract" the traffic to itself (and may do all sorts of interesting things with it, since it just got itself into a man-in-the-middle position for free).

In short: Don't do it that way.

And while we're at it: don't use the first option either (unless you're on NX-OS). A properly configured static route looks like this:

ip route <destination network> <destination subnet mask> <egress interface> <next hop ip>

or - in your case

ip route 192.0.2.128 255.255.255.128 fastEthernet0/0 192.0.2.48

Reasoning: without the egress interface, a recursive route lookup is taking place to find an egress interface towards the given next hop. Most of the time, this will be an interface into a directly attached subnet.

However, some strange things may occur if that usually "up" interface into the next hop's (local) subnet goes down, and if the next hop's subnet is still learned via some dynamic routing protocol: then the given static route may not disappear from the routing table (and thus will continue to be redistributed into possibly present dynamic routing protocols, leading to all sorts of strange effects).

Not so if the egress interface is given. If that goes down, the static route vanishes from the routing table, in all cases.

[1] ceterum censeo: proxy arp should be disabled wherever one encounters it (unless it's really, really, really needed).