From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 10

439 Words. Plan about 3 minute(s) to read this.

Building on the concepts in the last entry about DR’s and BDR’s, how then do things change in different network topologies?

  • Routers on either side of point-to-point links don’t bother with DR’s or BDR’s. Why should they? They’re implicitly the only possible devices on the segment.
  • With NBMA network, there are a number of potential scenarios, where you may or may not desire the LSA exchange efficiencies brought about by DRs. Depending on your specific requirements, you can define router interfaces as being on of several different OSPF network types. The network type you choose will govern the following:
    • Whether the router will try to elect a DR.
    • Whether the router has to learn about a neighbor through static configuration as opposed to the more typical Hellos.
    • Whether more than 2 neighbors will be allowed on a given subnet.
  • Network types and parameters:
    • Broadcast: Uses DR, Hello interval=10, No neighbor command required, More than 2 allowed.
    • Point-to-point: No DR, Hello interval=10, No neighbor command required, More than 2 NOT allowed.
    • Nonbroadcast: Uses DR, Hello interval=30, Neighbor command required, More than 2 allowed.
    • Point to multipoint: No DR, Hello interval=30, No neighbor command required, More than 2 allowed.
    • Point to multipoint nonbroadcast: No DR, Hello interval=30, Neighbor command required, More than 2 allowed.
    • Loopback: No DR, Hello interval=N/A, Neighbor command=N/A, More than 2 NOT allowed.
  • Use caution when configuring various OSPF network types over the various frame-relay network types you might encounter.
    • Remember that your timers must match, but the defaults are different. So if your potential neighbors are configured with different OSPF network types, you can run into a problem.
    • Your OSPF neighbors might be confused if some of them believe in a DR, and others do not. Everyone in the cloud should be expecting a DR, or not, for your neighbor relationships to form as you would expect and next-hops to be reachable.
    • If you choose to go with a DR, then the DR and BDR need to have a PVC to all other routers in the subnet. The DR and/or BDR are expected to exchange DD’s and acks with all other OSPF routers. Without the PVC in place, this process will fall apart.
    • You aren’t obligated to statically configure “neighbor” statements on both routes – one will suffice. But in the interest of self-documentation, it’s a best practice to do it on both.

The rest of this section of the book goes into an example of a partially meshed network, and shows various router outputs for OSPF routers attached to the frame-cloud. It’s an illustration of what we’ve already discussed, so I’m choosing to move on for time’s sake.