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.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

11 Responses to “OSPF Prefix Filtering using Forwarding Address”

  1. Oh, yes, this is definitely “esoteric” ;)

    • @Ivan,

      heh, what’s really is “fun” is that Cisco violates the RFC for FA checks. Per the standard the prefix must be either OSPF internal or inter-area route. However, Cisco’s implementation is OK if the prefix is accessible via any non-OSPF protocol, e.g. BGP. Then again, no one is oblidged to follow the standard, even if it makes sense ;)

  2. IK says:

    great research, thank you Petr!

  3. Deepak Arora says:

    Hi Petr,

    Can you please spend some time to writeup an article on OSPF Incremental SPF (ISPF), SPF throttling, pacing timers, I know it’s only matter of few command but understanding it’s behavior with some practical example will be a great help from you.

    Deepak Arora

  4. IPv6Freely says:

    Thank god nothing this crazy would ever be on the lab… still neat though!

  5. Eamonn McGonigle says:

    Hi Petr,

    Thanks for an interesting article. May I point out a small error in your diagram ? The network connected to R1:Serial0/0 is labelled as OSPF Area 168 but should be labelled as Area 0

  6. Bobby Hockensmith says:

    Can anybody explain why a Type-4 is inserted into a non-backbone area by an ABR when the type-5 has a non-zero forwarding address. I know IOS does this — not sure about Juniper — and there is nothing in the RFC to do this when it is not needed. I could be wrong, but I am positiive the Type-4 is not used. The routers in that area will use the LSA 3 to do a lookup for the forwarding-address to determine best path and metric and from there use the LSA 1 for the ABR that inserted the LSA 3.

  7. @NET_OG

    Did not post your comment just as you asked :) Sorry about the broken link, there was a leading space (%20) in the URL.

  8. Net_OG says:


    no worries I had the link thanks to google.

    Just being a good INE-Citizen and letting you guys know…
    thanks for the great post. Some of these posts were way to in depth for me but now they are really making a lot of sense. Keep up the good work.

  9. Olga says:

    >>However, Cisco’s implementation is OK if the prefix is accessible via any non-OSPF protocol, e.g. BGP

    It could be IOS version, because I cleary remember how we had problems while migrating to IS-IS and have some prefixes in IS-IS, some in OSPF – some E2 was not in RIB because FA was not reachable (but it was known via IS-IS).

  10. [...] Routing Problem with OSPF Forwarding Address OSPF Prefix Filtering Using Forwarding Address Tags: bgp, CCDE, ccie, eigrp, ospf, rip, third-party next-hop Download this page as a [...]


Leave a Reply


CCIE Bloggers