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

  • ip route
  • ip route 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 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.

network topology with two routers R1 & R2 sharing a /25 network, and R2 with another /25 network

1 Answer 1


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 fastEthernet0/0

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 weird 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).

  • Thank you very much for that clear and detailed answer !
    – Nakrule
    Feb 18, 2019 at 21:25
  • 1
    To be fair, the man-in-the-middle situation you describe is always possible with ARP - it's always a broadcast followed by a race-to-reply.
    – psmears
    Feb 18, 2019 at 22:14
  • @psmears agreed. However: While an ARP conflict in the given local subnet might be detected pretty easily to detect (especially by the system that owns the hijacked IP address), a fake ARP response for an off-subnet IP address is less obvious to spot. Feb 19, 2019 at 17:07
  • Yes and no: the system that owns a hijacked IP address is likely to notice if the hijacking is accidental (because it can ARP for its own address and see a reply from someone else), but if it's malicious it may well not (because the malicious ARP reply can be sent unicast, and never sent to the true owner of the IP). The sender of the packet is in the best position to notice (because it will get two conflicting ARP replies), but I think most stacks just ignore one of the ARPs... But in any case, the general principle of "proxy arp is [almost] always the wrong answer" definitely holds true :)
    – psmears
    Feb 19, 2019 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.