In the last post, we talked about some of the basics of OSPF. We discussed how neighbors form adjacencies, the multicast addresses OSPF uses, and some of the timers that OSPF uses. Before we jump into this post I want to cover a few items that I may have left out. Namely, I want to talk about the configuration we used to get to the end state we saw at the end of the first post. Some of the configuration commands we discuss will drive other conversation. Here’s our lab topology…
The configuration for OSPF is not unlike EIGRP. However, there are some rather distinct differences. Let’s look at the configuration of router1 to get a sense for how the configuration works…
This is basically it. Again, we are using sub interfaces since the router’s I have only have two Ethernet interfaces. The OSPF configuration looks remarkably similar to that of EIGRP with a few exceptions.
First off, the ‘router ospf 1’ does not mean the same thing that it did in EIGRP. In EIGRP, the number following the ‘router eigrp’ command was the AS (Autonomous System) number. This HAD to match on any routers that you wanted to become neighbors. In OSPF, it’s actually a number symbolizing a process ID. With that being the case, it does NOT need to match on routers that you would like to become neighbors.
Secondly, you’ll notice the addition of the ‘area 0’ tacked onto the end of the network definition. This is a considerable change from EIGRP. EIGRP had a single plane that all router’s ran on. OSPF can be separated into different areas and routes distributed between them based on what type of area they are. This is a large advantage over EIGRP (in some peoples minds) since it limits the amount of advertisements. Let’s talk a little bit about areas and then dive into router roles…
Areas
OSPF works off of the concept of areas. Regardless of how many areas you intend to build, there will always be one area. That one area that MUST exist is area 0. Area 0 is also commonly referred to as the backbone area. All other areas MUST connect to area 0.
Since OSPF is a link state protocol, by default, each router wants to have all of the information available so it can make it’s own decisions about the best path. Areas break that definition slightly. Routers in one area will have full topological awareness of each and every router in the same area. However, routers in different areas don’t. To put that a different way, routers in different areas have different links state databases. This also means that any LSA flooding (for certain LSAs) occurs only within a single area.
When we talk about traffic flowing through areas, we categorize the traffic in 3 main ways. Intra-area traffic is the traffic within a single area. Inter-area traffic represents traffic shared between areas. And finally external traffic represents traffic coming in from a different routing source (AKA another IGP).
There are different ‘kinds’ of areas but this isn’t worth discussing until we get a little more information about LSAs.
Router Types
That quick discussion on areas lends itself nicely to talking about the different router types. Router types are essentially defined by the area(s) they are in.
Internal routers – A router that has all of it’s interfaces in the same area. It can be assumed that there will also be only one copy of the link state database on internal routers.
Area Border Routers (ABRs) – ABRs can be thought of as bridging routers. The ABR bridges traffic from one or more non-backbone areas to the backbone area. An ABR MUST have one interface in the backbone. This being said, ABRs have two or more link state databases.
Backbone routers – I’m not even sure why they make this distinction since it’s a rather general one. Essentially any router that has a single interface in area 0 is a backbone router. Internal routers and ABRs could both be backbone routers.
Autonomous System Boundary Routers (ASBRs) – ASBRs are routers that redistribute information from another routing protocol into OSPF. An ASBR can live anywhere in the OSPF topology except in a stub area (we’ll see why shortly).
Network Types and the DR/BDR
While we are on the topic of router types, we should also talk about what OSPF sees as the different network ‘types’.
Depending on the type of network, OSPF will handle the configuration slightly differently. The main difference is whether or not a router is elected as the designated router (DR) and backup designated router (BDR).
Before we talk about the DR and BDR I should also point out that each network type can further be classified into either a transit or stub network. Transit networks have 2 or more routers attached to them whereas stub network only have a single router attached. Loopback interfaces are a great example of stub networks. DO NOT CONFUSE THE NETWORK TYPE WITH THE AREA TYPE! TWO DIFFERENT THINGS!
Point to point and point to multipoint networks do NOT have the concept of a DR and a BDR where Broadcast and NBMA do. The concept of the designated router is in place to solve a particular problem that multi-access networks bring with them. The big hitter is LSA flooding. Think about a bunch of routers on the same Ethernet segment flooding all of their LSAs to each other who it turn flood the LSAs to all of the other routers. That’s a lot of unnecessary flooding to share the same information. The second issue DRs and BDRs solve is that of adjacencies. If every router had an adjacency with every other router that would equate to a lot of adjacencies which would then equate to unnecessary flooding of router LSAs.
To solve this problem, multi-access networks elect a DR that is responsible for representing the the entire multi-access network (and all connected routers) as well as to mange the flood process within the multi-access network. Each router on the network will form an adjacency with both the elected DR on a segment as well as the elected BDR. The election of the DR and BDR is based on configured priority ,and when not configured, is based on the router’s RID. Taking a look at a subsection of our lab topology, we can see this in action…
While in reality, each of my segments is a multi-access network (Ethernet when not manually configured to be point to point) and will elect a DR and a BDR, this section is truly a multi-access network. Here, router1, router2, and switch1 share a common subnet. If we look at the neighbors from the perspective of each device we can get some insight on the DR and BDR roles…
In this case, we can see that they’ve elected router router2 as the DR and switch1 as the BDR. But why wasn’t switch1 picked as the DR since it had a higher RID? Like the RID reconfiguration example we saw in the first post, it’s a matter of timing. And apparently, it’s very, very, very picky about the timing. I was initially confused on the matter so I posted a question about it at network-forum. Deadcow and mellowd took a look at it for me and eventually we determined that it was spanning-tree causing the problem. To be honest, I’m still not 100% sure why, but since I’m using an SVI that relies on vlans to be ‘up’ for it to be ‘up’ I must have introduced some delay into the election process which caused 9.9.9.9 to not be elected as the DR. After enabling ‘spanning-tree portfast trunk’ on the switch interfaces I got the results I was looking for…
OSPF routers on a mutli-access subnet ONLY form adjacencies with the DR and the BDR. Adding in a 4th device temporarily we can see this in action…
In this case, we can see that adjacencies formed only with the DR (Switch1) and BDR (router3) on router1…
All other routers will show as being in a DROTHER state. If we look at some transactional data (LSU traffic) we can see the DR and BDR in action…
Notice that all router’s continue to send hellos to the ‘all OSPF routers’ multicast address of 224.0.0.5. When we get in a transactional situation dealing with LSA update we can see that the BDR (router3, 10.0.0.4) is sending it’s updates to the same address (First red box). However, when non-DR or non-BDR router’s reply, they only do so to the 224.0.0.6 address which is also known as the ‘all DR/BDR router address’. In this manner, all of the updates from the DR/BDR still get to all routers, but the responses from the non DR/BDR routers only go to the DR/BDRs.
LSAs and Link state DB
Now that we’ve discussed areas and router types, let’s talk a little bit about LSAs and the link state database. Since each router is making it’s own routing decisions, it is imperative that all of the routers in the same area have an identical link state database. This is achieved by neighboring routers telling each other about all of the other LSAs that it knows about. The confusion comes in when we start talking about LSAs. After all, taking a look at the link state database doesn’t really appear to tell us a whole heck of a lot about the prefixes we see in the routing table…
In fact, we don’t see anything at all in the link state database output that even looks like a prefix. That’s because we are ,once again, just looking at the LSA headers. Let’s talk a little bit about the different LSA types before we dive into how to actually look at them on the router.
Let’s just throw each LSA type into this table and then talk about them one at a time…
Router LSA (1) – The router LSA is generated by all routers and lists all of the router’s links, their associated cost, state, and any known OSPF members that exist on that particular interface. These LSAs are only flooded within the area which they are originated.
Network LSA (2) – The network LSA is generated by the DR of a multi-access network. The LSA contains information about the network including attached routers and is flooded only within the area in which they are originated.
Network Summary LSA (3) – This LSA type is originated by ABRs and are sent into a single area to to advertise destinations that are reachable outside of that area. This essentially tells all of the routers inside a specific area what other prefixes are available through a specific ABR. Additionally, this LSA type is used to send prefixes available within a specific area into the backbone area (0). Lastly this LSA type is used to advertise default routes that originate from another OSPF area.
ASBR Summary (4) – This LSA type is used to advertise the location of a ASBR. The destination is not actually a prefix, but rather a specific host address of an ASBR.
AS External (5) – This LSA type is advertised only by ASBRs and advertises either a default route, or a prefix that’s accessible outside of the OSPF domain.
Group Membership (6) – Used for multicast OSPF (MOSPF)
NSSA External (7) – We’ll be discussing not so stubby areas (NSSAs) coming up shortly. An NSSA external LSA is used to advertise a destination only within the NSSA area in which the destination originated.
External Attributes (8) – Proposed for carrying BGP info over OSPF. Never implemented.
Opaque (9,10,11) – Used to carry other information that may or may not be used by the actual OSPF routers.
Area types
Now that we know the different kinds of LSAs, we can talk about specific area types.
Stub areas
To put it simply, the ABR bordering a stub area and the backbone area simply advertises a 0’s route into the stub area using a type 3 (network summary) LSA. The idea here being that to access anything external to the area, you’d need to traverse the ABR . If you need to traverse the ABR, why would all of the routers in the stub area need the specific external routes to tell them to talk to the ABR? Why not just give them one default route to the ABR? The rules for stub areas are…
-ABRs advertise in a type 3 network summary LSA
-Do not advertise type 4 LSAs into the stub area
-Do not advertise type 5 LSAs into the stub area
-Stub router’s set a specific ‘E-Bit’ inside their hellos to 0. OSPF stub router’s will ONLY peer with other routers that have this bit set.
-Since we aren’t advertising type 5 LSAs (AS External) ASBRs can NOT exist in a stub area.
Totally Stubby areas
Taking the stub are to the next level totally stubby areas also block type 3 (Network Summary) LSAs. After all, if you are using a 0s route through an ABR to get out of the area anyway, why do you need the network summaries from other areas?
Not so Stubby Areas (NSSAs)
NSSAs allow a stub areas to have an ASBR inside of them. This would allow a stub area to learn routes from an external source and then advertise them into the OSPF domain. The NSSA LSA has something called the “P bit’ inside of it. The P bit determines whether or not the actual type 7 LSA gets distributed out of the stub area. If set to 0 the ABR will not advertise it out into OSPF. If set to 1 the ABR will translate the LSA to a type 5 and flood throughout the OSPF domain. This option allows you to learn external prefixes only within a given area.
This chart sums up the area type and LSAs that are allowed…
OSPF metric and path determination
The last thing I want to talk about in this post is the OSPF metric and how OSPF routers find the shortest path. OSPF is based on Dijkstra’s shortest path algorithm. While I’m not going to dive into the algorithm itself, we can sum it up by saying the lowest cost to a prefix is the winning path.
Cisco has a default interface cost for specific interface types. Basically, unless you set it to something else manually (common) these are the only values that I think you need to know…
Fast Ethernet (Faster than 100 meg ) – 1
T1 – 64
The rest of the values in the book are for interface speeds I haven’t dealt with in years (and even then they were old). So in our topology, we have all of them set to a cost of 1. The cost to a particular destination is the cost of all of the outgoing interfaces on the way to the destination. For instance if we look at our topology…
And then look at the routing table on router1…
We can see that most of the routers are learned by OSPF (’O’). We can also determine it’s OSPF because of the admin distance of the routes (110). The number next to the 110 is what we are interested in here. That number represents the routes ‘metric’. So doing some stare and compare here we can pretty easily verify what we are seeing…
To get to 10.0.0.28 /30 we have to go through 4 interfaces. Router1’s interface, one of switch1’s interface, then either router3 or router4, and then finally router5. This is also a good example of how OSPF can insert equal cost paths into the FIB.
I’m not going to beat the dead horse here, but I will look at the path to 10.1.1.1/32 quickly since that’s showing 5. The only matter of interest here is that going internally from a interface to a loopback apparently costs as a ‘hop’ hence the metric is 5.
So that’s the default metric. The metric can be change manually per interface using the interface subcommand ‘ip ospf cost <cost>; command. For instance, if we change the cost on router5’s interface facing router6 to 70…
We can see that reflected in router1’s FIB…
That’s really all there is to it.
I’ve officially updated my OSPF post outline to include two other posts where I’ll go through some area and LSA examples as well as spend some time getting comfortable with the OSPF RIB data.