RIP rocks in low-end hub-and-spoke networks

Yesterday I’ve introduced a scenario where RIP would (in my opinion) work much better than OSPF. If you were not persuaded by the “management-level” arguments, let’s focus on the technical details (but make sure you read the scenario first).

All you ever want to advertise to the remote sites in this design is the default route (or a network-wide summary). Alternatively, you might want to advertise only a route to a central LAN or server. Both requirements are easily met with RIP per-interface output filters. Doing something similar with OSPF is close to impossible. Either you place every remote site into a separate OSPF area (don’t even think about doing it; there could be hundreds of sites) or the routes within an area will leak between the remote sites.

RIP is also more stable than OSPF in this setup. Whenever a remote site disappears, the change in the OSPF area is unnecessarily propagated to all other remote sites in the same area. RIP doesn’t react at all; the output route filter at the central site stops all unnecessary updates.

As you know, OSPF requires hello packets and adjacencies to work properly. The central hub router must therefore track the adjacency states of hundreds of neighbors. When using RIP, the central router couldn’t care less … it sends out its routes every so often, collects whatever comes back and reports when a new remote route is received or an old one disappears.

7 comments:

  1. I'd much rather use EIGRP stub

    ReplyDelete
  2. EIGRP stub feature does *NOT* prevent hub router from advertising all information to spokes -- you have to use distribute-list or summarization up to 0/0. I'd choose OSPF w/ "ip ospf database-filter all out" to reduce flooding in hub-n-spoke environment.

    ReplyDelete
  3. @Michael: you might not have EIGRP on remote (low-end, low-cost) routers.

    @Uri: RIP has exactly the same configuration overhead as EIGRP; you have to configure summary or default route advertisement.

    ReplyDelete
  4. Sure.. It does have the same overhead. Btw, living in the all-cisco world may be we should start "ODR vs proto-X" flame?

    http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080093fde.shtml

    :)

    ReplyDelete
  5. In a very large (hundreds of spokes) dual-homed remote RIP environment, what's the convergence time for a primary hub failure? I poked around looking for information on this, but didn't find anything.

    ReplyDelete
  6. @uri: Don't worry, I could start the ODR religious war ... I just need to figure out a good provocative intro.

    @js: regardless of the number of spoke routers, the convergence time always depends on RIP timers.

    You might have interesting problems sending a huge number of RIP updates from the hub router, though.

    ReplyDelete
  7. I find eigrp stub is an elegant solution in a large hub and spoke network.

    Used with a single default distribution filter from the hub makes for a very small config and also allows the ability to leak certain routes beyond a default if desired to all spokes.

    ODR is also a low overhead, small config, but does not allow the ability to leak routes to the stubs (some would also argue ODR is not a routing protocol as it leverages CDP). It is also proprietary.

    For example, I blackhole host routes at the ingress by advertising them to the spokes in concert with uRPF.

    I'm not certain that ospf could perform as well in a large hub/spoke along with those capabilities.

    So I also think that RIPv2 could be a better fit in a large hub and spoke, providing a small and flexible config. (and then redistributing from the hub in/out of the core IGP)
    Compared to EIGRP, the downside is the convergence time and periodic flooding. The upside is it is an open protocol.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.