cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
19953
Views
86
Helpful
14
Replies

OSPF LSA Type 1 - Stub Network

dkhouri
Level 1
Level 1

Hi,

I can't seem to find meaningful information regarding the Stub Network state in a Type 1 LSA.

E.g

   Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 1.1.1.1
     (Link Data) Router Interface address: 10.45.13.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

   Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.45.13.0
     (Link Data) Network Mask: 255.255.255.252
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

Why does it exist? If it's already seen as a point-to-point link, why is it refeering it also as a Stub Network? What's so significant about it?
Are there any other terms that may appear instead of "Stub Network"


Thanks

DK

1 Accepted Solution

Accepted Solutions

Hello Garth,

Thank you for asking. Regarding the stub/transit network definition, for OSPF, only a multiaccess network type with at least two routers is considered a transit network. A point-to-point connection between two routers, even if being naturally a transit link, is not described as a transit network in the LSA1. This is given by the LSA1 link types and their associated IDs:

Type   Description
__________________________________________________
1      Point-to-point connection to another router
2      Connection to a transit network
3      Connection to a stub network
4      Virtual link

Type   Link ID
______________________________________
1      Neighboring router's Router ID
2      IP address of Designated Router
3      IP network/subnet number
4      Neighboring router's Router ID

Read these two tables from RFC 2328 closely: if two routers are interconnected by a point-to-point link, even if that link is naturally a transit link, it will be modelled in LSA1 using Link Type 1 (point-to-point link) referencing the neighbor's RID, and another entry describing the actual IP subnet located on this point-to-point link as a stub network. The Link Type 2 - a transit network - references the IP address of the Designated Router but such a router is elected only on multiaccess network types. Thus, even a transit link of a point-to-point OSPF type will not be modelled as transit network because there is no DR (i.e. no LSA2 for such a network) to point towards to. In OSPF terms, a transit network is only a multiaccess network having at least two routers.

I expected that the link 155.1.146.0 would be seen as a transit network on R5 because it is transit for 155.1.67.0/24 but it actually came up as a stub network.

That is absolutely correct. As you have indicated, the link between R1 and R6 is running as OSPF point-to-point type network. Therefore, even though this interconnection has all properties of a transit network (it really is a transit network in real life), the OSPF does not describe it as a single transit-type link entry in LSA1 but rather as a double record:

  1. A point-to-point link entry from R1 to R6 (and vice versa) that describes the interconnection between R1 and R6
  2. A stub network entry that describes the IP network located on the interconnection between R1 and R6

Note that you cannot use the transit type network entry here - it would necessitate referencing this network's DR which is not elected on point-to-point networks.

I hope this helps a bit but please feel welcome to ask further.

Best regards,
Peter

View solution in original post

14 Replies 14

Peter Paluch
Cisco Employee
Cisco Employee

Hello Daniel,

First of all, the OSPF differentiates between a transit network and a stub network. A stub network is a network that contains only a single router - its gateway to the rest of the topology. Typically, all Ethernet interfaces where only end stations are connected are considered as stub networks by OSPF. A transit network is a network that contains at least two routers, and obviously, this network can be used for a transit traffic flowing through that network, hence its name. Interconnections between routers are often, but not always, considered by the OSPF as transit networks.

This distinction is made because of memory requirements of the OSPF implementation. The OSPF maintains a topological graph of the network, and one of the common storage formats of a graph in a computer memory is an adjacency matrix. This matrix describes all necessary objects in the topology with the rows describing the "from object" and columns describing the "to object". For example, if routers i and j are connected by a direct link then the element M(i,j) of the matrix M will hold the cost of the link from router i to router j, and the element M(j,i) will hold the cost of the link from router j to router i (this allows for asymmetric link costs in opposite directions).

The question is now, what should be described by this matrix - which objects should be present in it. Obviously, each router has to be present in this matrix because a router not contained in this matrix is essentially unreachable with all its networks and possible destinations behind it. With the networks, it is a slightly different story. We could put all networks, both transit and stub, into the matrix and it would work well but if we have M routers and N networks (both stub and transit), the matrix would blow up to size of (M+N) rows x (M+N) columns. The key observation here is that the stub networks are actually uninteresting for shortest path calculations between routers because they do not provide any further path to any other part of the network. The stub network is the edge - there is nothing behind it, only the network itself. It can be considered an attribute of the router to which it is connected but it is not interesting as a transit topology object. This idea allows us to save memory by not including the stub networks into the "from" rows of the adjacency matrix and thus reducing its size. If out of N networks, only N' (N' < N) networks are transit networks, the adjacency matrix could be reduced to the size of (M+N') rows x (M+N) columns.

This is why the OSPF actually has the stub/transit network distinction in the first place.

Now, point-to-point links are modelled in a somewhat peculiar way by the OSPF: the link itself is described by the Point-to-Point type entry in the LSA1 and references the neighbor's Router ID. However, note that this entry does not contain any addressing information about the network on the link. Thus, the information about the subnet on the point-to-point link has to be described in an extra record, and this is where the stub network entry comes in. So, a point-to-point link is described by two entries in the LSA1 - one describing the physical interconnection (the direct point-to-point link) referencing Router IDs, the stub network entry indicated by both routers declares the presence of the relevant IP subnet on that link.

Sorry for this article being so large but actually, this is an involved topic and I couldn't press it into smaller space...

You are welcome to ask further! These are not intuitive issues.

Best regards,

Peter

Peter,

Thanks for the explanation there, I'm a bit curious around the whole stub/transit network definition. See I have read in Routing TCP/IP Volume 1, Second Edition the definition of a transit networks have two or more attached routers where as stub networks have only a single router attached.. where in RFC 2328 under section 2.1 (I've only just skimmed across the RFC looking for this info so it might be clarified further somewhere, reading the RFC is on my to do list for sure!) it states-

"The Autonomous System's link-state database describes a directed graph.  The vertices of the graph consist of routers and networks.  A graph edge connects two routers when they are attached via a physical point-to point network.  An edge connecting a router to a network indicates that the router has an interface on the network. Networks can be either transit or stub networks. Transit networks are those capable of carrying data traffic that is neither locally originated nor locally destined. A transit network is represented by a graph vertex having both incoming and outgoing edges. A stub network's vertex has only incoming edges."

Now, with your explanation below, it seems to match the explanation in the RFC but in any case, I labbed up the following topology and ended up with some unexpected results.

My topology is like this

.5 ----155.1.0.0/24---- .1 .1----155.1.146.0/24-----.6 .5---155.1.67.0/24----.7

The Links between R5, R1 and R6 are OSPF Point to Point Network Type

The Links between R6 and SW1 are OSPF Broadcast Network Type.

Router ID's are 150.1.Y.Y with Y being the router number

I expected that the link 155.1.146.0 would be seen as a transit network on R5 because it is transit for 155.1.67.0/24 but it actually came up as a stub network.

Rack1R5#show ip ospf database router 150.1.1.1

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

                Router Link States (Area 0)

  LS age: 1481
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 150.1.1.1
  Advertising Router: 150.1.1.1
  LS Seq Number: 80000008
  Checksum: 0x511A
  Length: 72
  Number of Links: 4

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 150.1.6.6
     (Link Data) Router Interface address: 155.1.146.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 155.1.146.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 150.1.5.5
     (Link Data) Router Interface address: 155.1.0.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 155.1.0.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

If I change the network type between R1 and R6 to broadcast, then it appears as a transit network not a stub network..

Rack1R5#show ip ospf database router 150.1.1.1

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

                Router Link States (Area 0)

  LS age: 35
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 150.1.1.1
  Advertising Router: 150.1.1.1
  LS Seq Number: 8000000A
  Checksum: 0xB75F
  Length: 60
  Number of Links: 3

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 155.1.146.6
     (Link Data) Router Interface address: 155.1.146.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 150.1.5.5
     (Link Data) Router Interface address: 155.1.0.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 155.1.0.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

I guess the actual definition of what is a transit network and what is a stub network is confusing me a bit. I'll probably understand it better once I read the RFC but those things can be a bit tricky to read also :-/

Cheers

Garth

Hello Garth,

Thank you for asking. Regarding the stub/transit network definition, for OSPF, only a multiaccess network type with at least two routers is considered a transit network. A point-to-point connection between two routers, even if being naturally a transit link, is not described as a transit network in the LSA1. This is given by the LSA1 link types and their associated IDs:

Type   Description
__________________________________________________
1      Point-to-point connection to another router
2      Connection to a transit network
3      Connection to a stub network
4      Virtual link

Type   Link ID
______________________________________
1      Neighboring router's Router ID
2      IP address of Designated Router
3      IP network/subnet number
4      Neighboring router's Router ID

Read these two tables from RFC 2328 closely: if two routers are interconnected by a point-to-point link, even if that link is naturally a transit link, it will be modelled in LSA1 using Link Type 1 (point-to-point link) referencing the neighbor's RID, and another entry describing the actual IP subnet located on this point-to-point link as a stub network. The Link Type 2 - a transit network - references the IP address of the Designated Router but such a router is elected only on multiaccess network types. Thus, even a transit link of a point-to-point OSPF type will not be modelled as transit network because there is no DR (i.e. no LSA2 for such a network) to point towards to. In OSPF terms, a transit network is only a multiaccess network having at least two routers.

I expected that the link 155.1.146.0 would be seen as a transit network on R5 because it is transit for 155.1.67.0/24 but it actually came up as a stub network.

That is absolutely correct. As you have indicated, the link between R1 and R6 is running as OSPF point-to-point type network. Therefore, even though this interconnection has all properties of a transit network (it really is a transit network in real life), the OSPF does not describe it as a single transit-type link entry in LSA1 but rather as a double record:

  1. A point-to-point link entry from R1 to R6 (and vice versa) that describes the interconnection between R1 and R6
  2. A stub network entry that describes the IP network located on the interconnection between R1 and R6

Note that you cannot use the transit type network entry here - it would necessitate referencing this network's DR which is not elected on point-to-point networks.

I hope this helps a bit but please feel welcome to ask further.

Best regards,
Peter

Peter,

seriously, putting together this answer with the previous one we have, by far, the best explanation available on the internet about this topic.

A thousand thanks.

Hello,

I am immensely honored - honestly.

Best regards,
Peter

Peter,

Thanks a lot for excellent explanation !!! it has helped me to understand the OSPF LSA,

please let me know if you have such more explanation on other topic, would be glad to read those 

Cheers

PD

Hi,

I am glad to know that this thread was helpful!

Regarding other topics - I do not write any personal blogs (I am probably too lazy for that) but I try to respond on these forums. There might be a few posts you would be interested in but I am afraid you would need to look for them the same way you found this one - probably by looking for keywords and browsing through the answers.

Best regards,
Peter

Hi Peter,

thanks for this explanation. It was most helpful. 


A further question though. I labbed this up with two routers on a multi-access segment. R1 has the interface to the segment shut down.

When I bring the R1 interface up in the segment, I see hellos of both routers and that R2 has seen R1 hellos (Active Neighbor Router ID of R1 shown).  LSUs are exchanged as unicast between the routers. During this exchange, the segment they see each other on is still being advertised as Stub. After a couple of unicast LSU, the DR (R2) will send a multicast LSU where the segment is now Transit as expected. 

Why are the unicast LSUs still showing stub? Is this possibly related to Adjacency states and DR not having been selected internally yet? I mean the router clearly see each other since they are exchanging LSUs..

Best regards,

Tim

Hello Tim,

Thank you for your kind words.

Why are the unicast LSUs still showing stub? Is this possibly related to Adjacency states and DR not having been selected internally yet?

It is indeed related to adjacency states - but not to "DR not having been selected internally yet". The DR must have been selected already, otherwise the two routers would not be attempting to become fully adjacent. Rember, only DR/BDR and other routers become fully adjacent on multi-access networks.

In order for two routers to advertise their adjacency as a link in their LSAs, they must first be fully adjacent. In addition, an LSA-2 is generated only for a transit network where at least two routers are already fully adjacent. However, your two routers are just creating a full adjacency which won't be up until they have both finished synchronizing their topology databases and land into the FULL state, and there are no other routers on the link in the FULL state so there is no LSA-2 present at this point. Therefore, during the database synchronization, when these routers are not in the FULL state yet, there is no link to be indicated in any of these routers' LSA, so both of them simply report the common link as a stub network. Only after these two routers become fully adjacent, they can indicate a link in their LSA-1, and this link can now point to the LSA-2 which can now be originated by the DR.

Would this make any sense? Please feel welcome to ask further!

Best regards,
Peter

Hi Peter,

yes, this makes sense.Thanks for the explanation

Plenty of questions still ;) But not related to this topic ecactly ! 

Best regards,

Tim

I just have to second this! Amazing explanation. Just spent about an hour banging my head against the wall trying to figure this out :-)

Peter, good gracious heavens above!! approximately 10 years later and your viewpoint in this particular corner of the internet is still a GEM! perhaps because it is often overlooked or ignored that the knowledge it brings about is so scarce one had to sift through tons of horribly repetitive pieces of information one already knows before the finder's eyes are finally set on the prize! 

in any case,  i cannot but thank you enough, good Sir! i wish you well in life! 

Superb

jimmysands73_2
Level 5
Level 5

In addition to the outstanding post others offered, here is a very detailed video about LSAs

https://learningnetwork.cisco.com/docs/DOC-7224

Review Cisco Networking for a $25 gift card