OSPF NSSA P-bit Explained

Hi Rene, The “P” bit now has a spot where the “NP” was in Wireshark, on the top of the section it’s actually called Propagate. Just an FYI

Great Practice Site, I passed my CCIE Route Switch two months ago…

Mike

3 Likes

Hi Rene,

Will the forwarding address be changed when ABR summarize the external route to other areas?

I thought Forwarding Address will be always ASBR address and Advertising router field will be changed.

But below point confused me.

To reach 5.5.5.5/32 we have to use forward address 192.168.45.5. R1 will use both R2 and R3 to reach this network:

R1#show ip route 5.5.5.5
Routing entry for 5.5.5.5/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 3
  Last update from 192.168.13.3 on FastEthernet0/1, 00:00:22 ago
  Routing Descriptor Blocks:
    192.168.13.3, from 222.222.222.222, 00:00:22 ago, via FastEthernet0/1
      Route metric is 20, traffic share count is 1
  * 192.168.12.2, from 222.222.222.222, 00:00:22 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

Regards,
Siji

Hello Siji

If you look at the output of the following command on both R2 and R3:

show ip ospf database nssa-external 5.5.5.5

you will see that the forward address is indeed the ASBR address for both routers.

From the point of view of R1, which is in another area, the routing entry for 5.5.5.5/32 is learned from both ABRs, the last update according to the above output, coming from R3. Both R2 and R3 are possible paths to the ultimate destination. If you were to issue the show ip ospf database command on R1, you should also see the forwarding address of 192.168.45.5 for that particular destination, however, the advertising router is the ABR.

Some additional helpful information about how the forwarding address is selected can be found here:

I hope this has been helpful!

Laz

hi,

Although advertising router is 192.168.234.3, how can R1 learn 4.4.4.4 from both of the R2 and R3? Why does not it learn only from R3?

R1#show ip route ospf | begin 4.4.4.4
O E2     4.4.4.4 [110/20] via 192.168.13.3, 00:38:49, FastEthernet0/1
                 [110/20] via 192.168.12.2, 00:38:49, FastEthernet0/0

R1#show ip ospf database external

            OSPF Router with ID (192.168.13.1) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 1346
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 4.4.4.4 (External Network Number )
  Advertising Router: 192.168.234.3
  LS Seq Number: 80000001
  Checksum: 0xFAE5
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 192.168.234.4
        External Route Tag: 0

regards,

Hello Murat

R1 will receive a Type5 LSA from both R2 and R3. This is why you see that both routes are in the routing table, since OSFP employs equal cost load balancing by default. Now the advertising router ID you see in the database is that of the last and most updated LSA type 5 that has been received. Even though the route was updated at the same time (to the second accuracy) according to the output of the routing table, one of the two routers will have sent their update a split second earlier. Thus, the advertising router in the database indicates the router from which the last advertisement was sent.

I hope this has been helpful!

Laz

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

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

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

1 Like

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?

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…

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

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

1 Like

Hi Laz,

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

  1. Using nssa-only on the redistribute command
  2. 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

Hello Samir

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

  1. 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.
  2. 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

1 Like