If every router in an enterprise environment was in a single OSPF area, at some point you’re going to encounter scalability issues due to any changes in the environment causing an SPF recalculation in all routers in that single area.
LSAs and their use within areas provide a mechanism for maximizing performance in OSPF by logically segmenting groups of contiguous links so that every router in the entire autonomous system does not have to have exact copies of the Link State Database (LSDB) and to reduce the amount of LSA flooding. SPF calculations are also isolated to each individual area rather than the entire environment. Different LSAs are used in different situations, and are treated differently depending on the type of OSPF area involved.
The following table represents the different LSA types, and was taken from the CCIE R&S OCG.
TYPE | NAME | DESCRIPTION |
1 | Router | One per router containing its RID and all interface IP addresses; also represents stub networks. |
2 | Network | One per transit network. Created by the DR and represents the subnet and router interfaces connected in the subnet. |
3 | Network Summary | Created by Area Border Routers (ABRs) to represent one area’s type 1 and 2 LSAs when being advertised into another area. This also defines the links (subnets) in the origin area, and cost, but no topology data. |
4 | ASBR Summary | Similar to a type 3 LSA, but it advertises a host route to reach an Autonomous System Boundary Router (ASBR) |
5 | AS External | Created by ASBRs for external routes injected into OSPF |
6 | Group Membership | Used for Multicast Open Shortest Path First (MOSPF). This is an extension to OSPF that allows multicast routing, allowing routers to share information about group memberships. This is not supported by Cisco. |
7 | NSSA External | Created by ASBRs inside of a NSSA area instead of a type 5 LSA. |
8 | External Attributes | Not implemented in Cisco routers. |
9-11 | Opaque | Used as generic LSAs to allow for easy future extension of OSPF; as an example, type 10 has been adapted for MPLS traffic engineering. |
The diagram below depicts a simple point-to-point network with all interfaces within the same area.
In this situation, there will only be Type 1 LSAs exchanged between routers. The LSA will contain the RID of the advertising router, connected links (subnets), and the RIDs of any other routers it has seen. Below is Wireshark output taken from a different network than the one diagrammed above. The link types seen here are:
- PTP – Point-to-point connection
- Stub – a subnet on which a router has not formed any neighbor relationships
- *QUESTION* The CCIE R&S OCG defines a stub network this way, but Wireshark packet capture lists connected subnets that HAVE formed neighbor relationships as stubs… what gives? The entries that contain the RIDs of the other routers are listed as PTP and the loopback of the advertising router is listed as a Stub
- *ANSWER* SPF treats these two “stub” entries as separate data structures from the PTP entries that actually specify the connected neighboring router. The more important of the two entries is the PTP entry. I don’t know exactly what that means, but I’ll push the “I Believe” button for now.
- *QUESTION* The CCIE R&S OCG defines a stub network this way, but Wireshark packet capture lists connected subnets that HAVE formed neighbor relationships as stubs… what gives? The entries that contain the RIDs of the other routers are listed as PTP and the loopback of the advertising router is listed as a Stub
When we talk about a multi-access environment, a DR is elected and here is where we can expect to see a Type 2 LSA – a Network LSA.
This type of LSA is generated by the DR and describes the subnet as well as the RIDs of the DR’s connected neighbors. The Link State ID will be the interface IP address of the DR within that subnet. It may seem odd that it lists itself as an attached router. This is because this LSA is treated as a pseudonode – not an actual physical device, but a logical node on the SPF mathematical model. So think of it as a separate entity from the actual physical router that is the acting DR.
You will find Type 1 and 2 LSAs inside of a single area. These are the most computation-intensive LSA types and they do not traverse areas. When you bring in multiple areas, this is where you encounter a Type 3 – a Network Summary LSA. Since R2 now has interfaces in two areas – area 0 and 4, it is now an Area Border Router (ABR).
This type of LSA is created by ABRs to represent subnets that the ABR can reach. Notice that it not only contains its directly connected subnets in area 4, but also the route it learned from R4. The nice thing about this is that a router, for example R3, doesn’t have to run the SPF algorithm for these routes. All it does is add its cost to reach the ABR, to the metric value gleaned from the LSA from the ABR. So in this case, the cost for R3 to reach 192.168.4.0 would be 3 (1 for the cost of R3’s fa0/0 interface, plus 2 for the metric advertised in the Type 3 LSA).
If you haven’t picked up on it already, an interesting note is that this is distance vector behavior because R3 in this example depends on R2 to tell it the metrics to reach routes in area 4 instead of R3 determining the cost on its own. So OSPF is a link state routing protocol, but when it comes to inter-area operations it uses a distance vector algorithm. Pretty cool. Something I found out from the TCP/IP Routing Vol I book is that this is the reason why there is a backbone area and that all areas must be connected to it. This essentially creates a hub-and-spoke topology and prevents the route-loops that distance vector protocols are so vulnerable to.
Continue to Part II.
Hi fellas,
ReplyDeleteThank you so much for this wonderful article really!
If someone want to read more about that LSAS I think this is the right place for you!
Way overdue but thank you! I obviously haven't edited the blog in a long while, but wanted to make sure to respond to your kind comment.
ReplyDelete