OSPF inter-area filtering not working

[jeremydetwiler16]

Good morning all! I'm running into an issue with some OSPF inter-area routing I'm working on. In a nutshell, I have a core switch and a WAN device in area 0 and the same core switch and a Fortigate in area 2. All WAN routes are learned in area 0 and being sent into area 2. I have defined the SVI to be assigned to area 2, like so:

interface Vlan2
ip address 10.1.2.3 255.255.255.248
ip ospf 1 area 2
end

So far so good and I have a successful OSPF neighborship with the Fortigate learning all OSPF routes with a gateway of 10.1.2.3. Next, I create a prefix-list to filter out 10.1.0.0/24:

ip prefix-list FilterDefault seq 5 deny 10.1.0.0/24

ip prefix-list FilterDefault seq 10 permit 0.0.0.0/0 le 32

Easy enough. Lastly, I apply the filter-list command in OSPF to filter this route out:

router ospf 1
area 2 filter-list prefix FilterDefault in

Should work right? WRONG. No matter what I do, I cannot filter out ANYTHING from the Fortigate. I tried area 0 filter-list prefix FilterDefault out. I even tried doing an ip prefix-list FilterDefault seq 10 deny 0.0.0.0/0 le 32 and still nothing is filtered. Am I missing something??? For reference, my core switch is a Cisco 3650 running IOS XE 16.6.5:

Cisco IOS XE Software, Version 16.06.05

Any help is appreciated!

[Georg Pauwen]

Hello,

you are using two different process IDs, is that on purpose ? Not sure how that influences the filtering. If you have configured the filter-list on the ABR, it should work.

interface Vlan2
ip address 10.1.2.3 255.255.255.248
ip ospf 1 area 2
!

router ospf 10254
area 2 filter-list prefix FilterDefault in

Can you post the output of:

show ip ospf 1 | begin area 2

from the ABR ?

[jeremydetwiler16]

Sorry, that was a typo from the actual config. I've fixed that in the original post so both are process ID 1. Here's the output:

Area 2
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 02:00:26.514 ago
SPF algorithm executed 8 times
Area ranges are
Area-filter FilterDefault in
Number of LSA 4. Checksum Sum 0x01E7B3
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 1
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

[Georg Pauwen]

Hello,

check the Link ID of the 10.1.0.0/24 network with 'show ip ospf database', it is probably something like 10.1.0.1, or whatever IP address you have configured on that interface. Match this IP with a /32 mask in the prefix list, and apply the filter list inbound on area 0:

ip prefix-list FilterDefault seq 5 deny 10.1.0.1/32
ip prefix-list FilterDefault seq 10 permit 0.0.0.0/0 le 32
!
area 0 filter-list prefix FilterDefault in

[Martin L]

I get always confused with in or out with LSA3 filtering with area x prefix in/out command;
I think u should use out not in, try
router ospf 1
area 0 filter-list prefix FilterDefault out

[Giuseppe Larosa]

Hello ,

first of all, only internal routes can be filtered.

Then if the prefix is learned in area 0 as an internal route, and the local router is an ABR  = it has one interface in area 0 and one interface in area 2, then you can perform inte area filtering in two ways:

area 0 filter-list FilterDefault out  --- > this should deny the prefix to each other area

area 2 filter-list FilterDefault in   ----> this should deny the prefix from entering area 2

To verify if the route filtering is effective you need to look at the summary routes in area 2 in OSPF database

show ip ospf database summary-route   <prefix>

Hope to help

Giuseppe

[jeremydetwiler16]

Ah, so the routes I'm trying to filter are external routes. How do I get around that? I did find this from a similar thread:

The external routes can be filtered on the router that originates them, therefore, if you like to filter them on the ABR of the area that has the ASBR, you need to convert that area into a NSSA, once you do that, the ABR receives Type-7s and originates type-5s, now you can configure the "summary-address 192.168.1.0 255.255.255.0 not-advertise" on the ABR because it is originating the external route/s.

I do need to make sure then that if I make the area learning the WAN routes an NSSA that I can still learn a default route from the ASBR and advertise that into the other area.

[Giuseppe Larosa · Accepted solution]

Hello Jeremy,

if the routes you want to filter / stop are external routes you need to use a NSSA area that cannot be area 0.

You stlll need an area 0 between the NSSA area and another area.

OSPF multi area requires area 0 to be at the center both for LSAs propagation both for user traffic routing.

However, an ABR is an ABR if it has at least one interface in area 0.

Without a live interface in area 0 the ABR wil not propagate LSAs between the other areas.

You need to do what is suggested in the sentence that you have reported.

The ABR has the faculty to convert LSA type 7 to type 5 selectively.

Either the ASBR does not set the P propagation bit in the LSA type 7 or the ABR creates a summary-address with no-advertise keyword.

This will block the translation of the specified prefix(es) matching the summary address.

All other LSA type 7 will be converted to type 5  (if the P bit is set on the ASBR node inside the NSSA area).

To be noted, for NSSA areas the ABR will not by default generate a default route to be injected into the NSSA area.

So all you need to do is to avoid to generate the default route on the ABR node(s) and just translate the default route coming as LSA type 7 from the ASBR node to a standard LSA type 5 and to block the unwanted route with the summary-address no-advertise trick.

You can achieve the desired routing behaviour, but area 0 must exist also as explained above.

Note:

if you have two ABR nodes between area NSSA and area 0 (and any other directly attached area) the type 7 to type 5 translation is performed only by the ABR with the highest OSPF RID,

This is normal and expected, load balancing and recursion is achieved by setting the Forwarding address to an address of the ASBR node.

The forwarding address must be advertised as an internal OSPF route in the NSSA area otherwise the external LSA will not be installed by other OSPF routers in other areas ( 0 and standard areas)

Hope to help

Giuseppe

[jeremydetwiler16]

Perfect explanation. Thanks very much Giuseppe!