RIP-for-IP Routed Network Design

Updated: April 30, 2010

Applies To: Windows Server 2008, Windows Server 2008 R2

A RIP-for-IP routed environment is best suited to a small-to-medium-sized, multipath, dynamic IP internetwork:

  • A small-to-medium-sized internetwork is defined as 10 to 50 subnets.

  • Multipath means that there are multiple paths for packets to travel between any two endpoints on the internetwork.

  • Dynamic means that the topology of the internetwork changes over time because networks are added and removed and links occasionally fail and come back up.

Candidates for a RIP-for-IP routed environment include:

  • A medium-sized business.

  • A large branch office or satellite office with multiple networks.

Consider the following design issues before you implement a RIP-for-IP routed environment.

The maximum diameter for internetworks that use RIP is 15 routers. The diameter is a measure of the size of an internetwork in terms of hops or other metrics. However, an RRAS server considers all non-RIP learned routes to be at a fixed hop count of 2. Static routes — even static routes for directly connected networks — are considered non-RIP learned routes. When an RRAS server acting as a RIP router advertises its directly connected networks, it advertises them at a hop count of 2 even though there is only one physical router to cross. Therefore, a RIP-based internetwork that uses RRAS servers has a maximum physical diameter of 14 routers.

RIP uses the hop count as a metric to determine the best route. Using the number of routers to cross as the basis for selecting the best route can lead to undesired routing behavior. For example, if two sites are connected by using a T1 link and a lower-speed satellite link as a backup, both links are assigned the same metric. When the router is given a choice between two routes of the same lowest metric (hop count), the router is free to choose between them.

If the router chooses the satellite link, then the slower backup link is used rather than the higher bandwidth link. To prevent the satellite link from being chosen, you can assign a custom cost to the satellite interface. For example, if you assign a cost of 2 to the satellite interface (rather than the default of 1), then the best route is always the T1 link. If the T1 link fails, the satellite link is chosen as the next best route.

If you use custom costs to indicate link speed, delay, or reliability factors, ensure that the accumulated costs (hop counts) between any two endpoints on the internetwork do not exceed 15.

For maximum flexibility, use RIP version 2 in your RIP-for-IP internetwork. If there are routers in your internetwork that do not support RIP version 2, you can use a mixed environment of RIP v1 and RIP v2. However, RIP v1 does not support classless interdomain routing (CIDR) or variable-length subnet masks (VLSM). If you have support for CIDR and VLSM in one part of your internetwork but not another, you might experience routing problems.

If a network is using a mixture of RIP v1 and RIP v2 routers, then you must configure the interfaces of the RRAS server to advertise by using either RIP v1 broadcasts or RIP v2 broadcasts and accept either RIP v1 or RIP v2 announcements.

If you use RIP version 2 simple password authentication, then you must configure all of the RIP v2 interfaces on the same network with the same case-sensitive password. You can use the same password for all the subnets of your internetwork or you can vary the password for each subnet.

If you use RIP to perform auto-static updates across demand-dial links, then you must configure each demand-dial interface to use RIP v2 multicast announcements and to accept RIP v2 announcements. Otherwise, the RIP request for routes is discarded by the router on the other side of the demand-dial link.

Because RIP is primarily a broadcast- and multicast-based protocol, you need a special configuration for proper RIP operation over a non-broadcast technology such as Frame Relay. How RIP is configured for Frame Relay depends on how the Frame Relay virtual circuits appear as network interfaces on RRAS servers. Either the Frame Relay adapter appears as a single adapter for all the virtual circuits (single adapter model), or each virtual circuit appears as a separate adapter (multiple adapter model).

With the single adapter model, also known as the non-broadcast multiple access (NBMA) model, the network of the Frame Relay service provider (also known as the Frame Relay cloud) is treated as an IP network and the endpoints are assigned IP addresses from a designated IP network ID. To ensure that RIP traffic is received by all of the appropriate endpoints on the cloud, you must configure the Frame Relay interface to unicast its RIP announcements to all of the appropriate endpoints. You do this by configuring RIP neighbors. For more information about configuring RIP neighbors, see Add a Unicast Neighbor in the RRAS Deployment Guide.

Also, in a spoke-and-hub Frame Relay topology, the Frame Relay interface for the hub router must have split-horizon processing disabled. Otherwise, the spoke routers never receive each other's routes. For more information, see Set Split-horizon Processing in the RRAS Deployment Guide.

With the multiple adapter model, each Frame Relay virtual circuit appears as a point-to-point link with its own network ID, and the endpoints are assigned IP addresses from a designated IP network ID. Because each virtual circuit is its own point-to-point connection, you can either broadcast (assuming both endpoints are on the same IP network ID) or multicast RIP announcements.

A silent RIP host (a nonrouter) processes received RIP announcements but does not make RIP announcements. The processed RIP announcements are used to build the routing table for the host. You do not need to configure silent RIP hosts with a default gateway. Silent RIP is commonly used in UNIX environments. If there are silent RIP hosts on a network, you must determine which version of RIP they support. If the silent RIP hosts only support RIP v1, then you must use RIP v1 on the network for that host.

Community Additions