OSPF NSSA P-bit Explained

Could I edit Access-list as flow to block only 192.168.45.5 on R2 and R3.

R2 & R3#
(config)#ip access-list standard FA
(config-std-nacl)#deny **192.168.45.5 0.0.0.0**
(config-std-nacl)#permit any

Hello Tuyen

I didn’t have the answer for you off the top of my head so I labbed it up. At first I thought that yes, this would work, because the access list is specifying a specific IP address. However, because this access list is then being used by a distribute list to filter prefixes from entering the routing table, I wasn’t sure how the distribute list would interpret this. I found that if you specify the specific IP address with a 0.0.0.0 wildcard mask, the distribute list will not remove the 192.168.45.0/24 subnet from the routing table. In order to “filter the forward address” you must actually filter the whole subnet as it would appear in the routing table, which means you must include the 0.0.0.255 wildcard mask.

I did some more experimentation and found the following with distribute lists:

  1. You can include a larger subnet mask to include multiple prefixes such as 192.168.44.0 0.0.254.255 for both the 192.168.44.0/24 and 192.168.45.0/24 networks
  2. If you are advertising networks on a loopback, you can use any wildcard mask as these are advertised as /32 networks using OSPF even if you have configured them as a /24 network.

I hope this has been helpful!

Laz

2 Likes

Hi Laz,
I forgot the prefixes point. I’m clear now. Thank you for your answer bro.

Rene, Thanks for an amazing content!! so R1 and R2 are in the same area “area 0”, and R2 and R4 are in the same area “area1” whey would R2 create T5 in area 0 and T7 in area 1? is it because area 1 is NSSA, and if area 1 was a normal area R2 would create T5 and send it to R4. I’m sorry but this is still confusing to me.

Hello Abdulrahman

First of all, we must keep in mind that this example has to do with the redistribution of a non-OSPF prefix into an OSPF NSSA area. By “non-OSPF” prefix, I simply mean a prefix that is not originally advertised by OSPF but is redistributed into OSPF.

Specifically, it has to do with the redistribution of the 4.4.4.4/32 subnet into the OSPF Area 1 which is an NSSA. This redistribution is performed by R4 in the lesson’s topology.

In this case, it is R4 that floods the NSSA with Type 7 LSAs. When a Type 7 LSA is received by an ABR, such as R2 and R3, it is translated to a Type 5 LSA before being flooded into Area 0.

So R4, as an ASBR in an NSSA generates a Type 7 LSA while R2 and R3 as ABRs, generate the Type 5 LSAs.

If Area 1 was not an NSSA, then R4 would generate a Type 1 LSA with a “flipped bit” to indicate it is an ASBR. The receiving ABR would translate this to a Type 4 LSA and flood it to area 0. More on this can be found in the following lesson:

I hope this has been helpful!

Laz

In the last part

R2 & R3#
(config)#ip access-list standard FA
(config-std-nacl)#deny 192.168.45.0 0.0.0.255
(config-std-nacl)#permit any

(config)#router ospf 1
(config-router)#distribute-list FA in

How did we decide its distribute-list FA in and not distribute-list FA out because we could see it like this
i am filtering the forward address and applied it ooutwards towards AREA 0 so R1 wont learn it

sorry if my question feels dumb
its little confusing to me thats why

Hello Anoop

When applying directly to distribute lists, it can become a little confusing. You must remember first that these filters are being applied in the control plane. Secondly, we must remember that it is the OSPF messages that are being filtered, and it is the direction of these messages that we must keep in mind.

In this particular example, Rene wanted to filter out the forward address on both R2 and R3, such that neither router will learn of the 192.168.45.0/24 prefix. This address would have been learned via OSPF messages that are incoming to R2 and R3 from R4.

Now having said that, if the out direction were to be used, it would have the same result for R1, because R1 would not receive any OSPF messages containing the 192.168.45.0/24 prefix, however, R2 and R3 would have this forward address in their routing tables. So you’re right that the result is the same for R1, but it is a different result for R2 and R3.

I hope this has been helpful!

Laz