Network's IP address as contents of Link ID and Link State ID in Router's and Summary LSA

Hello Rene,
Sometimes, in case of OSPF, I’m facing with a Host IP address and a prefix /32 in the fields, where I hope to find the network IP address with the prefix /30 and less accordingly. It would be great you could clear up my questions, which correspond to content of some LSA fields in case of point-to-point connection between Routers. Namely:

• Router’s LSA Link Type 3 (Stub Network Link) – Link ID / Link Data.
• Summary Network LSA – Link State ID / Network Mask

In both of cases, according to name - Network, it should be here network’s IP address / mask or prefix and length of prefix. Take an example. There are three point-to-point connection between three routers with assigned subnets and IP addresses for segment’s interfaces:

• 172.16.1.1, 172.16.1.2, mask – 255.255.255.0
• 172.16.2.1, 172.16.2.2, mask – 255.255.255.0
• 172.16.3.1, 172.16.3.2, mask – 255.255.255.0

Let’s suppose, all three reside in Area 0 and router with interface 172.16.1.1, for example, is the ABR and have to propagate information about Subnets to next Area.
First of all, each Router in theirs Router’s LSA have to form the Stub Network Link with network’s addresses and mask in the fields Link ID and Link Data accordingly:

• 172.16.1.0 / 255.255.255.0
• 172.16.2.0 / 255.255.255.0
• 172.16.3.0 / 255.255.255.0

Second, the Router will produce 3 summary-LSA with the same data as Link State ID and Mask.

Well, it is theory and concerning to the Stub Network link of Router’s LSA, it correspond to the RFC 2328 Option 2 case (Page 130). My question here would be following. There is also Option 1 in RFC, where Link ID could be presented as Host’s IP address with 0xffffff mask in the field - Link Data. Is this the case?
Next question. How Router would derive network’s IP address, when nevertheless there would be the network’s one?

I’m asking, because I have collide in my working activity with OSPF implementation where Link ID field contains Host IP address with prefix length /32. I have asked developers if it is correct, because on the next step, above mentioned ABR would produce 6 network summary LSA with host IP address of each Interface for each subnet. In which connection, that an additional aggregation command isn’t implemented yet. According to developers: it is completely correspond to the requirements of RFC2328 and only in case of presence additional aggregation’s command, for example, for each from three subnet, it would be possible to reduce number of the summary LSA to three. Only then, there will be network’s IP addresses and mask in Link State ID and Network Mask fields accordingly. Of course, additional aggregation command for the network 172.16.0.0/16, could reduce the number of summary LSA to single.

Therefore, my question is, if this implementation is correct. I’ve tried to modelling this situation with Cisco Packet Tracer. CISCO IOS acts according to the described scenario. That is, there is exactly the network prefix in the stub link of router’s LSA and also 3 summary LSA is generated by ABR for each point-to point subnet. Of course, without additional aggregation’s command.

RFC2328 doesn’t say definitely, if summary network LSA should consist only network’s address as Link State ID. There is only a description of example in RFC on Page 138, where is mentioned a condensing host routes Ia and Ib into a single summary-LSA. Is this the case? In general, is it difficult for Router, in case of point-to-point segment, to find out the prefix? What take the Router as the source for summary network LSA?

Would you like please to explain this situation?
Best Regards
Jurij

Hi @juraj651013,

After reading your post, let me make sure that I have the same topology that you had in mind:

ospf-area-0-area-1-three-routers

I added R3 behind R1, making R1 the ABR. The three point-to-point links are in between R1 and R2.

R1:

hostname R1
!
interface GigabitEthernet0/1
 ip address 172.16.1.1 255.255.255.0
 ip ospf network point-to-point
!
interface GigabitEthernet0/2
 ip address 172.16.2.1 255.255.255.0
 ip ospf network point-to-point
!
interface GigabitEthernet0/3
 ip address 172.16.3.1 255.255.255.0
 ip ospf network point-to-point
!
interface GigabitEthernet0/4
 ip address 192.168.13.1 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 network 172.16.1.0 0.0.0.255 area 0
 network 172.16.2.0 0.0.0.255 area 0
 network 172.16.3.0 0.0.0.255 area 0
 network 192.168.13.0 0.0.0.255 area 1
!
end

R2:

hostname R2
!
interface GigabitEthernet0/1
 ip address 172.16.1.2 255.255.255.0
 ip ospf network point-to-point
!
interface GigabitEthernet0/2
 ip address 172.16.2.2 255.255.255.0
 ip ospf network point-to-point
!
interface GigabitEthernet0/3
 ip address 172.16.3.2 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 network 172.16.1.0 0.0.0.255 area 0
 network 172.16.2.0 0.0.0.255 area 0
 network 172.16.3.0 0.0.0.255 area 0
!
end

R3:

hostname R3
!
interface GigabitEthernet0/1
 ip address 192.168.13.3 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 network 192.168.13.0 0.0.0.255 area 1
!
end 

Looking at the summary LSAs from R3’s perspective:

R3#show ip ospf database summary adv-router 172.16.1.1

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

                Summary Net Link States (Area 1)

  LS age: 932
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 172.16.1.0 (summary Network Number)
  Advertising Router: 172.16.1.1
  LS Seq Number: 80000031
  Checksum: 0x38C
  Length: 28
  Network Mask: /24
        MTID: 0         Metric: 1 

  LS age: 932
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 172.16.2.0 (summary Network Number)
  Advertising Router: 172.16.1.1
  LS Seq Number: 80000031
  Checksum: 0xF796
  Length: 28
  Network Mask: /24
        MTID: 0         Metric: 1 

  LS age: 932
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 172.16.3.0 (summary Network Number)
  Advertising Router: 172.16.1.1
  LS Seq Number: 80000031
  Checksum: 0xECA0
  Length: 28
  Network Mask: /24
        MTID: 0         Metric: 1

Hello Rene!
Thanks for answer. The topology could be a little bit changed. Because we are speaking about point-to-point connections, R1 should be connected with three another routers through point-to-point links instead of with one router. For Example: R1 to R2 through point-to-point link 172.16.1.0/24, R1 to R4 and R1 to R5 through links 172.16.2.0/24 and 172.16.3.0/24 accordingly. However, this actually does not change the look of summary network LSA e.g., 172.16.1.0/24’s connection between R1 and R2 from R3’s perspective, that you have presented.
In fact, since I’ve posted this topic, I’ve been deepening in described situation and found out, that it’s not a bug it’s a feature. Actually another implementation of OSPF, which, in principle, does not contradict to RFC2328. Let me explain.
According to our topology and OSPF implementation I’m dealing with, the summary network LSA of point-to- point connection between R1 and R2 look like:

You can see, here are two LSAs instead one. Also in the fields “Link State ID” of LSAs - the interface addresses with mask /32 accordingly istead of prefix with mask /24 (in native topology R1 have router ID 3.3.3.3).
So, at the beginning I was puzzled: how is it possible? That is why I decided to ask you. It differ from CISCO view and causes a doubt. As it turned out, it’s not a bug, because is connected to router LSA, more exactly, how in the router LSA is represented the stub link of point-to-point connection. According to RFC 2328 (page 130) there are two possibilities of stub link implementation:

In addition, as long as the state of the interface is “Point-to-Point” (and regardless of the neighboring router state), a Type 3 link (stub network) should be added. There are two forms that this stub link can take:

12.4.1.1. Describing point-to-point interfaces

            For point-to-point interfaces, one or more link
            descriptions are added to the router-LSA as follows:

            o   If the neighboring router is fully adjacent, add a
                Type 1 link (point-to-point). The Link ID should be
                set to the Router ID of the neighboring router. For
                numbered point-to-point networks, the Link Data
                should specify the IP interface address. For
                unnumbered point-to-point networks, the Link Data
                field should specify the interface's MIB-II [Ref8]
                ifIndex value. The cost should be set to the output
                cost of the point-to-point interface.

            o   In addition, as long as the state of the interface
                is "Point-to-Point" (and regardless of the
                neighboring router state), a Type 3 link (stub
                network) should be added. There are two forms that
                this stub link can take:

                Option 1
                    Assuming that the neighboring router's IP
                    address is known, set the Link ID of the Type 3
                    link to the neighbor's IP address, the Link Data
                    to the mask 0xffffffff (indicating a host
                    route), and the cost to the interface's
                    configured output cost.[15]

                Option 2
                    If a subnet has been assigned to the point-to-
                    point link, set the Link ID of the Type 3 link
                    to the subnet's IP address, the Link Data to the
                    subnet's mask, and the cost to the interface's
                    configured output cost.[16]

Here we can see that if stub link is made according to Option 2 we will see the usual CISCO view for stub link in router LSA:

Forum_Stub_Link_CISCO_2

And probably the appropriate single Summary Network LSA, as in your example.
But, in OSPF implementation I deal with, stub link representation is based on Option 1. Therefore as the result we will see the such view:

Forum_Stub_Link_LCOS_3

And as the result, the representation of point-to-point network through two Network Summary LSAs with interface addresses of both link’s endings (see example above).
So, I don’t know if the such representation has certain advantages. Probably it is simpler from development point of view. At least, some advantages is described in RFC2328’s footnote 15 (page 181).
It is interesting in this implementation also, that usage of aggregation’s command decreases Summary Network LSA to single. In this connection, I would like to ask. How does CISCO obtain a prefix in this stub link of Router LSA without aggregation?
And another please, probably not correspond to this topic, but sure to OSPF. :slight_smile:
What could be a reason, when a static route, which was redistributed in OSPF on ASBR and is presented in OSPF databases of ABR and another routers in backbone area as External LSA, doesn’t appear however in OSPF’s rib tables and accordingly in the routing tables of routers?
Tnank you in advance for your answer.
Best Regards!
Jurij