Not all static routes were created equal

In his excellent question, Matt reminded me of (almost prehistoric) days when static routes pointing to a connected interface (not IP next-hop) had administrative distance zero. I also remembered that we've had interesting routing problems as those static routes actually behaved like connected routes (and were redistributed into routing protocols with redistribute connected command).

This is no longer the case (and hasn't been since at least IOS release 12.2 ... I wasn't able to find a box running an older release to test it), all static routes now have default administrative distance one, and behave like they should (they never get redistributed with redistribute connected command).

For example, with the router configuration ...

ip route 0.0.0.0 0.0.0.0 serial 0/0.1
ip route 1.0.0.0 255.0.0.0 172.16.0.4

... both routes have identical administrative distance:

POP#show ip route 0.0.0.0Routing entry for 0.0.0.0 0.0.0.0, supernet
 Known via "static", >distance 1, metric 0 (connected), candidate default path
 Routing Descriptor Blocks:
 * directly connected, via Serial0/0.1
   Route metric is 0, traffic share count is 1
POP#show ip route 1.0.0.0
Routing entry for 1.0.0.0 255.0.0.0
 Known via "static", distance 1, metric 0
 Routing Descriptor Blocks:
 * 172.16.0.4
   Route metric is 0, traffic share count is 1

Searching through Cisco's Bug toolkit turned up only a single relevant bug: CSCdi38232 (redistribute connected should not redistribute static route to OSPF), which was fixed in IOS release 10.2 and 10.3, that's probably also when they've fixed the administrative distance.