OSPF and Static Routes - Page 2

jgadbois · ‎10-30-2009

Is there a way to stop ospf form advertising static routes? My router is picking up my static routes and advertising them to the others.

can this be stopped?

Peter Paluch · ‎10-30-2009

Seth, James,

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

Best regards,

Peter

jgadbois · ‎10-31-2009

Peter,

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.

Peter Paluch · ‎10-31-2009

Hello James,

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.

Best regards,

Peter

jgadbois · ‎10-31-2009

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.

CriscoSystems · ‎10-31-2009

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!!

Peter Paluch · ‎11-01-2009

Hello Seth,

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.

Best regards,

Peter

jgadbois · ‎11-01-2009

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.

Peter Paluch · ‎11-01-2009

James,

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

Best regards,

Peter

CriscoSystems · ‎11-01-2009

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.

jgadbois · ‎11-01-2009

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

Peter Paluch · ‎11-01-2009

Hello Seth,

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?

Best regards,

Peter