Building network automation solutions

9 module online course

Start now!

Correction: do not use the name option of the ip route command

In my February IP corner article, Small Site Multihoming, I've used an obscure name string option of the ip route configuration command to force the router to accept multiple otherwise identical static routes (plus it seemed like a nice way to document what the static route does). While this option is totally harmless on the point-to-point serial links that I was using, one of the readers experienced hard-to-diagnose problems on upstream LAN interfaces that disappeared when we've removed the name option from the configuration.

As the solution presented in the article does not need the name option to differentiate between the static routes (the track keyword is enough to make a difference), it should be removed (and we've already removed it from the HTML and PDF version of the article).

Update: It turned out the problems my reader experienced had nothing to do with the name option of the ip route command, but the generic advice still applies: don't use the features you don't need.


  1. Can you explain what strange issues the reader was having? We use the "name" keyword after static routes all the time to explain our logic so the other engineers can quickly see why it the static route is for.

    Almost everything is via routing protocols, but we still have some host routes for DMVPN or VTI tunnel destination targets.
  2. He was using reliable static routes (with the track option) and the backup static routes with high administrative distance. Sometimes the route with better administrative distance would not appear in the IP routing table even though the show ip route track reported it was up.

    It appeared as though the name keyword (that I've also used primarily for the documentation purposes) might be the cause, but after removing it, the original problem reappeared after a few days (and we still don't know what's causing it).
  3. Was/is their a Cisco Bug ID for this issue?
  4. Since the "name" parameter didn't cause any issues, can you correct this correction? If you Google for "cisco ip route name", this blog entry is a top match. Unless people read the comments, it will give them incorrect information and scare them for no reason.
Add comment