OSPF: P-bit Setting in Type-7 LSAs

This post represents the solution and explanation for quiz #5. Have a look at the quiz to understand the problem.

At first look, the quiz seemed tricky because of OSPFv3/IPv6, but the thing is that the problem/quiz applies to both OSPFv2 and OSPFv3!
As most of you already indicated in the Comments section, the junior engineer did make a mistake: he put/left the Vlan102 interface in area 0.0.0.0 (clearly shown in the output of command “show ipv6 ospf int b“) which makes from Dist-2 router an ABR (Area Border Router).

My next question to all of you would be: “so, what?… why an ABR cannot accept that default route received from another ABR (the COREs in our quiz)?” … let’s see why:

We all know that the motivation of having an NSSA is to allow external routes into a Stub area. External routes (learned from different routing domains) are carried within the NSSA area as Type-7 LSAs. As specified in RFC 1587, there are some bits in the Options field that are important in our context:

• N-bit = used in the Hello packets to indicated that the router has NSSA capability on that interface (two routers will not form an ajancency unless they agree on the N-bit, meaning they are both configured as NSSA for that interface)
• P-bit = (P – propagate) only used in type-7 LSAs to tell the ABRs to translate that type-7 LSA into a type-5 LSA. This P-bit is also used as a routing loop prevention mechanism.

Have a look at the picture below:

On the right-hand side, the ASBR (connected to other routing domains) will send the external prefixes within type-7 LSAs with the P-bit set. These LSAs will be translated into type-5 LSAs on both ABRs.

On the left-hand side, the ABR-1 and ABR-2 (COREs in our quiz) originate type-7 default route and they MUST NOT set the P-bit. When these type-7 LSAs reach other ABRs, since they don’t have the P-bit, they will not be considered for SFP calculations and will not get to the routing table.

Let’s have a look at OSPF’s database on our Dist-2:

Dist-2#sh ipv ospf database
...
                Type-7 AS External Link States (Area 192.168.1.0)

ADV Router      Age         Seq#        Prefix
192.168.255.1   231         0x80000001  ::/0
192.168.255.2   220         0x80000001  ::/0
...
Dist-2#sh ipv ospf database nssa-external

            OSPFv3 Router with ID (192.168.255.4) (Process ID 1)

                Type-7 AS External Link States (Area 192.168.1.0)


  LS age: 263
  LS Type: AS External Link
  Link State ID: 1
  Advertising Router: 192.168.255.1
  LS Seq Number: 80000001
  Checksum: 0x6565
  Length: 28
  Prefix Address: ::
  Prefix Length: 0, Options: None
  Metric Type: 2 (Larger than any link state path)
  Metric: 1

  LS age: 252
  LS Type: AS External Link
  Link State ID: 1
  Advertising Router: 192.168.255.2
  LS Seq Number: 80000001
  Checksum: 0x5F6A
  Length: 28
  Prefix Address: ::
  Prefix Length: 0, Options: None
  Metric Type: 2 (Larger than any link state path)
  Metric: 1



Dist-2#sh ipv route ::/0
% Route not found

As you can see, Dist-2 knows the two default injected by cores in the OSPF database, but does not put them into the routing table – as an ABR, it does not accept type-7 LSA without P-bit, in order to avoid routing loops.

Now, let’s fix the mistake ( configure area 192.168.1.0 on Vlan102 interface) and check again:

Dist-2(config)#int vlan 102 Dist-2(config-if)#ipv6 ospf 1 area 192.168.1.0 Dist-2(config-if)#end Dist-2# Dist-2#sh ipv route ::/0 ... ON2 ::/0 [110/1] via FE80::C001:1CFF:FE3C:10, FastEthernet0/1 via FE80::C000:1CFF:FE3C:10, FastEthernet0/0 Dist-2#

Dist-2#sh ipv osp int b Interface PID Area Intf ID Cost State Nbrs F/C Vl102 1 192.168.1.0 30 1 DR 0/0 Vl201 1 192.168.1.0 35 1 DR 0/0 Vl200 1 192.168.1.0 34 1 DR 0/0 Vl105 1 192.168.1.0 33 1 DR 0/0 Vl104 1 192.168.1.0 32 1 DR 0/0 Vl103 1 192.168.1.0 31 1 DR 0/0 Vl101 1 192.168.1.0 29 1 DR 0/0 Vl100 1 192.168.1.0 28 1 DR 0/0 Fa0/1 1 192.168.1.0 5 1 DR 1/1 Fa0/0 1 192.168.1.0 4 1 DR 1/1 Lo0 1 192.168.1.0 27 1 LOOP 0/0

you’ll notice the additional information “Routing Bit Set on this LSA” (that did not exist before !!). This is a Cisco implementation to indicate that the LSA is valid (passed all sanity checks) for SFP calculation (please note that this “routing-bit” is not an actual bit in the LSA Option field, it is stored only locally, not propagated to other OSPF routers).

In the end, let’s have a look how a type-7 LSA with P-bit SET looks like: suppose ASBR (Dist-1 in our case) redistributes the external prefix 2003:1:1:1::/64

Dist-2#sh ipv route 2003:1:1:1::/64
...
ON2  2003:1:1:1::/64 [110/20]
     via FE80::C001:1CFF:FE3C:10, FastEthernet0/1
     via FE80::C000:1CFF:FE3C:10, FastEthernet0/0
Dist-2#
Dist-2#sh ipv ospf database nssa-external
...
  Routing Bit Set on this LSA
  LS age: 42
  LS Type: AS External Link
  Link State ID: 2
  Advertising Router: 192.168.255.3
  LS Seq Number: 80000001
  Checksum: 0x89B4
  Length: 36
  Prefix Address: 2003:1:1:1::
  Prefix Length: 64, Options: P
  Metric Type: 2 (Larger than any link state path)
  Metric: 20

As you can see, this type-7 LSA will be flooded into entire NSSA area and it has the P-bit set (also notice the “Routing Bit Set on this LSA”).

Thanks everyone for your comments into the quiz !

OSPF LSA Types:

OSPF uses a LSDB (link state database) and fills this with LSAs (link state advertisement). Instead of using 1 LSA packet OSPF has many different types of LSAs and in this tutorial I’m going to show all of them to you. Let’s start with an overview:

• LSA Type 1:            Router LSA
• LSA Type 2:            Network LSA
• LSA Type 3:            Summary LSA
• LSA Type 4:            Summary ASBR LSA
• LSA Type 5:            Autonomous system external LSA
• LSA Type 6:            Multicast OSPF LSA
• LSA Type 7:            Not-so-stubby area LSA
• LSA Type 8:            External attribute LSA for BGP

# For many people it helps to visualize things in order to understand and remember. I like to visualize OSPF LSAs as jigsaw puzzle pieces. One jigsaw is nothing but all of them together give us the total picture…for OSPF this is the LSDB.

Here’s the first LSA Type:

Each router within the area will flood a type 1 router LSA within the area. In this LSA you will find a list with all the directly connected links of this router. How do we identify a link?

• The IP prefix on an interface.
• The link type. There are 4 different link types:

Link Type	Description	Link ID
1	Point-to-point connection to another router.	Neighbor router ID
2	Connection to transit network.	IP address of DR
3	Connection to stub network.	IP Network
4	Virtual Link	Neighbor router ID

Don’t worry too much about the link types for now, we will see them later. Keep in mind that the router LSA always stays within the area.

The second LSA type (network LSA) is created for multi-access networks:

The network LSA or type 2 is created for each multi-access network. Remember the OSPF network types? The broadcast and non-broadcast network types require a DR/BDR. If this is the case you will see these network LSAs being generated by the DR. In this LSA we will find all the routers that are connected to the multi-access network, the DR and of course the prefix and subnet mask.

In my example above we will find R1, R2 and the DR in the network LSA. We will also see the prefix 192.168.123.0 /24 in this LSA. Last thing to mention: the network LSA always stays within the area.

Let’s look at the third LSA type:

Type 1 router LSAs always stay within the area. OSPF however works with multiple areas and you probably want full connectivity within all of the areas. R1 is flooding a router LSA within the area so R2 will store this in its LSDB. R3 and R4 also need to know about the networks in Area 2.

R2 is going to create a Type 3 summary LSA and flood it into area 0. This LSA will flood into all the other areas of our OSPF network. This way all the routers in other areas will know about the prefixes from other areas.

The name “summary” LSA is very misleading. By default OSPF is not going to summarize anything for you. There is however a command that let you summarize inter-area routes. Take a look at my OSPF summarization tutorial if you are interested. If you are looking at the routing table of an OSPF router and see some O IA entries you are looking at LSA type 3 summary LSAs. Those are your inter-area prefixes!

Time for the fourth LSA type:

In this example we have R1 that is redistributing information from the RIP router into OSPF. This makes R1 an ASBR (Autonomous System Border Router). What happens is that R1 will flip a bit in the router LSA to identify itself as an ASBR. When R2 who is an ABR receives this router LSA it will create a type 4 summary ASBR LSA and flood it into area 0. This LSA will also be flooded in all other areas and is required so all OSPF routers know where to find the ASBR.

What about LSA type 5? Let’s check it out:

Same topology but I’ve added a prefix (5.5.5.0 /24) at our RIP router. This prefix will be redistributed into OSPF. R1 (our ASBR) will take care of this and create a type 5 external LSA for this. Don’t forget we still need type 4 summary ASBR LSA to locate R1. If you ever tried redistribution with OSPF you might have seen O E1 or E2 entries. Those are the external prefixes and our type 5 LSAs.

What about OSPF LSA type 6? Type 6 multicast ospf LSA I can skip because it’s not being used. It’s not even supported by Cisco. We use PIM (Protocol Independent Multicast) for multicast configurations.

If you are studying the LSA types for CCNA R&S then you don’t have to worry about LSA type 7. These are used for a special area type called NSSA that is only covered in the CCNP ROUTE material.

Let’s look at the last LSA type, number 7:

Last LSA type…promised! NSSA areas do not allow type 5 external LSAs. In my picture R1 is still our ASBR redistributing information from RIP into OSPF.

Since type 5 is not allowed we have to think of something else. That’s why we have a type 7 external LSA that carries the exact same information but is not blocked within the NSSA area. R2 will translate this type 7 into a type 5 and flood it into the other areas.

Let me summarize the LSA types for you:

• Type 1 – Router LSA: The Router LSA is generated by each router for each area it is located. In the link-state ID you will find the originating router’s ID.
• Type 2 – Network LSA: Network LSAs are generated by the DR. The link-state ID will be the router ID of the DR.
• Type 3 – Summary LSA: The summary LSA is created by the ABR and flooded into other areas.
• Type 4 – Summary ASBR LSA: Other routers need to know where to find the ASBR. This is why the ABR will generate a summary ASBR LSA which will include the router ID of the ASBR in the link-state ID field.
• Type 5 – External LSA: also known as autonomous system external LSA: The external LSAs are generated by the ASBR.
• Type 6 – Multicast LSA: Not supported and not used.
• Type 7 – External LSA: also known as not-so-stubby-area (NSSA) LSA: As you can see area 1 is a NSSA (not-so-stubby-area) which doesn’t allow external LSAs (type 5). To overcome this issue we are generating type 7 LSAs instead.

The only thing left to do is take a look at 

OSPF: UNDERSTANDING PROCESS ID TOPOLOGY

SCENARIO

TWO DEVICES

WAN & CORE

1. PURPOSE OF WAN DEVICE

This is the end device, on which we have access. This device is connected to Vendor.

2. PURPOSE OF CORE DEVICE

This is the core layer device of datacenter, connecting to WAN device further

LOGS

WAN # sh cdp nei

Device ID Local Intrusion HoldTme Capability Platform Port ID

Fuse_core_1 Gig 2/1 155 RSI WS-C6513 Gig 13/41

PHYSICAL CONNECTION: WAN (Gig2 / 1) ========== CORE (Gig 13/41) 

WAN # sh ip ospf int g2 / 1 | i Process

Process ID 100,   router ID 10146192252, Network Type BROADCAST, Cost: 1

CORE # sh ip ospf int g13 / 41 | i Process

Process ID 65225,   router ID 10.146.1.254, Network Type BROADCAST, Cost: 1

CONCLUSION

On all the interfaces of WAN device, Process ID 100 is running on the CORE device, Process ID 65225 is running.

At WAN device, we have Process ID 100  & Area is 0, on interface connecting to CORE device  

At Core Device, we have Process ID 65225 & Area is 0, on interface connecting to WAN device   

QUERY

By default, Two process ID can not communicate with any other subnets.

How these two routers have different process, exchanging routes with each other?

What can be the design prospective in this scenario?

MORE LOGS FOR REFERNCE PURPOSE 

CORE # sh ip ospf int | i Process

Process ID 65225, Router ID 10.146.1.254, Network Type POINT_TO_POINT, Cost: 1

Process ID 65225, Router ID 10.146.1.254, Network Type BROADCAST, Cost: 1

CORE # sh ip ospf int | i Area

Internet Address 10.146.192.161/30, Area 0

Internet Address 10.146.192.133/30, Area 0

WAN # sh ip ospf int | i Process

Process ID 100, Router ID 10.146.192.252, Network Type LOOPBACK, Cost: 1

Process ID 100, Router ID 10.146.192.252, Network Type BROADCAST, Cost: 1

WAN # sh ip ospf int | i Area

Internet Address 10.146.192.252/32, Area 0

Internet Address 10.146.203.97/28, Area 0

---

SOLUTION

Hey, re-think about statement

"Two different process ID can not communicate with each other"

That's true, above statement is correct, but there's a catch in the statement. So, i am re-phrasing the statement.

"Two different processes can not communicate with each other,

Or we can say

"Process ID is very significant to router"

Here, Two different processes are running, true, but on two different devices. So, this is a normal scenario. It will not create any problem. Routes will be exchanged between devices.