Routing Information Protocol – RIP
In this tutorial
Introduction
to routing information protocol – RIP
RIP
– operation and features
Avoiding
routing loops
RIPv1
– RFC 1058
RIPv2
– RFC 2453
Configuration for RIP on Cisco
and Juniper.
Limitations
Introduction to Routing Information Protocol – RIP
Routing
Information Protocol, abbreviated as RIP is The Most Basic, One of The Oldest –
distance vector routing protocol. Begin very old and basic, RIP deployment is
shrinking day by day. More advanced protocols such as OSPF are taking the place
of RIP, but as RIP was "The First", we’ll study it to understand the basics of
dynamic routing.
RIP has its roots in early
deployments at Xerox. In the mid-70s Xerox developed a protocol suit called PARC
Universal Protocol (PUP), running on 3Mbps network. PUP was routed by Gateway
Information Protocol (GWINFO). In later stages GWINFO developed into Xerox
Network System Routing Information Protocol and finally into IP – RIP i.e. Routing
information protocol to route IP packets. As a result of its simplicity and
popularity RIP was standardized in year 1988 under RFC1058 – RIPv1.
BSD – UNIX hosts also
implement RIP in a demon called route-d: pronounced as “route-dee”. Route-d
demon is available in 4.3 release of BSD.
RIP – operation and features
This protocol is most useful
as an Interior Gateway Protocol. RIP is very lightweight, dynamic routing
protocol that uses distance vector, Bellman-Ford-Fulkerson algorithm to compute
shortest path. RIP was designed to work with small and linear networks with
homogeneous links.
RIP defines two types of
messages: Request and Response. All the RIP messages or datagrams are sent
using UDP – User Datagram protocol with both, source and destination port set
to 520.
RIP can work with class-full
and class-less both types of networks, RIPv1 supports class-full networks and
RIPv2 supports class-less networks. (i.e. RIPv2 supports CIDR – Classless
Inter-Domain Routing).
RIP routers exchange the
messages with RIP neighbours. (Neighbours means directly connected remote
routers running similar routing entity, here RIP neighbour means directly
connected remote routers running RIP). These messages may contain messages type
or command, RIP version, IP address family identifier, network address, subnet
mask, metric, authentication passwords etc. depending on which version of RIP,
router is running. We’ll take a look at RIP packet format in upcoming sections.
RIP uses hop count as its
metric (i.e. hops is the only hope for RIP in its all the versions). Metric is
the property of routing protocol used to determine, which particular route
should be preferred over others, when two or more routes to same destination prefix
are learned by same routing protocol. In case of RIP each hop in the path
increments the hop count typically by 1.
RIPv1 broadcasts messages i.e.
sends messages to broadcast IP address (255.255.255.255). On the other hand
RIPv2 multicasts messages i.e. sends messages to multicast IP address
(244.0.0.9). (In case of Ethernet IP broadcast will be converted to L2/Ethernet
broadcast and IP multicast to L2/Ethernet multicast.)
RIP routers send routing
updates/messages at regular intervals of 30 seconds or when requested by
neighbour.
RIP implements counting to
infinity matric, split horizon and split horizon with poisoned reversed
techniques to avoid routing loops.
RIP routers can transmit and receive two types
of messages from their neighbour, request messages and response messages.
Request message
Local router can receive RIP request message
from remote RIP neighbour, requesting full routing table or specific route
only. For full routing table request, remote RIP neighbour must set address
family identifier to zero (AFI = 0) and metric to 16. Local router receiving
this request will respond to remote RIP neighbour by a unicasting its full
routing table. (Request message can be observed when router boots up or
resetting the routing process, in this case router will send request messages
to populate its routing table as quickly as possible.) The request is processed
entry by entry by local router.
RIP version 1 packet format
.
.
RIPv1 the packet format is
shown in figure above. Each RIPv1 datagram contains command, version number,
address family identifier, destination prefix, metric and zero fields. The
portion of the datagram from address family identifier through metric (shown in
RED block) can appear up to 25 times. The maximum size of an IP RIP packet is
512 bytes.
(Calculation for bytes:
Command = 1 byte
Version = 1 byte
Unused = 2 bytes
A. F. I. = 2 bytes X
25
Unused = 2 bytes X 25
IP Address = 4 bytes X 25
Unused = 8 bytes X 25
Metric = 4 bytes X 25
TOTAL = 504 bytes < 512 bytes)
Command:
It is 8 bit field and indicates
type of message.
1 = Request, request for router
to send full or partial routing table.
2 = Response, response from
router which has full or partial routing table.
3 = Traceon, this command are
to be ignored.
4 = Traceoff, this command are
to be ignored.
5 = Reserved, this value is
used by Sun Microsystems for its own purposes, can be ignored.
Address Family identifier:
It is used to identify the type
of network layer protocol being routed using RIPv1. This value is fixed to 2 in
the case of IP – RIP (RIP routing IP – network layer protocol).
There is a special case of AFI
set to 0 – zero (meaning unspecified) and metric set to 16 (indicating
destination network unreachable or infinity hops). This datagram is treated as request
to send the entire routing table, in this case local router will send entire routing
table to requesting remote router.
Must be zero:
These fields are unused in RIPv1,
so they must be set to 0 – zero.
IP Address / Network address:
It contains destination prefix
and has 32 bit space in RIP datagram. As RIPv1 supports classful (i.e FLSM Networks
– Fixed Length Subnet Mask Networks) addressing scheme only, the destination prefix
or networks advertised by RIPv1 will be classful.
Metric:
It represents the number of
hops in the case of RIP, though its 32 bit field – the valid values for RIP
routes are 1 to 16 with 16 representing destination network unreachable or infinity
hops.
RIP version 2 packet format:
RIPv2
the packet format is shown in figure above. Each RIPv2 datagram contains
command, version number, address family identifier, route target, destination
prefix, subnet mask, next hop metric and zero fields. Let’s have a look at “What’s
new?” in in RIP version 2.
Route Tag:
It is used to mark route as "internal"
RIP routes (routes within RIP domain) or "external" RIP routes, which
may have been imported from BGP. This field is important in case of
redistribution (i.e. importing and exporting – To and From RIPv2).
Address Family identifier:
It is almost same as RIPv1, the
only difference is if value of AFI set to 0xFFFF.
If AFI is set to 0xFFFF for
the first (and only the first) entry in datagram then, it indicates that the
entry contains authentication information. RFC – 2453 only supports plain text
password only. For authentication (plain text password) purpose 20 bytes will
be used, in this case RIPv2 datagram can carry only 24 route entries per datagram.
RFC – 2082, enables MD5 authentication
support for RIPv2. In case of MD5 authentication, 40 bytes will be used for authentication
purpose and RIPv2 datagram can carry only 23 route entries per such datagram.
Subnet Mask:
RIPv2 supports class-less
networks. (i.e. RIPv2 supports CIDR – Classless Inter-Domain Routing). This contains
the subnet mask of the destination prefix specified in “IP Address”, it can be
zero if no subnet mask info is specified.
Next Hop:
Next hop (better to say – the immediate
next hop) indicates, IP address to which packets to the destination prefix specified
by the route entry should be forwarded. If this value is set to 0.0.0.0 then it
indicates that routing should be done via originator of the RIPv2 advertisement.
RIP – Limitations
- VLSM support: RIPv1 does not have support for VLSM networks (i.e. it’s not CIDR enabled). This limitation was solved with the development of RIPv2 supporting VLSM (i.e. CIDR enabled)
- Route advertisements: RIPv1 send routing advertisements as broadcast (i.e. on IP address 255.255.255.255). As result of broadcast, non-RIP entities also receive such packets and process it, which costs for resources, memory and CPU utilization. This problem was solved with RIPv2 sending routing advertisements on multicast address 244.0.0.9.
- Hop count limit & Scalability: RIPv1 and RIPv2 both do not scale good for large networks. The valid hop count for RIP (both v1 and v2) is from 0 to 15, value of hop count = 16 is considered as destinations network unreachable.
- Slow convergence: Mechanism of sending routing updates in RIP is based on the timers and update will be sent after stipulated time. In worst case it may takes several minutes to converge network.
- Route table synchronization: Even though routers are started arbitrarily, RIP timers tend to synchronize over the period of time. This results in the burst of RIP updates every few seconds which costs for resources like bandwidth, memory and CPU utilization. Equipment manufacturers solved this problem with introduction of randomization in RIP timers (Although RFCs does not provide any details on this).
- Suboptimal path routing: RIP routing decisions depends on hops count i.e. RIP uses hop count as it’s metric. It does not consider bandwidth, delay, frame loss or congestion in network which may result in suboptimal path routing.
- Security problems: RIPv1 does not have any authentication feature. This clearly means there is no way routing entity can verify the received routers with response messages. This limitation was solved with RIPv2 supporting authentication (RFC 2082)
Configuring RIPv1 on Cisco 7200
With ref to network topology above, we have total 3
networks:
1. 10.0.0.0/8
network between local and remote router.
2. 11.0.0.0/8
network, configured as loopback interface IP address (11.11.11.11/8) on local
router.
3. 22.0.0.0/8
network, configured as loopback interface IP address (22.22.22.22/8) on remote
router.
RIPv1 configuration for local router.
en
configuration t
router rip
version 1
router rip
version 1
no auto-summary
network 10.0.0.0
network 11.0.0.0
network 10.0.0.0
network 11.0.0.0
exit
RIPv1 configuration for remote router.
en
configuration t
router rip
version 1
router rip
version 1
no auto-summary
network 10.0.0.0
network 22.0.0.0
network 10.0.0.0
network 22.0.0.0
exit
Routes on local router.
LOCAL#show ip route
# ---- Output truncated ---- #
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/8 is directly connected, FastEthernet0/0
L 10.0.0.1/32 is directly connected, FastEthernet0/0
11.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 11.0.0.0/8 is directly connected, Loopback100
L 11.11.11.11/32 is directly connected, Loopback100
R 22.0.0.0/8 [120/1] via 10.0.0.2, 00:00:00, FastEthernet0/0
LOCAL#
Routes on remote router.
REMOTE#show ip route
# ---- Output truncated ---- #
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/8 is directly connected, FastEthernet0/0
L 10.0.0.2/32 is directly connected, FastEthernet0/0
R 11.0.0.0/8 [120/1] via 10.0.0.1, 00:00:24, FastEthernet0/0
22.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 22.0.0.0/8 is directly connected, Loopback1
L 22.22.22.22/32 is directly connected, Loopback1
REMOTE#
Routes on local router.
LOCAL#show ip route
# ---- Output truncated ---- #
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/8 is directly connected, FastEthernet0/0
L 10.0.0.1/32 is directly connected, FastEthernet0/0
11.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 11.0.0.0/8 is directly connected, Loopback100
L 11.11.11.11/32 is directly connected, Loopback100
R 22.0.0.0/8 [120/1] via 10.0.0.2, 00:00:00, FastEthernet0/0
LOCAL#
Routes on remote router.
REMOTE#show ip route
# ---- Output truncated ---- #
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/8 is directly connected, FastEthernet0/0
L 10.0.0.2/32 is directly connected, FastEthernet0/0
R 11.0.0.0/8 [120/1] via 10.0.0.1, 00:00:24, FastEthernet0/0
22.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 22.0.0.0/8 is directly connected, Loopback1
L 22.22.22.22/32 is directly connected, Loopback1
REMOTE#
* stay tuned stay tuned I'll keep updating this blog page daily
Disclaimer
Information above is either from RFCs or it's Googled. This blog is result of my
enthusiasm, desire and hard work to lean networking and share my leanings. Most
of the times I’ll be using GNS3 network simulator. All I've here is collection
of my findings, thanks to Google. Please do not ask for any of the software
from CISCO/Juniper, it's better to Google it and try your luck.