Sunday, May 18, 2014

Routing Information Protocol – RIP



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
  1. 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)
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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.
  7. 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
no auto-summary
network 10.0.0.0
network 11.0.0.0
exit

RIPv1 configuration for remote router.
en
configuration t
router rip
version 1
no auto-summary
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#
 

* 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.

2 comments:

  1. nice.. very well explained... looking forward to next one

    ReplyDelete
    Replies
    1. Thanks bro !!
      stay tuned stay tuned lot more to come .... :)

      Delete