More Details on OSPF Route Filters

I did a few follow-up tests with the distribute-list in OSPF configuration command and stumbled across a few interesting facts (IOS release 12.4(15)T1 on a 3725 platform):

  • Although the router allows you to configure distribute-list acl in interface, it does not work. Routes received through that interface (or having the interface as the next-hop) are not filtered.
  • When you apply the distribute-list in command, the routing table is not changed. Clearing the IP routing table does not help, you have to clear ALL OSPF processes (including bringing down all OSPF adjacencies) with the clear ip ospf process command for the route filter to take effect.
  • The same limitations don't apply in the other direction: when you remove the distribute-list in, SPF is triggered and the routes appear in the IP routing table automatically.
  • The somewhat undocumented gateway option of the distribute-list in command works, but not quite as I would expect: the IP next hop, not the router-ID of the router advertising the IP prefix is matched by the prefix-list.

And, last but not least, I've lab-verified my previous claim: applying the distribute-list in on a transit router can result in a black hole, as the LSAs themselves are not filtered.

Recent posts in the same categories

9 comments:

  1. Anonymous 30 October 2007 15:36
    As a side note, Cisco introduced an OSPF ABR Type 3 LSA filter between area routers. I have not tested this feature but from the documentation it seems to be workable.

    http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hirp_c/ch15/habrt3f.htm
  2. Jozef Janitor 30 October 2007 17:30
    [quote]
    Although the router allows you to configure distribute-list acl in interface, it does not work. Routes received through that interface (or having the interface as the next-hop) are not filtered.
    [/quote]
    The distribute list doesn't work with OSPF because the router is not receiving information about networks, but about link states.
    As you have mentioned, if there would be a way to change this behavior (filter the link states) then it could cause routing problems (route hole, etc.). With OSPF every router in the area has to have the same knowledge about links and they have to compute with the SPF algorithm the same path (or tree).
  3. Ivan Pepelnjak 30 October 2007 19:50
    @William: how did you know that the inter-area filters were close to the top of my OSPF to-do list :)

    @Jozef: Conceptually we're saying the same thing, I'm just annoyed that the distribute-list interface command is there but does not work at all, while the distribute-list gateway command works (although not the way I would expect it to work, but then you can't be picky with undocumented commands, can you?)
  4. Anonymous 01 November 2007 15:51
    Ivan: I knew you would test the inter-area filters next because you liked to read up on Cisco stuff :-)
  5. Jozef Janitor 02 November 2007 12:07
    @Ivan: I am not so annoyed with the distribute-list command under the OSPF configuration. But yeah, it's pretty useless. More I am annoyed of the lack of an interface level command to add an IP address in this format:
    ip address 10.1.1.1 /24
    I hope that some future IOS versions will finally implement it :-)
  6. Anonymous 27 November 2007 05:57
    My understanding is that the distribute list in command does work, but not the way you think...Instead, it allows LSA's to be accepted, but it treats the interface that it is applied to as the criteria to filter incoming LSA's against in the next-hop field.

    It works this way, if I apply it to my fa0/0 interface, and I have an LSA sent in that specifies fa0/0 as the interface thru which that prefix is reachable, it will prevent that route from being installed into the routing table.
  7. Jose Jara 15 May 2012 20:33
    Ivan: It is true that distribute-list in filters the prefixes from the route table and not the LSAs from the database, but I would say that this is not 100% accurate.
    There are 2 exceptions from what I have seen doing some tests:

    - Applied on an ABR, it will filter the prefixes specified in the ACL from entering the route table, plus the LSAs type 3 to enter the area which is attached. Let's say that ABR is connected to Area-1, and it has type 3 of Area 2, it will filter those to enter Area-1. By the way, the distance 255 will do the same.
    - Applied on an ABR attached to a NSSA, it will filter the prefixes specified plus sending the type 5 LSAs to the Backbone. To be accurate, this has to be done on the ABR which is doing the translation of Type-7 to Type-5. This router will be the ABR with the highest router-ID according to NSSA RFC 1587. Here the distance command does not work to filter the LSA's.

    Best Regards,

    Jose.
    Replies
    1. Ivan Pepelnjak 15 May 2012 20:36
      Good point. It seems Cisco IOS behaves almost like it would do the inter-LSA information transfer through the IP routing table not within the OSPF database. Need to run a test or two to confirm ...
    2. Jose Jara 15 May 2012 21:10
      Indeed. It looks like the same behavior for the NSSA ABR. If you config a static route matching the type 3 LSA, it will not advertise it due to the better AD. The same for the external from the NSSA. By the way, probably I did something wrong before from the distance command for NSSA ABR because I have tested again and now it works :)
Add comment
Home
Sidebar