OSPF Prefix Filtering usi ...
    13 November 09

    OSPF Prefix Filtering using Forwarding Address

    Posted byPetr Lapukhov

    OSPF FA Overview

    This post is dedicated to one “esoteric” OSPF external route filtering method based on hiding OSPF Forwarding Address. Recall the meaning of OSPF FA. This is a special field used on OSPF type 5 and 7 LSAs to convey the information of the “external route source”. The purpose of FA is to optimize forwarding in situations where the external route source is connected to a shared segment. Here is an example:


    In this scenario, R2 is the ASBR redistributing RIP into OSPF. At the same time, R1 does not perform redistribution. Per normal OSPF rules, the external prefixes appear “attached” to R2 and thus both R1 and R4 should route across R2 to get to the networks behind R3. In order to avoid this suboptimal routing, OSPF may insert a non-zero FA field into type-5 LSAs, containing the IP address of R3: This will instruct R1 and R4 to route to R3 directly, instead of going across R2.

    Now an important thing here – the FA address must be accessible via the normal routing tables of R1 and R4. This requires the external link to be advertised into OSPF by some means, e.g. by enabling OSPF on the external link between R1, R2 and R3. Redistribution cannot be used for this purpose, as there are some restrictions. Here is a complete list of the requirements for enabling the OSPF FA in type 5 LSAs:

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

    (You may find more information by reading the article on Cisco’s website named Common Routing Problems with OSPF Forwarding Address.

    Notice the requirement for having the network type of “broadcast” or “non-broadcast” – this makes sense if you think that in real life you need to have a shared link with multiple “exit points”. However, you may forcefully configure a physically point-to-point link for the mentioned OSPF network types to enforce the effect of FA assignment.

    Application to Filtering

    Based on the requirement that FA needs to be reachable for the respective external routes to be considered, we may devise a filtering scheme for external routing information. More specifically, if there is a way to filter out the prefix corresponding to the FA, this will stop all routers that lost this information from using the external prefixes. There are two cases here.

    1. The FA prefix is filtered at the ASBR. Since OSPF must be enabled on the external link, the only option left is configuring a different area on the external link and using the inter-area route filter (area x filter-list) to block the prefix from propagating further.
    2. The FA prefix is filtered at the ABR(s) of the area containing the ASBR. You may use any of the methods described in the post OSPF Route Filtering Demystified to prevent type-3 LSA generation, e.g. use the inter-area route filtering.

    Let’s see how this could be done in a practical scenario. Below is a diagram of a single-area OSPF implementation. R1 redistributes RIP routes into OSPF.


    We enable OSPF area 0 on R1’s Frame-Relay interface (which uses the default non-broadcast OSPF network type) and apply inter-area route filtering:

    router ospf 1
    area 168 filter-list prefix TO_AREA168 in
    redistribute rip subnets
    network area 0
    network area 168
    ip prefix-list TO_AREA168 seq 5 deny
    ip prefix-list TO_AREA168 seq 10 permit le 32

    Now look at the OSPF database in SW2:

    Rack1SW2#sh ip ospf database external 

    OSPF Router with ID ( (Process ID 1)

    Type-5 AS External Link States

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

    Now check if this route is present in the routing table. Also make sure the FA address is not in the routing table too:

    Rack1SW2#sh ip route
    % Subnet not in table

    Rack1SW2#sh ip route
    % Subnet not in table

    Rack1SW2#show ip ospf database summary

    OSPF Router with ID ( (Process ID 1)

    Now, remove the inter-are route filter in R1 and check SW2’s routing table once again.

    Rack1R1(config-router)#no area 168 filter-list prefix TO_AREA168 in

    Rack1SW2#sh ip route
    Routing entry for
    Known via "ospf 1", distance 110, metric 65, type inter area
    Last update from on Vlan18, 00:00:16 ago
    Routing Descriptor Blocks:
    *, from, 00:00:16 ago, via Vlan18
    Route metric is 65, traffic share count is 1

    Rack1SW2#sh ip route
    Routing entry for
    Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 65
    Last update from on Vlan18, 00:00:16 ago
    Routing Descriptor Blocks:
    *, from, 00:00:16 ago, via Vlan18
    Route metric is 20, traffic share count is 1

    Finally, a few words on type-7 LSAs. Per the NSSA area RFC, the use of FA is mandatory with these LSAs. The reason is that there is only one 7-to-5 translating ABR and this might result in suboptimal routing without the use of FA. This makes the use of the special conditions mentioned previously unnecessary. You may always use FA-based prefix filtering with the external information conveyed in type-5 LSAs translated from type-7 LSAs.


    OSPF is a complicated protocol, which combines many features of distance-vector protocols with link-state behavior. Brought together, some of the features allow for sophisticated filtering techniques, not possible normally with pure link-state behavior. Using FA filtering is a good example of this phenomenon.

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo