Lecture #7 - Routing Information Protocol - Part 1

RIPv1: A Distance Vector Interior Routing Protocol

The Routing Information Protocol or RIP is one of the oldest distance vector routing protocols that is still in use. RIP version 1 (RIPv1) is destined as an interior routing protocol and is defined in RFC1058.

RIPv1 is a classful routing protocol, hence cannot function with CIDR based networks. However, a number of extensions were added in version 2 of the protocol (RIPv2), turning it into a classless routing protocol (whilst adding a number of other features/improvements). We will return to RIPv2 in the following lecture. A third variant - RIPng - exists to support IPv6 based networks, which we will address later in the subject.

Since RIPv1 is a classful routing protocol it expects to operate with classful networks and subnet masks. This will quickly become evident when working with RIPv1 and routers that are configured with no ip classless.

RIPv1 Operation

Since RIPv1 is a distance vector based routing protocol, its operation is fairly simple. Two message types are defined - a RIP Request and a RIP Response. A request message solicits an immediate response from neighbouring routers and is sent when RIP is first started on a router. This enables it to quickly populate its routing table without waiting for the next update period. A request may specify a particular network, or simply request the entire routing table.

Response messages simply contain a list of networks which are reachable via the sending router, along with the metric for each network. In the case of RIP, the metric is simply the number of hops to reach the network.

All RIPv1 messages are sent via the use of UDP datagrams, with a source and destination port of 520 (0x0208). The UDP datagram is in turn encapsulated within an IP datagram that is sent to the IPv4 limited broadcast address (255.255.255.255). The exception to this is when a response is sent as an answer to a request message - in this case the IPv4 datagram is sent to the requesting router's IPv4 unicast address and the UDP destination port matches the source port of their request.

Routing-by-Rumour: Gossip Time

Since RIPv1 is a distance vector based routing protocol, it periodically broadcasts a full copy of its routing table to neighbouring routers. By default, RIP will send an update in the form of an unsolicited RIP response message every 30 seconds.

RIP routers typically implement four timers:

1. Update Timer - default of 30 seconds. Sets interval between routing table broadcasts. In order to avoid synchronisation a Cisco router will subtract up to 15% of the update time on a random basis. This results in an update time that ranges between 25.5 and 30 seconds.
2. Invalid Timer - default of 180 seconds (six update periods). Used to expire routes when a update is not received. Reset whenever a valid RIP response is received for this route. If no update is received within this time frame the router considers the route as being invalid and increases the hop-count to 16 (ie. network becomes unreachable).
3. Garbage Collection or Flush Timer - default of 120 seconds (on Cisco IOS this defaults to 60 seconds). When a route is marked as being invalid the router continues to announce the route, however with a metric of 16 hops. When the flush timer expires the route is purged from the routing table and hence no longer announced.
4. Hold Down Timer - many RIP implementations use this timer, however it is not required or specified by RFC1058. When the metric for a route is increased (ie. we receive an update for a route with the same next hop, but with a higher metric) the route is placed into holddown for a default of 180 seconds (six update periods). During this period, any updates for this route are ignored.

Off the Wire

The following is a RIPv1 response message captured "off the wire" from a nearby network, minus the link-level header - the IP and UDP encapsulation however remain intact:

  45c0 0034 0000 0000 0211 a9fd 0a01 03fc
  ffff ffff 0208 0208 0020 0000 0201 0000
  0002 0000 0a01 0100 0000 0000 0000 0000
  0000 0001

Updating our Routing Table

On receipt of a RIP response message:

1. If the destination network is unknown, install the route, providing the hop-count is less than infinity (16 hops).
2. If the destination network is known and the new metric is smaller, install the route.
3. If the destination network is known, the new metric is larger and the next-hop is the same, update the metric.
4. If the destination network is known and the new metric is larger and the next-hop is not the same, ignore the update.
5. If the destination network is known, the new metric is the same and the next-hop is different, RFC 1058 calls for the update to be ignored. Cisco IOS however keeps up to four equal metric paths for load balancing.

Configuring a Router with RIP

Commands to be entered in Configuration Mode:

Configure Interfaces

R1(config)#
R1(config)#interface Ethernet0/0
R1(config-if)#ip address 192.168.1.254 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config-if)#
R1(config)#interface Ethernet1/0
R1(config-if)#ip address 192.168.2.254 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#

Enable IP Routing

R1(config)#ip routing

Enable the RIP Routing Protocol

R1(config)#
R1(config)#router rip
R1(config-router)#network 192.168.1.0
R1(config-router)#network 192.168.4.0
R1(config-router)#exit
R1(config)#

Save Configuration to NVRAM

Back in Privileged Mode:

R1#copy running-config startup-config

Achieving Stability

As discussed in our previous lecture, a number of inherent design flaws in the distance vector routing process can lead to instability and routing loops. RIP implements several techniques in order to combat these issues:

Split Horizon

RIP should implement split horizon in order to reduce the likelihood of "count to infinity" occurring. Simple split horizon works by suppressing information and not advertising routes back to interfaces from which they were learned.

Split Horizon with Poisoned Reverse

Preferably RIP should implement split horizon with poisoned reverse - instead of simply suppressing route advertisements, send them back to where we learned them from, however with a metric of infinity.

Triggered Updates

Instead of waiting for the timed update, RIP routers can broadcast almost immediately when they hear of a change, thus speeding up convergence. This also has the benefit of having routing loops reach 16 hops much faster than they would otherwise, thus removing the loop. Usually, the RIP response message will only include the changed route and not the entire routing table. An additional timer is usually implemented to prevent flooding in the case of route flapping.

Passive RIP

In certain circumstances it is necessary (or preferred) to only listen to RIP messages and not send them - usually this is selected on a per interface basis and is known as being in Passive Mode.

RIP can be instructed to operate passively on an interface via the following commands (entered in Configuration Mode):

R1(config)#router rip
R1(config-router)#passive-interface Ethernet0/0

This will prevent RIP messages from being sent out via the Ethernet0/0 interface, however the router will still process RIP messages received on this interface - preventing this would require a distribute-list (see later lecture).

Adjusting the Metric

Since RIP only uses the hop count as a metric, in a mixed network a wrong routing decision may result (ie. a faster preferred path with more hops will be less preferred over a slower path with less hops). This can be combatted by manually adjusting the metric for specific routes.

This is implemented using an offset-list which links an access list with an interface and metric increment:

R1(config)#access-list 10 permit 192.168.1.0
R1(config)#!
R1(config)#router rip
R1(config-router)#network 192.168.1.0
R1(config-router)#network 192.168.2.0
R1(config-router)#offset-list 10 in 2 Ethernet0/0

This instructs the router to examine all RIP response messages received on Ethernet0/0 - if the response message advertises a route which matches 192.168.1.0 (ie. the permit in the access list) then increment the hop count by 2.

References

RFC1058: Routing Information Protocol

Cisco IOS: Configuring Routing Information Protocol