When you put in an interface vice next hop in a static route, the static
route is regarded as "connected".
So the command
ip route 0.0.0.0 0.0.0.0 bri 0 200
results in a connected (static) route.
The IP routing protocols normally and automatically redistribute such routes, whether or not they have an administrative distance in them. This happens as long as the destination in the route matches a network statement in the router command. The interface also has to be up.
The problem this leads to is that when your backup link / DDR activates, BRI 0 is up, so the route gets advertised across the link. This in turn can lead to the central site pointing corporate default out the dialup link, and to routing loops. (It helps if the central site has " no ip classless", perhaps).
The solution seems to be:
Fresh thoughts:
Filtering per the above is probably a good idea no matter what. Prevents surprises!
From re-discussing the real-world unnumbered dial backup (via DDR) situation that raised the above issues... what hadn't come up was that HQ wasn't announcing corporate default (say 131.108.0.0 /16) to the remote sites. The remote sites have floating statics with 131.108.0.0 /16 pointed at BRI 0 (which is unnumbered). These were visibly getting redistributed and advertised, causing routing loops.
The misunderstanding this brought to light I've seen elsewhere, and fallen into myself a while back. It's really easy to do. So I think it's instructive to run through it here.
In the network I have in mind, HQ isn't advertising 131.108.0.0 /16, just /24 and smaller subnets of 131.108.0.0. Since there is no dynamic route with destination matching the floating static for 131.108.0.0 /16, the floating static gets installed as a route, which is why it is being redistributed. Filtering can fix this.
Having the dial backup router at HQ advertise 131.108.0.0 /16 is one of the assumptions of my article on alternative dial backup techniques: Designing Default and Dial Backup .
To emphasize the point here: dynamic advertisements, say for 131.108.4.0 /24, do not override a floating static destination of 131.108.0.0 /16, since they don't match that destination prefix.
There's another wrinkle to this story. Some of the remote sites use two routers, one with the Frame Relay link and the other with the ISDN backup link. Call them routers F and I, say. Router I has the floating static 131.108.0.0 /16 in it. If the Frame Relay link goes down, or if for some reason HQ doesn't advertise 131.108.0.0 /16 to the remote site, then the floating static gets installed and redistributed. When the link comes back up (or when HQ advertises 131.108.0.0 /16), the metric from I looks better to F than the Frame Relay metric. So the dynamic 131.108.0.0 /16 coming across the Frame Relay link is over-ridden by the dynamic 131.108.0.0 /16 from router I, which might tend to keep the ISDN link up (at least for traffic for subnets not otherwise dynamically advertised).
Router F does need the advertisement of 131.108.0.0 /16 from I when Frame Relay is down, in order to send traffic across the backup link. It doesn't need it when Frame Relay is working. One workaround is to use the distance command on F, to say that advertisements from I are "less reliable" or "less interesting" than dynamic routes (EIGRP in this case).
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .