April 25, 2019

Understanding OSPF Routing (part 2) - page 2

Smart Tinkering and Unnecessary Tinkering

  • October 29, 2008
  • By Charlie Schluting
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.

In a Nutshell
  • A well-designed network doesn't need to be "adjusted" beyond the capabilities of your routing protocol.
  • OSPF supports some crazy configurations, including the NSSA. Try to stay away from stubs, it's possible even on large networks.
  • On types: there are OSPF packet types, LSA types, and router types. Oh what fun it is.

When he's not writing for Enterprise Networking Planet or riding his motorcycle, Charlie Schluting is the Associate Director of Computing Infrastructure at Portland State University. Charlie also operates OmniTraining.net, and recently finished Network Ninja, a must-read for every network engineer.

Article courtesy of Enterprise Networking Planet, originally published June 8, 2006

Most Popular LinuxPlanet Stories