OSPF Route Filtering Demystified

Intro

There was a lot of blogging related to OSPF topics recently. In this post, I would like to clarify some common misunderstandings that many people have about OSPF route filtering. I have seen so many folks wrongfully understanding the underlying behavior so it’s about time to make the things clear.

OSPF Data Structures

To begin with, avoid using the term “LSA filtering” with OSPF. You cannot really filter LSAs – with the exception of one special case – you filter the network reachability information. To understand this in depth, start by recalling that OSPF deals with the following data structures:
1) Topological information. Outlines the connections in the graph describing the routers and the links in the network. This is what OSPF LSAs are about – they contain information about attached links. Think of LSAs as the objects that correspond to the “edges” of the graph. LSAs are stored in the LSBD – link state database. No real “routes” are stored in the LSDB, since this is the database for topological objects. However, routing or network reachability information is attached to the LSAs.
2) Network Reachability information. Contains the actual IP subnets. This information is “associated” with the network graph “edges” and you may think of it as “leaves” connected to the edges. Routing information does NOT describe any connectivity, just the prefix associated with the link. This information is contained in the LSAs, but as an “attribute”, and is used to populate the routing table – i.e. the RIB.
3) Main routing table. This is the router’s RIB, as OSPF does not have a RIB of its own, unlike BGP. This structure is used when OSPF generates new summary or external LSAs as we see later.
4) Routers routing table. This structure is unique to OSPF, and contains the IP addresses to reach the “border” routers – ASBRs and ABRs. It is used when calculating the respective inter-area routes, by adding the router path cost to the respective prefix advertised by this router. You may display the contents of this data structure by using the command show ip ospf border-routers.

OSPF route calculation overview

1) Routers establish adjacencies to flood topological information. The flooding process in OSPF is pretty complicated, and ensures the LSAs are delivered to all routers in a single area. As mentioned, topological information is carried in the form of LSAs and cannot be filtered, which it is essential to the OSPF algorithm. The only thing that limits LSA propagation is the flooding domain associated with the particular LSA type. Using the topological information learned, all routers within an area build the consistent graph of the network connections.
2) After all routers have a consistent topology view, they may calculate intra-area paths using the SPF algorithm and finally associate the network reachability information with the paths. This is where the “secondary”, leaf-level information comes in play. The leaves are attached to the paths and the routing table entries are calculated. So keep this in mind – first LSA flooding, then LSDB population, then SPF computations, and finally the RIB population.
3) After the intra-area paths have been calculated, inter-area routes are computed based on type-3/4 LSAs contents for other area information summarization. This process uses a quick and simple distance-vector computation algorithm, without the need for SPF computations. The router’s routing table is used extensively during this process.

When you can REALLY filter LSAs

Now, back to the case of LSA filtering. Some may recall the commands ip ospf database-filter all out or neighbor <IP> database-filter all out. Good point, but what it does is prevent the OSPF process from sending any LSAs out of the particular adjacencies. This could be done only if you’re sure that the LSAs will be flooded to all routers in the area by some other means. This is the special case I’ve been talking about previously. The purpose of this feature is to compensate for the absence of “mesh-groups” and limit the amount of flooding on NBMA subnets shared by many routers.

Overview of OSPF route-filtering

All right, so if you cannot really filter LSAs, how do you perform “route filtering” with OSPF? Using the term “route filtering” is the correct way of saying “LSA filtering”. You may apply route filtering to OSPF using the following two general methods:
1) Preventing optimal paths generated by OSPF from entering the RIB. This is what you can do by applying the command distribute-list in under the OSPF process. This affects routes installed in the RIB. There is one special extension of this method to filtering the FA (forwarding address) to block external OSPF routes.
2) Affecting the LSA generation process, by changing the “source” information used to generate the LSAs. There is a bunch of ways to do this, each specific to a particular LSA type. To understand this completely, we need to recall all the basic LSA types and their flooding scopes.

How OSPF generates different LSA types

LSA type 1. Describes an attached circuit, different link types. This is the fundamental building block of the topology graph. This LSA is flooded within the single area and never gets past the ABRs. The sources of information for LSA type-1 are the directly connected links. If you want to remove the network reachability information, just remove the link
LSA type 2. Generated only on the “shared” networks (BROADCAST/NON-BROADCAST network types) to minimize the amount of topological information generated. Imagine that you have 10 routers on a shared Ethernet segment. Normally, to fully describe the topology, every router would need to generate an LSA describing its connection to all other 9 routers. This would result in 90 LSAs. Using LSA type-2 and the Designated Router concept, every router needs to declare a connection to the DR, and the DR will generate a Type 2 LSA describing all routers on the segment (the “bunch”). In our example, this will result in 11 LSAs total. This LSA does not carry any real “network reachability” information with the exception of the netmask and the list of routers on the segment. It is used along with information from type 1 LSAs to describe the shared network. I like to think of it as a “glue” LSA. The flooding domain is one area as flooding stops at ABRs.
LSA type 3. Now this type is a bit tricky and brings in a lot of confusion. It is generated by an ABR to tell the routers in one area about the network in another area. Essentially, the router “pretends” like all the “foreign” networks are attached to it. From a topological perspective, this is true, because areas never know anything about another area’s topology – this information is lost when crossing the area boundaries. How are Type 3 LSAs generated? First of all, keep in mind that OSPF generates those by walking the main routing table, not the LSDB. This is per RFC 2328 clause 12.4.3 and in full accordance with distance-vector protocol behavior. Every route in the table has additional OSPF information associated with it, such as area number, route-type (intra-area, inter-area, external) next hop, and so on.
1) The ABR goes over the network reachability information in the RIB associated with intra-are routes for the particular area X and summarizes them honoring the area X range command settings. This results in Type-3 LSAs being generated and advertised into all other areas. Pay attention to the following important things:
1.1) Only intra-area routes are summarized. You cannot summarize inter-ara routes installed by processing type-3 LSAs learned from Area 0. Those will generate new type-3 LSAs in the ABR and will propagated them into non-backbone areas unmodified.
1.2) The intra-area routes are summarized PRIOR to applying the distribute-list filter and blocking the routes from entering the RIB. This is needed to allow for generation of a summary route, even if you don’t want the specific prefixes in the local RIB and calculate the correct metric if needed. Thus, even though OSPF walks over the RIB to gather the intra-area prefixes for summarization, it does so BEFORE applying the filter. The ultimate goal is making summarization the highest priority task, in order to increase network stability.
1.3) The OSPF metric for the summarized route is taken as the minimal among all intra-area routes. To ensure better routing stability, it is usually recommended setting the metric manually, to prevent LSA re-flooding in case some component route flaps and affects the summary metric.
2) Now, for dealing with the inter-area routes learned by the ARB, first of all, keep in mind that an ABR ONLY accepts and processes type-3 LSAs received from the backbone area. This is the well-know loop prevention mechanism built into OSPF, since OSPF behaves as a distance-vector protocol when dealing with inter-area routing information. This is a short description of how an ABR processes type-3 LSAs:
2.1) Ignore the type-3 LSA if it is NOT from the backbone area (prevents routing loops).
2.2) Walk over the inter-area routes learned via Area 0 in the RIB and generate respective type-3 LSAs which are flooded into the attached non-backbone areas. Thus, LSAs are effectively being re-generated based on the RIB contents.
Next, consider an important aspect of this process. The re-generated summary LSAs are generated AFTER applying the OSPF filter associated with the routing-process via the distribute-list in command. Thus, if you filter some of the inter-area routes from entering the RIB, the respective new summary LSAs will NOT get generated. This will stop routing information propagation into the attached non-backbone areas.
This quickly summarizes the type-3 LSA generation process. Notice that filtering the routing information is not based on some “LSA” filtering procedure, but rather on the routes contained in the RIB. At this moment, some people may recall the command area X filter-list prefix {in|out}. Good news here – this command applies after all summarization has been done and filters the routing information from being used for type-3 LSA generation. It applies to all three type of prefixes: intra-area routes, inter-area routes, and summaries generated as a result of the area X range command. All information is being learned from the router’s RIB.
Oh, almost forgot – LSA type-3 flooding scope is one area, it never crosses ABR boundaries – it just gets re-generated when needed! Now, here is a summary of inter-area router filtering commands (applicable only at an ABR):

Method 1: Filter the inter-area routes generated at ABR
router ospf 1
 area 10 filter-list prefix in NAME

Method 2: Filter out intra-area routes
router ospf 1
 area 10 range 1.1.1.0 255.255.255.0 no-advertise

Method 3: Filter inter-area routes learned by ABR from Area 0
router ospf 1
 distribute-list 1 in

LSA type 4
This type has always been confusing to many people. This LSA describes the metric that the ABR uses to reach the respective ASBR. This LSA contains the router-ID of the ASBR and the metric to reach it. ABRs generate type-4 LSAs based on the special “router routing” table which is visible when you issue the command show ip ospf border-routers. This command is the essense of the distance-vector OSPF behavior. During the inter-area path calculations, the ABR populates this table with “host” routing entries for every ABR and ASBR detected with the respective metrics. This table is never transferred to the main router routing table, but rather used for inter-area path computations and type-4 LSA generation. Effectively, the metrics in this table are used as metric offsets for the paths learned from ABRs and ASBRs.
The ABR generates type-4 summary LSAs into every normal attached area, to make sure the routers in there can reach the prefixes from the ASBR. You cannot really filter the contents of this LSA, as they are taken from the router routing table. The information from this LSA is used to populate the non-ABR routers “special” router routing table. The flooding domain is one area as it stops at the ABR.
LSA type 5
This LSA is originated by an ASBR (router redistributing external routes) and flooded through the whole OSPF autonomous system. You cannot limit the way this LSA is generated except to controlling the routes redistributed into OSPF. When a type-5 LSA is being generated, it uses the RIB contents and honors the summary-address commands in the ABR. You may filter the redistributed routes by using the command distribute-list out configured under the protocol, which is the source of redistribution or simply applying filtering with your redistribution.

Method 1:
router ospf 1
 distribute-list 10 out rip
!
access-list 1 deny 1.1.1.0
access-list 1 permit any

Method 2:
router ospf
 redistribute rip route-map RIP_TO_OSPF
!
route-map RIP_TO_OSPF
 match ip address 1

Method 3:
router ospf
 summary-address 10.0.0.0 255.255.25.0 no advertise

There is yet one more way to filter the routing information found in type-5 LSAs. If the LSA contains non-zero “FA” (forwarding address) field, OSPF process will check for this address to be accessible via RIB (RFC specifies that only OSPF routes should be considered, but it seems IOS satisfies with any route) before installing the actual prefix into the RIB. If the FA is not accessible, the corresponding external prefix is not installed into the global routing table. We will discuss this type of filtering a bit later, when we’ll be looking into type-7 LSAs. However, keep in mind that FA is non mandatory for type-5 LSA and is only assigned to a type-5 LSA under special conditions, outlined in the following document Common Routing Problem with OSPF Forwarding Address. Here is the list of the conditions:

• OSPF is enabled on the ASBR’s next hop interface AND
• ASBR’s next hop interface is non-passive under OSPF AND
• ASBR’s next hop interface is not point-to-point AND
• ASBR’s next hop interface is not point-to-multipoint AND
• ASBR’s next hop interface address falls under the network range specified in the router ospf command.

Please refer to the URL provided for more epxplanations.
There is only one more type of OSPF LSAs to discuss.
Type 7 LSA
These only exist at NSSA areas and have the flooding scope of a single area, as opposed to the whole domain for type-5 LSAs. The type-7 LSAs reaching ABRs are used to populate the local routing table and re-generate the new type-5 LSAs, originated now by the ABR. This is important – since the ABR becomes an ASBR and re-originates the routes, you may use the command summary-address ADDR MASK no-advertise to block the type-5 LSA generation. There is another, less obvious way to do things:
When an ABR generates type-5 LSAs, it adds the forwarding-address (FA) based on the information learned in the type-7 LSA. This information is originally inserted by the ASBR to help in optimal exit point selection. The use of forwarding-address with the type-7 LSAs is mandatory per the RFC, since there is just one translator, and it may lie on the sub-optimal path to the ASBR. Thus all routers in the OSPF autonomous system are supposed to rely on the FA for optimal routing to the translated prefixes. And here is the trick: if you filter the forward-address IP from the routing table in the ABR, using the command distribute-list in the type-5 LSA will not be generated!. Look at the following output, where R2 is an ABR for NSSA area 27:

Rack1R2#show ip ospf database nssa-external 

            OSPF Router with ID (150.1.2.2) (Process ID 1)

  Type-7 AS External Link States (Area 27)

  Routing Bit Set on this LSA
  LS age: 11
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 162.1.7.0 (External Network Number )
 Advertising Router: 162.1.7.7
  LS Seq Number: 80000001
  Checksum: 0xDEB5
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 11
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 162.1.10.0 (External Network Number )
 Advertising Router: 162.1.7.7
  LS Seq Number: 80000001
  Checksum: 0xBDD3
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

Rack1R2#show ip ospf database external 

            OSPF Router with ID (150.1.2.2) (Process ID 1)

  Type-5 AS External Link States

 ...
  LS age: 26
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 162.1.7.0 (External Network Number )
  Advertising Router: 150.1.2.2
  LS Seq Number: 80000001
  Checksum: 0x2193
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

  LS age: 26
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 162.1.10.0 (External Network Number )
  Advertising Router: 150.1.2.2
  LS Seq Number: 80000001
  Checksum: 0xFFB1
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

As you can see, R2 generates type-5 LSA with the same forwarding address found in type-7 LSA – “150.1.7.7”. Now we filter this IP address from entering R2′s routing table:

R2:
access-list 1 deny   150.1.7.7
access-list 1 permit any
!
router ospf 1
 distribute-list 1 in

And apply our verification once again:

Rack1R2#show ip ospf database nssa-external 

            OSPF Router with ID (150.1.2.2) (Process ID 1)

  Type-7 AS External Link States (Area 27)

  LS age: 222
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 162.1.7.0 (External Network Number )
  Advertising Router: 162.1.7.7
  LS Seq Number: 80000001
  Checksum: 0xDEB5
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

  LS age: 222
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 162.1.10.0 (External Network Number )
  Advertising Router: 162.1.7.7
  LS Seq Number: 80000001
  Checksum: 0xBDD3
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

Rack1R2#show ip ospf database external 

            OSPF Router with ID (150.1.2.2) (Process ID 1)

  Type-5 AS External Link States

And we can see that Type-7 to Type-5 translation is not working anymore, as the forwarding address is no longer reachable in the RIB. Notice that forwarding address should be accessible via the main RIB, not the routers routing table of OSPF. This special behavior is unique to the routes learned by processing the type-7 LSAs. Now what if you have to following topology:

And R3 is filtering the forwarding address for the type-5 LSAs originated at R4 using say area X range no-advertise or area X filer-list prefix {in|out} commands, so that R1 has no FA IP in its RIB. In this situation, R3 will have the route to the redistributed prefixes installed (it sees the FA!), but all other routers in the domain with the exception of the NSSA area internal routers will not. Even though they will receive the type-5 LSA, they will not be able to process them and use the information for routing – the forwarding address will be unreachable. One way to overcome this issue is by using the command area X nssa suppress-fa to instruct R3 on setting the FA to itself.

Summary of the post

We went over almost all of the important route-filtering scenarios for OSPF. The key thing you should remember is that non-local route filtering for OSPF is only available at ABRs and ASBRs, the points where OSPF behaves as a distance-vector protocol with respect to inter-area routing information. Here is the list of points you need to remember:
1) You cannot filter LSAs directly, you can only manipulate the routing information used to generate LSAs.
2) The above routing information is taken from local router’s RIB directly.
2.1) In the case of intra-area routes, RIB filters are applied after the type-3 LSAs are generated (intra-area routes are summarizable).
2.2) In the case of inter-area routes, RIB filters are applied prior to type-3 LSA generation (inter-area routes are not summarizable).
3) External AS routes can only be filtered at the ASBR.
4) NSSA routes can be filtered at an ASBR and the ABR performing the translation.
5) If the FA for an external prefix is NOT reachable, the router will NOT install it into the route table nor will it translate type-7 LSAs to type-5.

Futher Reading

1) RFC 2328. Dont skip this if you are serious about understanding OSPF
2) OSPF Design Guide by Sam Halabi. Excellent introductory reading on OSPF.
3) Cisco IP Routing by Alex Zinin. A must read to anyone who wants in-depth understanding of IP Routing internals.