Now for this post I am going to walkthrough configuring redistribution between OSPF & RIP. I will also cover route filtering config options between the two OSPF areas. At this point all routed connections between the routed FTD instance & the 4 CSRs are configured and working as expected.
Again, sharing the topology:
First I want to cover OSPF route filtering options before diving into examples of how to configure them on FTD. Covering the basics, there are 3 ways to conduct route filtering with OSPF:
Filter routes between different areas via a filter list with an ACL
Filter routes from getting installed in the route table via a distribute list
Filter routes from another protocol via redistribution configuration
It is important to know that a distribute list is not an actual list. It is the command used to enable the ability to filter routes. The filtering is actually performed via a prefix-list or ACL. Prefix-lists allow you to filter networks based on their subnet mask. Whereas an ACL in a route filtering example allows filtering on network addresses and not subnet masks.
So before diving into the FTD configuration with FMC I want to share a few things relating to route filtering. With no filtering in place on FTD, OSPF area 1 (connected on outside interface of FTD) can see OSPF area 0 routes learned on FTD from its dmz_1 interface OSPF adjacency (10.10.10.0/24). Here are snippets from the CSR connected to FTD outside interface:
We can see the 188.8.131.52 loopback emulating a LAN appear in the route table. We also see the same scenario where both the area 1 network and loopback appear between the other OSPF enabled area which contains the CSR connected to area 0 on the dmz_1 interface of FTD:
Since FTD is connected to both CSRs in different areas OSPF creates a type 3 summary LSA which gets flooded into each respective area. This type 3 LSA lets the CSRs know about prefixes from the other area/s. Lastly, the OSPF routes appearing in the route table with O IA means that those are type 3 summary LSAs which are the inter-area prefixes.
Ok so know that we have some background I want to focus on route filtering so that FTD filters the dmz_1 CSR loopback 184.108.40.206 from being advertised in the type 3 LSA to the CSR connected to the FTD outside interface. To do this I used the following in FMC for FTD route filtering:
OSPF Inter-Area (IA) Filtering = uses prefix lists; only the specified prefixes are sent from one area to another. All other prefixes are restricted. Can be applied out or into an area.
I will now share how to configure and verify (Inter-Area filtering via prefix-list) configuration with FTD & then share the updated route table from the respective CSR.
Step 1 is to create the prefix-list object (Objects->Object Management->Prefix-List->IPv4 Prefix-Lists):
So here I am preventing/restricting the dmz_1 CSR local loopback from being advertised & allowing all other prefixes.
Step 2 is to assign the prefix-list to the OSPF configuration (Devices->Device Management->Routing->OSPF->InterArea):
Under the OSPF routing configuration within FMC you assign the prefix-list object under the InterArea tab. It is enabled on process 1 & configured with/on inbound to area 1.
Final step is to deploy the configuration changes & verify.
FTD CLI verification:
Above we can see FTD hit counts on the prefix-list
Outside CSR verification:
We no longer see the dmz_1 loopback interface in the OSPF database or route table as expected :)
Ok so now I want to cover FTD route summarization. Utilizing route summarization allows you to decrease the size of the OSPF LSA database. Instead of advertising multiple type 3 or type 5 LSAs we can advertise a single route to summarize multiple routes.
To provide this example I created several additional loopbacks on the CSR connected to dmz_1 interface (note I did remove the OSPF Inter-Area filter from the previous example). The CSR on connected to the FTD outside interface has several type 3 LSAs in its database due to the creation/advertisement of the loopbacks with no summarization involved yet:
To configure route summarization on an OSPF area within FMC for FTD (Devices->Device Management->Routing->OSPF->Area->Range):
The dmz1_loop_summary object I created is a summary range = 220.127.116.11/22. Once this is created and applied to the area that the routes belong to. So in this case area 0 on dmz_1 side.
FTD route summarization verification:
We can see that the outside CSR LSA database is smaller than before:
The route table also depicts the summarized route for all loopbacks:
Ok, now for the last section of this blog, I will cover OSPF redistribution. A few things to cover/understand are:
Prefixes being redistributed into OSPF from another protocol create type 5 LSAs. These types of advertisements appear in the route table via O E1 or O E2.
My goal here is to advertise the loopback address on the CSR connected to the dmz_2 FTD interface (18.104.22.168). There are a few configuration steps required to make this happen.
Step 1: Configure standard access-list (Objects->Object Management->Access-list->Standard)
The overview of the configuration:
Step 2: Configure route-map
You now need to configure a route-map & assign the acl and additional parameters. Note that this route map will get added in the OSPF routing configuration.
Route map overview:
We assign the ACL as our match clause:
Step 3: Tying it all together and deploying with OSPF config:
Configuring redistribution on OSPF process 1, since the route is coming from RIP the type needs to be set to RIP, enable use subnets, set metric type, & tie in the route map so that only the loopback (22.214.171.124) is redistributed.
FTD OSPF redistribution verification on OSPF CSR:
Above we can see the dmz_2 CSR loopback 126.96.36.199 being advertised into OSPF due to the FTD configuration.
Additional RIP routes are hitting the deny (6 hits) & we can see the dmz_2 loop (188.8.131.52) hit count incremented.
Alright, so that wraps up this post covering OSPF route filtering, summarization, & redistribution on FTD. See more via the FTD tag. Cheers!