|
OSPF Routing Protocol: Popular and Robust
Traffic Cop For Your Routing Domain
OSPF is the most widely used IGP. When we discuss IGPs, we’re talking about one routing domain, or Autonomous System (AS). Imagine a medium-sized company with multiple buildings and departments, all connected together and sharing two redundant Internet links. All of the buildings on-site are part of the same AS. But with OSPF we also have the concept of an Area, which allows further segmentation, perhaps by department in each building. To understand the design needs for areas in OSPF, let’s start by discussing how OSPF works. There’s some terminology you may not have encountered before, including:
First, when a router running OSPF comes up it will send hello packets to discover its neighbors and elect a designated router. The hello packet includes link-state information, as well as a list of neighbors. Providing information about your neighbor to that neighbor serves as an ACK, and proves that communication is bi-directional. OSPF is smart about the layer 2 topology: if you’re on a point-to-point link, it knows that this is enough, and the link is considered “up.” If you’re on a broadcast link, the router must wait for an election before deciding if the link is operational.
Ballot-Stuffing Wins ElectionsThe election ballot can be stuffed, with a Priority ID, so that you can ensure that your beefiest router is the DR. Otherwise, the largest IP address wins. The key idea with a DR and backup DR (BDR) is that they are the ones to generate LSAs, and they must do database exchanges with other routers in the subnet. So, non-designated routers form adjacencies with the DR. The whole DR/BDR design is used to keep the protocol scalable. The only way to ensure that all routers have the same information is to make them synchronize their databases. If you have 21 routers, and want to bring another one up, then you’d have to form 21 new adjacencies. If you centralize the database, with a backup (just in case), then adding more becomes an easy to manage linear problem. The database exchange is part of bringing up adjacencies after the hello packets are exchanged, and it’s very important. If the databases are out of sync, we could risk routing loops, blackholes and other perils. The third part of bringing up an adjacency is Reliable Flooding, or LSA exchange. The details of an LSA, as well as a more advanced discussion of areas will be the topic of the next Networking 101. For now, just know that area zero is special, and if you have multiple areas, they must all touch area zero. This is also called the Backbone Area. There are different types of areas in OSPF, and it can get really crazy when you throw in Virtual Links to allow two areas to speak without hitting area zero. Alas, there also are different types of routers in OSPF. ABR DR, BDR ASBR The concept of redistribution finally rears its head: let’s say we have a router, an internal-only router (not a BR), and we wish to connect it to a new network that we don’t control. After this connection is made, we have a few options. We can fire up a non-IGP routing protocol, like BGP, to exchange routes. Alternatively, we could decide that a summary route is good enough, and hard-code a static route to the new network in this router. Anything directly using this router for this destination would be able to get to the new network, but OSPF doesn’t know about it. To make that happen, we ‘redistribute” the miscellaneous information into OSPF. We wouldn’t want to feed 200K+ routes from BGP into OSPF, but if we went the static route, we’d definitely want to propagate that information so everyone in our AS could get to the new place. As soon as we tell our internal router that it should redistribute static routes into OSPF, it becomes an ASBR, and the entire network can reach the new network. Come back next week for the areas and LSA discussion, which will consolidate your understanding of the whole OSPF concept, and enable you to understand good OSPF design.
In a Nutshell
Article courtesy of Enterprise Networking Planet, originally published June 1, 2006 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.
|