OSPF NSSA P-bit Explained

vdtuyen237 · April 8, 2020, 12:10am

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

lagapidis · April 8, 2020, 8:46am

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:

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
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

vdtuyen237 · April 8, 2020, 4:13pm

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

abdu_m_k · October 6, 2021, 4:41pm

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.

lagapidis · October 9, 2021, 5:56am

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

anoopst1993 · November 1, 2021, 7:37am

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

lagapidis · November 3, 2021, 6:15am

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

rvmcinnis · October 15, 2022, 3:10pm

Hi Rene et al,

you mention “On Cisco IOS there is no way to manually change the P-bit.” and then showed a few ways of changing that behavior, but don’t you think area X nssa default-information-originate nssa-only is one of the ways that we can turn on/off the P-bit “manually” , I mean you can either set the P-bit on by doing a area 3 nssa default-information-originate or off by doing a area X nssa default-information-originate nssa-only

lagapidis · October 19, 2022, 6:20am

Hello Ricardo

From my understanding, when Rene states that you cannot manually change the p-bit, it means that there is no command that directly manipulates the p-bit. In order to do so, you must do it indirectly using one of the two methods indicated in the lesson.

However, according to this Cisco command reference, in IOS version 15.0(1)M the nssa-only keyword was added. This keyword does indeed directly set the P bit to zero. I will let Rene know to make any modifications he sees fit to the lesson.

Now having said that, in order to set the P-bit, you don’t need to use the default-information-originate keyword. You can simply do it like so:

area 3 nssa nssa-only

This would set the P-bit to zero for all LSAs.

I hope this has been helpful!

Laz

konstantinos_dimos · January 2, 2023, 2:19am

referring to the last way u saw us about filtering forwarding address:

since there is a distribute-list deny the prefix , the db still holds the redistributed prefix and the prefix u are denying , so the lsa’s for these prefixes still promoted to the area 0, why we should wait to suppress these prefixes from the routing table on R1?
So trying to fix it…
R2, R3:

 router-id 222.222.222.222
 area 0 filter-list prefix prefix_r5 in

and

ip prefix-list prefix_r5 seq 5 deny 5.0.0.0/24
ip prefix-list prefix_r5 seq 10 permit 0.0.0.0/0

R1: show ip route

    1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/24 is directly connected, Loopback0
L        1.1.1.1/32 is directly connected, Loopback0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/2] via 192.168.12.2, 00:02:40, GigabitEthernet0/0
      192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/0
L        192.168.12.1/32 is directly connected, GigabitEthernet0/0
      192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.13.0/24 is directly connected, GigabitEthernet0/1
L        192.168.13.1/32 is directly connected, GigabitEthernet0/1

i cannot get the OIA records, although it filters the OE2. Any suggestion why is it happened?

lagapidis · February 10, 2023, 5:25am

Hello Konstantinos

The lesson here is used to show how the P-bit is used, and how we can prevent or allow the translation of a Type7 LSA to a Type5 LSA by an ABR. By filtering the forward address, the router is prevented from installing the route in the routing table. You are correct that the LSA still exists in the database.

Now if you want to actually filter that LSA, you can indeed do so on the ABRs using the prefix list as you have suggested. The goal of the lesson however, was to filter the forwarding address in the context of the P-Bit. To learn more about how to use prefix lists on ABRs to filter different LSA types, take a look at this lesson:

Your prefix list is actually denying all of the LSAs from area 1. The permit statement should be:

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

Take a look at this lesson to learn more about prefix lists.

I hope this has been helpful!

Laz

PS Sorry for the late reply, this one was written about a month ago but it wasn’t posted. I apologize, but here it is anyway…

samirkhair · August 18, 2023, 5:07pm

Hi,

I also came across the summary-address nssa-only command, which when applied to the ASBR, will set the p-bit to 0 to prevent 7/5 translation.

And I noticed something else that command seemed to do. When applied to the ABR instead, it also prevents translation, even though nssa-external LSA still says Options: (No TOS-capability, Type 7/5 translation, DC, Upward). So it seems to behave like the no-translate option.

The first solution looks valid, but the second one I’m not sure about as it is undocumented. Any thoughts?

Thanks,

Sam

lagapidis · August 22, 2023, 6:11am

Hello Samir

Yes, that is correct. The setting of the P-bit will inform the ABR, when it receives the OSPF LSA, that this particular Type 7 LSA should not be translated to a Type 5 LSA. This is achieved by using the nssa-only keyword which essentially sets the “nssa-only” attribute for the summary route (another way of saying the P-bit is set).

Yes, this is to be expected. When applied on the ABR, this command will act somewhat similarly to the area nssa no-redistribution command. Even if the Type 7 LSAs have the P-bit set, the ABR will not translate them into Type 5 LSAs. Essentially, the ABR is being instructed to ignore the P-bit in this situation and not perform the 7/5 translation.

Remember the summary-address nssa-only command primarily serves to control route summarization. However, when applied to an ABR, it has this side-effect of also influencing the translation of Type 7 to Type 5 LSAs. If your goal is to purely control LSA translation, it is preferrable to use commands specifically designed for that purpose (like area nssa no-redistribution). This helps make the configuration intent more explicit and understandable to others who might review or maintain the configuration in the future.

Indeed this is undocumented behavior since there is no description of how this feature reacts when implemented on an ABR (at least I was unable to find any). However, it is not completely unexpected, since any manipulation of the P-bit will cause the ABR to obey that indicator. However, because it doesn’t receive such an LSA from another OSPF router, this does not trigger the “no translation setting” in the output. It’s an interesting situation, and thanks for pointing it out!

I hope this has been helpful!

Laz

samirkhair · September 17, 2023, 1:13pm

Hi Laz,

I came across another couple of ways of setting the P-bit to 0:

Using nssa-only on the redistribute command
Using prefix-suppression on the ASBR’s OSPF interfaces to prevent the Type-7 LSA from having a forwarding address - which triggers the following log entry:

%OSPF-4-NSSA_NO_FA: OSPF process 1 lacks forwarding address for type 7 LSA 150.1.9.9 in NSSA 1 - P-bit cleared

Also, for your forward address filtering example (1.3), I recreated but with a single ABR. I applied the distribute list in command on the ABR to filter out the forwarding addresses network from the routing table (confirmed). However, when I checked R1’s routing table and Area 0’s LSDB, the Type7-5 translation had still occurred.

Thanks,

Sam

lagapidis · September 24, 2023, 6:00am

Hello Samir

Yes, you are correct. Those are indeed two valid methods of setting the P-bit to 0 in an OSPF NSSA configuration.

The nssa-only keyword in the redistribute command indeed prevents Type-7 LSAs from being translated into Type-5 LSAs, thus effectively setting the P-bit to 0.
Using prefix-suppression on the ASBR’s OSPF interfaces prevents the Type-7 LSA from having a forwarding address. This in turn triggers the log entry you mentioned, indicating that the P-bit has been cleared.

These methods can be particularly useful in scenarios where you want to limit the propagation of external routes within your OSPF network.

Thanks for sharing this valuable information. It’s always great to learn about different approaches to network configuration.

I hope this has been helpful!

Laz