RIP

-> it is a Distance Vector protocol and designed for use on smaller networks.
-> Bellman-Ford Distance Vector algorithm to determine the best “path” to a particular destination.
-> RIP supports IP and IPX routing.
-> RIP routes have an administrative distance of 120.
-> RIP utilizes UDP port 520.
-> RIP has a maximum hopcount of 15 hops.

Operation of RIP:
-> A Request message is used to ask neighboring routers to send an update. A Response message carries the update.
-> On startup, RIP broadcasts a packet carrying a Request message out each RIP-enabled interface. The RIP process then enters a loop,
listening for RIP Request or Response messages from other routers. Neighbors receiving the Request send a Response containing their route table.
i) ‘A’ receives routing talbe from ‘C’.
To      Cost
B          2

ii). ‘A’ modifies with next column + added metric.
To     Cost    Next
B         4           C

iii). ‘A’ compares routing table with old one.
To    Cost     Next
B         5            –

-> If a particular route entry included in the update is new, it is entered into the route table along with the address of the advertising router, which is read from the source address field of the update packet.
-> If the next-node entry is different, the receiving node chooses the row with smaller cost. if there is a tie, old one kept.
-> if next-node entry is same, the receiving node chooses the new row. ( the advertised hop count is higher than the recorded hop count, the route will be marked as unreachable for a specified holddown period. If at the end of that time the same neighbor is still advertising the higher hop count, the new metric will be accepted.)

-> After start up, the router gratuitously sends a Response message out every RIP-enabled interface every 30 seconds, on average. The Response message, or update, contains the router’s full route table with the exception of entries suppressed by the split horizon rule.
-> The destination address of the update is the all-hosts broadcast 255.255.255.255

-> A triggered update occurs whenever the metric for a route is changed and, unlike regularly scheduled updates, might include only the entry or entries that changed.
Also unlike regular updates, a triggered update does not cause the receiving router to reset its update timer; if it did, a topology change could cause many routers to reset at the same time and thus cause the periodic updates to become synchronized.
-> To avoid a “storm” of triggered updates after a topology change, another timer is employed. When a triggered update is transmitted, this timer is randomly set between one and five seconds; subsequent triggered updates cannot be sent until the timer expires.

Request message:
-> A RIP Request message might request either a full route table or information on specific routes only. When requesting for full route table, in Request message will address family identifier is set to zero, the address is all zeros (0.0.0.0), and the metric is 16. A device receiving such a request responds by unicasting its full route table to the requesting address,

-> broadcasts for RIPv1, multicast for RIPv2.
-> Sent by routers which have just come up and seeking to fill in their routing tables.

Response Message:
-> A Response can be received for one of several different reasons.
*response to a specific query
*regular update (unsolicited response)
*triggered update caused by a route change.
-> Some diagnostic processes might need to know information about a specific route or routes. In this case, a Request message might be sent with entries specifying the addresses in question. A device receiving this request will process the entries one by one, building a Response message from the Request message. If the device has an entry in its route table corresponding to an address in the request, it will enter the metric of its own route entry into the metric field. If not, the metric field will be set to 16. The response will tell exactly what the router “knows,” with no consideration given to split horizon or boundary summarization.
Timers:
-> Hold down timer:
*180 sec.
*This sets the amount of time during which the specific route is not updated by any router.
*Routes will enter into the holddown state when an update packet is received that indicated the route is unreachable. This continues either until an update packet is received with a better metric or until the holddown timer expires.
*A route will enter a hold-down state for one of three reasons:
• The invalid timer has expired.
• An update has been received from another router, marking that route with a metric of 16 (unreachable).
• An update from another router, marking that route with a higher metric than what is currently in the routing table (this is to prevent loops).

-> expiration timer / invalid timer:
*distance vector protocols use to limit the amount of time a route can stay in a route table without being updated.
*The Cisco IOS calls it the invalid timer.
*The expiration timer is initialized to 180 seconds whenever a new route is established and is reset to the initial value whenever an update is heard for that route.
*If an update for a route is not heard within that 180 seconds (six update periods), the hop count for the route is changed to 16, marking the route as unreachable.

-> the garbage collection / flush timer:
*it is set to 240 seconds (invlaid time + 60 se).
*The route will be advertised with the unreachable metric until the garbage collection timer expires, at which time the route will be removed from the route table.

-> This command applies to the entire RIP process. If the timing of one router is changed, the timing of all the routers in the RIP domain must be changed.
Therefore, these timers should not be changed from their default values without a specific, carefully considered reason.

Problem and Solution:
1.Two node loop instability
[X]–[A]—[B]
Link b/w X and A broken. A updates link failure. If A send its updated table to B, all will be fine. But if B sends before A, A updates as per B’s table to reach X. Now A sends routing table to B. B again sends back updated table to A with increased cost. So cost keeps going on.

Solutions:
i. defining infinity . 16 as infinity. so cannot be used in large systems.
ii.split horizon. after x link broken. (B sends before A) node does not advertise a route that received from a node to same node. so in 1st update itself system became stable. as B does not send route received from A to A, it may be because of split horizen or B didnt receive any route from A.
iii.split horizon & poison reverse: B can send a route that received from node A with infinity as distance.

2. Three-node instability
[X]—-[A]–[B]
|    |
|    |
[C]—|
after x link broken A sends to B & C. packet to C last. after some time C send old route of  x to B but wont send to A as that route received from A. B sends to A. after update of A  sends to C. loop continues.

Hints:
-> a network consist of mixed protocols, RIP is suitable for that.
-> it uses static metric

Equal cost Load balancing:
-> If more than one route exists to the same destination with equal hop counts, equal-cost load balancing will be performed.
eg:
R    10.10.0.0 [120/3] via 10.5.5.1, 00:00:20, Serial1
[120/3] via 10.1.1.1, 00:00:21, Ethernet0
R    10.11.0.0 [120/3] via 10.5.5.1, 00:00:21, Serial1
[120/3] via 10.1.1.1, 00:00:21, Ethernet0
-> load-balancing will occur over S1 and E0 for destination 10.10.0.0
-> type of load-balancing (i.e. per packet or per destination) depends on the switching mechanism deployed on the router.
-> RIP uses a round-robin system of load-balancing between equal metric routes, which can lead to pinhole congestion.
Pinhole congestion:
For example, two paths might exist to a particular destination, one going through a 9600 baud link, the other via a T1. If the metric (hop count) is equal, RIP will load-balance, sending an equal amount of traffic down the 9600 baud link and the T1. This will (obviously) cause the slower link to become congested.
-> This is because RIP uses only hop count to calculate route, not considering link state (e.g., bandwith).
-> solution- use equal lines, or use ospf (it calculate routes based on link state).

Auto summarization:
-> RIP v1 always uses automatic summarization.
-> The default behavior of RIP v2 is to summarize at network boundaries the same as RIP v1.
eg:

10.1.5.1/16        10.3.5.1/16         10.3.5.2/16
—————[A]————————————-[B]—
-> subnets are contiguous (that is, they belong to the same major network 10.0.0.0/8), and use the same subnet mask.
-> Router A sends a RIPv1 update to Router B.
-> because the 10.3.0.0 network is in the same major network as the 10.1.0.0 network, it will not summarize the address. so route entry will be 10.1.0.0
-> Router B will accept this routing update, and realize that the interface receiving the update (Serial0) belongs to the same major network as the route entry of 10.1.0.0. It will then apply the subnet mask of its Serial0 interface to this route entry.

10.1.5.1/16        192.168.123.1/24
—————[D1]————————-
-> networks are no longer contiguous.
-> Router A will consider itself a border router, as the 10.1.0.0 and 192.168.123.0 networks do not belong to the same major network.
-> Router A will summarize the 10.1.0.0/16 network to its classful boundary of 10.0.0.0/8. So route entry will be 10.0.0.0
-> does not have a directly connected interface in the 10.x.x.x scheme. Thus, it has no subnet mask to apply to this route

-> by default, RIPv2 will summarize unless you disable auto summarization.
-> In RIPv2 with no auto summarize, Router A will send an update that includes both the subnetted network (10.1.0.0) and its subnet mask (255.255.0.0).

Packet Formats:
RIPv1:
-> Uses Distance Vector protocol.
-> Host uses Passive mode. do not send out routes.
-> Uses UDP, port 520.
-> RIP packets do not leave LAN.
-> When using RIPv1, networks must be contiguous, and subnets of a major network must be configured with identical subnet masks. Otherwise, route table inconsistencies
(or worse) will occur.
-> sends updates as broadcasts to address 255.255.255.255

Packet Format:
-> Command:
* 1 byte.
* 1 for request, 2 for response,

-> Version:
* 1 byte
* 1 for RIPv1, 2 for RIPv2.

-> Unused:
* 2 byte
* set to all 0.

-> Address family Identifier:
* 2 byte
* identifying the protocol family. set to 2 for IP.
* it is also used while reqesting for full routing table information. that time set to 0 (zero).

-> Unused:
* 2 byte
* set to all 0.

-> IP address:
* 4 byte
* address of the destination of the route.
* General RIP Request, the IP Address is set to 0.0.0.0.

-> Unused:
* 4 byte
* set to all 0.

-> Unused:
* 4 byte
* set to all 0.

-> Metric:
* 4 byte
* a hop count between 1 and 16.

-> the initial portion of the message is 4 octets, and each route entry is 20 octets. Therefore, the maximum message size is 4 + (25 x 20) = 504 octets. Including an eight-byte UDP header will make the maximum RIP datagram size (not including the IP header) 512 octets.

Disadvantage:
-> RIPv1 packet carries 25 route entries.
-> entire table broad casted at 30 sec.
-> Bandwidth intensive.
-> slow convergence.
-> max 15 hops.

RIPv2:
-> compatible with RIPv1.
-> Added feature compare with RIPv1.
i). Authentication.
ii) subnet mask,
iii) Next hop.
iv) Route tag.
-> RIPv2 (RFC 2543) is classless, include the subnet mask with its routing table updates.
-> VLSMs, allowing discontiguous networks and varying subnet masks to exist.
-> It multicast to IP address 224.0.0.9, MAc= 01:00:5e:_:_:_ (from IP address). so non-rip nodes wont get disturbance.
*take last 23 bits from IP address’s binary form. 0000000:00000000:00001001
*Prepend a 0 to the last 23 – so this becomes :  00000000.00000000.00001001
*Convert this to hex which is 00:00:09.
*Prepend 01:00:5e so this becomes 01:00:5e:00:00:09
-> The use of multicasted announcements is optional. The broadcasting of RIP v2 announcements is also supported.
-> RIPv2 packet carries 25 route entries. With authentication, the maximum number of entries a single update can carry is reduced to 24.

Packet format:
-> Command:
* 1 byte.
* 1 for request, 2 for response,

-> Version:
* 1 byte
* 1 for RIPv1, 2 for RIPv2.

-> Unused:
* 2 byte
* set to all 0.

-> Address family Identifier:
* 2 byte
* identifying the protocol family. set to 2 for IP.
* it is also used while reqesting for full routing table information. that time set to 0 (zero).

-> Route Tag:
* 2 byte
* to distinguish routes that were RIP-based routes (internal to the RIP environment) from non-RIP routes (external to the RIP environment).
* The Route Tag is configurable on routers that can support multiple routing protocols..

-> IP address:
* 4 byte
* address of the destination of the route.
* General RIP Request, the IP Address is set to 0.0.0.0.

-> Subnet Mask:
* 4 byte
* it contains the subnet mask (also known as a network mask) of the network ID in the IP Address field.

-> Next Hop:
* 4 byte
* contains the forwarding IP address also known as the gateway address.
* If it is set to 0.0.0.0, the forwarding IP address (the next hop) for the route is assumed to be the source IP address of the route announcement.

-> Metric:
* 4 byte
* a hop count between 1 and 16.

Authentication:
-> it uses the first route entry in the RIP message to store authentication information.
-> To indicate authentication, the Family Identifier field is set to 0xFF-FF.
-> The Authentication Type field (normally used as the Route Tag field for a route) indicates the type of authentication being used.
Simple Password:
-> Command:
* 1 byte.
* 1 for request, 2 for response,

-> Version:
* 1 byte
* 1 for RIPv1, 2 for RIPv2.

-> Routing Domain:
* 2 byte
* set to all 0.

-> Address family Identifier:
* 2 byte
* identifying the protocol family. set to 2 for IP.
* it is also used while reqesting for full routing table information. that time set to 0 (zero).

-> Route Tag:
* 2 byte
* to distinguish routes that were RIP-based routes (internal to the RIP environment) from non-RIP routes (external to the RIP environment).
* The Route Tag is configurable on routers that can support multiple routing protocols..

-> IP address:
* 4 byte
* address of the destination of the route.
* General RIP Request, the IP Address is set to 0.0.0.0.

-> Subnet Mask:
* 4 byte
* it contains the subnet mask (also known as a network mask) of the network ID in the IP Address field.

-> Next Hop:
* 4 byte
* contains the forwarding IP address also known as the gateway address.
* If it is set to 0.0.0.0, the forwarding IP address (the next hop) for the route is assumed to be the source IP address of the route announcement.

-> Metric:
* 4 byte
* a hop count between 1 and 16.

-> Simple password authentication uses the Authentication Type value of 0x00-01.
-> next 16 bytes after the Authentication Type are used to store the authentication value.
-> For simple password authentication, the 16-byte Authentication Value field stores the left-justified, null-padded, case-sensitive, clear-text password.
-> RIPv1 system would skip this first route entry because it would belong to an address family other than IP, and proceed with the 24 remaining entries.

-> router (RIPv2 + no auth) will accept RIPv1 and unauthenticated RIPv2 messages,discard the authenticated RIPv2 messages.
-> router (RIPv2 + auth) will accept RIPv1 messages and RIPv2 messages that pass authentication, discard the unauthenticated and failed authentication RIPv2 messages.

Mixed RIP v1 and RIP v2 Environments:
-> If RIP v2 routers are on the same network as RIP v1 routers, the RIP v2 router interface must be configured to broadcast its announcements. Multicasted RIPv2 announcements are not processed by the RIP v1 routers.