OK, not really.
But this is where I am going to look at the six OSPFv2 LSA’s that we care about for the CCIE R&S lab. In detail. Hence the title.
First up; Type 1.
I’m not going to spend any time discussing how OSPF operates in this post. This is going to purely be a description of the LSA types as seen in a Cisco IOS OSPF database. You may pick up a bit of how the protocol operates from this description, but that will only be a side effect of explaining the fields as displayed.
For the purpose of this post I’m going to be using OSPF as defined in RFC 2328, which is the latest version of OSPF Version 2 in existence. There have been many iteration of OSPFv2 over the years, which in my curiosity I decided to track down.
http://www.ietf.org/rfc/rfc2328.txt April 1998
http://www.ietf.org/rfc/rfc2178.txt July 1997
http://www.ietf.org/rfc/rfc1583.txt March 1994
http://www.ietf.org/rfc/rfc1247.txt July 1991
http://www.ietf.org/rfc/rfc1131.txt October 1989
You’ll notice the very first iteration shows only the following message:
RFC-1131 "The OSPF Specification"
is available only in PostScript form in the file
RFC1131.PS
To obtain this file via the NIC's automatic mail server SERVICE, use
the Subject line: SEND RFC:RFCnnnn.PS (where nnnn is the number of
the RFC you wish to obtain).
If anyone knows if this is service is still active, and what the email address you send to is then please let me know. Otherwise, you can still find the PS version of this RFC here.But I digress. Back to the LSA’s!
First up is the good ole Type 1 LSA. This is called a “Router” LSA, and it’s used to describe the routers themselves and the links that it is connected to. A router will originate a Type 1 LSA for every area that is belongs to. Router LSA’s are described in detail in section 12.4.1 of RFC 2328.
Here’s how Cisco IOS displays them:
Routing Bit Set on this LSA
LS age: 256
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 8000000A
Checksum: 0x331A
Length: 60
Area Border Router
AS Boundary Router
Number of Links: 3
Link connected to: a Virtual Link
(Link ID) Neighboring Router ID: 3.3.3.3
(Link Data) Router Interface address: 10.0.23.2
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.0.12.2
(Link Data) Router Interface address: 10.0.12.2
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 2.2.2.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 1
Now for the tedious part… A line by line description!
Routing Bit Set on this LSA
This isn’t actually part of the LSA. This is something that is used by IOS internally in handling the LSA. The short of it is that it means there is a candidate route for installation in the RIB described in this LSA.
LS age: 256Our next line is the age of the LSA in seconds.
Options: (No TOS-capability, DC)The options field is used to specify other capabilities supported by the OSPF domain described in the LSA.
LS Type: Router LinksThis simply says this is LSA describes router links, or put another way that it is a Type 1 (Router) LSA.
Link State ID: 2.2.2.2The LSID specifies what this LSA describes. In this case this is a Router LSA, so the LSID identifies the RID the LSA is describing.
Advertising Router: 2.2.2.2The RID of the router that originated this LSA. With a Type 1 this should always be the same as the LSID.
LS Seq Number: 8000000AThis is the sequence number of the LSA.
Checksum: 0x4490A little error checking never hurt anyone did it?
Length: 48The length, in bytes, of the LSA, including the header.
Area Border RouterThis is something that you won’t see in every Type 1 LSA. There are a number of bits in the router LSA that describe special attributes of the router being described. These bits, the V, E, and B bits, are used to specify if the advertising router is a Virtual-Link endpoint, and ASBR or an ABR respectively. Depending on the topology you may see nothing, or any combination of the above entries and the following:
AS Boundary Router
Virtual Link EndpointBefore I move off of this field completely, I want us to make a mental note that we are only seeing the E and B bits set on our example LSA. The V bit is not set.
The next sections describe the links that this router is attached to.
Link connected to: a Virtual LinkThe first link that we see is clearly identified as a virtual link. The following two lines identify the RID of the other end of the virtual link and the IP address of the interface that the virtual link is established on (or the source address if you will). The line regarding the number of TOS metrics is now unused and a legacy component of the LSA; in any modern OSPF implementation this should be a 0. The last field of the TOS 0 metric is simply the OSPF cost associated with this link.
(Link ID) Neighboring Router ID: 3.3.3.3
(Link Data) Router Interface address: 10.0.23.2
Number of TOS metrics: 0
TOS 0 Metrics: 64
Before we move to the next link, I want to quickly circle back to the V, E and B bits, and the Link that we just looked at. There’s a discrepancy here, one that I think warrants an explanation.
How can this router be attached to a virtual link, but not be a “Virtual Link Endpoint”?
Quite easy actually. You see, the LSA that we’re looking at is the router LSA that 2.2.2.2 is advertising into area 0. The virtual link is actually inside of area 23. Or said another way, 2.2.2.2 is not a virtual link endpoint with an interface that belongs to area 0 (the interface belongs to area 23). So why do we see the virtual link in this LSA at all? Well that’s because a virtual link is considered to be part of area 0, and this is an area 0 LSA of course!
That’s a wicked bit of logic, but if you’re familiar with OSPF I don’t think that’s a hard concept at all.
Our example LSA contains information about two more links attached to this router:
Link connected to: a Transit NetworkThe first is obviously a transit network. This link is actually a regular Ethernet link. The LSA identifies the DR of the link (more on that in the Type 2 LSA), and the interface of the router that is attached to the link (you’ll notice that this router is the DR). Again, TOS is unused, and the metric is the OSPF cost associated with the link.
(Link ID) Designated Router address: 10.0.12.2
(Link Data) Router Interface address: 10.0.12.2
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 2.2.2.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 1
The last is a stub network. That’s exactly what it sounds like in that traffic cannot transit this link, it can only be destined for it. The next two fields identify the prefix and the prefix length of the link. The last two lines are the same as above.
In this example this stub network is actually a loopback interface that has “ip ospf network point-to-point” configured on it. By default OSPF always advertises loopbacks with a /32 mask. By making it a PTP network types OSPF will advertise the actual mask configured on the interface. If I remove that command you’ll see the link description change to the following:
Link connected to: a Stub NetworkI’ll round this post out with the only other type of link that you’ll see on a router LSA: a point-to-point link. This was taken off a frame relay point-to-point subinterface. I think by now we can all figure out what is going on here.
(Link ID) Network/subnet number: 2.2.2.2
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: another Router (point-to-point)And that’s a Type 1 LSA!
(Link ID) Neighboring Router ID: 3.3.3.3
(Link Data) Router Interface address: 10.0.36.6
Number of MTID metrics: 0
TOS 0 Metrics: 64
Next up will be a Type 2 (Network) LSA. Stay Tuned!
The complete list of OSPF LSA breakdowns:
http://blog.brokennetwork.ca/2012/10/ospf-router-lsa-type-1.html
http://blog.brokennetwork.ca/2012/10/ospf-network-lsa-type-2.html
http://blog.brokennetwork.ca/2012/10/ospf-summary-lsas-type-3-4.html
http://blog.brokennetwork.ca/2012/11/ospf-external-lsa-type-5.html
http://blog.brokennetwork.ca/2012/11/ospf-nssa-external-lsa-type-7.html
I think your not quite there on the stub network object in the type 1 lsa. You'll find that links that have adjacencies over them will have a P2P object describing them as well as a stub object. If stub object only describes links that cannot be transited this would not be the case. You ask why the duplication? The point of the stub object is to be used to generate routes for P2P links AND links that have no adjacency over them. P2P objects are used to create branches in the SPF graph tree between two nodes (you'll notice these objects do not reference subnet masks. They only reference the interface IP which is the ID of the branch). To create the graph each node must have a unique id and each branch must too. Creating the graph itself has nothing to do with routing and neither does the P2P object. Because the P2P object doesn't describe the network mask/route the stub object is used to hold the network/mask or the route. Stub networks are not created for transit network objects as these are essentially pointer records for the type 2 lsa (which holds graph and route info) and are supposed to be minimal in nature. One of the points of the type 2 lsa is to minimize the lsdb size by minimizing the size of the type 1 lsa's.
ReplyDeleteThe conclusion about the need for lsa type 2 in other words:
Deletefor every p2p link ospf creates in lsa type1, 2 objects:
one as p2p network stating next-hop router
one as stub network stating the mask address of the link
(ospf is classless thus sends info about mask)
this is not the case for lsa type 1 which defines broadcast network(ethernet). only a transit object is advertised by router , this do not contain mask, the info about mask is delegated to DR who send it in lsa type 2.