Partager via

RIP-for-IP design considerations

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

RIP-for-IP design considerations

To prevent problems, you should consider the following design issues before you implement RIP for IP.

Decreased diameter of 14 routers

The maximum diameter of RIP internetworks is 15 routers. The diameter is a measure of the size of an internetwork in terms of hops or other metrics. However, the server running Routing and Remote Access 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 a server running Routing and Remote Access 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 servers running Routing and Remote Access have a maximum physical diameter of 14 routers.

RIP costs

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 may lead to undesired routing behavior. For example, if two sites were connected together by using a T1 link and a lower-speed satellite link as a backup, both links are considered 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 goes down, the satellite link is chosen as the next best route.

If you are using 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.

Mixed RIP version 1 and RIP version 2 environments

For maximum flexibility, you should 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) implementations. If you have support for CIDR and VLSM in one part of your internetwork but not another, you may 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 server running Routing and Remote Access to advertise by using either RIP v1 broadcasts or RIP v2 broadcasts and accept either RIP v1 or RIP v2 announcements.

RIP version 2 authentication

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 networks of your internetwork or you can vary the password for each network.

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 sent by the requesting router is not responded to by the router on the other side of the demand-dial link.

RIP over Frame Relay

Since RIP is primarily a broadcast and multicast-based protocol, you need a special configuration for proper RIP operation over a nonbroadcast 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 servers running Routing and Remote Access. 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).

Single-adapter model

With the single adapter model, also known as the nonbroadcast 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.

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.

Multiple-adapter model

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.

Note

  • The preceding discussion also applies to other nonbroadcast technologies such as X.25 and ATM.

Silent RIP hosts

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.