The real nuts and bolts of everyone’s IGP of choice, OSPF, are a bit complex, but strangely satisfying. After understanding how it works, we’re left wondering, “what else do we need?” Make sure to review the first part of our look at OSPF before embarking on this potentially confusing journey.
This article will cover LSA types, packet types, and area types. First, however, we’d like to dispel a common misunderstanding about dynamic routing:
People have a tendency to tinker with traffic, even when they aren’t suffering from under-provisioned bandwidth. In OSPF, you cannot really influence the way traffic is routed, aside from adjusting a path’s metric. Some routers support making changes to weights, but this isn’t usually necessary. OSPF generally takes care of assigning weights, based on the speed of the interfaces on a router. You can also use ECMP (equal cost multipath) with OSPF, if you have two links to the same place and wish to load balance in a round-robin fashion. Don’t try tinkering with OSPF parameters; more likely than not, if you think you have a problem it’s a network design issue, and fixing that will accomplish your goals.
The LSA and Packets
Pivotal to understanding the impact OSPF will have on your network is realizing there are multiple types of LSAs. Updates are sent every few seconds, which result in updates to the LSA database, and possibly the routing table. “New” LSAs will cause every single router to ditch its routing table and start over with the SPF (shortest path first) calculation.
There are five distinct packets types that can be sent as LSAs. The hello and database descriptions were covered in the first installment of this article, and they are used during the “bringing up adjacencies” stage. OSPF packet type 3 is a link-state request, and type 4 is a link-state update. Finally, type 5 is a link-state ACK. OSPF is implemented as a layer 4 protocol, so it sits directly on top of IP. Neither TCP nor UDP are used, so to implement reliability OSPF has a checksum and its own built-in ACK. To troubleshoot by sniffing traffic, we need to know that the OSPF multicast address is 188.8.131.52, and DRs use 184.108.40.206 to talk amongst themselves.
Finding the shortest path on a weighted, directed graph is computationally hard, and takes considerable time, even on today’s routers. Thankfully Edsger W. Dijkstra made this better with his SPF algorithm, but it’s still tough. This is the main reason OSPF can’t be used on the Internet, and you don’t want to squirt your full BGP Internet routing table into OSPF. Every time a network is deleted or added, an SPF recalculation happens.
Try not to be confused by another “type.” OSPF has many, so be sure to pay attention to the “type” you’re referring to. LSAs can be either an update packet, or a request packet. These are the different types of LSAs that can be sent, and these are either Type 3 or 4 OSPF packets:
- Type 1: router LSA. A router sends this to describe neighbors and its own interfaces.
- Type 2: network LSA. For broadcast networks only; this LSA is flooded by the DR and lists OSPF-speaking routers on the network.
- Type 3: network summary LSA. Sent by an ASBR to advertise networks reachable through it. A stub area router will also use this for the default route.
- Type 4: ASBR-summary LSA. Sent by ASBR, but only internally. This describes to the others how to get to the ASBR itself, and uses only internal metrics.
- Type 5: AS-external LSA. Used to describe external routes to internal areas. Can be used to advertise “this is the way to the Internet” (or some subset of).
- Type 6: Group summary. Used in multicast (MOSPF). Ignore this.
- Type 7: NSSA area import.
Notice that we have both a router and a network LSA. The reason a router LSA exists is because in the absence of a DR, there is no network LSA sent. The router LSA would include a list of all links to the other routers on a network. So OSPF can work in the absence of a DR or BDR, albeit with increased complexity due to the fact that the DR is no longer providing nice summaries.
We’ve already mentioned a few different types of OSPF areas, and brushed upon the idea of a backbone area in the last article. In actuality, there are only two types of areas: normal areas, which touch area zero; and stub areas, that hang off another area without touching area zero. A stub area does not accept external LSAs. A stub does not provide transit, i.e. it doesn’t ship packets across itself. A stub area only has one way out, which is through the area it’s connected to, which means that any internal routers in the stub area don’t need to recalculate the SPF.
Okay, NSSA was mentioned above, so this charade can’t be keep up for long. There’s actually another type of area: the Not So Stubby Area. The only difference is that a NSSA can send a type 7 LSA to export internal routes. Interestingly, this type of LSA is translated at the ABR into a type 5 (AS-external) LSA. So a NSSA gives up some specific routes to the entire OSPF domain. Think of this as being equivalent to an ASBR: it can export some AS-external routes into the backbone. Presumably it got them by running another routing protocol internally, such as RIP or BGP. The NSSA router that connects itself to the area (not area zero, this is a stub) cannot accept AS-external routes; it can only send them.
Now it’s time to truly get confused. Let’s say we have a NSSA that can’t physically be connected to area zero because of physical locality issues. It’s possible that you want the stub described above to be on area zero. Alternatively, you might have two stubs hanging off a non-backbone area, and you want them to talk without having to touch area zero, because going through the backbone would be inefficient. A virtual link can save you from this poorly designed nightmare, by creating a tunnel from one router to another. When the tunnel comes up, a virtual adjacency is formed between the two end-point routers, and they can adjust their routing tables accordingly.
OSPF is extremely versatile. I’ve even seen people use OSPF for highly available failover. A router speaking OSPF will automatically detect if the route goes away (because the host running ospfd stopped responding), and it will stop sending traffic to that host. Good for job security, but bad if it breaks at 2:00am and you’re the only person who knows OSPF. Seriously though, OSPF is extremely powerful, mostly because it’s very fast to converge and uses little bandwidth. None rival OSPF's abilities among IGPs.