684 Words. Plan about 3 minute(s) to read this.
On to the last portion of the chapter, covering specifics of OSPF configuration. I’m going to hit the highlights of the book here, touching on topics not previously mentioned that seem interesting or significant. Well, it’s ALL interesting and significant, I suppose. But I’m trying to summarize the key points of the book. Not rewrite it in its entirety.
- “ip ospf dead-interval minimal hello-multiplier 4” would configure a dead interval of 1 second, the resulting hello interval being one quarter of a second.
- OSPF process ID’s do not have to be the same for neighbor adjacencies to form.
- A router OSPF priority is configured from 0 – 255 on an interface. The higher the priority, the more likely the router will become the DR.
- In the router ospf paragraph, you configure an area to be a stub with an “area x stub” statement. For that area to become totally stubby, add the “no-summary” keyword at the end.
- “clear ipospf process” will restart OSPF on that router, causing all neighbors to fail and restart.
- Some key points about link cost:
- You can manually set the cost on a neighbor assuming you manually created the neighbor first of all (i.e., you had to create the neighbor because the OSPF network type you’re on doesn’t support hellos).
- You can set the cost per interface using the “ip ospf cost” interface command.
- Cost calculations default to the reference bandwidth of 100,000,000 divided by interface bandwidth in bps. Implicitly, this doesn’t scale beyond fast-ethernet, as 10Gbps and 1Gbps would calculate to be an equal cost as fast.
- You can change your reference bandwidth with the “auto-cost reference-bandwidth <x Mbps>”. Be sure to do this on all OSPF routers in your network for consistent OSPF calculations.
- With 12.3(11)T, you don’t have to use the network statement in the OSPF paragraph to enable OSPF on a particular interface. Rather, you can use “ip ospf x area x” to do so on a specific interface. Which I like, since so much of how OSPF operates is interface-specific.
- “Filtering routes” within OSPF is a bit of a misnomer, as OSPF doesn’t exchange routes with neighbors. Rather, it exchanges link-states. To wit, there are 3 different approaches to route filtering with OSPF.
- You can do a “distribute-list in” to filter routes that SPF has calculated and are heading for the routing table. You aren’t filtering inbound LSAs, but rather limiting what you’ll allow OSPF to populate the routing table with from the LSDB.
- You can use an ABR to filter a prefix list of networks that will not be injected into (or out of, as you’ve configured) an area via type 3 LSA. “ip prefix-list list-name” coupled with “area x filter-list prefix list-name in|out”
- You can summarize contiguous networks with an “area range” statement in the OSPF paragraph that tells the ABR to inject a larger, single summary type 3 LSA into the area, instead of injecting all the smaller networks that fall into the summarized area. And if you wanted, you could tack on a “not-advertise” keyword at the end, which caused the summarized LSA to not be advertised at all.
- A virtual link can be used in a situation where an area can’t directly connect to area 0, or where you’ve got 2 areas with the same number (partitioned areas) that need to be connected for proper OSPF functioning.
- OSPF authentication is possible.
- You can use type 0 (none), type 1 (clear text) or type 2 (MD5).
- You enable authentication on a per-interface basis with “ip ospf authentication”.
- Default is none.
- You can change the default authentication type for an area with the “area authentication” command in the router ospf paragraph.
- Keys are configured as interface commands.
- You can use multiple keys; if you do, OSPF will send one copy of the message per key, resulting in multiple messages.
- You can create an OSPF stub router, which is not the same as a stub area. Conceptually similar, but not the same. A stub router is expected to be a network endpoint solely – not a transit router. The stub router is only going to forward packets destined for locally attached networks.
Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks