Do you have a command similar to redistribute static in your OSPF configuration? If so then removing it will stop your router from advertising static routes. That command is the only way how an OSPF router can be forced to advertise static routes to its neighbors. Normally, OSPF router advertises only the OSPF-discovered networks. Most certainly, static routes are not advertised in OSPF by default.
Before removing that command please make sure that by removing it, no connectivity issues will be introduced into the network.
EDIT: Peter beat me to the punch!!
The router shouldn't be doing this on its own without the "redistribute static" command configured under the OSPF process. Are you sure the static routes are actually being advertised, separately, by OSPF; and not that the interfaces activated by your "network" command under OSPF are the same ones that your static routes use? (Are these static routes to remote networks, or are just the directly connected links being advertised?)
Your answer is completely flawless. Thanks for submitting it! :) Let's see what the author of the original post tells us about his config.
Please let us know what you find out. One or more of us might learn something new.
(Peter - thanks for the thumbs-up; my BSCI studies have me hungering for encouragement!)
Let me add one question: How do those static routes look like on the other routers? Are they marked as "OE1" or "OE2" in the routing table? That would be a sure sign of them being redistributed. In that case, you would be able to find out quite precisely who is advertising them.
For example, have a look here: this output contains information about an OSPF internal and external route - the 192.0.2.0/24 network marked as "OE2" is the redistributed static route:
R3#show ip route ospf
10.0.0.0/24 is subnetted, 2 subnets
O 10.0.12.0 [110/128] via 10.0.23.2, 00:00:05, Serial1/1
O E2 192.0.2.0/24 [110/20] via 10.0.23.2, 00:00:05, Serial1/1
By issuing the following command, I can find out who is actually redistributing this information:
R3#show ip route 192.0.2.0
Routing entry for 192.0.2.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Last update from 10.0.23.2 on Serial1/1, 00:01:17 ago
Routing Descriptor Blocks:
* 10.0.23.2, from 10.0.12.1, 00:01:17 ago, via Serial1/1
Route metric is 20, traffic share count is 1
Note the highlighted information: it tells me who is the ASBR advertising this route, and I know it's OSPF RouterID - it is 10.0.12.1. Now, assuming that I know which router has the RID of 10.0.12.1, I've got it.
Let me tell you that you should feel absolutely comfortable about your BSCI studies. The questions you are posting on these forums reveal that you are thinking very thoroughly about every topic, and by all means, that is something very valuable and very helpful in your preparations even if that is not the easiest way to go. I am sure we will soon be able to congratulate you on your passed exams - and not just BSCI :)
Keep up the good work you're doing.
I did find a router that has eigrp and ospf running on them. Both are redistributing routes to one another. Will eigrp pick up static routes on its own? Maybe that is how they are creeping in.
No routing protocol picks up and redistributes static routes by default. Each routing protocol is by default very protective of its own information and does not include information from any other routing protocol, including connected or static routes, into its database.
The EIGRP should not be therefore picking up static routes by default. It would also need to have the redistribute static command present in order to actually include them in its advertisements.
There is a notable exception for distance-vector routing protocols like EIGRP or RIP: if a static route is defined only by its output interface and not using the next-hop IP address, it is considered as directly connected. In that case, it can also be advertised in EIGRP or RIP using the network command that applies to all directly connected networks. This does not apply to link-state routing protocols like OSPF or IS-IS.
Have a look on my earlier post to find out who is redistributing the information into OSPF.
Thanks very much to both of you for your kind ratings but let me say that I am not hunting points here. I just want to help. (That being said, a rating is always a great satisfaction if I managed to be of help.)
I seem to have found the culprit. It's an upstream router which I don't control. So I have put in access lists and distribute-list in statements to try and get rid of it.
My only problem now is two ASAs that don't seem to want to give up the pesky routes. All of the pesky routes disappear in my routers when I deny them and do the distribute-list staements but this is somehow not carried to the ASAs.
I am scratching my head but still working on it.
In OSPF, you can use the distribute lists only to influence your own routing table - one router at a time. The network will be filtered out of your own routing table but the remaining routers will not be affected. The reason for this is that in OSPF, the routing information is carried in so-called Link State Advertisements, or LSAs, and the LSAs may be filtered or modified only by their originating routers and not by anyone else, with the notable exception of border routers between areas. As the originator of the external routes is the upstream router, no other router within your area has the right to filter out that LSA.
You will probably have to configure your ASAs using distribute lists to filter out those networks as well - if they support distribute lists. Another solution could be to ask the upstream provider to remove those networks from OSPF if you do not need them.
Also, setting an area type to stub would prevent any external routes from being advertised to you. However, changing the areas and their types should be done only after careful planning.
Thanks, again, Peter. I guess my only recourse is to contact them and see what the reaction will be. I'm going to see if the distribute-list solution will fit in my situation.
Hey that's interesting. So if my router has a distribute list configured inbound on serial 1; and also has an ospf neighborship out serial 2; the route that the distribute list prohibits will be kept out of my router's table; but the LSA with the same route will be passed along, by my router; out Serial 2? (This is, let's say, a point-to-multipoint setup; with no DR.)
And the very route that my router prohibits in its distribute list could jolly well show up in the ip tables of the downstream routers?
This is interesting!!
Exactly. The filtered route will not appear on your router but the downstream neighbor on Serial2 will have it in its routing table.
In distance-vector protcols, it is very easy to simply remove a network from a routing update, as the routing update is merely an array of networks and their metrics. There's no problem in omitting some of them - or even better, assigning an infinite metric to them (this is what the EIGRP does when using distribute-lists). It is very easily done.
However, in link-state protocols, distribution lists work very differently. The routing information in link-state protocols is hidden in topological components - routers, network and links. These topological components are described by individual LSAs in OSPF. Now, if you wanted to filter out a network in OSPF in the same way as in distance-vector protocols, you would in essence need to either remove the particular LSA from your database or modify it so that it does not contain the unwished information - and this is something you are not allowed to do unless you are the originator of that LSA. Remember - the LSAs are the sole property of their originators. Within an area, only the originator of an LSA has the right to modify its contents or remove it from the database altogether (by expiring it).
This is the reasoning behind the logic of distribution lists in OSPF. In OSPF, the distribute-list in the in direction therefore only affects your particular routing table but it does not affect your link state database. Even if you filtered out some network, the LSA describing it is still present in your LSDB and will be flooded to your neighbors so they will know about it.
The distribute-list in the out direction is applicable only on ABSRs, and it filters the external networks advertised out by the ASBR. This command actually has a network-wide effect, as it limits the external networks present in the LSA5 generated by this ASBR. However, if the router is not an ASBR, a distribute-list in the out does not have any effect whatsoever.
This might be slightly confusing but remember that in OSPF, is much harder to tamper with the link state database.
Peter and Seth,
And it gets more interesting. I've tracked the distribute-list command with the ASA 5500 product and it appears that is was available first with RIP and then EIGRP. But as of the latest release (8.x I think)it appears it is NOT supported in OSPF.??. So my original problem will have to solved another way. I've already talked to the purveyor of the routes and we are going to work on a solution. But why not support the command in OSPF, a very widely used routing protocol?
Peter, your explanation was great.
You are heartily welcome. Regarding the distribute-list support on ASA - well, the primary purpose of the ASA is to do firewalling, not to be a fully fledged router. While normal routers do support distribute-lists for OSPF in the way I have previously described, the ASA boxes may support far less features in their OSPF implementation. The operating system on ASA is much different from the IOS (I believe that ASA runs a Linux-based operating system) and so I suspect there are differences between the OSPF implementations.
I would really like to know how Cisco maintains an implementation of a particular protocol in its diverse operating systems... :-)
Problems could sprout up like crazy though, if you've got routers with distribute-lists configured to filter out the very routes that the same routers effectively keep on advertising.
If I'm a router and I have a point-to-point neighbor to whom I've forwarded an LSA that describes a route that my distribute-list filtered out of my table, my point-to-point neighbor downstream might not have a distribute list and therefore jolly well installs the route in its own table once he gets the LSA. But since he got the LSA from me, he considers me the next-hop in the path and will therefore forward that networks traffic to me; even though I've obviously got no routing entry for it.
So I guess I'm confused about the best practices for using distribute-lists versus selecting which routers should use, and advertise, default routes only.
This is how it all started for me. It sounds like the distribute-list command is a point solution only. It does get tiresome updating all the routers. And if, unbeknownst to you, slips in a static route upstream, well....
You are correct about the problems. There are really few disadvantages to link-state protocols but there are two very outspoken:
1.) You can't summarize in an arbitrary point of a network. Summarization would be equivalent to changing the LSAs of other routers which is not permitted. The only place where you can perform summarization are the ABRs (inter-area routes) or the ASBRs (external routes).
2.) You can't do route filtering in an arbitrary point of the network. The reason is the same as described earlier. Again, the only points for network or area-wide filtering are the ABRs and ASBRs. The reason that the ABRs and ASBRs are allowed to do summarization or filtering is that actually, they convey the information about a particular area or external networks in their own LSAs. The external networks are placed into LSA5. Regarding the inter-area summarization, while the area is described by LSA1 and LSA2, these cannot be flooded in another areas and instead, the LSA3 is originated on ABR so the ABR has the right to define its contents including filtering or summarizing.
You wrote: But since he got the LSA from me, he considers me the next-hop in the path
You are partially correct here. It is true that if your neighbor has a route in his routing table that you have filtered out and you happen to be the next-hop to that route, all sorts of weird routing problems can ensue, from routing loops through suboptimal routing to blackholing traffic. But you are not the next-hop just because you have sent your neighbor some LSA. You are sending to your neighbor all LSAs you have in your LSDB and yet you aren't the next-hop for all possible destinations in a network. You will be identified as a next-hop only if objectively your you lie on the best path.
Regarding the best practice using distribute-list versus default routes - I am not quite sure what you have in mind here. I do not really see the alternative here. Can you please elaborate further?