Thursday, October 25, 2012

OSPF Router LSA: Type 1

Ahh yes, this is the part of the CCIE studying where I revisit topics that I’ve previously studied before but have since started to forget some of the finer details of. This is where my inability to pass the stupid lab combined with the finite amount of memory capacity I have becomes a pain in the ass and forces me to redo things. This is where I my blogging takes on a morose tone and I start to sound like a whiny little bitch.

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.

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:

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: 256

Our 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 Links

This 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.2

The 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.2

The RID of the router that originated this LSA. With a Type 1 this should always be the same as the LSID.

LS Seq Number: 8000000A

This is the sequence number of the LSA.

Checksum: 0x4490

A little error checking never hurt anyone did it?

Length: 48

The length, in bytes, of the LSA, including the header.

Area Border Router AS Boundary Router

This 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:

Virtual Link Endpoint

Before 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 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.

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:

The 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.

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:

I’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.

2 comments:

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.

The conclusion about the need for lsa type 2 in other words:for every p2p link ospf creates in lsa type1, 2 objects:one as p2p network stating next-hop routerone 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.