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: 184.108.40.206. 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.
- 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.
- 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:
R1: router ospf 1 area 168 filter-list prefix TO_AREA168 in redistribute rip subnets network 220.127.116.11 0.0.0.0 area 0 network 18.104.22.168 0.0.0.0 area 168 ! ip prefix-list TO_AREA168 seq 5 deny 22.214.171.124/24 ip prefix-list TO_AREA168 seq 10 permit 0.0.0.0/0 le 32
Now look at the OSPF database in SW2:
Rack1SW2#sh ip ospf database external OSPF Router with ID (126.96.36.199) (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: 188.8.131.52 (External Network Number ) Advertising Router: 184.108.40.206 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: 220.127.116.11 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 18.104.22.168 % Subnet not in table Rack1SW2#sh ip route 22.214.171.124 % Subnet not in table Rack1SW2#show ip ospf database summary 126.96.36.199 OSPF Router with ID (188.8.131.52) (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 184.108.40.206 Routing entry for 220.127.116.11/24 Known via "ospf 1", distance 110, metric 65, type inter area Last update from 18.104.22.168 on Vlan18, 00:00:16 ago Routing Descriptor Blocks: * 22.214.171.124, from 126.96.36.199, 00:00:16 ago, via Vlan18 Route metric is 65, traffic share count is 1 Rack1SW2#sh ip route 188.8.131.52 Routing entry for 184.108.40.206/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 65 Last update from 220.127.116.11 on Vlan18, 00:00:16 ago Routing Descriptor Blocks: * 18.104.22.168, from 22.214.171.124, 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.
11 Responses to “OSPF Prefix Filtering using Forwarding Address”
Leave a Reply